14 жовтня GitHub оновив HydraFusion – research preview, який оркеструє кілька моделей для однієї задачі – і додав HydraFusion Max для «найглибшого reasoning і найретельнішого аналізу». У pool зараз Claude Opus 5.5, GPT-6 Astra, GPT-6.1 Sol і GPT-6 Luna; конкретні моделі й кроки залежать від workflow. Це не чергова модель у picker, а ставка на те, що вибір моделі – runtime-рішення оркестратора, а не релігійна позиція розробника. Розбираємось, чому це логічно, що воно ламає в дебагінгу і як підготуватись.

Що саме оновили

За changelog GitHub, HydraFusion «оркеструє кілька моделей для створення однієї відповіді, поєднуючи їхні сильні сторони». Обидва варіанти – research preview, доступні на Copilot Pro, Pro+, Business і Enterprise з увімкненими experimental/preview-фічами, у VS Code, Copilot app і CLI.

Конкретні механізми, які GitHub описує:

  • Різний reasoning effort на різних кроках: medium на initial draft, high на review. Тобто система не палить максимум compute там, де він не потрібен.
  • Cascade-workflow із judge-кроком: окремий крок інспектує початкову роботу і запитує repair лише коли бачить проблему. Не «завжди переробляй», а «переробляй за показаннями».
  • Critique-workflow: більше спирається на tools для прямої інспекції workspace і використовує паралельні critic-моделі.

Поділ простий: звичайний HydraFusion – для agentic-задач із балансом швидкості, вартості й якості; Max – коли потрібен найглибший аналіз і ціна питання виправдовує compute.

Чому один picker на всі задачі – це антипатерн

Production-агент майже ніколи не має одного типу роботи. Типовий цикл: згенерувати boilerplate, знайти багу в race condition, написати тести, зробити final review. Це чотири різні задачі з різними вимогами до глибини reasoning – і платити ціну frontier-моделі за кожен chmod так само дивно, як віддавати найскладніший архітектурний розбір найшвидшій і найдешевшій моделі.

HydraFusion формалізує те, що зрілі команди вже будували руками: draft дешевшою, перевірка сильнішою, repair лише за сигналом judge. Якщо ти колись писав власний каскад «маленька модель → ескалація за потреби», тут та сама ідея, але як managed-фіча.

Знайома механіка? Так: judge-крок – це той самий патерн «спеціалізована перевірка замість сліпої довіри», який ми розбирали у статті про evals для AI-агентів. Оркестратор просто вбудовує його в runtime.

Нова проблема: хто винен, коли відповідь погана

Multi-model оркестрація робить debugging складнішим на порядок. Коли одна модель дала одну відповідь – зрозуміло, кого питати. Коли draft зробила Luna, критикували паралельно Sol і Opus, а фінальне рішення зібрав cascade – питання «чому агент так вирішив» без інструментів перетворюється на археологію.

Для production-використання тобі потрібні traces: яка модель виконала який крок, скільки токенів, яка latency, чому стався escalation до Max, хто ухвалив final decision. Це рівно та дисципліна, яку ми описували в статті про AI observability – з HydraFusion вона перестає бути «nice to have».

Пастки multi-model підходу

  1. Увімкнути Max для всього. Max – для задач, де глибина аналізу виправдовує compute. Якщо все «найважливіше», то ніщо не найважливіше, а рахунок – найбільший.
  2. Оцінювати research preview як продукт. GitHub прямо називає це research preview: workflow і pool моделей можуть змінитися. Не будуй критичний процес на механіці, яка завтра інша.
  3. Порівнювати з однією моделлю за відчуттями. Якщо хочеш зрозуміти, чи дає оркестрація виграш саме на твоїх задачах – потрібен власний eval на 20–30 реальних тікетах, а не враження від двох промптів.
  4. Забути, що моделі – залежність. Pool сьогодні такий, завтра інший. Абстрагуй рівень «fast / balanced / deep-review» у своїх процесах, а конкретні моделі мапь політикою – цю ж пораду ми давали для щоденної роботи з агентами.

Розклади свій workflow на кроки

Візьми свій типовий agent-workflow і розклади його на кроки. Для кожного чесно відміть: потребує цей крок глибокого reasoning чи це механічна робота? Порахуй, скільки відсотків кроків реально виграють від найсильнішої моделі. Якщо менше половини – ти вже знаєш, звідки оркестрація на кшталт HydraFusion візьме економію, і можеш відтворити той самий патерн навіть без неї: дешева модель за замовчуванням, ескалація за сигналом.

Головний висновок релізу не про GitHub. Model selection стає runtime concern. Senior-розробник дедалі менше мусить пам'ятати, «яка модель зараз топ-1 на бенчмарку», і дедалі більше – проєктувати routing, verification і cost. Це нормальна еволюція: ми теж колись перестали сперечатися про текстові редактори і почали будувати CI.