GitHub testa HydraFusion, que roteia seu prompt entre vários modelos de IA

O GitHub anunciou o Project HydraFusion, uma research preview do Copilot que trata a execução de tarefas de código como um problema de otimização: em vez de mandar todo prompt para um único modelo fixo, ela monta em tempo de execução um plano usando modelos de vários fornecedores, escolhidos conforme a complexidade da tarefa. A novidade foi noticiada pela InfoQ e já está disponível como preview em todos os planos do Copilot, acessível pela configuração /experimental dentro do GitHub Copilot CLI.

O ponto que interessa para quem roda Copilot em produção não é mais um modelo novo, e sim uma camada de orquestração. HydraFusion avalia o prompt de entrada usando sinais explícitos de capacidade, pensados para operações complexas: raciocínio em múltiplos passos, geração automática de código, debugging estruturado e uso avançado de ferramentas. Com base nisso, decide como executar.

Os três padrões de execução

Em vez de um modelo estático, HydraFusion roteia a requisição por um de três padrões de runtime, segundo a complexidade e o contexto:

• Single: um único modelo selecionado executa direto, quando tem capacidade suficiente para resolver a tarefa sozinho. Otimiza velocidade e baixa latência.
• Cascade: um modelo mais eficiente (e barato) gera um rascunho da solução, que passa por um quality gate. Se atende aos requisitos, é aceito; se não, a tarefa escala para um modelo mais forte.
• Critique: um modelo redator produz uma solução inicial, avaliada por um modelo crítico independente, só leitura, de outra família de modelos e sem acesso a execução de ferramentas (o texto compara ao padrão Rubber Duck de revisão). O modelo original então faz uma única revisão estruturada com base nesse retorno.

Na prática, é a ideia de "nem toda tarefa precisa do modelo mais caro" transformada em arquitetura. Um autocomplete ou refactor trivial não justifica acionar um modelo de fronteira; uma correção de bug com várias etapas, sim, e ainda ganha uma segunda opinião antes de aplicar patch.

As cinco regras que sustentam a execução

O GitHub descreve cinco princípios operacionais que ancoram a arquitetura, e vale prestar atenção neles porque é aí que mora a diferença entre "demo" e "algo que roda em produção":

1. Contabilidade completa: rastreia custo em tokens e uso em cada perna do fluxo (rascunho, crítica, revisão, escalonamento, retry e fallback).
2. Execução limitada (bounded execution): timeouts estritos e handles de cancelamento.
3. Passos de revisão isolados: impedem ações modificadoras dentro de um ambiente sem ferramentas.
4. Aplicação à prova de falha: rejeita patches se a validação falhar ou a execução for cancelada.
5. Roteamento validado: checa disponibilidade e bindings do modelo antes de o runtime começar.

O destaque, para o dev que se preocupa com fatura, é a contabilidade por perna do fluxo. Como um único prompt pode passar por rascunho, crítica e revisão, o custo deixa de ser "uma chamada, um valor" e vira a soma de várias chamadas potencialmente em modelos diferentes. Ter isso rastreado por leg é o que permite entender de onde vem a conta.

Os números que o GitHub apresenta

Em avaliações offline controladas, sobre três benchmarks de coding agêntico, o GitHub afirma que os fluxos seletivos igualaram ou superaram a qualidade de baseline reduzindo custo estimado de forma substancial. Os dois resultados citados:

O CheckpointBench é um benchmark interno multi-turno, montado a partir de sessões reais e replayáveis de coding agêntico do próprio Copilot, ancoradas em repositórios públicos específicos e commits imutáveis. A referência de comparação em ambos os casos é o Claude Opus 5.

Um aviso editorial necessário: são números do próprio GitHub, em avaliação offline controlada, não medição independente. "Igualar qualidade cortando dois terços do custo" é a promessa central, e é exatamente o tipo de afirmação que só o uso real, com seu código e seu contexto, confirma ou desmente.

Como ligar no seu ambiente

O recurso está disponível como preview para usuários de todos os tiers do Copilot, via /experimental dentro do GitHub Copilot CLI. O caminho descrito é atualizar o CLI, ativar o modo experimental e escolher o HydraFusion na seleção de modelos:

# atualize o ambiente do CLI, então dentro da sessão:
/experimental on
/model   # selecione HydraFusion na interface

O faturamento segue as taxas de token padrão dos modelos efetivamente invocados durante a execução. Ou seja: não há preço fixo do HydraFusion, você paga o que cada perna do fluxo consumir nos modelos subjacentes. Daí a importância da tal contabilidade completa para não ser surpreendido.

O que muda para quem constrói no Brasil

Para times brasileiros que já pagam Copilot em produção, a leitura prática é dupla. De um lado, roteamento multi-modelo é uma forma de comprar performance de fronteira sem pagar preço de fronteira em toda requisição, o que importa num cenário em que o custo de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → é cobrado em dólar e cada chamada pesa no orçamento. De outro, a conta fica menos previsível: um prompt que escala de Cascade para o modelo forte, ou que aciona o padrão Critique, custa mais do que um Single. Para quem faz FinOps de IA, monitorar o consumo por perna deixa de ser opcional.

Vale também registrar o que segue em aberto. Não há data de disponibilidade geral (ainda é research preview), não sabemos quais modelos exatamente entram no pool de roteamento além da referência ao Opus 5, e os benchmarks são internos. O padrão Critique, com um modelo crítico read-only de outra família revisando o rascunho antes de aplicar patch, é o que mais promete em qualidade, mas é justamente o que mais adiciona chamadas, e portanto custo, por tarefa. Testar em tarefas representativas do seu repositório, comparando qualidade e fatura contra o seu modelo atual, é o único jeito honesto de saber se o trade-off compensa.

Fonte: InfoQ