Em 4 de setembro de 2026, a GitHub anunciou o Project HydraFusion, um projeto disponibilizado como prévia de pesquisa dentro do GitHub Copilot para orquestrar modelos de inteligência artificial de vários provedores durante a execução de tarefas de programação. Em vez de escolher previamente um único modelo, o HydraFusion cria um plano de execução e determina se a tarefa precisa de uma solução direta, de uma revisão independente ou de ser escalada para um modelo mais capaz.
A iniciativa vem após o recurso Auto model selection, lançado pela GitHub no início do ano para escolher o modelo mais adequado para cada tarefa. No entanto, o HydraFusion amplia a ideia da seleção de um modelo para a criação de um fluxo de trabalho completo que equilibra a qualidade do resultado, o custo e o tempo de resposta, enquanto a complexidade operacional permanece oculta para o desenvolvedor que escolhe o HydraFusion da mesma forma que escolhe qualquer outro modelo no Copilot.
Três caminhos para executar a tarefa
O sistema avalia sinais relacionados ao raciocínio, à geração de código, à depuração e ao uso de ferramentas, e então escolhe um dos três modos de execução:
- Single: um único modelo assume a resolução direta da tarefa quando sua capacidade é suficiente.
- Cascade: um modelo mais eficiente começa elaborando a solução; em seguida, um portão de qualidade decide se ela será aprovada ou se a tarefa será encaminhada a um modelo mais poderoso.
- Critique: um modelo elabora uma solução inicial; depois, um modelo independente de uma família diferente a revisa em um contexto somente leitura, antes que o primeiro modelo faça uma única revisão da solução.
A GitHub afirma que o objetivo da seletividade é usar chamadas adicionais apenas quando se espera que elas melhorem o resultado. Dessa forma, o caminho direto preserva a velocidade e a eficiência, enquanto os outros dois acrescentam revisão ou escalonamento às tarefas que podem se beneficiar deles.
O que os testes mostraram
A GitHub avaliou políticas fixas do HydraFusion em três testes de agentes de programação: TerminalBench 2.1, DeepSWE e o CheckpointBench interno, baseado em sessões reais no GitHub Copilot. Os resultados foram comparados com duas linhas de base: Claude Opus 5 e GPT-5.6 Sol, usando entradas, ferramentas, limites de execução, premissas de preços e condições de avaliação idênticos.
No TerminalBench 2.1, o HydraFusion alcançou uma melhoria de 4,9 pontos percentuais na qualidade das tarefas verificadas, com uma redução de 67% no custo estimado do fluxo de trabalho em comparação com o Claude Opus 5. No DeepSWE, que se concentra em tarefas de engenharia de software no nível do repositório e na compreensão das dependências entre arquivos, o sistema ficou 1,5 ponto percentual atrás do Opus 5, com um custo 36% menor. Já no CheckpointBench, a diferença de qualidade foi de apenas 0,1 ponto percentual, com redução de custo de 65%.
A contabilização de custos inclui todas as etapas da execução, incluindo elaboração, revisão, edição, escalonamento, novas tentativas e planos de fallback. No entanto, a GitHub descreve esses resultados como testes off-line, limitados pelas versões dos testes, pelas configurações dos fluxos de trabalho, pelo conjunto de modelos e pelas premissas de preços utilizadas.
Controles operacionais e limites da prévia
A GitHub projetou o HydraFusion com controles que incluem o registro do custo e do uso de cada etapa, a definição de limites de tempo para cancelamento e execução e o isolamento das etapas de revisão em contextos sem ferramentas e sem possibilidade de modificar o repositório. O sistema também verifica previamente as definições dos fluxos de trabalho, o vínculo entre modelos, o comportamento dos substitutos e a disponibilidade dos modelos, e não aplica nenhuma correção se a operação for cancelada ou se o processo de verificação falhar.
A GitHub recomenda atualmente começar a experimentar com tarefas de programação grandes e bem definidas, enviadas em um único prompt ao Copilot no modo de operação automática. Posteriormente, a empresa pretende se concentrar na melhoria do desempenho de sessões com várias etapas e de maior duração. A empresa também alerta que os modelos, os fluxos de trabalho, os nomes, a disponibilidade e o comportamento do produto podem mudar durante o período de prévia.
Leitura editorial: da escolha do modelo ao projeto do fluxo de trabalho
A mudança mais importante aqui não é a adição de um novo modelo, mas a transferência da decisão de execução do desenvolvedor para uma camada de orquestração que decide quando uma única tentativa é suficiente e quando a tarefa justifica o custo de uma revisão ou de um escalonamento. Se os resultados dos testes se refletirem no uso real, isso poderá proporcionar aos desenvolvedores uma qualidade próxima à dos modelos mais poderosos em algumas tarefas, sem que seu custo seja pago em cada solicitação.
Mas os números ainda não comprovam uma superioridade geral em todos os padrões de programação; eles estão vinculados a testes específicos, políticas controladas e resultados off-line. Continuam em aberto as questões sobre tempo de resposta, confiabilidade, comportamento do sistema em sessões longas, eficiência do cache e segurança — aspectos que, segundo a GitHub, serão medidos durante a prévia.