Статті
Досить бездумного fan-out: чотирирівнева оркестрація на Claude Haiku 5.5 на практиці
Claude Haiku 5.5 швидкий і дешевий, але якщо віддавати йому всі завдання паралельно, це лише посилює хибні судження, упередженість оцінювача та ризики Supply Chain. У статті розбирається багаторівнева архітектура: судження Fable, оркестрація Opus, реалізація Sonnet і Haiku, перевірка в CI, приймання Opus, а також які завдання справді варті fan-out.
· 1 хв читання
Claude Haiku 5.5 вийшов 7 жовтня 2026 року. Коли промпт не перевищує 100 тисяч токенів, його ціна становить одну двадцяту від ціни Sonnet 5.5, а затримка — найменша серед нинішнього покоління Claude.
Коли модель і дешева, і швидка, легко спокуситися: розбити всі coding-завдання на частини, паралельно віддати зграї Haiku, і справу зроблено.
У прототипі це, можливо, і спрацює. Але в реальному інженерному середовищі швидко зіткнетеся з трьома проблемами:
- Малі моделі погано справляються з неоднозначністю. Офіційне позиціювання Haiku 5.5 — масові завдання з низькою затримкою: класифікація, вилучення, маршрутизація та субагенти. Коли вимога містить бізнесову неоднозначність і потребує контексту всієї системи, модель легко видає результат, що виглядає завершеним, але насправді вгадав хибний напрямок.
- Якщо доручити моделі вибирати відповідь, виникає упередженість оцінювача. Коли великій моделі дати прочитати десятки результатів, вона схильна вибирати версію, що «має гарну архітектуру», а не ту, логіка й виконання якої справді правильні.
- Права зростають разом із кількістю Worker. Якщо дозволити паралельним субагентам автоматично встановлювати пакети чи змінювати конфігурацію, то N Worker — це N додаткових входів для потенційно шкідливих пакетів.
Тому я перейшов на багаторівневу оркестрацію (Hierarchical Orchestration): кожен рівень робить лише те, що вміє найкраще, а паралельність Haiku застосовується тільки там, де вона справді потрібна.
Спершу висновок: Fable відповідає за те, щоб усе обдумати, Opus — за розподіл і приймання, Sonnet — за основну реалізацію, а Haiku виконує лише механічні завдання та пошукові завдання, що перевіряються автоматично. Кандидати спершу проходять CI, і лише потім їх бачить модель.
Чотири рівні: судження, оркестрація, перевірка, приймання#
Вхідна вимога
│
▼
[Рівень судження]Fable: архітектурні рішення, розбиття завдань, критерії приймання
│
▼
[Рівень оркестрації]Opus Main Session: лише розподіляє, повторно не розбиває
├─► Шлях A: складне, але з чіткими межами ──► реалізує Sonnet
├─► Шлях B: механічне завдання ──► один Haiku
├─► Шлях C: пошукове, кілька розв’язків ──► кілька Haiku, кожен у власному Git Worktree
│
▼
[Рівень перевірки]Build, Type Check, Test, Benchmark (для шляху C залишаються лише 2–3 найкращі)
│
▼
[Рівень приймання]Opus зводить результат за критеріями приймання
У разі невдачі — ескалація: Haiku двічі виправляє й не проходить ➔ Sonnet ➔ повернення до Opus
Те, на якому рівні стоїть кожна модель, визначено за офіційним позиціюванням і ціною. Нижче — дані з офіційної документації Anthropic станом на 8 жовтня 2026 року; ціни вказано в доларах США за мільйон токенів:
| Модель |
Офіційне позиціювання |
Затримка |
Ціна Input / Output |
| Claude Fable 5.1 |
Складні міркування та тривала agentic-робота |
Повільніша |
$10 / $50 |
| Claude Opus 5.5 |
Тривалий agentic coding і робота зі знаннями |
Середня |
$4 / $20 |
| Claude Sonnet 5.5 |
Найкраще поєднання швидкості та можливостей |
Швидка |
$2 / $10 |
| Claude Haiku 5.5 |
Масова класифікація, вилучення, маршрутизація та завдання субагентів із низькою затримкою |
Найшвидша |
від $0.10 / $0.50 |
Ціна Haiku 5.5 має два ступені: якщо промпт перевищує 100 тисяч токенів, вона стає $0.50 / $2.50.
Рівень судження: Fable відповідає за архітектурні рішення та критерії приймання#
Не кожній вимозі потрібен Fable. Це найдорожчий і найповільніший рівень, тож я залучаю його лише тоді, коли вимога неоднозначна, стосується інтеграції між системами або потребує ключового архітектурного рішення.
Fable має видати три речі:
- Дизайн рішення
- Розбиття завдань
- Критерії приймання (Acceptance Criteria), які для кожного підзавдання можна перевірити тестами
Міркування й розбиття має виконувати один і той самий рівень. Лише той рівень, що чітко осмислив сліпі зони системи, здатен нарізати підзавдання з чистими межами; якщо архітектуру віддати A, а розбиття — B, визначення інтерфейсів зазвичай розмиваються.
Винятком є завдання з безпеки. Усі моделі Claude нинішнього покоління мають класифікатори безпеки: коли запит блокується, повертається stop_reason: "refusal", і легітимну роботу з безпеки також можуть заблокувати помилково. Класифікатор Fable 5.1 охоплює більшість змісту про безпеку, і, за офіційними поясненнями, модель не розроблялася для сфери безпеки; Opus 5.5 же дозволяє шукати вразливості у вихідному коді. Тому для вимог на кшталт виправлення вразливостей я одразу віддаю початковий аналіз Opus.
Рівень оркестрації: Opus лише розподіляє, повторно не розбиває#
Opus — це Main Session, який відповідає за маршрутизацію та розподіл роботи. Цей рівень не переглядає архітектуру і не виконує друге розбиття.
- Шлях A, складне, але з чіткими межами: завдання зі складною логікою, але з уже чітко визначеними межами інтерфейсів, віддаються Sonnet. Це основна робоча сила для реалізації.
- Шлях B, прості механічні завдання: шаблонний код (Boilerplate), перейменування змінних, додавання простих модульних тестів, доповнення документації — віддаються одному Haiku.
- Шлях C, пошукові й оптимізаційні завдання: тонке налаштування продуктивності, різні варіанти складного SQL чи Regex, пошук причин Flaky Test — саме тут запускається fan-out: кілька Haiku, кожен у власному окремому Git Worktree, пробують різні розв’язки.
Незалежно від шляху, результат має пройти рівень перевірки.
Рівень перевірки: спершу машина, потім модель#
Дуже поширена практика — віддати весь паралельно створений код Opus або Sonnet і попросити перевірити його промптом.
Проблема в тому, що, читаючи код, модель легко приваблюють охайне форматування та повні оголошення типів, хоча це не означає, що код пройшов граничні тести. Тому кандидати мають спершу пройти машинний бар’єр:
- Build і Type Check: компілюється, типи правильні
- Unit / Integration Tests: модульні й інтеграційні тести проходять
- Benchmark / Profiling: вимірювання продуктивності та пам’яті
Те, що не пройшло автоматичні тести, одразу відсіюється. З кандидатів шляху C Opus дивиться лише на 2–3 найкращі, що пройшли перевірки й мають найкращі показники, — це ще й економить context window і токени.
Рівень приймання: Opus зводить результат, у разі невдачі — ескалація вгору#
Нарешті Opus зводить результат за критеріями приймання, визначеними на рівні судження. Коли Worker застрягає, ескалація (Escalation Path) іде послідовно вгору:
- Haiku зазнає невдачі: після 2 автоматичних виправлень, що не пройшли, повторні спроби припиняються.
- Виправлення перебирає Sonnet.
- Якщо й Sonnet не проходить приймання, це зазвичай означає суперечність у розбитті завдання або в початкових припущеннях. Завдання повертається до Opus, і Opus вирішує, чи варто відправити його назад до Fable на повторне розбиття.
Три правила перед виходом у продакшн#
Не робіть fan-out сліпо#
Простим завданням кілька Worker не потрібні, а високонеоднозначні завдання малі моделі не розв’яжуть. Лише пошукові завдання, де «простір розв’язків великий» і «автоматичні тести дають швидку перевірку», варті паралельного запуску кількох Haiku.
Ізолюйте середовище, зафіксуйте Lockfile#
Git Worktree ізолює зміни коду, щоб паралельні Worker не перезаписували файли один одного; він не обмежує ні мережу, ні те, до чого програма має доступ. Щоб захиститися від Supply Chain Attack, потрібен ще й sandbox, а також заборона Worker самостійно встановлювати неперевірені пакети чи змінювати Lockfile. Безрозсудно відкрите право на встановлення — це все одно що дозволити Agent заносити в репозиторій пакети й скрипти невідомого походження.
Приймайте за виміряними даними, а не за оцінкою моделі#
Результати тестів, покриття, використання пам’яті та затримка — ось відтворювані й порівнянні підстави. Текстову оцінку моделі можна брати до уваги, але не можна використовувати для приймання якості коду.
Дешеву модель треба застосовувати в правильному місці#
Haiku 5.5 робить паралельність дешевою, але сама по собі паралельність не робить результат правильним. Лише коли судження, розподіл, перевірку й приймання розділено, дешевизна та швидкість стають справжньою перевагою.
Така багаторівнева схема — це, по суті, той самий Graph, про який я писав у статті AI Agent — це насправді гнучка команда: хто робить першим, кому передає після завершення і кому — якщо виникає проблема.