Microsoft plant, dass GitHub Copilot Aufgaben künftig je nach Kontext zwischen lokal laufenden Modellen und Cloud-Modellen verteilt. Für Copilot Auto nannte Microsoft Ende Oktober 2026 als Ziel. Bereits beschrieben ist außerdem die manuelle Auswahl eigener Modelle über BYOK – sie funktioniert anders als die geplante automatische Weiterleitung.

Microsoft plant lokales und Cloud-Routing für GitHub Copilot

Das englischsprachige GitHub-Video stellt das geplante lokale Modell-Routing vor; es ist eine Ankündigung, keine Bestätigung des Starts.

Microsoft beschrieb am 7. Oktober 2026 Copilot Auto als geplante Funktion: GitHub Copilot soll Aufgaben anhand des Kontexts und des Sitzungscache über mehrere Gesprächsrunden hinweg einem lokalen oder einem Cloud-Modell zuweisen. Der genannte Zeitpunkt Ende Oktober ist das Ziel für diese Funktion.

GitHub beschreibt außerdem die geplante automatische Erkennung installierter lokaler Modelle, etwa über Ollama oder Microsoft Foundry Local. Zu den Aufgaben, die lokal laufen sollen, zählt GitHub einfache Anfragen und Erklärungen zu einer Codebasis. GitHub stellt die Nutzung lokaler Rechenleistung auch als Möglichkeit dar, für solche Abläufe keine AI-Credits einzusetzen. Lokale Inferenz beansprucht weiterhin die eigene Hardware und Strom.

BYOK und Copilot Auto geben die Modellauswahl unterschiedlich ab

Bei BYOK (Bring Your Own Key) wählen Nutzer einen Anbieter oder ein konkretes Modell und richten den Endpunkt selbst ein. Copilot Auto soll diese Auswahl künftig für einzelne Aufgaben übernehmen und dabei zwischen lokaler Verarbeitung und Cloud-Inferenz wechseln. Microsoft nennt Aufgabenkontext und Cache-Zustand als Faktoren für diese Entscheidung.

ModusWer Modell oder Route auswähltBedeutung für die Verbindung
BYOKNutzer konfigurieren einen Anbieter oder wählen ein Modell.Der konfigurierte Endpunkt kann lokal oder remote sein. Ein Remote-Anbieter erhält weiterhin Anfragen und Codekontext.
Copilot AutoCopilot soll Aufgaben anhand von Kontext und Sitzungscache lokal oder in der Cloud verarbeiten.Die geplante Route kann ein Cloud-Modell einbeziehen; Auto ist daher kein Offline-Modus.

Microsoft beschreibt lokale Modelloptionen für Copilot CLI, die Copilot-App und Visual Studio Code. Die verfügbaren Funktionen und Anforderungen sind jedoch nicht für alle Oberflächen gleich. Die konkreten BYOK-Einstellungen von GitHub beziehen sich hier auf Copilot CLI.

Welche lokalen Modelle Copilot CLI unterstützt

GitHub nennt für Copilot CLI die Provider-Typen openai, azure und anthropic. Der Typ openai unterstützt OpenAI-Chat-Completions-kompatible Endpunkte, darunter Ollama, vLLM und Foundry Local. Für einen lokalen Ollama-Dienst nennt GitHub http://localhost:11434 als Beispiel für COPILOT_PROVIDER_BASE_URL; COPILOT_MODEL verweist auf die Kennung des installierten Modells. Einen API-Schlüssel braucht die Konfiguration nicht, wenn der lokale Dienst keine Authentifizierung verlangt.

Das für Copilot CLI konfigurierte Modell muss Tool-Aufrufe und Streaming unterstützen. GitHub empfiehlt für gute Ergebnisse ein Kontextfenster von mindestens 128k Tokens. Diese Anforderungen gelten für die CLI-Konfiguration, nicht automatisch für jede Copilot-Oberfläche.

Lokale Inferenz ist nicht automatisch Offlinebetrieb

Mit COPILOT_OFFLINE=true verhindert Copilot CLI Verbindungen zu GitHub. Die Einstellung blockiert aber keinen Remote-Anbieter, der als Modell-Endpunkt eingerichtet wurde: An diesen können weiterhin Prompts und Codekontext gesendet werden. Soll der Modellverkehr lokal bleiben, muss der Anbieter lokal laufen oder sich in derselben isolierten Umgebung befinden.

Auch Copilot Auto ist kein Offline-Modus: Die geplante Funktion soll Aufgaben sowohl lokalen als auch Cloud-Modellen zuweisen können. BYOK gibt dagegen die Kontrolle über den gewählten Anbieter, verlangt aber, dass Nutzer dessen Endpunkt konfigurieren.

Modellstandort und Tool-Sandbox sind getrennte Kontrollen

Ein lokales Modell begrenzt nicht von selbst den Zugriff eines Agenten auf Shell, Dateien oder Netzwerk. Microsoft beschreibt Sandbox-Regeln als eigene Kontrolle, deren Wirkung vom jeweiligen Werkzeug abhängt. Bei aktivierter Sandbox laufen Shell-Befehle sowie standardmäßig lokale MCP- und Sprachserver-Prozesse innerhalb einer Prozessgrenze. MCP steht für Model Context Protocol.

Die integrierten Dateifunktionen werden innerhalb von Copilot anhand der geltenden Richtlinien geprüft; sie laufen nicht als vom Betriebssystem isolierte Unterprozesse. Remote-MCP-Server liegen außerhalb der lokalen Prozess-Sandbox. Microsoft beschreibt für diese Server eine Prüfung der Verbindungsvorgaben innerhalb von Copilot, wenn die MCP-Sandbox-Kontrollen greifen.

Microsofts Sandbox-Backends nach Betriebssystem

Microsoft nennt drei lokale Backends für die Prozess-Sandbox. Dafür ist laut Microsoft weder eine separate virtuelle Maschine noch ein Container-Image nötig.

BetriebssystemVon Microsoft genanntes Backend
WindowsBaseContainer über ProcessContainer und Microsoft Execution Containers (MXC)
macOSSeatbelt
Linuxbubblewrap