GitHub testa HydraFusion, que roteia seu prompt entre vários modelos de IA
Research preview do Copilot monta plano de execução dinâmico entre modelos de fornecedores diferentes e promete cortar custo mantendo qualidade. Já dá pra ligar no CLI.
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":
- Contabilidade completa: rastreia custo em tokens e uso em cada perna do fluxo (rascunho, crítica, revisão, escalonamento, retry e fallback).
- Execução limitada (bounded execution): timeouts estritos e handles de cancelamento.
- Passos de revisão isolados: impedem ações modificadoras dentro de um ambiente sem ferramentas.
- Aplicação à prova de falha: rejeita patches se a validação falhar ou a execução for cancelada.
- 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:
| Benchmark | Qualidade vs. baseline | Custo estimado |
|---|---|---|
| TerminalBench 2.1 | +4,9 pontos percentuais em qualidade de tarefa verificada | 67% menor que Claude Opus 5 |
| CheckpointBench | empate técnico (diferença de 0,1 p.p.) | 65% menor |
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 interfaceO 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
Este artigo foi escrito por Redação iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Baeta. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
Comentários
Ninguém comentou ainda. Começa a conversa?