Маршрутизація coding agent між кількома моделями

Вплив маршрутизації між кількома моделями на coding agent

Маршрутизація між кількома моделями надсилає кожен запит до найдешевшої моделі, яка може його обробити. Для chat-трафіку це працює добре. Для coding agent така схема зазвичай коштує більше, ніж заощаджує, оскільки основну частину вартості agent становить префікс prompt, кешований окремо для кожної моделі, а перемикання моделей знищує цей кеш.

Основне правило цієї статті: між провайдерами слід маршрутизувати заради доступності, між рівнями — заради вартості лише на межі завдань, а для будь-яких agentic-сценаріїв закріплювати одну модель на сесію. Нижче наведено обґрунтування.

Чотири терміни, визначені один раз. Router вибирає модель для кожного запиту. Gateway — це проксі, через який проходить запит; він може також виконувати маршрутизацію, але це не обов’язково. Prompt cache — це сховище провайдера для обробленого префікса prompt, тому наступний запит із тим самим префіксом тарифікується за часткою ціни вхідних даних. KV cache (key value cache) працює за тим самим принципом усередині сервера, яким ви керуєте самостійно.

Чому чат-трафік маршрутизується добре, а трафік агентів — ні

Запит у чаті — це один раунд. Він надходить, класифікується, передається моделі, і модель повертає відповідь. На наступний запит нічого не переноситься. Маршрутизатор може передати одне питання малій моделі, а наступне — великій, і жоден із цих запитів не «знає» про інший. Саме таке навантаження вимірює майже кожен benchmark маршрутизації, і якісні маршрутизатори справді добре з ним працюють.

Раунд агента — це не один запит. Одна інструкція на кшталт «виправте тест, який завершується помилкою» перетворюється на 20–60 API-викликів. Кожен виклик повторно передає весь контекст розмови: системний prompt, усі визначення інструментів, кожен файл, який агент прочитав, і кожен результат виконання команди, який він отримав. Контекст лише збільшується. До 30-го виклику повторюваний префікс може містити десятки тисяч токенів, тоді як справді новий вміст кожного виклику — лише кілька сотень.

Ця структура змінює значення слова «дорогий». У чаті вартість приблизно дорівнює ціні моделі, помноженій на кількість запитів. У циклі агента вартість визначається префіксом, за який стягується плата під час кожного окремого виклику. Увесь подальший матеріал випливає саме з цього факту.

Кеш промпту належить окремій моделі, а агент працює всередині цього кешу

Anthropic встановлює ціну читання з кешу на рівні 0.1 базової ціни вхідних даних, а запису в кеш на п’ять хвилин — на рівні 1.25. Це опубліковані роздрібні ціни станом на August 2026.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

Порівнюйте другий ряд із першим по горизонталі, а не по вертикалі. Читання з кешу для Opus 5 коштує 0.50 доларів за мільйон токенів. Вхідні дані без кешування для Haiku 4.5, найдешевшої моделі в списку, коштують 1.00 доларів. Отже, повторне читання прогрітого префікса на найдорожчій моделі коштує за один вхідний токен менше, ніж одноразове читання того самого префікса на найдешевшій моделі.

Це порівняння руйнує більшість планів маршрутизації. Router, який переміщує роботу «вниз» на нижчий рівень, порівнює роздрібні ціни. Але агент у середині сеансу не платить роздрібну ціну за модель, яку вже використовує. Він платить ціну читання з кешу, а вона вже нижча за ціну вхідних даних без кешування для дешевшої моделі.

Кеші індексуються за хешем префікса промпту та належать окремим моделям. Запит до іншої моделі хешується відносно сховища, яке ще не бачило цього промпту, тому кеш не знаходиться і стягується повна ціна. Кеш також має ієрархічну структуру: спочатку tools, потім system, потім messages. Зміна на будь-якому рівні інвалідовує цей рівень і всі наступні. Тому редагування одного визначення tool видаляє кеш system prompt, розташований після нього. Агенти, які реєструють tools під час виконання, стикаються з цією проблемою навіть без змін у router.

Скільки насправді коштує одне перемикання посеред сесії

Розглянемо сесію зі стабільним префіксом на 40,000 токенів. Це звичайний розмір після того, як агент прочитав кілька файлів. Нижче наведено вартість префікса для одного ходу, розраховану за наведеними вище цінами.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Якщо залишитися на Opus 5 із прогрітим кешем, префікс цього ходу коштує 0.020 доларів. Перший хід після перемикання на Sonnet 5 коштує 0.100 доларів, оскільки в Sonnet немає запису для цього префікса і його потрібно записати. Повернення на Opus 5 коштує 0.250 доларів, оскільки початковий запис вийшов із кешу, поки сесія працювала на іншій моделі.

Отже, перемикання туди й назад оплачує два записи в кеш замість двох читань із кешу. Натомість один хід використовує ціну генерації Sonnet, а не Opus. У блоці з деталями наведено повний розрахунок: економія становить частки цента, а штраф за кеш — десятки центів. Штраф більш ніж на порядок перевищує економію. Він зростає разом із довжиною префікса, тоді як економія не змінюється.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

Формати викликів інструментів відрізняються залежно від провайдера

Агент працює в циклі з викликами інструментів, тому формат виклику має значення, якого він не має в чаті. Messages API від Anthropic повертає блок вмісту tool_use і очікує у відповідь блок tool_result. API, сумісні з OpenAI, повертають масив tool_calls, у якому function.arguments є рядком у форматі JSON, а не вкладеним об’єктом. Шлюз перетворює один формат на інший, і для звичайних викликів це перетворення працює коректно.

Проблеми виникають у граничних випадках. Паралельні виклики інструментів, коли модель надсилає кілька викликів в одній відповіді, у різних системах представлені по-різному та підтримуються неоднаково. Строге дотримання схеми є функцією окремого провайдера, тому модель, яка гарантує аргументи, що відповідають схемі, на одному endpoint, на іншому лише прагне повертати коректні аргументи. Агент бачить цю відмінність як результат інструмента з помилкою аналізу, а потім намагається виправити її, витрачаючи ще один хід. Такі ходи виправлення оплачуються за повною ціною префікса, тому невідповідність форматів відображається і в рахунку, і в транскрипті.

Для self-hosted endpoint це потрібно налаштувати явно. OpenAI-compatible server у vLLM потребує --enable-auto-tool-choice разом із --tool-call-parser, що відповідає сімейству моделі (hermes, mistral, llama3_json та інші), а також chat template, який обробляє повідомлення з роллю tool. Документація vLLM прямо описує обмеження цього підходу: з tool_choice="auto" і без обмеження на строгу схему vLLM вилучає виклики інструментів із необробленого тексту, тому аргументи іноді можуть мати неправильний формат або не відповідати схемі параметрів функції. Вибір неправильного parser для вашої моделі є помилкою конфігурації. Вона проявляється як нездатність агента викликати інструменти, і про це варто знати до того, як ви спрямуєте на цей endpoint network traffic. Тут важлива відмінність між Ollama і vLLM під час самостійного розгортання моделей, оскільки ці системи надають tool calling на різних умовах.

Поведінка змінюється посеред завдання без помилки

Fallback-маршрутизація — це функція, яку найчастіше вмикають випадково. Шлюз налаштовано повторювати запит до іншої моделі, якщо перша повертає обмеження частоти або помилку 5xx, а потім поміщати модель, що не спрацювала, у cooldown на кілька секунд. Для чат-трафіку це саме те, що потрібно. У межах тривалого завдання агента це означає, що другу половину завдання виконано моделлю, яку ви не обирали.

Ніщо не повідомляє про це. Завдання не завершується помилкою, агент не показує попередження, а статус завершення має значення success. У результаті план створює одна модель, а зміни вносить інша. Посеред завдання змінюються стиль і набір типових прийомів. Єдиний надійний сигнал — поле model у журналі запитів шлюзу або в метаданих відповіді. Тому, якщо ви взагалі використовуєте fallback, записуйте це поле для кожного запиту та перевіряйте його, коли результат вас дивує. Налагодження поведінки без інформації про модель, яка створила результат, забирає більше часу, ніж заощадив fallback.

Така сама проблема виникає під час стиснення контексту. Багато агентів узагальнюють довгу історію, викликаючи малу модель. Якщо цей виклик використовує іншу модель або інший системний промпт, він створює власний запис у кеші й не оновлює запис основної сесії. Тому наступний повний запит знову обробляє префікс без кешу. Стиснення заощадило токени, але кеш було втрачено.

Маршрутизаційні накладні витрати реальні, але затримка не є головною проблемою

Маршрутизатори справді виконують додаткову роботу для кожного запиту, і важливо правильно оцінювати її обсяг. DigitalOcean повідомляє, що їхня модель Arch-Router визначає намір маршрутизації приблизно за 51 мілісекунду та досягає точності маршрутизації 93.17% у їхньому власному оцінюванні. Це їхні показники, отримані під час їхніх вимірювань і на їхньому бенчмарку, а не наші та не універсальний результат. Якщо прийняти ці цифри без поправок, висновок заспокоює: 51 мілісекунда для сорока викликів агентів додає приблизно дві секунди до завдання, яке виконується кілька хвилин.

Не ці дві секунди роблять маршрутизацію дорогою. Справді відчутні витрати виникають тоді, коли маршрутизатор класифікує запит за допомогою повного виклику моделі, адже це другий inference для кожного запиту, який оплачується та потрапляє в чергу так само, як і будь-який інший. В основі обох сценаріїв лежить наведена вище арифметика кешу, яка взагалі не є накладними витратами. Це вартість того, що маршрутизація мала оптимізувати.

На сервері, яким ви керуєте самостійно, діє те саме правило, але можливостей для компромісів менше. Локальний еквівалент prompt cache — це кешування префіксів у KV cache, який зберігається в пам’яті GPU. Розміщення двох моделей на одному GPU розподіляє цю пам’ять між ними, тому кожна модель отримує менший KV cache і швидше витісняє префікси. Отже, маршрутизація між двома локальними моделями може одночасно зменшити коефіцієнт влучань у кеш для обох моделей. Якщо ви підбираєте апаратні ресурси для цього сценарію, корисніше спочатку звернутися до матеріалу про пам’ять і CPU, які насправді потрібні coding agent на VPS, а не до маршрутизатора.

Правило вибору маршруту

• Маршрутизуйте запити між провайдерами для забезпечення доступності. Якщо альтернатива — невдалий запит, будь-яка вартість є виправданою. Прив’яжіть fallback до моделі з таким самим форматом викликів інструментів, щоб цикл агента продовжував працювати, і записуйте, яка модель обробила кожен виклик.
• Маршрутизуйте запити між рівнями вартості лише на межах завдань. Вибрати Haiku для перейменування, а Opus для рефакторингу — правильне рішення, якщо його прийнято один раз до початку сесії. Те саме рішення на тридцятому кроці цієї сесії буде неправильним.
• Використовуйте одну модель для всієї сесії, якщо агент виконує дії. Цінність сесії полягає в її прогрітому кеші. Розглядайте перемикання моделей так само, як очищення цього кешу, оскільки саме це й відбувається.
• Вільно маршрутизуйте запити субагентів. Субагент починає роботу з новим невеликим контекстом і не має прогрітого кешу, який можна втратити, тому для нього можна вибрати модель відповідно до завдання. Це єдиний випадок усередині агента, коли маршрутизація майже не має вартості.

Для реалізації цієї схеми всю роботу виконує gateway: псевдоніми моделей і явні списки fallback. Мінімальна конфігурація проксі LiteLLM має такий вигляд.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

Спрямуйте агента на agent-primary, і він залишатиметься на одній моделі, доки ця модель доступна. Обидва записи належать одному провайдеру, тому формат викликів інструментів не зміниться після спрацювання fallback. У цей момент ви все одно погоджуєтеся на зміну рівня вартості, але це виправданий компроміс, оскільки альтернатива — невдалий запит. Це маршрутизація для забезпечення доступності без додаткової маршрутизації за вартістю — саме така комбінація найчастіше потрібна агентам для роботи з кодом. Повний опис, зокрема налаштування ключів і бюджетів, наведено в матеріалі як запустити self-hosted gateway LiteLLM на власному VPS, і в цій публікації ми навмисно не повторюємо його.

Коли одна правильно вибрана модель краща за будь-який маршрутизатор

Маршрутизація вирішує проблему різної складності запитів. У coding agent ця різниця не така велика, як здається, оскільки дорога частина кожного виклику — це один і той самий префікс, незалежно від запиту. Коли префікс домінує, різниця між дешевим і дорогим рівнями майже зводиться до різниці в цінах на output, а output становить невелику частку токенів agent.

Тому типовий обґрунтований вибір — одна модель, вибрана заздалегідь, з увімкненим кешуванням і достатньо довгим TTL (time to live), щоб перекрити паузи, коли ви зупиняєтеся прочитати diff. Anthropic пропонує запис у кеш на одну годину за ціною 2 базових input, і це окупається після двох читань. Часто це ефективніший важіль, ніж будь-який маршрутизатор. Свідомо виберіть рівень, скориставшись прямим порівнянням Opus, Sonnet і Haiku. Якщо проблема все ще у вартості, зменшуйте її за допомогою бюджетів і менших контекстів, як описано в матеріалі як контролювати витрати AI agent на VPS, а не перемикайте моделі посеред сесії.

Використовуйте маршрутизацію, коли запити незалежні та короткі або коли subagent починають роботу з новими контекстами. Фіксуйте модель, коли одна довга сесія виконує одне завдання. Більшість роботи coding agent належить до другого типу. Саме тому маршрутизатор, який заощаджує кошти у вашому chat product, тут непомітно збільшить витрати. Якщо ви ще не вибрали сам agent, у матеріалі порівняння Claude Code, Cursor, Codex і Copilot описано, як кожен із них обирає модель. Деякі з них приймають це рішення автоматично.

FAQ

Чи справді перемикання моделей посеред сесії втрачає кеш промпту?

Так. Кеші промптів ідентифікуються хешем префікса промпту та зберігаються окремо для кожної моделі. Тому запит до іншої моделі перевіряється в сховищі, яке ще не бачило цього префікса. Збіг не знаходиться, і ви сплачуєте повну ціну вхідних даних без кешування, а якщо кешування ввімкнено — додатково ще й запис у кеш. Повернення до попередньої моделі також не відновлює початковий запис, оскільки стандартний час життя в 5 хвилин до цього зазвичай минає. Перевірте поля cache_read_input_tokens і cache_creation_input_tokens в об’єкті usage відповіді: якщо під час довгої сесії читається нуль кешованих токенів, це є відповідним симптомом.

Чи завжди маршрутизація до дешевшої моделі зменшує витрати агента?

Лише якщо немає теплого кешу, який можна втратити. Читання кешу в Anthropic коштує 0.1 базової ціни вхідних даних. Тому читання з теплого кешу в Opus 5 дешевше за некешоване введення в Haiku 4.5. Якщо сесія вже має великий кешований префікс, поточна модель і так є дешевшим варіантом для вхідних даних. Маршрутизація вигідна, коли контекст новий і невеликий: на початку завдання або в субагенті, який передає лише потрібний йому контекст.

Чому мій агент почав поводитися інакше посеред завдання?

Перевірте, чи спрацював fallback у gateway. Якщо для основної моделі перевищено ліміт запитів або отримано помилку 5xx, gateway повторює запит через резервну модель і на кілька секунд переводить основну модель у cooldown. Тому решта завдання виконується в іншому місці. Це не спричиняє помилки чи попередження, і завдання все одно повідомляє про успішне завершення. Поле model у журналі запиту gateway або в метаданих відповіді є єдиним надійним записом. Тому записуйте його для кожного запиту, якщо взагалі використовуєте fallback.

Чи однаково працюють виклики інструментів у всіх провайдерів?

Не зовсім. Messages API від Anthropic використовує блоки вмісту tool_use і tool_result, тоді як API, сумісні з OpenAI, використовують масив tool_calls, у якому function.arguments є рядком у форматі JSON. Gateway добре перекладає поширені випадки, але паралельні виклики інструментів і сувора перевірка схеми відрізняються залежно від провайдера. У self-hosted vLLM потрібно встановити --enable-auto-tool-choice і --tool-call-parser, що відповідає сімейству вашої моделі. У документації vLLM зазначено, що без суворого обмеження схеми сервер вилучає виклики інструментів із необробленого тексту, тому аргументи іноді можуть мати неправильний формат.

На який час слід установити TTL кешу для сесії програмування?

Для безперервної роботи використовуйте стандартний час життя 5 хвилин, а варіант на 1 годину — коли людина переглядає diff між ходами. В Anthropic запис на 5 хвилин коштує 1.25 базової ціни вхідних даних, а запис на 1 годину — 2, тоді як читання коштує 0.1. Запис на 5 хвилин окупається одним читанням, а запис на 1 годину — двома. Тому в сесії, до якої ви плануєте повернутися й продовжити роботу, довший час життя зазвичай коштує менше, ніж повторна оплата некешованого префікса.