Die Claude Advisor Strategy, erklärt von Praktikern, die sie schon ausgeliefert haben

Die meisten Teams, die einen KI-Agent bepreisen, starten mit derselben Frage: Wie gross muss das Modell ganz oben eigentlich sein? Heute hat Anthropic einen Post veröffentlicht, der die Frage komplett umdreht.

Die Claude Advisor Strategy setzt ein günstiges Modell an die Spitze, entweder Sonnet oder Haiku, und zieht Opus nur dann hinzu, wenn das günstige Modell nicht weiterweiss. Keine End-to-End-Opus-Rechnung. Keine Haiku-Solo-Schwäche. Das grosse Modell taucht nur dort auf, wo es wirklich gebraucht wird.

Wenn Du schon einmal versucht hast, Opus durchgängig zu fahren und Dir die Kosten pro Task die Decke gesprengt haben, wirst Du das kennen. Wenn Du Haiku solo getestet hast und gesehen hast, wie es bei den harten Entscheidungen patzt, wirst Du das ebenfalls kennen. Wir fahren eine Cross-Vendor-Variante genau dieses Musters seit Monaten für KMU-Kunden: GPT-5.4-mini als Advisor, darunter eine Mischung aus GPT-5.4-nano und Gemini 2.5 Flash Lite als Worker. Anthropics Post ist das erste Mal, dass wir das Muster sauber benannt und gemessen sehen.

Das hier ist der Praktiker-Read. Du bekommst die Definition in Klartext, Anthropics veröffentlichte Zahlen, den Vergleich zu den Mustern, die sie ersetzt, ein Entscheidungs-Framework für Deinen eigenen Workload und die Fehlermodi, die im Anthropic-Post nicht stehen. Wenn Du das abkürzen willst, kannst Du jederzeit einen kostenlosen 30-Minuten KI-Potenzial-Check buchen und Dein Agent-Use-Case mit auf den Call bringen.

Was die Claude Advisor Strategy wirklich ist

Die Claude Advisor Strategy ist ein Multi-Model-Agent-Muster, bei dem ein günstiger Executor einen Task End-to-End ausführt und ein smarteres Modell nur dann als Advisor aufruft, wenn er an einer Entscheidung hängenbleibt, die er nicht lösen kann. Der Advisor gibt einen Plan, eine Korrektur oder ein Stop-Signal zurück, und der Executor läuft weiter. Der Advisor ruft nie Tools auf. Er produziert nie Output für den Nutzer. Er schubst den Executor nur an.

In Anthropics Version ist der Executor Sonnet oder Haiku, der Advisor ist Opus, und der Advisor ist als einzelnes Tool mit dem Namen advisor_20260301 in die normale Tool-Liste des Executors eingehängt. Kein Orchestrierungs-Framework, keine extra Round-Trips, kein separater API-Call, der irgendwas zusammenflickt. Du deklarierst das Advisor-Tool in demselben Request, der den Agent startet, und der Executor entscheidet selbst, wann er es aufruft.

Das Letzte ist der wichtige Teil. Die Advisor Strategy ist kein Router. Sie ist kein Orchestrator, der entscheidet, wer was macht. Sie ist ein dumm-bis-bewiesen-festgefahren Executor, der auf eigene Verantwortung eskaliert.

Die Zahlen, die Anthropic veröffentlicht hat

Anthropic hat den Post mit zwei Benchmark-Vergleichen ausgeliefert, und es lohnt sich, sie sorgfältig zu lesen, bevor Du das Muster kopierst.

• Sonnet mit Opus-Advisor vs. Sonnet allein: +2,7 Prozentpunkte auf SWE-bench Multilingual, und 11,9% günstiger pro agentischem Task.
• Haiku mit Opus-Advisor vs. Haiku allein auf BrowseComp: 41,2% vs. 19,7%, mehr als das Doppelte des Scores. Rund 85% günstiger pro Task als Sonnet allein.

Zwei Dinge stechen heraus. Erstens: Die Sonnet-plus-Opus-Kombination ist in KI-Kostenkurven selten, weil sie gleichzeitig günstiger und besser ist als Sonnet allein.

Zweitens: Haiku plus Advisor ist nicht besser als Sonnet allein. Anthropic ist da ehrlich. Haiku mit Advisor liegt auf BrowseComp immer noch rund 29% unter Sonnet solo. Was für Haiku plus Advisor spricht, ist der Preis: Du zahlst Tiny-Model-Tarife für den grössten Teil des Tasks und Advisor-Tarife nur für die Eskalationen.

Typischer Advisor-Output: 400 bis 700 Tokens pro Aufruf. Das ist ein Absatz, kein Plan-Dokument. Der Advisor ist da, um den Executor loszureissen, nicht um die Strategie neu zu schreiben.

Für ein KMU, das einen hochvolumigen Agent fährt und bei dem die Kosten pro Task der limitierende Faktor sind, ist Haiku plus Advisor die interessante Kombination. Für ein Team, bei dem der Agent auf jedem einzelnen Task so smart wie möglich sein muss, gewinnt Sonnet plus Advisor auf ganzer Linie.

Wie sich die Claude Advisor Strategy vom klassischen Orchestrator-Worker unterscheidet

Das klassische Orchestrator-Worker-Muster setzt das smarte Modell an die Spitze. Der Orchestrator empfängt den Task, zerlegt ihn in Subtasks, delegiert jeden Subtask an einen günstigeren Worker und setzt die Ergebnisse am Schluss wieder zusammen. Es ist die Default-Architektur in den meisten Agent-Frameworks, weil es der Art entspricht, wie Menschen delegieren: Der Senior plant, die Juniors führen aus.

Die Advisor Strategy dreht das um. Das günstige Modell führt den ganzen Task durch. Das smarte Modell spricht nur, wenn es angesprochen wird. Es gibt keinen Zerlegungsschritt, kein Zusammenflicken, kein Plan-und-Delegiere-Ritual. Der Executor läuft einfach, und wenn er gegen eine Wand läuft, fragt er.

Es gibt noch eine dritte Richtung, die man kennen sollte. NVIDIA hat kürzlich Arbeit an einem kleinen Orchestrierungs-Agent namens Orchestrator-8B veröffentlicht, der das klassische Muster anders umdreht: kleiner Orchestrator an der Spitze, grosse Worker darunter für spezialisierte Tasks. NVIDIAs Post ist lesenswert, wenn Du den vollen Kosten-Qualitäts-Trade-Space sehen willst.

Drei Muster, eine Entscheidung:

Muster	Wer sitzt oben	Wer macht die Arbeit	Wann es gewinnt
Klassisches Orchestrator-Worker	Smarter Orchestrator	Günstige Worker	Tasks, die vor der Ausführung zerlegt werden müssen
Claude Advisor Strategy	Günstiger Executor	Günstiger Executor mit Advisor-Eskalationen	Tasks, bei denen die meisten Schritte einfach und ein paar hart sind
Small Orchestrator, grosse Worker	Kleiner Orchestrator	Grosse, spezialisierte Worker	Tasks, bei denen das Routing hart und die Ausführung spezialisiert ist

Wenn Du diese Woche die Spec für einen neuen Agent schreibst, ist diese Tabelle die Entscheidung, die Du treffen musst, bevor Du ein Modell auswählst.

Wir fahren das seit Monaten Cross-Vendor mit GPT-5.4-mini und Gemini

Eine Praktiker-Notiz, weil die News-Wave-Rezeption diesen Teil verschlafen wird: Die Advisor Strategy ist nicht Anthropic-exklusiv. Das advisor_20260301-Tool ist Claude-spezifisch. Das Muster ist es nicht.

Wir fahren eine Cross-Vendor-Variante dieses Musters seit Monaten für KMU-Kunden. GPT-5.4-mini ist der Advisor. GPT-5.4-nano und Gemini 2.5 Flash Lite sind die Worker. Der Mini berät alles.

Wenn ein Worker an einer Entscheidung hängen bleibt, die er nicht lösen kann, reicht er den Kontext an den Mini weiter, der einen Plan, eine Korrektur oder ein Stop-Signal zurückgibt. Der Worker nimmt den Faden dann wieder auf und beendet den Task.

Zwei Dinge haben uns beim Ausrollen der ersten Version überrascht.

Das Erste: Du brauchst kein Frontier-Modell als Advisor. Anthropic nutzt Opus, ihr grösstes Modell. Wir nutzen GPT-5.4-mini, das ist Mid-Tier.

Für die KMU-Workloads, die wir typischerweise betreuen, Dokumentenklassifizierung, Ticket-Triage, strukturierte Extraktion, leichte Browser-Tasks, sind die Entscheidungen, an denen der Worker hängen bleibt, nicht frontier-hart. Sie sind mittel-hart. Ein Mid-Tier-Advisor reicht, und er schiebt die Kostenkurve weiter nach unten, als es eine Opus-Paarung je könnte.

Das Zweite: Dem Advisor ist es egal, welches Labor den Worker gebaut hat. Ein ask_advisor(context)-Aufruf funktioniert gleich, egal ob der Aufrufer ein OpenAI-Nano oder ein Google Flash Lite ist. Du gibst die Ein-Round-Trip-Bequemlichkeit von advisor_20260301 auf und zahlst bei jeder Eskalation ein bisschen extra Latenz. Dafür behältst Du Cross-Vendor-Portabilität, und die zählt, wenn Deine Kunden zusehen, wie drei Frontier-Labore sich jedes Quartal gegenseitig überholen.

Wenn Du einen Read willst, ob das zu Deinem Stack passt, ist das genau die Art Frage, die wir bei den KI-Agenten abdecken, die wir für KMU bauen. Buche einen kostenlosen 30-Minuten KI-Potenzial-Check und wir gehen Deinen Use-Case durch das Entscheidungs-Framework, bevor Du eine einzige Zeile Code schreibst.

Wann die Advisor Strategy der richtige Griff ist

Ein Fünf-Fragen-Entscheidungs-Framework, in der Reihenfolge, in der wir es mit Kunden durchgehen:

1. Sind die meisten Deiner Task-Schritte von einem kleinen Modell lösbar, mit nur ein paar wenigen harten Entscheidungen? Wenn ja, kann ein kleiner Executor die Last tragen und nur bei den harten Stellen eskalieren.
2. Lassen sich die harten Entscheidungen im Voraus benennen? Du musst dem Executor sagen können: "Wenn Du X siehst, frag den Advisor." Unscharfe Eskalationsgrenzen produzieren entweder ständige Eskalation oder gar keine.
3. Ist der Advisor-Output begrenzt? Plan, Korrektur oder Stop-Signal. Wenn Du willst, dass der Advisor ganze Aufsätze schreibt oder Tools aufruft, baust Du etwas anderes.
4. Kannst Du die Advisor-Aufrufe pro Task begrenzen? max_uses in Anthropics Version, oder ein Counter in Deiner. Ohne Cap sprengt Advisor-Thrash Dein Budget.
5. Ist das Gesamt-Token-Budget immer noch niedriger als wenn Du das grosse Modell durchgängig laufen lässt? Addiere Worker-Tokens und Advisor-Tokens und rechne nach. Wenn nicht, nimm einfach das grosse Modell.

Fünfmal ja und die Advisor Strategy ist der richtige Griff. Jedes Nein und Du solltest etwas anderes verwenden. Wir sind diese Checkliste mit mehreren Kunden in der Architekturphase durchgegangen, und jedes Mal hat sie einen teureren Fehler später verhindert.

Wann sie der falsche Griff ist

Die Advisor Strategy ist in vier typischen Situationen falsch.

Die meisten Deiner Schritte sind hart. Wenn der Worker bei jedem zweiten Schritt eskaliert, zahlst Du ständig Advisor-Tarife und erbst obendrauf die Advisor-Latenz. Dann lass einfach das grosse Modell durchgängig laufen. Du bist einfacher und günstiger.

Du kannst die Eskalationsgrenze nicht benennen. Wenn der Executor nicht erkennen kann, welche Entscheidungen hart und welche einfach sind, eskaliert er entweder nie (stille falsche Antworten) oder immer (Kostenexplosion). Klassisches Orchestrator-Worker ist hier besser: Der smarte Orchestrator trifft den Routing-Call, anstatt diesen Call an ein günstiges Modell zu delegieren.

Du brauchst sichtbares Reasoning für den Nutzer. Die Advisor Strategy versteckt das Denken des Advisors im Advisor-Turn. Wenn Deine Nutzer sehen müssen, warum der Agent eine Entscheidung getroffen hat, setz ein Reasoning-Modell an die Front und lass den Advisor leise im Hintergrund sitzen.

Dein Worker erkennt seinen eigenen Stuck-State nicht. Ein Worker, der nicht weiss, dass er hängt, liefert falsche Antworten mit voller Überzeugung aus. Bevor Du die Advisor Strategy produktiv ausrollst, teste Deinen Worker auf Tasks, von denen Du weisst, dass sie hart sind, und beobachte, ob er eskaliert. Wenn nicht, ist entweder der Worker zu schwach oder der Eskalations-Prompt zu eng.

Wie Du das ohne Anthropics API verdrahtest

Eine minimale Skizze, wie Du das Advisor-Muster mit zwei beliebigen Modellen implementierst:

def run_agent(task, worker, advisor, max_advisor_calls=5):
    context = new_context(task)
    advisor_calls = 0
    while not context.done:
        step = worker.next_step(context)
        if step.is_stuck and advisor_calls < max_advisor_calls:
            guidance = advisor.ask(context.summary(), step.question)
            advisor_calls += 1
            if guidance.kind == "stop":
                return context.halt(reason=guidance.text)
            context.apply(guidance)
        else:
            context.apply(step.result)
    return context.result

Das ist alles. Der Executor läuft in seiner normalen Schleife, der Advisor ist ein einzelner Funktionsaufruf, und ein Counter deckelt das Advisor-Budget pro Task. Anthropics advisor_20260301-Tool spart Dir innerhalb des Claude-Stacks den Round-Trip, weil der Executor keine API-Grenze verlassen und neu betreten muss. Das ist ein Latenz- und Ergonomie-Vorteil, kein architektonischer Unterschied.

Ein paar Guardrails, die wir immer mit ausliefern:

• Ein harter Cap auf Advisor-Aufrufe pro Task, im Code durchgesetzt, nicht nur im Prompt.
• Logging bei jeder Eskalation und bei jeder Nicht-Eskalation auf einer Entscheidung, die der Prompt als hart markiert hat. Ohne diese Daten kannst Du die Eskalationsgrenze nicht tunen.
• Ein Gesamt-Token-Budget, damit der Task sauber abbricht, wenn er durchdreht.

Limitierungen und Fehlermodi, die Anthropic nicht erwähnt

Anthropics Post ist ein Produkt-Post. Er benennt das Muster, veröffentlicht die Zahlen, liefert das Tool aus. Er listet die Fehlermodi nicht auf. Vier sind wissenswert, bevor Du das Muster in Produktion ausrollst.

Advisor-Thrash. Der Executor liest einfache Entscheidungen als hart und eskaliert bei jedem Schritt. Symptom: Kosten pro Task klettern innerhalb weniger Tage Produktionsverkehr über Deine Obergrenze. Fix: Den Prompt, der entscheidet "eskaliere ich?", enger ziehen, und einen Alarm auf die Eskalationsrate setzen, damit Du es in Stunden statt Wochen bemerkst.

Latenz-Inflation. Jeder Advisor-Aufruf ist ein sequenzieller LLM-Call. Wenn der Worker zweimal pro Task eskaliert und der Advisor im Schnitt zwei Sekunden braucht, sind das vier Sekunden extra auf Deiner Baseline. Für asynchrone Agents okay. Für Echtzeit-UX schmerzhaft.

Kontextfenster-Verschmutzung. Der Advisor liest den Kontext des Executors. Lang laufende Agents mit fetten Kontexten machen jede Eskalation teuer. Plane Kontext-Kompression ein, bevor Du einen lang laufenden Agent ausrollst, sonst findest Du es auf die harte Tour heraus, wenn die Token-Rechnung kommt.

Das Silent-Non-Escalation-Problem. Der Worst Case, und der, vor dem wir Kunden am lautesten warnen. Der Executor hätte eskalieren sollen, hat es nicht getan und liefert eine zuversichtliche falsche Antwort ohne Alarm aus. Die Gegenmassnahme ist langweilig, aber nötig: Logge jede Entscheidung, die der Prompt als hart markiert hat, sample die nicht-eskalierten Fälle und überprüfe sie in Deinem normalen QA-Rhythmus. Wenn Du das überspringst, lieferst Du irgendwann den stillen Fehler aus, der Vertrauen kaputt macht.

Was die Claude Advisor Strategy wirklich ändert

Die Claude Advisor Strategy ist eine benannte, gemessene, verdrahtete Version eines Musters, das Produktions-Teams schon eine Weile laufen lassen. Anthropics Beitrag sind die Benennung, die Benchmarks und das In-API-advisor_20260301-Tool, das das Ganze innerhalb ihres Stacks auf einen einzigen API-Call zusammenfaltet. Das ist ein echter Gewinn, wenn Du ohnehin auf Claude festgelegt bist.

Wenn nicht, gilt das Muster trotzdem. Günstiger Executor, smarter Advisor, begrenzte Eskalation, harter Cap auf Aufrufe. Wir fahren es Cross-Vendor mit GPT-5.4-mini, das GPT-5.4-nano und Gemini 2.5 Flash Lite berät, und es hat den Kontakt mit echten KMU-Workloads überlebt. Die Architektur ist das, was zählt. Die Modellwahl ist ein Regler, an dem Du drehen kannst.

Wenn Du das für Deinen eigenen Agent evaluierst, buche einen kostenlosen 30-Minuten KI-Potenzial-Check. Bring den Use-Case mit, wir sagen Dir, ob die Advisor Strategy die richtige Form ist, bevor Du eine Zeile Code schreibst. Mehr zur KI-Agent-Architektur für KMU findest Du in unserem Pillar wie Du KI-Agenten by default in einem Tresor hältst, und der Follow-up zu dem OpenAI Cybersecurity-Modell und was es für KMU bedeutet deckt die Cross-Vendor-Landschaft ab.

Das Muster hat jetzt einen Namen. Benutz es oder nicht. Aber evaluier es beim nächsten Mal, wenn Du nach einem Orchestrator greifst.