HydraFusion Max não escolhe um modelo para sua tarefa. Ele planeja quem redige, quem julga e quem conserta

A primeira geração de roteamento de modelos fazia uma pergunta por requisição: qual modelo deve responder a isto? A atualização de 14 de outubro do GitHub para o HydraFusion, sua orquestração multi-modelo para o Copilot, faz uma pergunta diferente: qual modelo deve fazer qual parte do trabalho, e com que intensidade cada um deve pensar?

O HydraFusion agora recorre a um pool de Claude Opus 5.5, GPT-6 Astra, GPT-6.1 Sol e GPT-6 Luna, e o GitHub adicionou uma opção Max ajustada para as tarefas mais exigentes, com maior esforço de raciocínio onde a profundidade importa, enquanto a orquestração ainda pondera a eficiência de tokens. Ambos permanecem em preview de pesquisa, para os planos Copilot Pro, Pro+, Business e Enterprise com recursos experimentais ou preview habilitados, e sujeitos às políticas de modelo da organização.

O que mudou nos workflows

Dois padrões de orquestração foram reformulados, e eles mostram para onde o design está indo.

1. Redigir com esforço de raciocínio médio
2. Um juiz inspeciona o trabalho inicial
3. Reparo solicitado apenas se necessário

Gasto com produçãoGasto com verificação

Cascade costumava deixar um modelo inicial tentar uma tarefa e escalar para um modelo mais forte quando necessário. Agora ele adiciona uma etapa de julgamento que inspeciona o trabalho inicial e pede um reparo apenas se necessário. Critique costumava depender fortemente de resumos de texto do trabalho; agora ele usa ferramentas que inspecionam o workspace real e executa vários modelos críticos em paralelo. E o esforço de raciocínio não é mais o padrão de cada modelo: o HydraFusion define esforço médio para rascunhos iniciais e esforço alto para revisão.

Cada uma dessas escolhas move o gasto de produção para verificação. Os rascunhos ficam mais baratos; o julgamento ganha mais atenção. É uma estratégia de execução, não uma escolha de modelo.

Por que críticos que leem o workspace importam

Um revisor que apenas lê um resumo de uma mudança revisa o relato do autor sobre o trabalho, não o trabalho. Críticos que inspecionam arquivos, executam ferramentas e veem o repositório podem capturar o que o resumo deixou de fora. É a mesma distinção entre uma alegação e evidência que perpassa uma boa revisão de código humana, e é uma melhoria real em um sistema que revisa a si mesmo.

Ainda é o sistema revisando a si mesmo. Críticos paralelos extraídos do mesmo pool de modelos são uma verificação mais forte do que um único crítico, mas não são independentes no sentido de um teste determinístico ou de um responsável humano. Trate a revisão interna do HydraFusion como melhoria de qualidade antes do pull request, não como substituto da revisão depois dele.

Como avaliar

Mais chamadas de modelo por tarefa podem aumentar a qualidade, o custo ou ambos. O changelog do GitHub não fornece preços ou uma comparação de custo para a opção Max, então a economia precisa ser medida no seu próprio trabalho:

1. Escolha um conjunto fixo de tarefas reais dos seus repositórios, com resultados bons conhecidos, e execute-as no seu padrão atual, no HydraFusion e no Max.

2. Meça o custo por mudança aceita, não o custo por requisição. Uma execução que custa três vezes mais e faz merge sem retrabalho pode ser mais barata do que três tentativas baratas e um revisor frustrado. Defendemos isso em inferência precificada por tarefa concluída.

3. Registre o tempo até uma mudança mesclável, porque a orquestração multiestágio adiciona latência mesmo quando economiza revisão.

4. Decida onde o Max é permitido. Um nível construído para as tarefas mais difíceis será usado para as fáceis se for o padrão. Faça dele uma escolha explícita por repositório ou tipo de tarefa.

Uma prévia de como os portfólios de modelos vão operar

O HydraFusion é um recurso de codificação, mas o padrão se generaliza. Argumentamos que as empresas teriam um portfólio de modelos com papéis distintos e que a própria orientação da OpenAI aponta para roteamento por tarefa. O GitHub dá o próximo passo: roteamento por etapa dentro de uma tarefa, com um orçamento para o pensamento em cada uma.

Para times de plataforma, isso muda o que a política precisa expressar. “Quais modelos são aprovados” não é mais suficiente. As perguntas passam a ser quais modelos podem redigir, quais podem julgar, quanto de raciocínio cada etapa pode gastar, e quem vê a conta. Resolva isso enquanto o recurso ainda é um preview, e o primeiro rollout em produção não vai resolver por você.