Copilot SDK em C#: trocar o modelo não significa trocar o runtime

A Microsoft publicou um exemplo em .NET 10 que usa o GitHub Copilot SDK com um deployment próprio de modelo.[12] O SDK mantém cliente, sessão e orquestração, enquanto ProviderConfig define endpoint e autenticação do provedor.[12] O texto cita OpenAI, Anthropic, Ollama, Foundry Local e endpoints compatíveis, como vLLM e LiteLLM.[12]

O detalhe que evita uma interpretação errada: o processo local do Copilot CLI continua necessário.[12] Trocar o destino da inferência não elimina o runtime. Minha leitura é que essa separação pode ser útil, desde que cada camada seja avaliada pelo que realmente faz.

O que muda para quem desenvolve

O exemplo usa Microsoft Foundry ou Azure OpenAI com a Responses API e mantém configurações em User Secrets.[12] A autenticação padrão aproveita Microsoft Entra ID e a sessão do Azure CLI, com uma chave de API como alternativa.[12] O callback de bearer token utilizado é marcado como experimental.[12]

Para uma aplicação C#, recomendo pensar em três contratos: como a sessão é criada, como o modelo é chamado e quais ações o runtime pode executar. A possibilidade de substituir o provedor ajuda a testar opções, mas não prova equivalência entre respostas, ferramentas ou comportamento de erro.

No contexto do artigo, BYOK significa usar o próprio provedor ou credencial, não configurar chaves de criptografia de armazenamento.[12] Vale esclarecer o termo na documentação do projeto para evitar que uma opção de inferência seja apresentada como uma garantia de proteção de dados.

Como aplicar

Comece pela menor integração possível: uma pergunta com dados sintéticos, ferramentas desabilitadas e tempo máximo de espera definido. O próprio exemplo desabilita ferramentas, skills, descoberta de configuração e operações Git no host para isolar a comunicação com o modelo.[12]

Use esse isolamento como ponto de partida do teste. Verifique autenticação, resposta útil, erros explícitos e encerramento da sessão. Compare um retorno normal com credencial inválida, timeout e resposta vazia, sempre em ambiente controlado.

Depois habilite uma capacidade por vez. Para cada ferramenta, documente entradas permitidas, efeitos e condições de recusa. Registre também o que precisa mudar da identidade de desenvolvimento para a identidade do serviço, sem transportar automaticamente uma sessão pessoal para produção.

O critério de aceite proposto é identificar em qual camada uma falha ocorreu e impedir que ausência de conteúdo seja registrada como tarefa concluída.

Cuidados e limites

O artigo alerta que limites de saída em modelos de raciocínio podem ser consumidos por tokens internos, terminando sem resposta visível; o exemplo trata resposta vazia como erro.[12]

Também recomendo verificar o comportamento de rede do conjunto antes de alegar que um endpoint local mantém todo o processamento local. A escolha do provedor responde onde a inferência configurada acontece; a avaliação do runtime é uma obrigação separada.

Reutilizar a orquestração pode reduzir trabalho de integração. Não transforma, sozinho, configuração experimental em contrato estável de produção.

Fonte

[12] Fonte: Microsoft .NET Blog. Publicação: 19/10/2026 às 13:00.