AIREITERUma tarefa de programação pode parecer trivial até esbarrar em uma dependência entre arquivos. O Project HydraFusion escolhe o fluxo que, na visão do sistema, tem mais chances de atingir o nível de qualidade necessário — mas a versão de pesquisa ainda não revela o caminho exato nem garante a mesma economia em todos os repositórios.
Como funciona a decisão de roteamento
O Project HydraFusion é uma camada de orquestração em tempo de execução dentro do GitHub Copilot CLI, não um novo modelo de base. Você seleciona o HydraFusion (Research Preview); o runtime escolhe os modelos e a forma de execução.
| Fluxo | Sequência de execução | Principal benefício | Principal desvantagem |
|---|---|---|---|
| Single | Um único modelo selecionado resolve a tarefa diretamente. | Menor sobrecarga de fluxo e caminho de latência mais simples. | Não há escalonamento automático nem revisão independente. |
| Cascade | Um modelo eficiente cria o primeiro resultado; um controle de qualidade o aprova ou encaminha a tarefa para um modelo mais forte. | Evita usar o modelo mais potente quando a primeira tentativa já é suficiente. | Uma reprovação pode acrescentar chamadas de modelo, tokens e tempo de espera. |
| Critique | Um modelo produz o rascunho; um crítico independente, de outra família de modelos, faz a revisão; depois, o modelo responsável pela solução revisa o resultado uma vez. | Acrescenta uma segunda perspectiva para mudanças mais sujeitas a erros. | Adiciona trabalho serial, e o crítico não pode executar ferramentas nem editar o repositório. |
Para testar a versão de prévia, execute /update, depois /experimental on, em seguida /model e selecione HydraFusion (Research Preview). O GitHub documenta essa sequência no anúncio oficial do HydraFusion. A versão de prévia está disponível em todos os planos do Copilot, embora o acesso gerenciado pela organização possa depender da política do Copilot CLI configurada pelo administrador.
Esses são padrões de execução, não três comandos públicos para forçar manualmente uma solicitação. O material de lançamento descreve a seleção do HydraFusion e deixa o runtime equilibrar desempenho, custo e latência.
O que o runtime tenta prever
Segundo o GitHub, o HydraFusion usa sinais de capacidade relacionados a raciocínio, geração de código, depuração e uso de ferramentas. A partir deles, escolhe o padrão de execução mais eficiente que, na estimativa do sistema, deve atingir o nível de qualidade exigido pela solicitação. O GitHub, porém, não publica os limiares nem uma regra determinística como “três arquivos significam Cascade”.
Por isso, o formato da tarefa serve como referência, não como garantia de roteamento: uma edição pequena, com caminho de teste evidente, combina conceitualmente com Single; uma solicitação potencialmente difícil se encaixa no escalonamento seletivo do Cascade; e uma mudança que se beneficia de uma revisão independente combina com Critique. O anúncio não traz uma lista fixa de modelos para cada solicitação nem um rastreamento legível da rota.
Dá para forçar Single, Cascade ou Critique?
O GitHub documenta a seleção do HydraFusion e a escolha do fluxo pelo runtime; não há documentação de um comando público para forçar um dos três padrões. Quando o roteamento previsível for importante, use um modelo fixo do Copilot.
Quando cada fluxo justifica uma chamada extra
Single: execução direta quando o caminho está claro
O Single encaminha a tarefa para um único solucionador dentro do fluxo normal de agente do Copilot, que respeita as permissões configuradas. É adequado para uma edição pequena e bem especificada, uma explicação curta ou uma correção com implementação e caminho de teste claros.
A vantagem está em um perfil de custo e latência mais simples. O fluxo não adiciona deliberadamente uma etapa de controle de qualidade nem uma segunda opinião — portanto, o desenvolvedor continua sendo o principal responsável pela revisão caso o solucionador interprete a tarefa de forma errada.
Cascade: só escale quando a primeira tentativa não for suficiente
O Cascade começa com um modelo eficiente. Um controle de qualidade avalia o resultado produzido e pode encaminhar a tarefa para um modelo mais forte quando a primeira tentativa não atinge o nível esperado.
A lógica econômica é condicional:
- O primeiro modelo cuida das tarefas que consegue concluir adequadamente.
- O controle de qualidade filtra resultados fracos ou incertos.
- Apenas as tarefas que precisam de mais capacidade seguem pelo caminho mais potente.
Isso pode reduzir o custo médio do fluxo em comparação com o envio de todas as tarefas para um modelo de fronteira. Ainda assim, um escalonamento, uma nova tentativa ou um fallback pode criar uma cauda mais cara e lenta, e o GitHub não publicou uma taxa universal de escalonamento para o planejamento específico de cada repositório.
Critique: pague por uma segunda perspectiva
O Critique funciona como um ciclo de rascunho, revisão e nova versão. O primeiro solucionador cria o resultado; um crítico de outra família de modelos o analisa em um contexto isolado, sem ferramentas e somente de leitura; depois, o solucionador original faz uma revisão única.
O crítico não pode executar os testes do projeto, inspecionar um arquivo gerado por meio de um comando nem aplicar a correção por conta própria. O Critique oferece diversidade na revisão, não uma implementação independente de ponta a ponta.
O balanço dos benchmarks: custo menor não significa uma única promessa de qualidade
O GitHub avaliou políticas fixas do HydraFusion em comparação com o Claude Opus 5 em três benchmarks de programação com agentes. Os números abaixo vêm do anúncio oficial do GitHub.
| Benchmark | Qualidade do HydraFusion vs. Claude Opus 5 | Custo estimado do fluxo vs. Claude Opus 5 | Leitura prática |
|---|---|---|---|
| TerminalBench 2.1 | +4,9 pontos percentuais | 67% menor | Maior qualidade verificada das tarefas a um custo estimado menor nesta avaliação. |
| DeepSWE | −1,5 ponto | 36% menor | Uma economia relevante, acompanhada de uma concessão mensurável de qualidade em trabalhos difíceis de repositório. |
| CheckpointBench | −0,1 ponto | 65% menor | Qualidade praticamente equivalente a um custo estimado substancialmente menor. |
Os resultados mistos de qualidade são justamente o ponto central: o HydraFusion foi pensado para acrescentar inferência quando o ganho esperado de qualidade justificar o custo e a latência, não para usar mais modelos em toda solicitação.
O GitHub afirma que manteve consistentes as entradas, as ferramentas, os limites de execução, os preços e a avaliação, contabilizando as etapas de rascunho, crítica, revisão, escalonamento, nova tentativa e fallback. Ainda assim, são estimativas controladas e offline, vinculadas às políticas avaliadas, ao conjunto de modelos, às versões dos benchmarks e às premissas de preço.
Esses dados não mostram que uma tarefa comum do Copilot custará 67% menos nem que o HydraFusion superará o Claude Opus 5 em uma determinada base de código. Enquanto testa a versão de prévia em cargas de trabalho reais, o GitHub recomenda começar com tarefas substanciais, bem delimitadas e realizadas na primeira interação, que caibam em um único prompt.
A equação de custo tem três componentes
Ao avaliar o HydraFusion, separe o custo esperado de tokens, o custo da cauda e o tempo de espera.
| Fator | Single | Cascade | Critique |
|---|---|---|---|
| Trabalho inicial | Um solucionador | Primeiro, um solucionador eficiente | Primeiro, o solucionador que cria o rascunho |
| Trabalho extra | Nenhum por definição | Modelo mais forte após uma reprovação no controle | Crítico e uma revisão do solucionador |
| Formato do custo | Mais previsível | Condicional; aumenta com escalonamento ou nova tentativa | Estruturalmente maior que o de um rascunho direto |
| Formato da latência | Caminho mais simples | Curto quando aprovado; mais longo após escalonamento | A revisão e a nova versão prolongam o caminho |
| Mecanismo de qualidade | Capacidade do solucionador | Controle de qualidade e escalonamento | Revisão independente e nova versão |
Um custo estimado menor não significa automaticamente uma resposta mais rápida: o Cascade pode tornar os casos escalonados mais lentos, o Critique adiciona uma revisão serial e o Single responde rapidamente, mas deixa mais validação a cargo do desenvolvedor.
A documentação de uso do Copilot CLI do GitHub informa que o comando /usage exibe a duração da sessão, os AI Credits consumidos, as linhas editadas e o detalhamento do uso de tokens por modelo. Essas informações ajudam a comparar tarefas reais, mas não explicam todas as decisões de roteamento nem mostram os rascunhos intermediários descartados.
A caixa-preta entre o prompt e o patch
O GitHub descreve uma contabilização completa das etapas do fluxo, execução limitada com comportamento de timeout e cancelamento, revisão isolada, roteamento validado e aplicação segura do patch depois de fluxos inválidos ou cancelados. Esses controles reduzem o risco operacional, mas não provam que a rota ou o código final estejam corretos.
O GitHub também afirma que a versão de prévia mantém os rascunhos intermediários até conseguir devolver um único resultado coerente. Isso dificulta saber se uma tarefa permaneceu no Single, foi escalonada pelo Cascade ou passou pelo Critique e por uma revisão.
Um usuário real apontou diretamente essa lacuna de observabilidade:
“O próximo recurso que eu gostaria de ver no produto é um rastreamento legível mostrando qual modelo fez o quê e por que o roteador mudou de caminho.” — @_Mazzana no X
Sem um comprovante da rota, os desenvolvedores não conseguem relacionar completamente o custo, a latência e o patch final de uma tarefa ao fluxo que os produziu.
Como testar a versão de prévia sem tirar conclusões precipitadas
Trate o HydraFusion como um experimento antes de transformá-lo no padrão da equipe:
- Crie uma branch ou worktree limpa e registre o commit inicial.
- Teste uma correção rotineira, uma mudança entre arquivos e uma tarefa ambígua com um critério de aceitação reproduzível.
- Inclua o comportamento esperado, as restrições e os comandos de teste no primeiro prompt.
- Inspecione o diff final, verifique se houve alterações em arquivos não relacionados e execute você mesmo os testes relevantes.
- Registre a duração da sessão, o uso visível de AI Credits ou tokens, o resultado dos testes e qualquer sinal visível de nova tentativa ou escalonamento.
- Repita o processo em várias tarefas antes de comparar o HydraFusion com um modelo fixo.
Não tente deduzir o modo oculto apenas pelo tamanho da resposta. Uma resposta longa pode refletir a complexidade do repositório, e não o uso do Critique. Mantenha um fallback com modelo fixo para trabalhos longos, com várias interações, sensíveis à latência ou de alto impacto: o GitHub recomenda tarefas na primeira interação para a versão de prévia atual e aponta o desempenho melhor em interações múltiplas como foco futuro em suas orientações de lançamento.
FAQ do HydraFusion
Posso selecionar manualmente Single, Cascade ou Critique?
Não por meio de um comando de modo do HydraFusion documentado. O controle disponível atualmente é selecionar o HydraFusion e deixar o runtime escolher; quando o roteamento determinístico for importante, use um modelo fixo.
Como o HydraFusion é cobrado?
O GitHub afirma que o uso se baseia nos tokens consumidos pelos modelos utilizados pelo HydraFusion, cobrados pela tarifa padrão de cada modelo, conforme descrito no anúncio oficial. Uma redução observada em benchmark não representa um desconto universal para clientes, e fluxos com várias etapas podem consumir mais do que uma solicitação direta.
O HydraFusion é mais interessante quando a tarefa é importante o bastante para se beneficiar de escalonamento ou revisão seletiva, mas estruturada o suficiente para ser verificada. Em trabalhos rápidos, a simplicidade do Single pode pesar mais; em tarefas longas ou de alto risco, o comportamento previsível de um modelo fixo ainda pode ser a melhor escolha operacional até que as evidências do repositório justifiquem a orquestração adicional.