Advisor- und Orchestrator-Pattern:
Multi-Agent-Kostenoptimierung fuer autonome Agenten

Das Kostenproblem bei autonomen Multi-Agenten-Systemen

Autonome Agenten-Systeme wie die, die Clawgency fuer OpenClaw-Einsaetze implementiert, bestehen selten aus einem einzigen Modellaufruf. Ein Kundenservice-Agent etwa recherchiert im CRM, sucht in einer Wissensdatenbank, formuliert eine Antwort und dokumentiert den Vorgang – vier bis zehn Modellaufrufe fuer eine einzige Aufgabe sind keine Seltenheit. Laeuft jeder dieser Aufrufe ueber das leistungsstaerkste verfuegbare Modell, skaliert die Rechnung linear mit dem Volumen, unabhaengig davon, ob der jeweilige Teilschritt diese Leistungsfaehigkeit ueberhaupt braucht.

Zur Einordnung der reinen Modellkosten: Anthropics aktuell veroeffentlichte API-Preise (Stand 15.07.2026, platform.claude.com/docs/en/about-claude/pricing) zeigen ein Preisverhaeltnis von etwa 5:1 bis 10:1 zwischen dem Flaggschiffmodell Fable 5 (10 $ Input / 50 $ Output pro Million Token) und einem schnelleren Modell wie Sonnet 5 (2 $ Input / 10 $ Output, Preis bis 31.08.2026). Diese Differenz multipliziert sich ueber jeden Agentenschritt, jede Session, jeden Monat.

Das Advisor-Pattern: teures Modell nur an Entscheidungspunkten

Anthropic hat im April 2026 im Blogbeitrag "The advisor strategy" ein eigenes Advisor-Tool vorgestellt: Ein schnelleres, guenstigeres Modell uebernimmt den gesamten Arbeitsablauf. Ein leistungsstaerkeres Modell wird nur an ausgewaehlten, kritischen Entscheidungspunkten als "Advisor" konsultiert, nicht bei jedem Schritt. In Anthropics eigenem Benchmark verbesserte diese Kombination das Ergebnis auf SWE-bench Multilingual um 2,7 Prozentpunkte gegenueber dem alleinigen Einsatz des teureren Modells, bei 11,9 Prozent geringeren Kosten pro Aufgabe.

Technisch ist das Advisor-Tool als eigenstaendiges Tool-Call-Pattern implementiert: Das guenstigere Modell kann waehrend seines Arbeitsablaufs das Advisor-Tool aufrufen, wenn es an einen Punkt kommt, an dem es unsicher ist oder eine hoeherwertige Einschaetzung braucht. Der Rest der Session laeuft unveraendert ueber das guenstigere Modell weiter.

Zur Vorsicht bei kursierenden Zahlen: Fuer neuere Modellkombinationen (Sonnet 5 als Arbeitsmodell, Fable 5 als Advisor) werden online teils hoehere Werte genannt, etwa "92 % der Fable-5-Leistung bei 63 % der Kosten" auf einem als "SWE-bench Pro" bezeichneten Benchmark. Diese Zahl liess sich keiner offiziellen Anthropic-Quelle eindeutig zuordnen – wir geben sie deshalb nicht als gesicherten Fakt wieder, sondern nur die oben genannten, direkt auf Anthropics eigene Ankuendigung zurueckfuehrbaren 2,7 Prozentpunkte und 11,9 Prozent.

Das Orchestrator-Pattern: planen teuer, ausfuehren guenstig

Ein zweites, noch besser dokumentiertes Muster stammt aus dem offiziellen Claude-Cookbook-Repository (github.com/anthropics/claude-cookbooks, Notebook managed_agents/CMA_plan_big_execute_small.ipynb): Das teure Flaggschiffmodell uebernimmt ausschliesslich die Planung – es zerlegt eine Aufgabe in Teilschritte. Mehrere Instanzen eines guenstigeren Modells arbeiten diese Teilschritte anschliessend parallel als Worker ab.

Das ist eine andere Form von "parallel" als in unserem Artikel zu Git Worktrees und parallelen KI-Agenten: Dort verteilen mehrere Agenten unabhaengige Entwicklungsaufgaben auf mehrere Worktrees – Durchsatz durch Aufgaben-Parallelisierung. Hier arbeiten mehrere Instanzen desselben guenstigen Modells parallel an Teilschritten einer einzigen, vom teuren Modell geplanten Aufgabe – Kostenoptimierung durch Rollentrennung, kein Mehr an gleichzeitig erledigten Aufgaben.

Auf dem BrowseComp-Benchmark erreichte dieser Aufbau 86,8 % Genauigkeit bei 18,53 $ pro Aufgabe, gegenueber 90,8 % Genauigkeit bei 40,56 $, wenn das Flaggschiffmodell die komplette Aufgabe allein loest – rund 96 % der Ausgangsleistung bei etwa 46 % der Kosten. Diese Zahlen sind direkt aus dem Cookbook nachvollziehbar, nicht nur eine Paraphrase.

Ein zusaetzlicher, mechanisch nachvollziehbarer Kostenhebel: Jeder Sub-Agent fuehrt seinen eigenen Prompt-Cache. Wiederholter Kontext (Systemprompt, gemeinsame Referenzdaten) wird dadurch nicht bei jedem Worker erneut zum vollen Preis abgerechnet.

Was belegt ist, und was nicht

Kurze Zusammenfassung zur Einordnung, welche Zahlen in diesem Artikel auf eine Primaerquelle zurueckgefuehrt werden koennen – und welche nicht:

Wie sich das auf OpenClaw-Agenten uebertragen laesst

OpenClaw-Agenten, wie Clawgency sie fuer DACH-Unternehmen implementiert, bestehen aus konfigurierbaren Rollen mit jeweils eigenem Modell-Backend. Das Advisor/Orchestrator-Prinzip uebertraegt sich direkt:

• Fuer Kundenservice-Agenten: Standardanfragen (FAQ-Antworten, Statusabfragen) laufen ueber ein schnelles, guenstiges Modell. Eskalationen, mehrdeutige Anfragen oder Faelle mit hohem geschaeftlichem Risiko werden an ein leistungsstaerkeres Modell als Advisor weitergereicht – analog zum Anthropic-Pattern.
• Fuer Dokumentenverarbeitung und Batch-Aufgaben: Ein Planungsschritt (welche Dokumente, welche Reihenfolge, welche Ausnahmen) laeuft ueber ein leistungsstaerkeres Modell, die eigentliche Extraktion/Klassifikation laeuft parallel ueber mehrere guenstigere Worker-Instanzen – direktes Orchestrator-Pattern.
• Kostentransparenz als Voraussetzung: Ohne Logging pro Agentenrolle und Modellkombination bleibt jede Optimierung Bauchgefuehl. Wir bauen das deshalb standardmaessig in jede OpenClaw-Implementierung ein.

# Illustrative Rollenkonfiguration eines OpenClaw-Agenten (Beispielsyntax, keine Referenzimplementierung)

rolle: kundenservice-standard
modell: schnell-guenstig
eskalation:
  bedingung: mehrdeutige_anfrage ODER hohes_risiko
  modell: leistungsstark        # Advisor-Pattern

rolle: dokumentenpruefung-planung
modell: leistungsstark          # plant, fuehrt selbst nicht aus
worker:
  anzahl: 5
  modell: schnell-guenstig      # Orchestrator-Pattern

Praxisrechnung: 20 Fakten verifizieren

Aus dem Claude-Cookbook-Beispiel, direkt uebertragbar auf viele OpenClaw-Use-Cases (Recherche, Datenabgleich, Dokumentenpruefung): Die Aufgabe, 20 Fakten zu verifizieren, kostete im Orchestrator-Aufbau 1,61 $ und dauerte 194 Sekunden. Dieselbe Aufgabe, geloest allein vom Flaggschiffmodell, kostete 4,00 $ und dauerte 608 Sekunden – nicht nur 2,5-mal teurer, sondern auch rund 3-mal langsamer. Ueber 80 % der verbrauchten Token liefen im Orchestrator-Aufbau ueber den guenstigeren Worker-Tarif.

Wo dieser Ansatz an Grenzen stoesst

• Nicht jede Aufgabe laesst sich sauber aufteilen. Manche Agentenaufgaben sind durchgehend anspruchsvoll und lassen sich nicht in "einfache" und "kritische" Teilschritte zerlegen, ohne Qualitaet zu riskieren.
• Aufteilung ist Architekturarbeit, kein Konfigurationsschalter. Der Workflow muss von Anfang an so strukturiert sein, dass sich Rollen und Teilschritte trennen lassen.
• Caching muss explizit geprueft werden – siehe oben, Abschnitt "Orchestrator-Pattern".
• Die 92/63-Zahl ist mit Vorsicht zu geniessen. Planen Sie mit den belegten Groessenordnungen (Advisor: rund 12 % Ersparnis; Orchestrator: teils ueber 50 % bei parallelisierbaren Aufgaben), nicht mit den groessten kursierenden Werten.

FAQ: Multi-Agent-Kostenoptimierung mit Advisor- und Orchestrator-Pattern