HydraFusion é uma prévia de pesquisa do GitHub Copilot CLI que escolhe entre três fluxos: um modelo resolve sozinho, um modelo econômico tenta antes de uma possível escalada, ou um modelo produz e outro critica antes da revisão. O GitHub relatou reduções de custo estimado entre 36% e 67% em três benchmarks, com diferenças de qualidade de menos 1,5 a mais 4,9 pontos em relação ao Claude Opus 5. Esses números não são uma promessa para o seu repositório; servem para desenhar um piloto controlado.
Entenda o que a orquestração está fazendo
Em vez de pedir que a pessoa escolha um modelo para cada tarefa, HydraFusion seleciona um padrão de execução. No fluxo Single, um modelo responde diretamente. No Cascade, uma opção mais eficiente cria a primeira solução e um controle decide se é necessário escalar. No Critique, um segundo modelo, de outra família e sem ferramentas, revisa a proposta antes de uma única correção.
A ideia é gastar mais inferência somente quando ela pode melhorar o resultado. Para a empresa, isso desloca a decisão de compra: o foco deixa de ser apenas qual modelo foi usado e passa a incluir política de roteamento, critérios de aceitação, custo total e rastreabilidade de cada etapa.
Leia os resultados com o denominador correto
No TerminalBench 2.1, a configuração apresentada pelo GitHub teve qualidade verificada 4,9 pontos superior e custo estimado 67% menor que o Claude Opus 5. No DeepSWE, o custo foi 36% menor com qualidade 1,5 ponto inferior. No CheckpointBench, o custo caiu 65% e a qualidade ficou 0,1 ponto abaixo.
Os testes foram offline, com revisões específicas dos benchmarks, pool de modelos, políticas e premissas de preço definidos pelo GitHub. Todos usaram o mesmo nível médio de raciocínio, mas o CheckpointBench é interno. Os resultados ajudam a formular hipóteses; não permitem prever custo, latência ou taxa de acerto no código da sua empresa.
Escolha tarefas adequadas para o primeiro piloto
O próprio GitHub recomenda começar com tarefas substanciais, bem delimitadas e de um único pedido no modo autônomo. Selecione mudanças com teste automatizado e reversão simples, como corrigir um bug reproduzível, atualizar uma integração isolada ou refatorar uma função com comportamento coberto.
Evite usar a prévia como primeira experiência em migração crítica, incidente de produção ou código sem testes. Um piloto precisa de conjunto fixo de tarefas, estado imutável do repositório e critérios definidos antes da execução. Assim, a equipe compara soluções equivalentes e não apenas impressões.
- Tarefa reproduzível e com escopo fechado
- Commit inicial fixado para todas as execuções
- Teste ou verificação objetiva de conclusão
- Limite de tempo e custo por tentativa
- Revisão humana antes de integrar a mudança
Calcule o custo completo do fluxo
A prévia cobra de acordo com os tokens consumidos pelos modelos usados, nas taxas padrão de cada modelo. Portanto, registre todas as etapas: rascunho, crítica, revisão, escalada, nova tentativa e fallback. Comparar apenas a primeira chamada subestima justamente o trabalho que a orquestração adiciona.
Inclua também tempo de revisão, execução de testes e correções posteriores. Uma solução mais cara por sessão pode ser mais barata se reduzir retrabalho; uma solução aparentemente econômica pode perder valor quando exige muita intervenção. Use custo por tarefa aceita, não custo por resposta produzida.
Meça qualidade, latência e segurança juntas
Defina sucesso como uma combinação: testes aprovados, aderência ao escopo, ausência de regressão, revisão aceita e tempo até integração. Registre latência do início ao resultado e tempo humano de revisão. Para segurança, verifique dependências, permissões, segredos e alterações fora dos arquivos previstos.
O GitHub descreve execução limitada, crítica isolada, aplicação segura de patches e validação das políticas como princípios do sistema. Mesmo assim, a empresa continua responsável pelo repositório e pelo uso. Proteções do produto não substituem branch protegida, integração contínua e aprovação adequada.
Compare com uma referência justa
Execute o mesmo lote com o fluxo atual da equipe e com HydraFusion. Mantenha tarefa, commit, ferramentas, tempo disponível e definição de pronto. Se a comparação muda modelo, instrução e teste ao mesmo tempo, o ganho não pode ser atribuído à orquestração.
Use amostra suficiente para incluir tarefas simples, médias e difíceis. Analise distribuição, não apenas média. Uma política pode economizar muito em tarefas fáceis e falhar de forma cara nas raras mudanças críticas. Separe também falhas do modelo, do ambiente e da avaliação.
Como acessar a prévia sem tratar experimento como padrão
Segundo o GitHub, HydraFusion está disponível em todos os planos do Copilot por meio da área experimental no Copilot CLI. O roteiro oficial é atualizar o CLI, ativar recursos experimentais e selecionar HydraFusion como modelo. Disponibilidade, nome, modelos e comportamento podem mudar durante a pesquisa.
Crie um grupo pequeno, limite os repositórios e documente como sair da prévia. Não altere o fluxo de toda a engenharia com base em um único resultado positivo. A decisão de ampliar deve considerar estabilidade, previsibilidade financeira, qualidade e capacidade de auditoria.
Limitações e cuidados
HydraFusion é uma prévia de pesquisa, com foco inicial em pedidos únicos. O GitHub informa que desempenho em sessões longas e iterativas ainda é área de desenvolvimento. Resultados, modelos, políticas, preços e disponibilidade podem mudar.
Benchmarks não reproduzem toda a base de código, dependências e riscos de uma empresa. Não envie segredos ou dados incompatíveis com as políticas internas. Mantenha revisão independente e acompanhe custo real por equipe antes de negociar orçamento ou produtividade prometida.
Para levar daqui
HydraFusion transforma a seleção de modelos em uma política de execução. O valor só aparece quando a empresa mede custo total, qualidade verificada, latência e esforço humano no mesmo conjunto de tarefas, com limites e reversão definidos.
