Що робить HydraFusion GitHub Copilot, коли ви обираєте її як модель?

Як система обирає робочий процес

HydraFusion розглядає вибір процесу як задачу оптимізації. Для кожного запиту оцінюються сигнали здатностей: рассудження, генерація коду, налагодження, робота з інструментами. Система обирає найменш складний патерн, що задовольняє планку якості. Сьогодні існує три патерни. Single передає завдання одній моделі. Cascade дозволяє ефективній моделі створити черновик; потім якісний шлюз вирішує: прийняти його чи ескалаціювати до потужнішої моделі. Critique залучає одну модель для черновику, іншу — для лише-читання критики, а потім автор черновика робить ревізію. Кожен патерн цілить у власний компроміс між якістю та витратами. Single зберігає швидкість, коли однієї моделі достатньо. Cascade відкриває шлях до сильнішого висновку, не платячи за нього завжди. Critique додає незалежний погляд там, де огляд допомагає краще за ще одну спробу без допомоги.

Середовище виконання фіксує роль, результат, витрати, затримку та діагностику для кожного етапу. Ззовні ви бачите єдину зрозумілу відповідь і один набір змін з урахуванням дозволів. Усередині система агрегує витрати по чергуванню, критиці, ревізії. Також враховує ескалацію, повторні спроби та запасні варіанти. Кожен етап має явний таймаут і поведінку скасування. Кроки огляду виконуються в ізольованих контекстах без інструментів, тоді як кроки вирішення використовують спільний робочий простір. Жоден патч не застосовується, якщо робочий процес скасовано або не пройшов валідацію. Визначення процесів, прив'язки моделей, поведінка запасних варіантів перевіряються ще до початку виконання. Доступність моделей теж перевіряється заздалегідь.

Що показують бенчмарки

Фіксовані політики HydraFusion оцінювали на трьох агентних бенчмарках кодування. Це TerminalBench 2.1 та DeepSWE. Також використовувався CheckpointBench. Використовували Claude Opus 5 та GPT-5.6 Sol як базові лінії. Кожна політика отримувала однакові вхідні дані завдань, інструменти, ліміти виконання. Припущення щодо ціни та умови оцінки були однаковими. Обробка відсутніх результатів також збігалася. Вимірювалися підтверджена якість завдання та повна оціночна вартість робочого процесу. У розрахунок вартості входив кожен викликаний етап.

На TerminalBench 2.1 найкраща налаштована конфігурація покращила підтверджену якість завдань на 4,9 відсоткові пункти при на 67 відсотків нижчій оціночній вартості порівняно з Opus 5. На DeepSWE результат наблизився до Opus 5 на 1,5 відсоткового пункта, скоротивши витрати на 36 відсотків. На CheckpointBench — на 0,1 відсоткового пункта при на 65 відсотків дешевшій вартості. Ці контрольовані офлайн-результати стосуються конкретних ревізій бенчмарків, конфігурацій процесів. Також важливі пул моделей та цінових припущень. Усі моделі оцінювалися на одному середньому рівні рассудження.

TerminalBench 2.1 оцінює агентів кодування на складних багатокрокових завданнях у термінальних середовищах.

DeepSWE перевіряє складні завдання інженерії ПЗ рівня репозиторію. Вони вимагають навігації по великих кодових базах та розуміння міжфайлових залежностей, а також створення повних виправлень.

CheckpointBench — внутрішній багаторазовий бенчмарк, зібраний з реальних сесій агентного кодування GitHub Copilot. Кожна розмова прив'язана до конкретного публічного репозиторію та незмінного коміта, гарантуючи відтворюваність кожної сесії. Бенчмарк збалансований за мовою та типом завдання. Складність теж враховується. Набір очищений для якості. Він утворює реалістичний набір для оцінки, що тісно відображає продакшн-сесії агентного кодування.

Налаштування маршрутизації

Політики маршрутизації сформувалися за тим, як розробники використовують GitHub Copilot на реальних завданнях кодування. Щоб зробити ці процеси відтворюваними, команда зібрала CheckpointBench з реальних траєкторій сесій кодування Copilot. Систему вдосконалювали багаторазово на CheckpointBench і DeepSWE, а також TerminalBench 2.1. Оптимізували по набору оцінювань, а не під окремий бенчмарк. Оцінки за здатностями дали узгоджену базу для порівняння кандидатських політик маршрутизації. Замість ручного налаштування порогів застосували пошук променем для побудови оптимальної політики рішень. Кожного кандидата вимірювали проти замороженої базової лінії за якістю та витратами. Режими відмов теж враховувалися.

Цей бенчмарк дає найповнішу послідовність запусків. Прогрес не був лінійним. Між 11 та 25 серпня дві операційні помилки в оцінювальному тестовому наборі дали помилкові запуски. Їх виключили з тренду продуктивності, виправили, а далі йшли подальші зростання. До 25 серпня система досягла найсильніших робочих точок у записаній серії. Цей запис розвитку показує, як політики вдосконалювалися через повторні експерименти. Дослідницький прев'ю розширює цей цикл навчання на реальні робочі навантаження розробників.

Що можна спробувати сьогодні

Доступ відкривається через /experimental у GitHub Copilot CLI для користувачів усіх планів GitHub Copilot. Використання базується на токенах, спожитих моделями HydraFusion, за ціною кожної моделі за стандартною тарифною сіткою. Щоб спробувати: запустіть /update для встановлення останньої версії. Потім увімкніть /experimental on. Далі виконайте /model і оберіть HydraFusion (Research Preview). Зворотний зв'язок — через /feedback у Copilot CLI або в обговоренні GitHub Community.

Для цього прев'ю найкращим стартом є одноразові задачі кодування з одного промпту. Команда зосередиться на сильній багаторазовій продуктивності з довгими ітеративними сесіями пізніше. Прев'ю створене, щоб дізнатися, які завдання виграють від складних процесів і як координація впливає на затримку та витрати в практиці. Для найкращого досвіду сьогодні почніть із суттєвих добре обмежених задач кодування, які можна передати Copilot у автопілотному режимі одним промптом.

Система показує етапи процесу, але тримає проміжні чернетки до повернення єдиного узгодженого результату. Ці чернетки можуть бути переглянуті або перероблені, а також відкинуті, тому їхній живий показ міг би здаватися остаточною роботою. Очікування без достатньої видимості — реальний компроміс для розробників. Команда активно шукає кращі оновлення прогресу, керуючись зворотним зв'язком з дослідницького прев'ю.

Результати, моделі, процеси, доступність, назви та поведінка продукту можуть змінитися під час навчання на прев'ю. Наступний реальний приріст у агентному кодуванні прийде від поєднання передового інтелекту з координацією під час виконання. HydraFusion — їхня перша ставка на цю ідею: перехід від вибору найкращої моделі до динамічного побудови найкращого способу вирішення кожного завдання.