AIREITERЗадача по программированию может выглядеть элементарной — ровно до того момента, пока не выяснится, что она затрагивает несколько связанных файлов. Project HydraFusion подбирает сценарий, который, по оценке системы, должен обеспечить нужное качество, но в исследовательской preview-версии точный маршрут скрыт, а одинаковой экономии для всех репозиториев никто не обещает.
Как устроена маршрутизация
Project HydraFusion — это слой оркестрации во время выполнения внутри GitHub Copilot CLI, а не новая базовая модель. Пользователь выбирает HydraFusion (Research Preview), после чего среда сама определяет, какие модели и в какой последовательности использовать.
| Сценарий | Последовательность выполнения | Главное преимущество | Главный компромисс |
|---|---|---|---|
| Single | Одна выбранная модель сразу решает задачу. | Минимальные накладные расходы и самый простой путь по задержке. | Нет встроенной эскалации и независимой проверки. |
| Cascade | Быстрая модель готовит черновой результат; контроль качества либо принимает его, либо передаёт задачу более сильной модели. | Сильнейшая модель не используется, если первого прохода достаточно. | Неудачная проверка может добавить вызовы моделей, токены и время ожидания. |
| Critique | Одна модель готовит результат, независимый критик из другого семейства моделей проверяет его только для чтения, после чего решающая модель один раз вносит правки. | Второй взгляд помогает находить ошибки в рискованных изменениях. | Появляется дополнительная последовательная работа, а критик не может запускать инструменты или редактировать репозиторий. |
Чтобы попробовать preview-версию, выполните /update, затем /experimental on, после чего — /model и выберите HydraFusion (Research Preview). GitHub описывает эту последовательность в официальном анонсе HydraFusion. Preview доступна во всех тарифах Copilot, хотя в организациях доступ может зависеть от политики Copilot CLI, которую включил администратор.
Речь идёт о сценариях выполнения, а не о трёх публичных переключателях, которыми можно вручную принудить нужный маршрут для конкретного запроса. В материалах запуска описан другой подход: выбрать HydraFusion и позволить среде самостоятельно находить баланс между производительностью, стоимостью и задержкой.
Что именно пытается предсказать среда
По словам GitHub, HydraFusion учитывает сигналы, связанные с рассуждением, генерацией кода, отладкой и использованием инструментов. Среда выбирает наиболее эффективный сценарий, который, как она ожидает, позволит достичь нужного уровня качества. При этом GitHub не раскрывает пороговые значения и не публикует детерминированные правила вроде «три файла — значит Cascade».
Поэтому тип задачи — лишь ориентир, а не гарантия маршрутизации. Небольшая правка с очевидным способом проверки логично подходит для Single; потенциально сложный запрос — для Cascade с выборочной эскалацией; изменение, которому полезна независимая проверка, — для Critique. В анонсе нет фиксированного списка моделей для каждого запроса и читаемого лога маршрута.
Можно ли принудительно включить Single, Cascade или Critique?
GitHub документирует выбор HydraFusion и передачу решения самой среде. Публичной команды для принудительного выбора одного из трёх сценариев не заявлено. Если нужна предсказуемая маршрутизация, используйте конкретную модель Copilot.
Когда дополнительный вызов действительно оправдан
Single: прямое выполнение для понятных задач
В режиме Single задача проходит через одну модель-решатель в обычном агентском цикле Copilot с учётом разрешений. Это подходящий вариант для небольшой чётко сформулированной правки, короткого объяснения или исправления, для которого заранее понятны реализация и способ тестирования.
Главный плюс — более простой и предсказуемый профиль стоимости и задержки. Сценарий намеренно не добавляет контроль качества или второе мнение, поэтому при неправильном понимании задачи основным проверяющим остаётся разработчик.
Cascade: эскалация только при необходимости
Cascade начинает работу с эффективной модели. Затем контроль качества оценивает получившийся вариант и может передать задачу более сильной модели, если результат не достигает нужной планки.
Экономика здесь строится на условной логике:
- Первая модель выполняет задачи, с которыми способна справиться на приемлемом уровне.
- Контроль качества отсекает слабые или сомнительные результаты.
- Более мощный маршрут получают только задачи, которым действительно не хватает возможностей первой модели.
Такой подход может снизить среднюю стоимость по сравнению с отправкой каждой задачи во frontier-модель. Но эскалация, повторная попытка или запасной сценарий способны сделать отдельные запросы дороже и медленнее. Универсальный показатель частоты эскалаций для планирования в конкретных репозиториях GitHub не публиковал.
Critique: цена второго мнения
Critique — это цикл «черновик — проверка — доработка». Первая модель создаёт результат, критик из другого семейства моделей проверяет его в изолированном контексте без инструментов и с доступом только для чтения, а исходная модель один раз вносит исправления.
Критик не может запустить тесты проекта, проверить сгенерированный файл через команду или самостоятельно применить исправление. Critique даёт разнообразие при проверке, но не независимую реализацию задачи от начала до конца.
Что показывают бенчмарки: низкая стоимость не означает одинаковое качество
GitHub сравнил фиксированные политики HydraFusion с Claude Opus 5 на трёх бенчмарках агентской разработки. Все цифры ниже взяты из официального анонса GitHub.
| Бенчмарк | Качество HydraFusion по сравнению с Claude Opus 5 | Расчётная стоимость сценария по сравнению с Claude Opus 5 | Как это понимать на практике |
|---|---|---|---|
| TerminalBench 2.1 | +4,9 процентного пункта | на 67% ниже | В этой оценке качество проверенных задач выше, а расчётная стоимость ниже. |
| DeepSWE | −1,5 пункта | на 36% ниже | Заметная экономия сопровождается измеримым снижением качества на сложных задачах в репозитории. |
| CheckpointBench | −0,1 пункта | на 65% ниже | Качество почти такое же, а расчётная стоимость существенно ниже. |
Именно смешанные результаты здесь наиболее показательны: HydraFusion должна добавлять вычисления тогда, когда ожидаемый прирост качества оправдывает стоимость и задержку, а не подключать дополнительные модели к каждому запросу.
GitHub утверждает, что в оценке были одинаковыми входные данные, инструменты, ограничения выполнения, цены и методика проверки, а в подсчёт вошли этапы подготовки черновика, критики, доработки, эскалации, повторных попыток и резервного выполнения. Это всё равно контролируемые офлайн-оценки, привязанные к конкретным политикам, набору моделей, версиям бенчмарков и допущениям по ценам.
Они не означают, что обычная задача в Copilot будет стоить на 67% меньше или что HydraFusion превзойдёт Claude Opus 5 именно в вашем коде. На время тестирования preview GitHub рекомендует начинать с существенных, хорошо очерченных задач по разработке, которые укладываются в один запрос, и проверять их на реальных рабочих нагрузках.
У стоимости есть три составляющие
Оценивая HydraFusion, разделяйте ожидаемую стоимость токенов, стоимость редких долгих сценариев и время ожидания.
| Фактор | Single | Cascade | Critique |
|---|---|---|---|
| Начальная работа | Одна модель-решатель | Сначала эффективная модель | Сначала модель готовит черновик |
| Дополнительная работа | По задумке отсутствует | Более сильная модель после неудачной проверки | Критик и одна доработка решающей моделью |
| Профиль стоимости | Более предсказуемый | Зависит от ситуации; растёт при эскалации или повторной попытке | Структурно выше, чем у прямой генерации |
| Профиль задержки | Самый простой путь | Короткий при принятии результата, длиннее после эскалации | Дополнительные проверка и доработка увеличивают время |
| Механизм повышения качества | Возможности решающей модели | Контроль качества и эскалация | Независимая проверка и доработка |
Меньшая расчётная стоимость сценария не означает автоматически более быстрый ответ: Cascade может замедлить запросы с эскалацией, Critique добавляет последовательную проверку, а Single возвращает результат быстрее, оставляя разработчику больше работы по валидации.
В документации Copilot CLI GitHub сказано, что команда /usage показывает длительность сессии, израсходованные AI Credits, число изменённых строк и разбивку использования токенов по моделям. Эти данные помогают сравнивать реальные задачи, но не объясняют каждое решение маршрутизатора и не показывают отброшенные промежуточные черновики.
Что происходит между запросом и патчем
GitHub описывает полный учёт всех этапов сценария, ограниченное выполнение с обработкой тайм-аутов и отмены, изолированную проверку, валидированную маршрутизацию и безопасное применение патча после невалидного или отменённого сценария. Эти механизмы снижают операционные риски, но не доказывают, что выбранный маршрут или итоговый код верны.
GitHub также сообщает, что preview удерживает промежуточные черновики, пока не сможет вернуть один связный результат. Поэтому пользователю сложно понять, осталась ли задача в Single, была ли она передана через Cascade или прошла через Critique и доработку.
Один из реальных пользователей прямо указал на этот пробел в наблюдаемости:
«Следующая функция, которую я хотел бы увидеть, — понятный лог: какая модель что сделала и почему маршрутизатор переключился». — @_Mazzana в X
Без квитанции о маршруте разработчик не может полностью связать стоимость задачи, задержку и итоговый патч со сценарием, который их сформировал.
Как тестировать preview и не делать лишних выводов
Сначала воспринимайте HydraFusion как эксперимент, а не как новый стандарт команды:
- Создайте чистую ветку или worktree и зафиксируйте исходный коммит.
- Проверьте одну обычную исправляющую задачу, одно изменение в нескольких файлах и одну неоднозначную задачу с воспроизводимой проверкой результата.
- В первом запросе укажите ожидаемое поведение, ограничения и команды для тестирования.
- Изучите итоговый diff, проверьте отсутствие посторонних изменений и самостоятельно запустите нужные тесты.
- Запишите длительность сессии, видимое потребление AI Credits или токенов, результат тестов и любые заметные признаки повторной попытки или эскалации.
- Повторите проверку на нескольких задачах, прежде чем сравнивать HydraFusion с фиксированной моделью.
Не пытайтесь определить скрытый режим только по длине ответа. Большой объём может быть следствием сложности репозитория, а не работы Critique. Для длинных многошаговых сессий, чувствительных к задержке задач и критически важных изменений держите запасной вариант с фиксированной моделью: для текущей preview GitHub рекомендует задачи, решаемые за первый запрос, а улучшение работы в длинных многошаговых сценариях называет будущим направлением в материалах запуска.
FAQ по HydraFusion
Можно ли вручную выбрать Single, Cascade или Critique?
Не с помощью документированной команды выбора режима HydraFusion. Сейчас пользователь выбирает HydraFusion и передаёт решение среде; если важна детерминированная маршрутизация, используйте фиксированную модель.
Как тарифицируется HydraFusion?
GitHub сообщает, что использование рассчитывается по токенам, которые потребляют задействованные HydraFusion модели, причём каждый вызов оплачивается по стандартной ставке соответствующей модели, как описано в официальном анонсе. Снижение стоимости в бенчмарке не является универсальной скидкой для клиентов, а многоэтапный сценарий может потребить больше токенов, чем прямой запрос.
HydraFusion особенно интересна для задач, которые достаточно важны, чтобы оправдать выборочную эскалацию или дополнительную проверку, но при этом достаточно хорошо структурированы для валидации. Для быстрой работы может оказаться важнее простота Single; для длинных или критически важных задач более практичным вариантом пока остаётся предсказуемое поведение фиксированной модели — по крайней мере до тех пор, пока данные из конкретного репозитория не подтвердят пользу дополнительной оркестрации.