Warum ein einzelnes Modell nicht ausreicht
Die verfügbaren LLMs haben unterschiedliche Stärken. Claude liefert bei Reasoning und der Synthese komplexer Zusammenhänge. Gemini verarbeitet lange Dokumente und Codebasen am Stück. Codex arbeitet bei Code-Aufgaben: Boilerplate, Refactoring, Unit-Tests. Ein lokales Open-Source-Modell deckt repetitive Textarbeit ab, ohne Token-Kosten und ohne Cloud-Abhängigkeit. Komplexes Reasoning leistet es nicht.
Viele Anwender bleiben dennoch bei einem Modell, weil jeder Werkzeugwechsel Reibung erzeugt. Die Bequemlichkeit endet, sobald das bevorzugte Modell drosselt oder für eine konkrete Aufgabe ungeeignet ist.
Ein Engpass limitiert alles, was vor ihm liegt. Das gilt im Sondermaschinenbau genauso wie in der Technischen Redaktion und in der KI-gestützten Arbeit. Wirksam ist die Verteilung der Arbeit auf mehrere Modelle, die ihre jeweilige Stärke einbringen.
Die Architektur: Rollen statt Werkzeugkasten
Das Konzept eines Multi-LLM-Orchestrators folgt derselben Logik wie klassische Prozessberatung: klare Rollen, klare Verantwortlichkeiten, ein Regelwerk auf Papier statt nur im Kopf einer Person.
Claude (Opus 4.6) ist der Orchestrator. Er kennt alle laufenden Projekte, Regeln und Kundenkontexte. Er entscheidet, welches Modell welche Aufgabe übernimmt. Das Claude-Kontingent ist teuer und bleibt den Aufgaben vorbehalten, die tiefes Reasoning verlangen. Boilerplate, Recherchen und Textvorlagen wandern zu den Spezialisten.
Gemini (Google) ist der Rechercheur. Lange Dokumente, umfangreiche Kontexte, Analysen über große Datenmengen. Eingebunden per Slash-Command /gemini, nutzt ein eigenes Kontingent.
Codex (OpenAI) ist der Code-Spezialist. Boilerplate, Refactoring, Debugging. Eingebunden per /codex, nutzt ein ChatGPT-Kontingent.
Ein lokales Open-Source-Modell übernimmt die repetitive Textarbeit. Newsletter-Rohentwürfe, Dokumentationsblöcke, einfache Umformulierungen. Welches konkrete Modell läuft, ist für die Architektur austauschbar.
Eine Statusline zeigt die Live-Limits der drei Cloud-Provider. Zu sehen sind Limits, als auch die Reset-Timer der jeweiligen Modelle und die aktuellen Aktivitäten. Der Orchestrator verwendet diese Information für die Routing-Entscheidung: Bei knappem Claude-Kontingent wandern mehr Aufgaben zu den Spezialisten.
Warum Memory der eigentliche Kern ist
Die Modell-Architektur allein ist noch keine Lösung. Das zeigt sich, sobald ein spezialisierter Agent ohne Kontext arbeitet: Er improvisiert. Er beginnt Strukturen zu scannen und greift auf Bereiche zu, die ihn nichts angehen sollten. Ihm fehlt das Regelwerk, er kennt seine Grenzen nicht.
Ein gemeinsames Memory-System ist die Voraussetzung dafür, dass mehrere Modelle koordiniert arbeiten.
Das System besteht aus einer SQLite-Datenbank im WAL-Modus, einem MCP Memory Server als Claude-Code-Subprocess und einer Cross-Agent-CLI, über die Gemini und Codex per Bash auf dieselbe Datenbasis zugreifen. Sobald Claude Memory-Files schreibt, synchronisiert ein PostToolUse-Hook die Datenbank automatisch.
Der Inhalt ist in vier Kategorien strukturiert:
- User: Wer ist der Nutzer, wie arbeitet er, was sind seine Präferenzen.
- Project: Status laufender Projekte, offene Punkte, wo die Arbeit stehengeblieben ist.
- Feedback: Regeln aus Fehlern und Korrekturen. „Schreibe nie direkt in einen Deployment-Ordner.“ „Auth-Fixes immer mit Nebenwirkungs-Check.“ Solche Regeln werden einmal aufgeschrieben und stehen dann bei jeder Session zur Verfügung.
- Reference: Wo liegt was. Welcher Server hat welche Adresse. Wo liegen Credentials.
Aktuell sind 75 Einträge in der Datenbank. Die Suche läuft über Text-Substring-Matching. Eine Embedding-basierte Variante ist vorbereitet, aufgrund eines Torch-Versionskonflikts aber nicht permanent aktiv.
Ergebnis: Ein spezialisierter Agent greift beim Start auf strukturierte Kontextinformationen zu. Projektstatus, Regeln, Infrastruktur-Referenzen. Die Wiederholung der Grundlagen bei jeder Session entfällt.
Konfigurationssymmetrie
Das dritte Element ist das Regelwerk. Claude liest bei jedem Start eine CLAUDE.md mit Infrastruktur, Standing Orders, Projekt-Übersichten und Verhaltensregeln. Ein Migrationsskript spiegelt dieses Dokument in GEMINI.md und AGENTS.md, damit Gemini und Codex dieselbe Regelbasis haben.
Das aktuelle Setup enthält 13 Slash-Commands auf Claude, gespiegelt als 25 Gemini-Skills, plus 8 Subagents für spezialisierte Aufgaben. Ein Identity-Lint-Hook blockiert falsche Namensschreibweisen und ASCII-Umlaute, weil diese Fehler in Kundendokumenten nicht akzeptabel sind und kein Modell sie zuverlässig ohne explizite Regel vermeidet.
Was im Kopf bleibt, vergisst das Modell nach der Session. Was in einer Datei steht, gilt beim nächsten Start wieder. Viele Anwender verzichten auf diese Dokumentation und erklären der KI täglich dieselben Regeln.
Grenzen des Systems
Embeddings teilweise nicht verfügbar. Der Torch-Versionskonflikt zwischen LM Studio und der sentence-transformers-Bibliothek ist noch nicht gelöst. Solange LM Studio nicht aktiv läuft, greift der Fallback auf Text-Substring-Suche. Das funktioniert ohne semantische Suche.
Gemini löst ~/-Pfade unter Windows nicht zuverlässig auf. Der Workaround mit absoluten Pfaden ist funktional und dokumentiert.
Memory-Drift. Einträge veralten, wenn sich Projekte ändern. Ein Memory-System braucht aktive Pflege wie ein Prozesshandbuch. Wer es einmal anlegt und nie wieder anfasst, hat nach einigen Monaten eine veraltete Datenbasis.
Codex mit Eigenheiten bei Auth- und JWT-Fixes. Um stille Fehler bei Fixes auf anderen API-Routen zu verhindern, sind ausreichende Checks als Pflicht im Regelwerk vorzusehen.
Lokale Open-Source-Modelle scheitern bei komplexem Reasoning. Für Architekturentscheidungen bleiben sie ungeeignet. Auch muss stets das „Input-Output Nutzenverhältnis“ ständig geprüft werden. Je kleiner die open Source Modelle sind, umso mehr Nacharbeit ist möglicherweise erforderlich.
Vier Modelle zusammen sind nicht omnipotent. Sie funktionieren bei klar definierten Aufgaben mit vorhandenem Kontext. Unklare Aufgaben ohne Regelwerk liefern entsprechend unklare Ergebnisse.
Für wen der Ansatz sinnvoll ist
Der Aufbau ist für Einzelpersonen oder kleine Teams gedacht, die bereits mehrere KI-Abos aktiv nutzen: Claude, Google AI Pro, ChatGPT. Die Orchestrierung verteilt die Last auf die bereits bezahlten Kontingente und erzeugt keine zusätzlichen Kosten. Geschätzt wandern 40 bis 50 Prozent der delegierbaren Arbeit zu Gemini oder Codex. Das ist eine Beobachtung aus dem Produktiveinsatz, keine kontrollierte Messung.
pers. Anm. d. A.
Der redundante Ansatz ist in jedem professionellen Szenario sinnvoll, in dem automatische Prozesse oder Leistungserbringung von KI-Systemen abhängig ist. In vielen Firmen sind keine oder kaum manuelle Fallbacks vorhanden, denn schließlich will man genau diese (manuellen Prozesse) mit einem solchen System obsolet machen.
Gerade bei einem Ausfall eines „Single Source“ Systems, können die Schäden immens sein. Ganze Prozesse können dann zum Erliegen kommen. Unternehmerinnen und Unternehmer müssen hier dringend die im Einkauf gültigen Qualitätsstandards der „Second-“ oder „Third Source“ anwenden und so für bestmögliche Ausfallsicherheit sorgen.
Wer Monitoringdienste wie z.B. https://status.claude.com/ abonniert, bekommt ein sehr gutes Verständnis dafür, wie oft derartige Dienste nicht zur Verfügung stehen.Nicht außer Acht zu lassen ist ferner die Tatsache, dass alle relevanten Dienste (von „le Chat“, Mistral (Frankreich) einmal abgesehen), amerikanische Dienste sind. Sich in dieser Hinsicht von einem Land abhängig zu machen, ist eine Strategie, die spätestens dann nicht mehr aufgeht, wenn das Land die Rechenleistung für eigene Zwecke nutzen muss – z.B. bei nationalen Notständen und Krieg (zu Beginn des Iran-Krieges, war das sehr deutlich spürbar). Ebenso denkbar wäre eine politische und wirtschaftliche Einflussnahme solcher Länder, durch die bewusste Verknappung des Rohstoffs „Rechenleistung“.
Für Enterprise-Szenarien mit Mehrbenutzer-Anforderungen, zentraler IT-Governance und formalen Compliance-Anforderungen ist das Setup ungeeignet. Es fehlen Benutzerverwaltung, Audit-Logs und RBAC-Struktur. Unternehmen mit diesen Anforderungen brauchen eine andere Architektur.
Für den Einzelnutzer mit täglicher KI-Arbeit ist die praktische Frage: Existiert ein Regelwerk, das spezialisierte Agenten kontrollierbar macht?
Fazit
Ein einzelnes Modell-Limit erzeugt einen Engpass im Arbeitsablauf. Engpässe lassen sich durch Verteilung auf mehrere Ressourcen beheben. Verteilung funktioniert nur mit einem geteilten Regelwerk. Diese Logik gilt in menschlichen Teams und in KI-Teams gleichermaßen.
Den vollständigen Fachartikel mit technischer Architektur finden Sie als PDF zum Download direkt hier: