GitHub HydraFusion zkouší skládat AI tým pro každý programátorský úkol

Výběr modelu býval v AI nástrojích podobný volbě motoru v autě. Uživatel nebo služba vybral jeden model a ten pak řešil celý úkol od začátku do konce. GitHub nyní zkouší praktičtější přístup: model nemusí být jen „mozkem“ celé operace, ale může dostat konkrétní roli v delším procesu.

HydraFusion proto nevybírá pouze nejlepší model. Vybírá způsob práce. Pro jednoduchý požadavek může použít jediný model. U složitějšího úkolu nechá levnější nebo rychlejší model připravit první návrh, nechá jej projít kontrolou a teprve potom případně přizve výkonnější model. U jiného zadání může jeden model napsat řešení a druhý ho nezávisle zkritizovat.

GitHub oznámil HydraFusion jako výzkumný náhled v oficiálním blogu. Podle zveřejněného popisu systém využívá modely od více poskytovatelů a celý proces řídí za běhu, tedy v okamžiku, kdy vývojář zadá konkrétní úkol.

Od výběru modelu k plánování celého řešení

HydraFusion navazuje na dřívější funkci Auto model selection. Ta měla za úkol najít pro daný požadavek jeden nejvhodnější model. HydraFusion jde o krok dál: považuje výběr workflow za optimalizační problém.

Systém podle GitHubu vyhodnocuje signály související s uvažováním, generováním kódu, laděním a používáním nástrojů. Na jejich základě se snaží vybrat nejméně složitý postup, který má ještě šanci splnit požadovanou úroveň kvality. Přidá další model nebo kontrolní krok jen tehdy, pokud by to mohlo zlepšit výsledek.

V praxi to připomíná tým programátorů. Jeden člověk udělá rychlý návrh, druhý projde změny a seniorní kolega se zapojí až u problému, který první dvojice nevyřeší. Rozdíl je v tom, že tento tým pracuje automaticky a jeho jednotlivé role se mohou měnit podle zadání.

Tři režimy, které HydraFusion používá

Single: jeden model a hotovo

Nejjednodušší režim se jmenuje Single. Jeden vybraný model dostane úkol a vyřeší ho samostatně. Tento postup je vhodný tam, kde není důvod přidávat další kontrolu nebo další volání modelu.

Výhodou je rychlost a předvídatelnější spotřeba tokenů. Pokud vývojář požádá například o menší úpravu existující funkce nebo vysvětlení části kódu, další kritický tým by mohl být jen zbytečná zastávka navíc.

Cascade: levnější první pokus, silnější model jako záloha

Režim Cascade začíná efektivnějším modelem. Ten připraví návrh řešení. Následně nastoupí kontrolní mechanismus, který posoudí, zda návrh splňuje požadovanou úroveň. Pokud ne, úkol se předá výkonnějšímu modelu.

To je důležitý rozdíl proti prostému automatickému výběru modelu. Nejde jen o rozhodnutí před začátkem generování. Systém může reagovat na kvalitu konkrétního mezivýsledku. Pokud první pokus stačí, není nutné platit za náročnější model. Pokud nestačí, workflow má připravenou cestu k eskalaci.

Critique: jeden model píše, druhý hledá chyby

Ve třetím režimu, nazvaném Critique, jeden model vytvoří návrh a nezávislý kritik z jiné modelové rodiny jej zkontroluje. Původní model pak dostane připomínky a řešení jednou upraví.

Kritický model pracuje v režimu pouze pro čtení a nemá přímý přístup k úpravám repozitáře. To omezuje riziko, že kontrola sama změní soubory nebo vytvoří další vedlejší problém. GitHub tento přístup přirovnává k principu Rubber Duck, ovšem s tím rozdílem, že zde „gumová kachnička“ skutečně analyzuje kód a vrací připomínky.

Nejde jen o kvalitu. Důležitá je také kontrola nákladů

Každé další volání modelu stojí čas a peníze. HydraFusion proto neslibuje, že bude vždy používat více modelů. Jeho smyslem je použít více kroků pouze tehdy, když se to vyplatí.

GitHub uvádí, že systém eviduje náklady a výsledky jednotlivých částí workflow. Počítá se generování návrhu, kritika, revize, případná eskalace, opakování i záložní postup. Vývojář přitom dostane jednu souvislou odpověď a jednu sadu změn respektující oprávnění v repozitáři.

Součástí návrhu jsou také provozní pojistky. Každý krok má vlastní časový limit a možnost zrušení. Kritické kontroly probíhají odděleně a bez nástrojů pro úpravu projektu. Pokud je workflow zrušeno nebo neprojde validací, systém nemá aplikovat neověřený patch. Před spuštěním se navíc kontroluje dostupnost modelů, vazby mezi jednotlivými rolemi a chování záložních cest.

Benchmarky: nejlepší výsledek je výrazně levnější, ale ne vždy lepší

GitHub testoval pevně nastavené politiky HydraFusion na třech agentních programátorských benchmarcích. Jako referenční bod použil Claude Opus 5. Modely běžely se střední úrovní uvažování. Výsledky je proto nutné chápat jako laboratorní srovnání konkrétních workflow, nikoli jako záruku pro každý repozitář.

• Terminal-Bench 2.1: o 67 % nižší odhadované náklady a o 4,9 procentního bodu vyšší ověřená kvalita než u Claude Opus 5.
• DeepSWE: o 36 % nižší odhadované náklady, ale kvalita byla o 1,5 procentního bodu nižší.
• CheckpointBench: o 65 % nižší odhadované náklady a kvalita nižší pouze o 0,1 procentního bodu.

Nejdůležitější je právě druhá část tabulky. HydraFusion není automaticky lepší ve všech úlohách. Na Terminal-Bench 2.1 překonal referenční model při výrazně nižších nákladech. Na DeepSWE kvalitu mírně ztratil. U CheckpointBench se výsledek prakticky vyrovnal, přestože odhadované náklady klesly o 65 %.

GitHub do testů zahrnul také GPT-5.6 Sol jako jednu z porovnávaných základních konfigurací, ale zveřejněné shrnutí uvádí hlavní relativní čísla vůči Claude Opus 5. Detailní výsledky tedy nelze poctivě převést na jednoduché tvrzení, že HydraFusion poráží všechny konkurenční modely ve všech kategoriích.

Podrobnosti o metodice a dalších výsledcích jsou uvedeny v oficiálním oznámení GitHubu. Základní popis výsledků zveřejnil také MarkTechPost.

Dostupnost v Česku a cena

HydraFusion je od 4. září 2026 dostupný jako research preview v GitHub Copilot CLI. GitHub uvádí dostupnost pro uživatele všech plánů Copilot. Aktivace probíhá přímo v příkazové řádce:

1. spustit příkaz /update,
2. zapnout experimentální funkce pomocí /experimental on,
3. příkazem /model vybrat HydraFusion (Research Preview).

Pro české vývojáře je podstatné, že nejde o službu omezenou pouze na Spojené státy. Dostupnost v konkrétním účtu se však může řídit podporou GitHub Copilot a nastavením organizace. Zdrojové oznámení nepotvrzuje samostatnou českou lokalizaci rozhraní HydraFusion. Není proto správné tvrdit, že nástroj nabízí plnohodnotné české rozhraní nebo českou dokumentaci.

HydraFusion nemá vlastní jednoduchou cenu typu „X dolarů měsíčně“. Účtování probíhá podle tokenů spotřebovaných modely, které konkrétní workflow vyvolá, a podle standardních sazeb těchto modelů. Výsledná cena proto závisí na tom, zda systém použije jeden model, přidá kritiku, zopakuje návrh nebo úkol eskaluje k výkonnějšímu modelu. Aktuální přehled je v dokumentaci GitHubu k modelům a cenám Copilotu.

Co HydraFusion skutečně mění

Největší změnou není další název v nabídce modelů. HydraFusion přesouvá rozhodování z rukou vývojáře do samotného runtime systému. Uživatel nemusí předem odhadovat, zda je problém vhodný pro rychlý model, silnější model nebo kontrolu druhým modelem.

To může být užitečné hlavně u práce s celými repozitáři, kde je rozdíl mezi „napiš funkci“ a „najdi příčinu chyby, uprav několik souborů a zachovej kompatibilitu testů“ značný. Druhý úkol není jen delší prompt. Vyžaduje plánování, práci s nástroji, kontrolu změn a někdy i návrat k předchozímu kroku.

Zároveň ale zůstává několik limitů. HydraFusion je zatím výzkumný náhled pouze v Copilot CLI. Nejde o otevřený model, nejsou k dispozici open weights ani samostatná cesta pro vlastní nasazení. Benchmarky jsou offline a některé výsledky ukazují, že nižší cena může jít za cenu mírně horší kvality.

Za rozumný závěr proto považuji následující: GitHub netvrdí, že jeden model vyřeší všechno lépe. Zkouší, zda dobře navržený tým modelů dokáže pro konkrétní úkol nabídnout lepší poměr kvality, rychlosti a ceny. U programování je to logický směr. Stejně jako není nutné posílat každou reklamaci k firemnímu řediteli, není nutné každý drobný bug řešit nejdražším dostupným modelem.

FAQ