# HydraFusion Max: Copilot більше не хоче, щоб ти вибирав одну модель

> GitHub оновив HydraFusion і додав Max: кілька моделей на одну задачу, judge-крок, паралельні critics і різний reasoning effort. Розбираємо, що це означає для agent-архітектури.

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

---

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](https://github.blog/changelog/2026-10-14-hydrafusion-updates-and-new-max-option), 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-агентів](/blog/ai-agent-evals). Оркестратор просто вбудовує його в runtime.

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

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

Для production-використання тобі потрібні traces: яка модель виконала який крок, скільки токенів, яка latency, чому стався escalation до Max, хто ухвалив final decision. Це рівно та дисципліна, яку ми описували в [статті про AI observability](/blog/ai-agent-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» у своїх процесах, а конкретні моделі мапь політикою – цю ж пораду ми давали для [щоденної роботи з агентами](/blog/claude-code-dlia-react).

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

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

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