Escolher um modelo barato para uma tarefa simples parece fácil. Manter essa escolha coerente quando a conversa muda de complexidade é outra história. O Copilot Fusion, anunciado em disponibilidade geral em 28 de outubro, reúne seleção automática e a orquestração do Project HydraFusion para assumir parte dessa decisão.

No mesmo dia, o GitHub apresentou uma prévia experimental de roteamento entre modelos locais e nuvem. São estágios diferentes: Fusion chegou à disponibilidade geral; a escolha automática de modelos no dispositivo ainda exige configuração experimental.

O nível de esforço passa a orientar a escolha

Fusion aparece no seletor de modelos, mas representa um sistema de execução. Standard é voltado ao trabalho cotidiano; High e Max permitem orquestração mais intensa. A documentação atual descreve execução com um modelo, escalada após avaliação de um rascunho e revisão por outros modelos antes da resposta final.

Essa é a continuidade do HydraFusion que já acompanhamos. O avanço de produto está em reunir essas decisões em uma experiência disponível em VS Code, CLI, aplicativo Copilot e JetBrains, sujeita aos modelos permitidos pelo plano e pelas políticas.

Para quem controla consumo, isso muda a pergunta. Em vez de escolher sempre o modelo mais forte ou sempre o menor, a equipe define quanta análise a tarefa merece e observa o resultado. Um ajuste de texto e uma investigação de concorrência em código podem justificar esforços diferentes, mesmo dentro do mesmo projeto.

Rodar localmente não torna a sessão offline

A prévia permite que Fusion Standard considere modelos locais compatíveis. O anúncio descreve instalação gerenciada via Windows ML e configuração manual no CLI em outros sistemas, com diferenças de suporte entre clientes. Adicionar um modelo por BYOK, usando sua própria configuração de provedor, não o torna automaticamente elegível.

A decisão de roteamento continua na nuvem. Essa condição impede tratar o recurso como solução offline ou assumir que toda a sessão permanecerá no computador. Antes de usá-lo com código sujeito a restrições, é necessário verificar o caminho dos dados e as políticas aplicáveis.

A capacidade do dispositivo também entra na decisão. Um modelo disponível no seletor não garante boa experiência no hardware de cada pessoa. A avaliação deve observar latência, qualidade e recursos consumidos em tarefas representativas.

Economia depende do trabalho que chega ao fim

A cobrança acompanha os modelos utilizados, e chamadas adicionais de revisão podem aumentar o consumo. A documentação informa desconto temporário de 30% nos custos dos modelos para planos pagos até 30 de novembro de 2026. Uma promoção ajuda na comparação inicial, mas não deve sustentar sozinha a projeção de custo permanente.

O GitHub divulga comparações favoráveis de desempenho e custo em benchmarks. Sem reproduzir as condições, não faz sentido convertê-las em promessa de economia para qualquer repositório. Um teste útil precisa incluir correção, retrabalho e tempo de revisão, além dos tokens.

Há ainda um detalhe operacional: descartar um rascunho não desfaz automaticamente as edições que ele já fez no workspace, segundo a documentação. A resposta final pode parecer consolidada enquanto os arquivos ainda precisam de inspeção. O seletor ficou mais simples; conferir o diff continua fazendo parte do trabalho.

Fontes em inglês: Fusion, modelos locais e documentação.