Technical Context
Я регулярно бачу одну й ту саму картину в агентних пайплайнах: архітектура виглядає красиво на схемі, але в реальності все впирається в латентність і вартість «дрібних» викликів. Коли у вас 10–30 фонових агентів (парсинг, нормалізація, генерація дрібних фрагментів коду, класифікація, звірка), ви раптово платите як за повноцінного помічника з глибоким мисленням — і ще чекаєте його відповідь там, де достатньо «швидкої і простої» моделі.
У цьому контексті мені подобається практична порада з обговорення: спробувати перемкнути модель саме для субагентів (subagents) через змінну оточення CLAUDE_CODE_SUBAGENT_MODEL. Важливо: я не сприймаю її як «офіційну фічу Anthropic». З мого досвіду, такі змінні майже завжди належать конкретному інструменту (наприклад, CLI/IDE-обгортці, агентному раннеру, внутрішньому фреймворку). Але як прийом конфігурації — це золото: один параметр, який змінює економіку всього ланцюжка.
Логіка проста: замість того щоб ганяти фонові виклики на Sonnet/Opus, я задаю їм окрему модель: Haiku або більш «легкий» варіант Sonnet, а головний оркестратор залишаю на сильній моделі. За відомими публічними тенденціями в лінійці Claude (ціни та профілі моделей змінюються, але принцип стабільний): Opus — найдорожчий і найповільніший, Sonnet — баланс, Haiku — швидкість і ціна. Для мультиагентних графів це критично, тому що сумарна вартість зростає не лінійно, а через кількість вузлів і повторні виклики.
Окремо в обговоренні фігурує посилання на chatjimmy.ai як на «реально fast» інференс. Я як архітектор ставлюся до цього суворо: без бенчмарків, SLA та зрозумілого походження моделі/провайдера я вважаю це експериментом, а не основою продакшену. У прототипі — можна. У контурі, де є дані клієнта, аудит і відповідальність, — я спочатку вимагаю вимірювання (latency p50/p95, rate limits, стабільність) та юридичну ясність щодо даних.
Як я зазвичай впроваджую подібне перемикання: виділяю типи завдань субагентів і пов'язую їх із профілем моделі. Приблизний мапінг виглядає так:
- «Дрібний код» (генерація функцій, тестів, рефакторинг 20–50 рядків) — швидкий/дешевий Claude (часто Haiku достатньо).
- «Збірка рішення» (злиття правок, пошук причини бага, архітектурний вибір) — Sonnet як основний робочий інструмент.
- «Критичний шлях» (дорогі помилки: фінанси, юридичні формулювання, промислові регламенти) — Opus/найсильніша модель, але точково.
Якщо ваш раннер дійсно читає CLAUDE_CODE_SUBAGENT_MODEL, то ви отримуєте швидкий важіль: змінювати модель субагентів без переписування коду і без ризику випадково «пустити» головного агента на слабший інтелект.
Business & Automation Impact
У моїх проектах з автоматизації за допомогою ШІ швидкість субагентів майже завжди важливіша за їхній IQ. Бізнесу потрібне не «ідеальне міркування» в кожному вузлі графа, а передбачуваний throughput: документи обробилися за 2 хвилини, інцидент класифікувався за 10 секунд, звіт зібрався до початку зміни.
Що змінюється в економіці, коли я виношу фонові завдання на дешевшу модель:
- Зниження вартості токенів — банально, але ефект величезний: в агентних системах 60–90% викликів часто припадають на допоміжні кроки.
- Зниження p95-латентності пайплайна — ланцюжок працює швидше, тому що вузькі місця найчастіше саме в «масових» викликах.
- Менше блокувань оркестратора — головний агент не чекає повільних субагентів, особливо якщо ви робите fan-out паралельно.
Хто виграє? Команди, які вже мислять маршрутизацією (model routing) і рахують вартість на рівні графа, а не одного запиту. Хто програє? Ті, хто «за звичкою» поставив одну топову модель скрізь і тепер намагається оптимізувати копійками — кешем промптів при тому, що кожен субагент все одно ходить у дорогу модель.
У впровадженні ШІ для реального сектору я впираюся ще в одну практику: розділяю «точність» і «безпеку». Легка модель може бути менш точною, але безпечною при правильній постановці завдань: обмежений формат відповіді, валідація схемою, заборона на вільний текст, пост-перевірки. Тоді субагент стає не «розумним консультантом», а детермінованим перетворювачем даних.
Якщо ж ви берете невідомий «швидкий» провайдер заради мілісекунд, то ціна помилки легко перекриває економію. Я не раз бачив, як економили на інференсі, а потім платили тижнями за розбір інциденту з якістю даних або витоком. Тому моє правило таке: у продакшені спочатку офіційні провайдери/контури, потім оптимізація, і тільки потім — експерименти з альтернативними шлюзами.
Strategic Vision & Deep Dive
Мій неочевидний висновок: головне прискорення мультиагентних систем дає не «найшвидша модель», а правильна архітектура ШІ-рішень — коли я зменшую кількість мисленнєвих кроків і перетворюю частину агентів на компілятори/валідатори. У таких графах субагентам не потрібно «розуміти світ»; їм потрібно стабільно видавати JSON, патч або список дій.
Тому я будую агентні системи у два шари. Перший — шар дешевих виконавців (класифікація, вилучення, нормалізація, генерація чернеток). Другий — шар дорогого контролю (арбітр, планувальник, фінальна перевірка). Змінна на кшталт CLAUDE_CODE_SUBAGENT_MODEL якраз допомагає закріпити цей поділ технічно: дешеві виконавці фізично не можуть випадково «увімкнути Opus», тому що модель задана окремо.
З практики Nahornyi AI Lab я додам ще три прийоми, які дають більше ефекту, ніж нескінченна зміна моделей:
- Жорсткі ліміти токенів для субагентів: 256–1024 tokens на відповідь майже завжди достатньо для фонової роботи. Довгі відповіді — це прихований податок.
- Кешування на рівні завдань, а не промптів: кешуйте нормалізовані входи (наприклад, «тип документа + хеш тексту»), інакше кеш буде марний через дрібні відмінності.
- Паралелізм із бар'єром: запускаю fan-out на швидких агентах, а потім один «сильний» агент збирає результати та вирішує конфлікти.
Моя ставка на 2026 рік проста: переможуть команди, які перестануть «ранити 19 бекграунд агентів на Sonnet» за замовчуванням і почнуть проектувати маршрутизацію як частину продукту. Хайп навколо «найрозумнішого» швидко минає, а корисність вимірюється графіком витрат, часом виконання та кількістю ручних ескалацій. Пастка впровадження — оптимізувати модель, не оптимізуючи сам процес.
Якщо ви хочете прискорити свою мультиагентну систему і знизити вартість без втрати керованості, я запрошую вас обговорити архітектуру і маршрутизацію моделей з Nahornyi AI Lab. Напишіть мені, і консультацію проведу особисто я — Vadym Nahornyi; розберемо ваш граф агентів, токени, latency і план переходу в стабільний продакшен.