Ollama als Orchestrator, Cloud-LLMs für die schwere Arbeit

Lokale LLMs haben ein Performance-Problem. Wer Qwen3 oder Kimi lokal auf dem MacBook fährt, merkt schnell, dass die schwere Arbeit für einen autonomen Coding-Agenten nicht reicht. Gleichzeitig wollen viele DACH-Teams ihren Code nicht in die Cloud schicken. Mit Ollama v0.21.0 vom 16. April 2026 und dem am 7. April gelaunchten Copilot-CLI-BYOK-Feature gibt es jetzt einen praktischen Ausweg: Ollama als lokaler Orchestrator, der die schweren Subtasks an Cloud-LLMs delegiert. Und der Copilot-CLI-Befehl /fleet macht das auch noch parallel.

Was GitHub und Ollama konkret freigeschaltet haben

Bei GitHub Copilot CLI lässt sich seit dem 7. April das Standard-Routing auf GitHub-gehostete Modelle ersetzen (BYOK-Feature). Drei Provider-Kategorien werden unterstützt: OpenAI-kompatible APIs (dazu zählen Ollama, vLLM, Foundry Local), Azure OpenAI, und Anthropic. Die Konfiguration läuft über Environment-Variablen.

Ollama hat am 16. April nachgezogen. In Version 0.21.0 gibt es jetzt ollama launch copilot, das die Konfiguration in einem Rutsch erledigt. Für Cloud-Modelle genügt:

Unterstützte Modelle laut Ollama-Doku: kimi-k2.5:cloud, glm-5:cloud, minimax-m2.7:cloud, qwen3.5:cloud, glm-4.7-flash, qwen3.5. Wichtige Anforderung: Copilot braucht ein großes Kontextfenster, mindestens 64k Tokens werden empfohlen. Kleinere lokale Modelle scheiden damit aus.

Was /fleet anders macht

Der Copilot-CLI-Befehl /fleet zerlegt einen Implementation-Plan in unabhängige Subtasks und dispatcht diese an parallel laufende Subagenten. Jeder Subagent bekommt sein eigenes Context Window, isoliert vom Main-Agent und den anderen Subagenten. Das ist der entscheidende Unterschied zu einer einfachen "mach alles nacheinander"-Schleife: Context-Isolation verhindert, dass die Agenten sich gegenseitig mit irrelevanten Tokens überfluten.

GitHubs Dokumentation nennt drei typische Szenarien, in denen /fleet glänzt:

• Dokumentation für mehrere Module. API-Authentifizierung, Endpoints und Error Handling parallel dokumentieren, am Ende zusammenführen.
• Feature-Flag-Rollout. API-Layer, UI-Komponenten und Konfigurationsdateien gleichzeitig anpassen, wenn die Änderungen in getrennten Verzeichnissen liegen.
• Datenbankmigrationen. Schema-Erstellung zuerst, danach ORM-Modelle und API-Handler parallel, Integration-Tests zeitgleich mit den Handlern.

Der Orchestrator erkennt Parallelisierbarkeit über klare Dateigrenzen, explizite Abhängigkeiten im Prompt und modulare Struktur. Gut zu wissen: Jeder Subagent interagiert eigenständig mit dem LLM. Das heißt bei Premium-Modellen wie Claude Opus 4.7 auch, dass der Token-Verbrauch höher liegt als bei einem sequenziellen Run.

Das Hybrid-Muster im Detail

Spannend wird es, wenn man die Features zusammenlegt. Ollama läuft auf dem lokalen Rechner, ein Qwen3.5 oder GLM-4.7-Flash-Modell dient als Standard-Backend für den Main-Agent. Der erledigt schnelle Arbeiten: Lesen, Planen, Orchestrieren, einfache Edits.

Wenn der Main-Agent einen /fleet-Call absetzt, kann er pro Subtask entscheiden, welches Modell zum Einsatz kommt. Einfache Subtasks bleiben lokal. Harte Subtasks, bei denen ein Frontier-Modell gebraucht wird, werden per BYOK an Anthropic oder OpenAI delegiert. Der Code, mit dem der Subagent arbeitet, bleibt im Read-Context, der Output kommt zurück, wird im Main-Agent konsolidiert.

Für Teams mit Datenschutz-Anforderungen gibt es zusätzlich den Offline-Modus.

In dieser Konfiguration kontaktiert Copilot CLI keine GitHub-Server mehr, sämtliche Telemetrie ist deaktiviert. Der Agent kommuniziert ausschließlich mit dem konfigurierten Provider. Kombiniert mit einem lokalen Ollama-Modell heißt das: Air-Gapped-Entwicklung ist möglich, der Code verlässt die Maschine nicht. Für Projekte unter NDA, für öffentliche Verwaltung, für Banken und für alles, was nach DORA oder KRITIS-Regulierung läuft, ist das ein echter Unterschied zu "Copilot, aber bitte lieber."

Wann sich das Setup lohnt

Drei Szenarien, in denen das Hybrid-Muster besser passt als reines Claude Code oder reines Copilot-in-der-Cloud:

Szenario 1: Compliance-sensitive Repos. Wenn der Code nicht in fremde Hände soll, aber trotzdem Agenten-Unterstützung gewünscht ist, ist der Local-Ollama-Pfad die richtige Wahl. Komplexe Tasks werden bewusst delegiert, der Rest bleibt lokal.

Szenario 2: Kostenkontrolle. Wer jeden Token zählt, weil die Monthly-Bill sonst schmerzt, kann für den Großteil der Routine-Arbeit auf lokale Modelle setzen und nur bei harten Problemen die teure Cloud nutzen. Das Ollama-Cloud-Angebot (3 Modelle parallel gegen Aufpreis, 10 Modelle im Pro-Plan) füllt die Lücke zwischen lokal und Frontier.

Szenario 3: Parallelisierbare Migrations-Arbeit. Eine größere Refactoring-Welle, bei der mehrere Dateien gleichzeitig umgearbeitet werden müssen, wird mit /fleet deutlich schneller. Drei lokale Subagenten für die einfachen Dateien, ein Claude-Opus-Subagent für die harte Stelle, fertig.

Weniger sinnvoll ist das Setup, wenn du nur eine einzelne Feature-Datei anfasst. Der Overhead lohnt sich erst ab einer gewissen Task-Komplexität. Und wer ohnehin alle Tasks in der Cloud laufen lässt, gewinnt mit Ollama als Zwischenschicht nichts.

Sicherheits-Nebenbemerkung

Nur einen Tag vor dem Ollama-Release hat OX Security die MCP-Sicherheitslücke in den Anthropic-SDKs offengelegt. Wer das Hybrid-Setup aufbaut, sollte die Konsequenzen mitdenken. Copilot CLI unterstützt MCP-Server, also greift die dort beschriebene RCE-Problematik auch hier. Das ändert nichts am Hybrid-Muster selbst, aber es heißt: MCP-Server in Sandboxes laufen lassen, User-Input nicht blind durchreichen, und nur verifizierte Server-Quellen nutzen.

Einordnung

GitHub hat im Februar 2026 Claude und Codex in Copilot freigeschaltet. Im April ist Opus 4.7 dazugekommen, und jetzt folgt das Ökosystem-Opening mit BYOK plus lokalen Modellen. Zusammen mit /fleet entsteht ein Muster, das weder OpenAI Codex noch Claude Code so bieten: ein Agent, der nach Provider und Modell pro Subtask unterscheiden kann, und der komplett Air-Gapped läuft, wenn das gebraucht wird.

Für DACH-Teams, die bisher zwischen "Cloud-Agent mit Datenschutz-Bauchschmerzen" und "lokales Modell ohne Power" gewählt haben, eröffnet sich ein dritter Weg. Die Umsetzung ist aktuell noch Command-Line-heavy und verlangt Ops-Verständnis, wird aber in den nächsten Monaten absehbar komfortabler werden.

Wer heute einen Mittelstands-Kunden hat, der "KI im Code, aber bitte nicht in die Cloud" fordert, kann jetzt eine funktionierende Antwort geben, statt nur den Kopf zu schütteln.