Microsoft detalla el enrutamiento local de Copilot

Microsoft detalló el 8 de octubre de 2026 cómo GitHub Copilot pretende alternar entre modelos locales y servicios en la nube, y qué límites de aislamiento aplicará a algunas herramientas de agente. La compañía fijó finales de octubre como objetivo para Copilot Auto, el modo que pretende elegir dónde procesar una tarea según su contexto y la caché de una sesión con varios turnos.

La novedad desarrolla la estrategia híbrida que NeoTeo había tratado en una cobertura anterior de Microsoft: este seguimiento concreta cómo se relacionan la elección del modelo y el control de las herramientas.

BYOK y Auto ofrecen controles distintos

BYOK —siglas de bring your own key, o «trae tu propia clave»— permite que el usuario configure un proveedor o seleccione un modelo. Copilot Auto, en cambio, pretende decidir cuándo una tarea usa inferencia en el dispositivo y cuándo recurre a la nube. Microsoft anunció ambos enfoques para Copilot CLI, la aplicación Copilot y Visual Studio Code; la documentación de BYOK cubre Copilot CLI y Visual Studio Code.

En Copilot CLI, BYOK admite proveedores openai, azure y anthropic. El tipo openai también permite conectar servicios compatibles con la API OpenAI Chat Completions, como Ollama, vLLM y Foundry Local. El modelo debe admitir llamadas a herramientas y transmisión de respuestas; GitHub recomienda una ventana de contexto de al menos 128.000 tokens para obtener los mejores resultados.

Para conectar una instancia local de Ollama, se configura COPILOT_PROVIDER_BASE_URL con http://localhost:11434 y COPILOT_MODEL con el identificador del modelo instalado. Si el servicio local no requiere autenticación, no hace falta una clave de API.

En Visual Studio Code, el selector de modelos permite abrir Manage Language Models y añadir un proveedor o un punto de conexión compatible. Para Ollama, la aplicación dirige a los usuarios a la extensión oficial: su proveedor integrado está obsoleto. Los modelos usados por agentes también deben admitir llamadas a herramientas.

Un modelo local no garantiza una sesión sin conexión

En Copilot CLI, COPILOT_OFFLINE=true impide que la aplicación se conecte a GitHub, pero no a un proveedor remoto configurado: ese servicio sigue recibiendo las solicitudes y el contexto del código. Para mantener el procesamiento dentro de un entorno aislado, el proveedor también debe ser local o estar en ese mismo entorno.

Visual Studio Code permite usar BYOK con un modelo local para chatear sin conexión, sin una cuenta de GitHub ni un plan de Copilot. Otras funciones siguen dependiendo de una cuenta de GitHub, entre ellas las sugerencias de código, la búsqueda semántica y las funciones que utilizan embeddings (representaciones numéricas del contenido).

Auto tampoco equivale a un modo sin conexión: como pretende poder derivar tareas a modelos en la nube, su enrutamiento puede implicar procesamiento remoto. La ubicación del modelo y la conectividad son decisiones distintas.

Qué cubre el sandbox de Copilot

Microsoft presentó el sandbox como un control separado de la elección del modelo. Según la compañía, los comandos de shell y, de forma predeterminada, los servidores locales de Model Context Protocol (MCP) y de lenguaje se ejecutan dentro de un límite de proceso.

Las herramientas de archivos integradas reciben comprobaciones de política del agente, pero no quedan aisladas como procesos hijos mediante controles del sistema operativo. Los servidores MCP remotos también quedan fuera del sandbox de procesos local. Por eso, seleccionar un modelo local no establece por sí solo los permisos de las herramientas ni contiene las conexiones a servicios remotos.

El mecanismo de aislamiento cambia según el sistema operativo

Microsoft indicó que Copilot usa la capa BaseContainer de ProcessContainer, de Microsoft Execution Containers (MXC), en Windows; Seatbelt en macOS; y bubblewrap en Linux. La compañía señaló que estos mecanismos no requieren una máquina virtual aparte ni una imagen de contenedor.