# Claude Haiku 5.5 у Copilot: чому «менша» модель іноді правильніша

> Haiku 5.5 став GA у GitHub Copilot для швидких high-volume задач: subagents, quick edits, термінал. Розбираємо антипатерн «frontier model everywhere» і tiering, який реально зменшує вартість агентів.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/claude-haiku-5-5-copilot

---

Claude Haiku 5.5 з 7 жовтня generally available у GitHub Copilot – на планах від Pro і вище, у VS Code, CLI, cloud agent, мобільних застосунках і решті поверхонь. GitHub позиціонує його для «швидкої high-volume роботи: subagents, quick edits і термінальні задачі». І це хороший привід проговорити антипатерн, який тихо з'їдає бюджети у 2026: **frontier model everywhere** – звичка ганяти найдорожчу модель на кожну дрібницю.

## Факти релізу без прикрас

GA з 7 жовтня, доступний на Pro, Pro+, Max, Business і Enterprise. Поверхні – практично все: VS Code, Visual Studio, Copilot CLI, cloud agent, Copilot app, github.com, GitHub Mobile, JetBrains, Xcode, Eclipse. Білінг usage-based за прайсом провайдера; для Business/Enterprise модель вмикається за замовчуванням, якщо адмін не вирішив інакше.

Ключова vendor-заява GitHub (їхнє early testing, не незалежний бенчмарк): «у ранньому тестуванні Haiku 5.5 зрівнявся з Claude Sonnet 5 на багатьох coding-задачах, використовуючи значно менше токенів і кроків».

«На багатьох» – не «на всіх». Але для класу задач, під який модель позиціонують, цього достатньо, щоб поставити правильне питання: а скільки твоїх задач взагалі потребують frontier-модель?

## Де маленька модель виграє

Розклади типовий agent-workflow на кроки:

1. зібрати список змінених файлів;
2. класифікувати їх за типом;
3. запустити відповідні тести;
4. узагальнити failures;
5. зробити складний root-cause analysis.

Перші чотири кроки – механічні. Це extraction, classification і summarization, де «розумніша» модель дає той самий результат за більші гроші й довший час. П'ятий крок – єдиний, де глибина reasoning справді вирішує.

Якщо 80% кроків агента може якісно закрити легка модель, загальна вартість системи падає сильніше, ніж від будь-якої оптимізації промптів. І це без втрати якості там, де якість критична.

## Tiering: здорова архітектура агента

Та сама ідея, яку [Jev доводить до крайності зі спеціалізованими decision-моделями](/blog/jev-ai-typesafe), у м'якшій формі працює всередині звичайного agent-стека:

| Рівень | Що робить | Приклад |
|---|---|---|
| Легка модель | extraction, класифікація, routine edits, subagents | Haiku 5.5 |
| Сильніша модель | ambiguous reasoning, складний дебаг | Sonnet/Opus-клас |
| Детермінований код | валідація, lint, тести | без моделі взагалі |
| Людина | незворотні та high-impact рішення | merge, deploy, гроші |

Зверни увагу на третій рядок: найдешевша «модель» – її відсутність. Перевірку формату JSON робить парсер, а не LLM.

Цікаво, що GitHub сам рухає цю ідею далі: [HydraFusion оркеструє кілька моделей в одній задачі](/blog/github-copilot-hydrafusion-max) – драфт пише одна, критикує інша, ремонт вмикається лише за потреби. Model routing стає runtime-рішенням, а не полем у settings.

## Як перевірити на собі

Vendor-заява «зрівнявся з Sonnet 5» – сигнал, не вердикт. Свій замір робиться за годину: візьми 20 типових **дрібних** задач (rename, додати тест, поправити типи, узагальнити diff) і прожени через Haiku 5.5 та свій поточний default. Порівняй якість, час і вартість. Процедура та сама, що в [повноцінних agent-evals](/blog/ai-agent-evals), лише компактніша – а якщо обираєш між більшими моделями, [framework вибору тут](/blog/gemini-4-argon-copilot-model-selection).

Типовий результат такого заміру (за моїми очікуваннями, перевір на своєму repo): на рутинних задачах різниці в якості не видно, різниця у швидкості й вартості – в рази.

## Антипатерни вибору моделі

1. **Frontier на все.** Найдорожча модель на форматування коментарів – це не перфекціонізм, це марнотратство.
2. **Легка модель на все.** Зворотна крайність: економія на root-cause analysis обертається годинами людського дебагу.
3. **Tiering без вимірювання.** Розподіл задач між рівнями – гіпотеза, яку треба перевірити, а не вгадати.
4. **Ігнорування токенів-кроків.** «Менше tokens і steps» означає і швидше, і дешевше – у subagents це множиться на кількість викликів.
5. **Жодного fallback.** Якщо легка модель не впоралась – ескалація на сильнішу має бути автоматичною, а не ручною.

## Порахуй свій тиждень у токенах

Відкрий логи свого agent-стека (або історію Copilot-сесій) за тиждень і розклади виклики на дві купки: «потребувало глибокого reasoning» і «механічна робота». Порахуй співвідношення. Якщо механіки більше половини – порахуй, скільки коштував би той самий тиждень із tiering-ом. Це число зазвичай переконливіше за будь-яку статтю.

Найрозумніше інженерне рішення – не завжди найрозумніша модель.