GitHub Copilot deixa escolher onde o agente roda e qual modelo usar no VS Code

O GitHub Changelog publicou em 28 de outubro de 2026, na esteira da GitHub Universe 2026, o resumo dos lançamentos do ano para o Copilot no VS Code. O fio condutor não é um recurso isolado: é dar ao dev duas escolhas que até aqui vinham decididas pela plataforma. Onde o agente roda. E qual modelo resolve a tarefa.

Para quem mantém stack em produção, isso não é cosmético. Onde o código circula é pergunta de compliance. Qual modelo responde é pergunta de custo. O GitHub tratou as duas no mesmo pacote de anúncios.

Nuvem ou máquina própria: a escolha de onde o agente roda

Até agora, um agente do Copilot ficava preso à sessão em que nasceu. Fechou a janela do VS Code, perdeu o fio. A novidade central é o Agent Host, uma camada que isola a sessão do Copilot da janela individual do editor, então o trabalho continua rodando em segundo plano mesmo depois que você fecha a pasta do projeto.

Daí nascem dois caminhos opostos:

• Sessão na nuvem: iniciada pela janela Agents do VS Code, roda na infraestrutura do próprio GitHub. Fechar o notebook não para o trabalho, e a mesma sessão pode ser retomada no VS Code, no app GitHub Copilot, no GitHub Mobile, no github.com, no Copilot CLI ou até numa conversa iniciada por DM no Slack ou no Microsoft Teams.
• Sessão remota via Agent Host: usando Remote SSH e dev tunnels, o agente roda numa máquina diferente da que você está usando, com o mesmo código, as mesmas ferramentas e as mesmas dependências. A máquina remota e seu Agent Host precisam continuar ligados, mas o trabalho sobrevive à desconexão do VS Code local.

A diferença prática é onde o código e os segredos do projeto trafegam. Sessão na nuvem tira o peso da sua máquina, mas o trabalho roda em infraestrutura do GitHub. Agent Host remoto mantém tudo dentro do seu próprio parque de máquinas, o que importa em times com exigência de que código sensível nunca saia da rede interna.

Para controlar um agente que roda na sua própria máquina a partir do celular, o comando é code agent host --github-environment, executado num terminal aberto na pasta do projeto. O GitHub Mobile vira controle remoto; quem faz o trabalho continua sendo a máquina de desenvolvimento, que precisa ficar ligada.

Comparar modelos antes de confiar num só

A segunda escolha é qual modelo resolve a tarefa, e aqui o recurso novo é o Compare model results, ainda em preview. Na janela Agents, dá para rodar modelos e harnesses diferentes em paralelo sobre o mesmo problema e revisar os resultados lado a lado. Um modelo Juiz pode recomendar qual resposta é melhor, e a opção Synthesize combina ideias das diferentes tentativas numa solução só.

Isso muda o cálculo de custo por tarefa. Rodar três modelos em paralelo custa mais do que rodar um, mas para uma decisão de arquitetura que vai virar código em produção, comparar abordagens antes de aceitar a primeira resposta pode valer o gasto extra. Para uma refatoração trivial, não compensa: use o modelo mais barato disponível e siga.

Acompanha essa mudança uma consolidação de comportamento: o harness do Copilot, construído sobre o Microsoft Copilot SDK, agora é o padrão em novas sessões tanto no editor quanto na janela Agents. Na prática, o agente se comporta de forma mais parecida entre VS Code, Copilot CLI e o app GitHub Copilot, o que reduz a surpresa de trocar de cliente no meio de uma tarefa.

CLI mais fácil de instalar

O Copilot CLI ganhou caminho de instalação direto pelo instalador do VS Code: no Windows, pelo próprio instalador; no macOS, ao adicionar o VS Code ao PATH; no Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, bastando rodar copilot. É um detalhe pequeno, mas reduz o atrito de levar o mesmo agente do editor para o terminal.

Computer use: o agente clicando na sua tela

O recurso mais experimental do pacote é o computer use. Com ele, o Copilot lê e interage com aplicativos de desktop, inclusive clicando em controles e editando texto fora do editor e do terminal. Está disponível em macOS e Windows, habilitado em Settings pela chave chat.agentHost.computerUse.enabled, seguido de reiniciar o VS Code e rodar /computer on numa sessão do Copilot.

Cada aplicativo exige aprovação explícita, e a configuração é compartilhada entre Copilot CLI e o app GitHub Copilot, então no macOS as permissões de sistema só precisam ser concedidas uma vez. Organizações podem desativar o recurso inteiro por política. Vale tratar como o que é: experimental, útil para automatizar tarefas que não têm API nem CLI, mas sem garantia de estabilidade entre versões.

Protocolo aberto para quem quer construir o próprio cliente

Para quem não quer depender só dos clientes oficiais, o GitHub abriu o Agent Host Protocol (AHP), que permite a qualquer cliente conectado se manter sincronizado com uma sessão viva e retomar o estado depois de uma reconexão. O comando code agent host sobe o host, e bibliotecas de cliente já existem para TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) →, Rust, Go, Kotlin e Swift.

Isso abre espaço para integrações internas: um painel de time, um bot interno, uma extensão de IDE que não seja o VS Code, todos falando o mesmo protocolo que move sessões entre nuvem e máquina local.

Governança: marketplace, plugins e conectores

O pacote inclui ainda ajustes de governança que interessam a quem administra Copilot num time maior:

Administradores Business e Enterprise que quiserem esses recursos em preview precisam habilitar Editor preview features antes. Políticas de enterprise continuam controlando quais plugins são obrigatórios ou bloqueados, e marketplaces estritos podem desligar os marketplaces embutidos por completo.

O que pesar antes de adotar

Em resumo: a escolha de onde rodar o agente e qual modelo usar não é gratuita, ela move custo e superfície de risco. Antes de trocar o fluxo de trabalho do time, vale medir três coisas: se o ganho de continuidade entre dispositivos compensa manter uma sessão na nuvem do GitHub ativa; se a exigência de compliance do projeto justifica manter Agent Host rodando numa máquina remota só para isso; e se a tarefa em questão realmente precisa comparar múltiplos modelos, ou se um modelo único e mais barato já resolve.

Para times com exigência regulatória forte, o caminho natural é o Agent Host remoto via SSH, mesmo com o custo operacional de manter uma máquina sempre ligada. Para quem prioriza velocidade e não tem restrição de onde o código roda, a sessão na nuvem com continuidade entre celular, editor e github.com reduz fricção real no dia a dia. As duas opções convivem no mesmo produto, e nenhuma é a resposta certa para todo stack.

Fonte: GitHub Changelog