Das Orchestrator-Pattern: Ein Modell plant, ein anderes führt aus — und was das euch spart

Auf Reddit und in ein paar viral gegangenen LinkedIn-Threads (der bekannteste von Prajwal Tomar) macht seit einigen Tagen ein Muster die Runde, das die Community pragmatisch „Orchestrator-Pattern" nennt: Ein starkes, teures Modell plant eine Aufgabe und delegiert die Ausführung an mehrere günstigere Sub-Modelle, die parallel arbeiten. Der Orchestrator prüft am Ende die Zwischenergebnisse, sortiert, komprimiert, gibt die Antwort.

Was daran erst mal nicht neu klingt, ist konkret in einer Weise geworden, die praktisch nutzbar ist. Zwei Entwicklungen der letzten Wochen haben das ausgelöst: Erstens die Fable-Reinstate-Caps, die Teams zwingen, mit Fable sparsam umzugehen. Zweitens die Sonnet-5-Hidden-Cost-Diskussion: Wer den vermeintlich günstigen Sonnet 5 als monolithisches Agenten-Modell einsetzt, verbrennt viel Geld für Multi-Turn-Chains. Beide Probleme lösen sich mit einem Orchestrator-Setup elegant.

Wir haben das Muster seit Dienstag in drei laufenden Kundenprojekten produktiv getestet — Coding-Automatisierung, Recherche-Pipeline, Marketing-Content-Fabrik. Die Erfahrungen und Zahlen daraus sind konkret genug, um jetzt eine Praxis-Empfehlung zu geben.

Die Grundidee in einem Satz

Ihr habt eine Aufgabe, die eine gute Antwort braucht. Statt sie einem einzelnen Modell zu übergeben, spaltet ihr sie in zwei Schichten:

Schicht 1 (Orchestrator): Ein hochwertiges Modell — Fable 5, Opus 4.8, oder GPT-5.6 Sol, wenn ihr Zugang habt — bekommt die Aufgabe und schreibt einen Plan. Nicht die Antwort. Der Plan enthält: welche Teilprobleme sind zu lösen, welche Reihenfolge, welche Kriterien für „fertig". Der Orchestrator schreibt keinen Code, generiert kein Marketing-Copy, liest keine Fachartikel — er verteilt.

Schicht 2 (Sub-Modelle): Für jedes Teilproblem wird ein günstigeres Modell aufgerufen — Sonnet 5, GPT-5.6 Terra oder Luna, oder ein lokales Modell — und liefert die konkrete Antwort auf eine eng definierte Teilfrage. Diese Sub-Aufrufe können parallel laufen. Sie haben eng gefasste Prompts, kurze Antworten, kein Kontext von den Nachbaraufrufen.

Schicht 3 (Orchestrator, Runde 2): Der Orchestrator sammelt die Teilergebnisse, prüft sie auf Konsistenz und Qualität, komprimiert und liefert die finale Antwort an den Nutzer.

Der ökonomische Trick liegt in der Token-Verteilung. Der Orchestrator sieht viel Kontext, produziert aber vergleichsweise wenige Token (die Planungs- und Kontrollstruktur). Die Sub-Modelle sehen wenig Kontext, produzieren die Masse an Output-Token — aber zu deutlich niedrigerem Preis pro Token. In der Summe ist die Rechnung deutlich günstiger als „alles auf Fable" und deutlich stabiler als „alles auf Sonnet".

Setup 1: Coding-Automatisierung

Klassisches Beispiel: „Refactoriere Modul X, das über 12 Dateien verteilt ist, in ein sauberes Interface-Pattern."

Ohne Orchestrator (Sonnet 5 monolithisch): Sonnet läuft mit 200-400k Kontext, hält den Zustand im Kopf, ruft über 15-30 Tool-Calls die Änderungen aus. Token-Verbrauch typisch: 180-260k Input, 60-90k Output. Bei Intro-Preis (2/10 USD per MTok) landen wir bei 96-126 US-Cent pro Refactor — plus die zwei-drei Nachschleifen, wenn Sonnet in Details wackelig wird.

Mit Orchestrator (Fable 5 plant, Sonnet 5 führt aus): Fable 5 bekommt den High-Level-Prompt plus die Dateiliste (ca. 15-20k Kontext), schreibt einen Plan mit 12 nummerierten Sub-Aufgaben, jede in 3-5 Sätzen präzisiert. Fable-Token: ca. 18k Input, 3k Output. Für jede der 12 Sub-Aufgaben ruft der Wrapper Sonnet 5 parallel auf, jede Sub-Aufgabe mit ca. 6-8k Input und 2-4k Output. Zusatz-Runde am Ende: Fable prüft, ob alle 12 Teile zusammenpassen.

Real gemessene Kosten in unserem Setup diese Woche: 6-9 US-Cent für Fable-Runden, 30-40 US-Cent für die 12 Sub-Aufrufe. Gesamt: 40-50 Cent pro Refactor. Das sind 55-60% Ersparnis gegenüber dem monolithischen Sonnet-Setup — bei sichtbar besserer Konsistenz zwischen den Dateien, weil Fable die architektonische Kohärenz plant, statt sie in einer Chain zu improvisieren.

Der Zusatzvorteil: Bei Fable-Weekly-Caps verbraucht der Orchestrator nur wenige Anfragen pro Refactor. Ein Team, das mit dem alten Setup nach zwei Tagen den Fable-Cap gerissen hat, kommt jetzt eine ganze Woche aus.

Setup 2: Recherche-Pipeline

Aufgabe: „Erstelle einen Marktüberblick zu X mit 20-30 Quellen, geordnet nach Relevanz für den europäischen Mittelstand."

Ohne Orchestrator: Ein Modell kaut sich durch eine lange Recherche-Chain, Web-Searches wechseln sich ab mit Zusammenfassungen, das Modell verliert nach 15-20 Tool-Calls den Faden, produziert Wiederholungen. Kosten hoch, Qualität ungleichmäßig.

Mit Orchestrator: Fable 5 (oder Opus 4.8) macht die initiale Themen-Aufgliederung: sieben bis zehn Sub-Themen mit klaren Suchbegriffen. Für jedes Sub-Thema läuft parallel ein GPT-5.6 Terra oder Sonnet 5 mit eng gefassten Suchen und einer Zusammenfassung. Fable prüft am Ende, ob alle Sub-Themen abgedeckt sind, identifiziert Lücken, sortiert nach Relevanz.

Unsere Erfahrung: Die Ergebnisqualität ist deutlich einheitlicher, weil jeder Sub-Aufruf einen fokussierten Auftrag hat statt einer sich entwickelnden Chain. Die Gesamtkosten liegen bei ca. 40% dessen, was ein monolithisches Fable-Setup gekostet hätte, und bei etwa 65% eines monolithischen Sonnet-Setups mit gleicher Chain-Länge.

Zusatzvorteil: Wenn eines der Sub-Modelle wackelig antwortet, könnt ihr diesen einen Sub-Aufruf gezielt neu laufen lassen. Das monolithische Setup kennt keinen sauberen Retry-Punkt.

Setup 3: Marketing-Content-Fabrik

Aufgabe: „Erstelle acht Social-Media-Posts zu Thema X, drei LinkedIn-Longforms, ein Newsletter-Text und zwei Blog-Artikel-Outlines — alle konsistent in Ton und Positionierung."

Ohne Orchestrator: Ein Modell arbeitet die Liste sequentiell ab, driftet nach dem fünften Item stilistisch, die letzten Outputs weichen erkennbar von den ersten ab. Manuelle Nachbearbeitung nötig.

Mit Orchestrator: Fable 5 schreibt ein detailliertes Briefing für den Ton, die Positionierung, die Kernbotschaften pro Format (ca. 800 Wörter Briefing). Danach laufen die einzelnen Content-Stücke parallel als Sub-Aufrufe an Sonnet 5, jedes mit dem Briefing als Prompt-Vorspann. Fable prüft am Ende die Konsistenz und markiert Stücke, die stilistisch driften.

Kosten sinken um ca. 30-40% gegenüber dem monolithischen Setup. Wichtiger ist aber: die Konsistenz-Prüfung am Ende fängt genau die Drift ab, die bei einem sequentiellen Setup unvermeidlich ist. Zeit-Ersparnis in der manuellen Nachbearbeitung: bei einem 14-teiligen Batch typisch 90 Minuten pro Woche.

Wie ihr das technisch aufsetzt

Die Umsetzung ist keine Wissenschaft. Was ihr braucht:

Ein Orchestrator-Wrapper. Das kann ein Python-Skript sein, ein n8n-Workflow, eine kleine LangGraph- oder LangChain-Anwendung. Kern-Funktion: rufe Modell A mit einem Planungs-Prompt auf, parse das Ergebnis in Sub-Aufgaben, rufe für jede Sub-Aufgabe parallel Modell B auf, sammle die Ergebnisse, gib sie an Modell A zur Kontrolle.

Ein sauberes Planungs-Format. Der Orchestrator liefert am besten strukturierten Output — JSON oder ein klar formatiertes Markdown mit nummerierten Sub-Aufgaben. Das erspart euch Parsing-Debugging.

Parallelisierung. Die Sub-Aufrufe müssen parallel laufen, sonst verpufft ein Großteil des Kostenvorteils in Latenz. Zwischen 5 und 20 gleichzeitige Aufrufe sind je nach Rate-Limits eures Providers realistisch.

Klare Prompt-Templates pro Sub-Aufgabe. Der Orchestrator gibt strukturierte Anweisungen, das Sub-Modell hat pro Aufruf einen engen, klar definierten Auftrag mit Erfolgs-Kriterium.

Für Setups mit fünf oder mehr laufenden Agenten empfehlen wir zusätzlich das gestern in der Show-HN aufgetauchte Tool mcpsnoop — quasi ein Wireshark für MCP-Traffic. Das ist die günstigste Möglichkeit, die Kommunikation zwischen Orchestrator und Sub-Modellen zu debuggen, wenn eines der Sub-Ergebnisse verspätet oder inkonsistent ist.

Wo das Orchestrator-Pattern NICHT lohnt

Ehrlich, damit ihr die Zeit nicht in falscher Richtung investiert:

Bei einfachen Prompt-Response-Aufgaben. „Fasse dieses PDF zusammen" braucht keinen Orchestrator. Da verpufft die Zusatzlatenz und der Zusatzaufwand ohne Gewinn. Faustregel: unter 10 sinnvoll trennbaren Sub-Aufgaben ist das monolithische Setup meist besser.

Bei stark sequentiellen Workflows. Wenn jede Sub-Aufgabe strikt auf das Ergebnis der vorherigen wartet — zum Beispiel bei einem Kompiler-basierten Refactor mit engen Abhängigkeiten — dann verliert ihr die Parallelisierung, und der Orchestrator wird zum Overhead.

Bei sehr eng gekoppelten Aufgaben. Wenn Sub-Aufgaben so eng miteinander verwoben sind, dass sie ohne Nachbar-Kontext gar keine sinnvolle Antwort liefern können, ist das Aufteilen kontraproduktiv. Klassisches Anti-Beispiel: „Formuliere diesen Absatz in fünf verschiedenen Stilen" — die Stile beeinflussen sich, ein einzelnes Modell macht das besser als fünf parallele Sub-Aufrufe.

Was das im Kontext der letzten Wochen bedeutet

Wir hatten in der Blog-Reihe der vergangenen Woche mehrfach das Argument gemacht, dass Multi-Provider-Setups jetzt kein Nice-to-have mehr sind, sondern eine strukturelle Notwendigkeit — nach dem Fable-Ban, nach der Programmatic-Policy, nach der GPT-5.6-Drosselung. Das Orchestrator-Pattern ist ein natürlicher Bestandteil dieser Multi-Provider-Architektur: es macht Multi-Modell-Setup zur ökonomischen Standardarchitektur, nicht mehr zur Ausnahme.

Ein Nebeneffekt, den wir für die nächsten Monate interessant finden: Ein sauber gebautes Orchestrator-Setup ist anbieter-agnostisch. Ob eure Sub-Modelle Sonnet 5, Terra oder GLM-4.7-Flash lokal sind, entscheidet ihr pro Konfiguration. Wenn Persona am Dienstag greift, könnt ihr die Sub-Modell-Auslieferung auf Anbieter umleiten, die nicht betroffen sind. Wenn Fable in einer Woche wieder eingeschränkt wird, ist der Orchestrator austauschbar. Ihr baut euch damit die operative Handlungsfähigkeit, die die letzten Wochen strategisch gefordert haben, gleich mit ein.