O seletor de modelos está virando um seletor de orquestração

O GitHub tirou o HydraFusion da linha de comando e o levou para o editor em 30 de setembro. A prévia de pesquisa agora roda no VS Code 1.140 e versões posteriores, e no aplicativo GitHub Copilot, o que coloca uma ideia bastante incomum diante de desenvolvedores comuns: pare de escolher um modelo, escolha um fluxo de trabalho.

O HydraFusion não é um modelo. É uma camada que decide, a cada turno, quantos papéis de modelo a tarefa precisa.

Três formatos para uma solicitação

Single é o caso familiar. Um modelo trata a solicitação, do jeito que o Copilot Auto já funciona.

Cascade começa barato. Um modelo eficiente escreve um primeiro rascunho, e um portão de qualidade ou o aceita ou escala o trabalho para um modelo mais forte. O objetivo é manter edições rotineiras em modelos baratos e reservar os caros para problemas que realmente precisam deles.

Critique gasta mais para ser mais seguro. Um modelo faz o rascunho, um segundo modelo de uma família diferente atua como crítico somente leitura, e o modelo que fez o rascunho revisa uma vez com base nesse feedback. O crítico nunca toca no código, o que impede que o ciclo vire dois modelos discutindo.

A diferença em relação ao Auto é arquitetural. O Auto decide qual modelo único deve receber seu prompt. O HydraFusion decide quantos papéis o turno precisa e como eles interagem. Isso é uma mudança significativa em onde mora o controle da inteligência. Historicamente, você escolhia um modelo porque ele era melhor no seu tipo de trabalho. Aqui, você escolhe uma política de otimização e deixa a plataforma compor os modelos por baixo.

A economia é real e também autodeclarada

O problema está na cobrança. O GitHub cobra por tokens à tarifa padrão de cada modelo selecionado. Uma execução do Critique chama pelo menos dois modelos, então pode custar mais por solicitação do que uma chamada única. O Cascade foi projetado para custar menos, empurrando o trabalho fácil para baixo. A economia não é um desconto em nenhum modelo. É uma aposta de que a maioria dos turnos não precisa do melhor modelo.

As próprias avaliações controladas do GitHub relataram reduções de custo de fluxo de trabalho de 36 a 67 por cento em relação à sua linha de base Claude Opus 5 em três benchmarks de agente de codificação, com qualidade 4,9 pontos percentuais maior no TerminalBench 2.1, 1,5 ponto menor no DeepSWE e 0,1 ponto menor no CheckpointBench. Esses são números produzidos pelo fornecedor no próprio ambiente de teste do GitHub. Eles são uma hipótese sobre o seu repositório, não uma garantia, e o conjunto de modelos que participam do HydraFusion ainda não foi totalmente publicado. Qualquer coisa construída sobre a prévia deve tratar o comportamento de roteamento como algo que pode mudar sem aviso.

Há também um custo simples de latência. Um rascunho mais uma revisão leva mais tempo do que uma única resposta. Equipes nos planos Business e Enterprise precisam acompanhar de perto os painéis de uso, porque o sistema decide quando escalar e essa decisão não é gratuita.

Uma otimização que você não consegue inspecionar é difícil de confiar

A parte incômoda do roteamento é que quem toma a decisão é a plataforma, não o desenvolvedor. Você consegue ver qual modelo respondeu depois do fato, mas não consegue ver facilmente por que o sistema escolheu um fluxo de trabalho, o que o portão de qualidade mediu, ou quão perto uma execução do Cascade chegou de escalar. As alegações de benchmark do GitHub descrevem uma média em seu próprio conjunto de testes, e médias escondem os casos que importam.

Essa lacuna transforma a orquestração em um problema de governança, e não puramente técnico. Uma equipe de engenharia que precisa explicar por que um determinado pull request foi revisado por duas famílias de modelos e cobrado de acordo precisa de telemetria de roteamento, e a prévia ainda não a expõe. O remédio não é evitar o recurso. É testá-lo como você testaria qualquer dependência cujo funcionamento interno é oculto: em um conjunto fixo e entediante de tarefas de repositório, medindo o custo de tarefas concluídas em comparação com um único modelo de ponta, e observando repetições e esforço de revisão em vez do preço de etiqueta de uma seleção.

A comparação com o Auto vale a pena manter. O Auto responde a uma pergunta sobre qual modelo é mais adequado a um prompt. O HydraFusion responde a uma pergunta sobre quanto processo um turno merece, e processo sempre foi a parte cara do trabalho de software.

O efeito colateral curioso é que isso torna a escolha de modelo menos emocional. Desenvolvedores criam apego a modelos específicos, e esses apegos geralmente se baseiam em um punhado de sucessos memoráveis. Um sistema que roteia por tipo de tarefa e escala em caso de falha reconhece discretamente que nenhum modelo único vence em todas as categorias, o que já é verdade há um tempo e raramente é levado em conta.

O próximo canto do editor está sendo construído para isso

A compilação Insiders já mostra aonde isso vai em seguida. Um recurso chamado Compare Agents, rotulado Run Multiple Agents, envia um prompt para vários agentes em paralelo, cada um em seu próprio worktree do git, e então um agente árbitro escolhe um vencedor ou entrega a lista de finalistas a uma pessoa.

O detalhe interessante é o que o árbitro analisa. Ele compara arquivos alterados e estatísticas de diff, resultados de testes, status de build, diagnósticos, tempo e diferenças arquiteturais. Ele executa a suíte de testes. Não pede a outro modelo de linguagem para ler o código e adivinhar. Essa é uma pequena decisão com grandes consequências, porque significa que a comparação está fundamentada no estado real do projeto, e não na opinião de um modelo sobre ele.

O restante da mesma versão é infraestrutura mais discreta que só importa quando agentes rodam em paralelo. Sessões com várias pastas permitem que cada conversa em uma sessão use sua própria pasta ou worktree, para que as alterações parem de colidir. A delegação remota entrega uma tarefa a um host de agente remoto conectado. Pastas de worktree compartilhadas reutilizam diretórios ignorados para evitar reinstalar dependências em cada branch. Os Dev Containers agora param após cinco minutos de inatividade e reiniciam sob demanda.

A governança continua chegando nos mesmos commits que os recursos

A metade da versão voltada para TI não é um complemento de última hora. Quando recursos de IA estão indisponíveis, o editor agora informa a versão mínima necessária em vez de um aviso genérico para atualizar. Administradores podem definir um nível padrão para o modelo Auto. Uma nova configuração do OpenTelemetry mapeia o uso do Copilot de volta para desenvolvedores individuais.

Leia esses três juntos e o formato fica claro. Uma plataforma que coordena vários modelos ao longo de vários turnos gera custos, telemetria e questões de permissão que um autocomplete de modelo único nunca gerou. A atribuição de custos deixa de ser uma curiosidade financeira e se torna um pré-requisito para deixar o recurso chegar perto de produção.

A revisão com vários modelos já é prática padrão entre equipes de engenharia cuidadosas há algum tempo. Você pede a um modelo que escreva e a outro que procure erros, ou tenta um modelo rápido primeiro e escala quando a saída decepciona. O HydraFusion pega esse hábito e o torna automático, o que é conveniente e também remove uma decisão que algumas equipes gostavam de tomar manualmente.

Por quanto tempo um recurso de prévia deve permanecer como prévia é uma pergunta justa. As ferramentas estão chegando mais rápido do que a política ao redor delas, e a previsibilidade de preços é a primeira vítima. Uma execução do Critique que, silenciosamente, chama dois modelos de ponta em um repositório grande pode gastar dinheiro de verdade antes que alguém perceba. Se o HydraFusion se tornará padrão depende menos de o roteamento funcionar e mais de o GitHub conseguir deixar a conta legível o suficiente para alguém assiná-la.