Експеримент розробника-одинака з трьома моделями Claude дозволив скоротити щомісячні витрати на API на 35 % та зменшити медіанну затримку виконання завдань із 42 до 27 секунд. Шляхом маршрутизації простих завдань із низьким рівнем неоднозначності на дешеву модель Haiku, рутинної роботи — на Sonnet, а складних завдань із високими ставками — на потужну Opus, автор довів, що звичка використовувати «найкращу модель для всього» є дорогою ціною.

Чому маршрутизація мала значення

Автор керує автономним агентом для написання коду, який отримує постійний потік завдань із розробки: виправлення помилок лінтера, додавання нових функцій, аудит безпеки та глибоке налагодження. Протягом місяців агент надсилав кожен запит моделі Opus — найпотужнішій моделі Claude, припускаючи, що вища якість завжди переважить ціну. Opus має значно вищу ціну за токен, тому рахунки зростали безконтрольно.

Коли автор запровадив багаторівневу схему маршрутизації, витрати впали до 65 % від початкового рівня, а використання Opus скоротилося до 11 % від загальної кількості завдань.

Як працює трирівнева система

Логіка маршрутизації ґрунтується на неоднозначності, а не на кількості рядків коду, яких торкається завдання. Автор визначив три категорії:

  • Haiku – завдання з низьким рівнем неоднозначності та детермінованим результатом. Приклади: виправлення попереджень лінтера, перейменування змінних, узагальнення лог-файлів. Правильна відповідь зазвичай — це один рядок коду або тексту.
  • Sonnet – основний робочий інструмент. Виконує впровадження функцій, рутинне виправлення помилок та стандартний рефакторинг, де проблема зрозуміла, але рішення може вимагати кількох кроків.
  • Opus – критично важлива робота з високим рівнем неоднозначності. Архітектурні рішення, аудит безпеки, складні сесії налагодження або будь-яке завдання, де правильний шлях не є очевидним і помилка може зірвати весь процес.

Статична таблиця пошуку зіставляє кожен вхідний запит із відповідною моделлю на основі цих правил. Автор пробував використовувати «розумну» модель, яка визначала б рівень на льоту, але додаткове використання токенів звело нанівець будь-яку економію. Прості статичні правила охопили приблизно 80 % робочого навантаження, зробивши систему дешевою та передбачуваною.

Страховка через ескалацію

Дешеві моделі все одно припускаються помилок. Щоб помилкова відповідь Haiku або Sonnet не зірвала збірку, система ескалює запит після двох невдач, перенаправляючи його на наступний рівень. Ця страховка дозволяє вчасно виявляти помилки та підтримувати безперебійну роботу конвеєра без ручного втручання.

Цифри, що говорять самі за себе

Після чотирьох тижнів роботи багаторівневого маршрутизатора автор зафіксував такі зміни:

  • Витрати на API впали до 65 % від початкової вартості (скорочення на 35 %).
  • Медіанний час виконання скоротився з 42 до 27 секунд.
  • Використання Opus зменшилося з обробки кожного запиту до лише 11 % від загальної кількості завдань.

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

Уроки для інших розробників

  1. Починайте з простого, а не зі складного. Більшість щоденних завдань із кодуванням не потребують найпотужнішої моделі. Використання Sonnet як моделі за замовчуванням для неоднозначних завдань заощадило більше грошей, ніж спроби прогнати все через Haiku.
  2. Вимірюйте складність, а не обсяг. Виправлення стану гонитви (race condition) в один рядок може бути складнішим за рефакторинг цілого файлу. Маршрутизуйте залежно від того, наскільки неоднозначним є рішення, а не від кількості змінених рядків.
  3. Слідкуйте за рівнем ескалації. Зростання кількості ескалацій свідчить про те, що статичні правила більше не відповідають навантаженню. Коригуйте категорії до того, як дешеві моделі почнуть спричиняти часті збої в робочому процесі.

Резервування найдорожчої моделі для найскладніших завдань і передача решти дешевим моделям робить розробку за допомогою ШІ швидкою та доступною. Справжня перевага полягає в дисциплінованій стратегії маршрутизації, яка підбирає правильний інструмент для правильного завдання.