Microsoft beschreibt für GitHub Copilot eine geplante automatische Verteilung von Aufgaben auf lokale Modelle und Cloud-Inferenz. Zugleich erläutert das Unternehmen, wie die Sandbox Agentenwerkzeuge begrenzen soll. Für Copilot Auto peilt Microsoft einen Start bis Ende Oktober 2026 an.
Der Unterschied ist wichtig: Wo ein Modell rechnet und welche Rechte ein Agent bei der Ausführung von Werkzeugen hat, sind zwei getrennte Fragen. An NeoTeos frühere Berichterstattung zu Microsofts Hybrid-KI-Ansatz für Windows knüpft dieser Artikel mit den konkreteren Plänen für Copilot-Routing und Sandbox-Grenzen an.
Microsoft beschreibt lokale Modelle und Sandbox-Werkzeuge für Copilot
Microsoft stellte am 8. Oktober 2026 zwei Ansätze für Copilot vor: Nutzerinnen und Nutzer sollen ein lokales Modell ausdrücklich auswählen können, oder Auto soll Aufgaben zwischen lokaler und Cloud-Inferenz verteilen. Die neuen Optionen nannte Microsoft für Copilot CLI, die Copilot-App und Visual Studio Code.
Auto soll laut Microsoft den Aufgabenkontext und den Cache-Zustand über mehrere Gesprächsrunden berücksichtigen. Für die ausdrückliche Auswahl lokaler Modelle nannte das Unternehmen MAI Code 1.1 Flash über Windows ML sowie lokale Modelle an OpenAI-kompatiblen Endpunkten. Das sind unterschiedliche Wege: Bei Auto übernimmt Copilot die Zuordnung; bei der manuellen Auswahl bestimmen Nutzerinnen und Nutzer das Modell selbst.
BYOK und Auto erfüllen unterschiedliche Aufgaben
BYOK steht für „Bring Your Own Key“: Nutzerinnen und Nutzer verbinden einen eigenen Anbieter oder Endpunkt beziehungsweise wählen ein Modell. Auto soll dagegen selbst zwischen lokaler und Cloud-Inferenz routen.
| Modus | Wer wählt oder routet das Modell? | Beschriebene Copilot-Oberflächen |
| BYOK | Nutzerinnen und Nutzer konfigurieren einen Anbieter oder wählen ein Modell. | Copilot CLI und Visual Studio Code |
| Auto | Copilot soll Aufgaben anhand von Kontext und Cache zwischen lokaler und Cloud-Inferenz verteilen. | Copilot CLI, Copilot-App und Visual Studio Code |
Für Copilot CLI unterstützt BYOK die Anbietertypen openai, azure und anthropic. Der Typ openai umfasst auch kompatible lokale Endpunkte wie Ollama. Ein Modell für die CLI muss Tool-Aufrufe und Streaming unterstützen; GitHub empfiehlt für beste Ergebnisse ein Kontextfenster von mindestens 128.000 Tokens.
In Visual Studio Code lassen sich Anbieter und Modelle über die Modellauswahl und „Manage Language Models“ hinzufügen. Für Ollama verweist die Dokumentation auf die Ollama-Erweiterung; der integrierte Ollama-Anbieter ist veraltet.
Lokale Inferenz bedeutet nicht automatisch Offline-Betrieb
Ob Copilot vollständig offline arbeiten kann, hängt vom jeweiligen Ablauf ab. Bei der CLI verhindert COPILOT_OFFLINE=true die Verbindung zu GitHub. Ist der eingestellte Modellanbieter jedoch ein entfernter Dienst, erhält dieser weiterhin Prompts und Codekontext. Für eine vollständig isolierte Verbindung muss der Anbieter lokal oder in derselben isolierten Umgebung laufen.
In Visual Studio Code kann BYOK-Chat mit einem lokalen Modell ohne GitHub-Konto und Copilot-Abo vollständig offline funktionieren. Andere Funktionen – darunter Inline-Vorschläge, semantische Suche und Funktionen, die Einbettungen nutzen – benötigen weiterhin ein GitHub-Konto. Ein lokales Chatmodell bedeutet also nicht, dass alle Bestandteile von Copilot lokal laufen.
Was die Sandbox einschließt
Microsoft unterscheidet bei der Sandbox nach Werkzeugtyp. Shell-Befehle sowie standardmäßig lokale MCP- und Sprachserver laufen innerhalb einer Prozessgrenze. MCP steht für Model Context Protocol.
Eingebaute Dateifunktionen erhalten laut Microsoft Richtlinienprüfungen durch den Agenten-Harness, laufen aber nicht als vom Betriebssystem isolierte Kindprozesse. Entfernte MCP-Server liegen außerhalb der lokalen Prozess-Sandbox. Die Wahl eines lokalen Modells und die Beschränkung der Werkzeugausführung bleiben damit eigenständige Einstellungen.
Die genannten Sandbox-Backends nach Betriebssystem
Microsoft nennt unterschiedliche technische Grundlagen für die Prozessgrenze: Unter Windows kommt die BaseContainer-Stufe von ProcessContainer aus Microsoft Execution Containers (MXC) zum Einsatz, unter macOS Seatbelt und unter Linux bubblewrap. Nach Microsofts Beschreibung benötigen diese Backends weder eine separate virtuelle Maschine noch ein Container-Image.
