Microsoft ha descrito un plan para que GitHub Copilot reparta las tareas de los desarrolladores entre modelos locales y modelos en la nube. La función, bautizada como Copilot Auto, tiene finales de octubre de 2026 como fecha objetivo. Mientras llega, la compañía ya documenta cómo configurar proveedores locales en la interfaz de línea de comandos para evitar el consumo de créditos de IA en determinadas tareas.
Microsoft hizo este anuncio el 7 de octubre de 2026 a través de un vídeo en inglés centrado en las opciones de enrutamiento automático. Conviene aclararlo desde el principio: Copilot Auto sigue siendo, por ahora, un plan con fecha objetivo, no una función que los desarrolladores puedan activar ya. Según lo descrito, el sistema decidiría dónde procesar cada petición atendiendo al contexto de la tarea y al estado de la caché durante sesiones con varios turnos de conversación.
BYOK y Copilot Auto: cómo elige Copilot el modelo
Con BYOK (Bring Your Own Key), somos nosotros quienes configuramos manualmente un proveedor o elegimos un modelo compatible. Copilot Auto, en cambio, está pensado para automatizar esa decisión según el contexto de cada tarea y la caché acumulada en la sesión. Microsoft ha descrito estas opciones para Copilot CLI, la aplicación Copilot y Visual Studio Code.
GitHub ha incorporado además la detección automática de modelos locales ya instalados, por ejemplo, los que corren sobre Ollama o Foundry Local. La compañía señala que este tipo de procesamiento resulta útil para consultas sencillas, explicaciones sobre una base de código o automatizaciones que se ejecutan en segundo plano. El argumento de fondo es evitar el gasto de créditos de IA en esas tareas cotidianas, aunque conviene recordar que ejecutar un modelo en el propio equipo también tiene un coste: el de los recursos de hardware y la electricidad que consume.
La diferencia de fondo es quién tiene el control en cada momento. Con BYOK sabemos en todo momento qué proveedor procesa la solicitud, porque lo hemos fijado nosotros. Copilot Auto, tal como está planteado, delegaría esa decisión en el propio sistema a lo largo de una conversación con varios turnos.
Para enchufar un modelo local a la línea de comandos, GitHub reconoce tres tipos de proveedor: openai, azure y anthropic. El primero, openai, es el que cubre los servicios compatibles con la especificación OpenAI Chat Completions, entre ellos Ollama, vLLM y Foundry Local. No vale cualquier modelo: tiene que admitir llamadas a herramientas y streaming, y GitHub recomienda trabajar con una ventana de contexto de al menos 128k tokens si queremos obtener buenos resultados.
La propia documentación de GitHub detalla cómo dejarlo listo con Ollama en local: la variable COPILOT_PROVIDER_BASE_URL debe apuntar a https://localhost:11434, y COPILOT_MODEL tiene que identificar el modelo que tengamos instalado. Si ese proveedor local no exige autenticación, nos podemos ahorrar la clave de API.
Funcionamiento local y modo sin conexión de la IA
Trabajar con un modelo local no equivale a trabajar sin conexión, y conviene no confundir ambos conceptos. La variable COPILOT_OFFLINE=true impide que Copilot CLI contacte con los servidores de GitHub, pero no bloquea las solicitudes que se envíen a un proveedor remoto que tengamos configurado. Si ese proveedor vive en otra máquina o en otro servicio de la red, seguirá recibiendo las peticiones y el contexto del código que le enviemos.
Mantener el procesamiento estrictamente dentro de nuestro equipo exige configurar un proveedor local; aislar la red por completo depende, además, del entorno concreto donde se ejecute todo. Copilot Auto y el modo sin conexión de la CLI resuelven, de hecho, cuestiones distintas: el primero está planteado para repartir el trabajo entre modelos locales y en la nube, mientras que la segunda opción corta las conexiones con GitHub sin tocar las que vayan a un proveedor remoto ya configurado. La ruta que elijamos para la inferencia determina dónde se ejecuta el modelo, pero no define por sí sola qué permisos tienen las herramientas que usa el agente: ese control corresponde al sandbox, que funciona de manera independiente.
El sandbox de herramientas: shell, archivos y servidores MCP
Microsoft aplica límites distintos según el tipo de herramienta cuando el sandbox está activo. Los comandos de shell y, de forma predeterminada, los procesos locales de MCP y de servidores de lenguaje se ejecutan dentro de un límite de proceso. Las herramientas de archivos integradas, en cambio, quedan sujetas a las políticas efectivas de Copilot, sin aislarse como procesos independientes controlados por el sistema operativo.
Los servidores MCP remotos se sitúan fuera de ese sandbox de procesos local: cuando se les aplican controles de aislamiento, Copilot verifica su política de conexión dentro del propio proceso, no mediante un contenedor externo. Conviene no perder de vista que elegir un modelo local no activa de forma automática el aislamiento de las herramientas. La inferencia local decide dónde se procesa cada petición; el sandbox, de manera independiente, regula qué puede hacer el agente con los procesos y con los archivos.
Con BYOK, los desarrolladores ya pueden configurar hoy proveedores openai, azure y anthropic en Copilot CLI sin esperar a nada más. Lo que todavía falta por confirmar es el alcance definitivo de Copilot Auto, su calendario exacto dentro del objetivo de finales de octubre de 2026 y si tendrá algún efecto sobre los planes y precios actuales de GitHub Copilot.