Optimierung von Kosten und Intelligenz

Wenn ein Workload vom Prototyp in die Produktion übergeht, werden Kosten zu einer erstrangigen Design-Einschränkung. Das leistungsfähigste Modell kann im großen Maßstab zu teuer sein, und das günstigste Modell kann bei der Qualität zu kurz kommen. Kosten gut zu managen bedeutet zu verstehen, wie jeder Kostenhebel die Ausgabequalität beeinflusst, denn manche Hebel gehen auf Kosten der Qualität und manche nicht. Die Claude Platform gibt dir direkte Kontrolle über diese Abwägung. Du wählst das Modell, die Effort-Stufe und die Architektur für jede Anfrage, wodurch du einen Workload fast überall auf der Kosten-Intelligenz-Grenze platzieren kannst.

Die Hebel gibt es in zwei Arten:

• „Free wins" (kostenlose Gewinne) senken die Ausgaben, ohne die Qualität zu berühren: „prompt caching" (Prompt-Caching), Token-Hygiene, ein Prompt-Audit gegen das Modell, das du betreibst, Batch-Verarbeitung mit 50 % Rabatt für Arbeit, die bis zu 24 Stunden warten kann, und Workspace-Ausgabenlimits als Absicherung.
• „Tradeoffs" (Abwägungen) tauschen Kosten gegen Intelligenz: Modellwahl, Effort, Ausgabe-Obergrenzen und Task-Budgets sowie Multi-Modell-Architekturen.

Jeder Hebel kommt mit gemessenen Ergebnissen und der Regel, wann er sich lohnt. In Anthropics Messungen war Prompt-Caching mit großem Abstand der größte Hebel: Es senkte die Kosten von Agent-Schleifen auf den Benchmarks dieses Leitfadens um den Faktor 2,5 bis 3,7 und reduzierte die Rechnung eines kleinen Triage-Agenten um 83 %, oder 88 % mit zusätzlichem Input-Trimming. Die Multi-Modell-Hebel sind enger gefasst; ein zweites Modell lohnte sich in zwei Formen, als Advisor und als Orchestrator.



Hier beginnen

Ordne deine Situation einer Zeile zu.

Diese Ergebnisse sind Anthropic-intern (Referenzierte Benchmarks) und richtungsweisend, keine Garantien; miss also auf deinem eigenen Workload mit der Vier-Schritte-Methode.



Ausgaben senken, ohne Qualität zu verlieren

Prompt-Caching, Token-Hygiene, Batch-Verarbeitung und ein Prompt-Audit gegen dein aktuelles Modell senken alle, was du zahlst, ohne die Ausgabequalität zu senken. Zwei Vorbehalte gelten: Batch-Verarbeitung tauscht Latenz gegen ihren Rabatt, und Context Editing, ein Token-Hygiene-Hebel, kostete im in diesem Abschnitt gemessenen Lauf mehr, als es einsparte.



Wiederholten Kontext cachen

Schalte Prompt-Caching vor jedem anderen Hebel ein, denn jeder Turn einer agentischen Aufgabe sendet die gesamte wachsende Konversation erneut: System-Prompt, Tool-Definitionen und jeden vorherigen Turn. Eine Aufgabe mit 40 Turns sendet ihren ersten Turn 40-mal, sodass die Aufgabenkosten ungefähr mit dem Quadrat der Turn-Anzahl wachsen. Caching stoppt das erneute Senden nicht, aber jedes erneute Senden kostet etwa ein Zehntel so viel und wird schneller verarbeitet: Das Präfix wird zum Cache-Read-Tarif abgerechnet, einem Zehntel des Input-Preises, und jeder Turn zahlt den 1,25-fachen Cache-Write-Tarif nur für das, was neu ist.

Über Anthropics gemessene Läufe hinweg sind Cache-Reads routinemäßig die größte Einzelkomponente der Aufgabenkosten, was Caching wertvoller macht als die meisten Modellwahl-Entscheidungen. Anthropic bepreiste Läufe von WideSearch¹ und DeepResearch Bench II⁷ mit und ohne Caching:

Die Standard-Lebensdauer des Caches beträgt 5 Minuten und die Turns einer Agent-Schleife liegen Sekunden auseinander, sodass der Rabatt bei jedem Turn für die meisten Token gilt; die dargestellten Läufe erreichten Trefferquoten von 81 % bis 90 %. Die Einsparung variiert mit der Episodentiefe, weil kürzere Schleifen weniger erneut lesen, aber Caching blieb bei jedem gemessenen Modell und Benchmark der größte Einzelhebel.

Wenn deine Schleife zwischen Turns auf Menschen wartet, verwende die 1-Stunden-Cache-Dauer. Sie kostet mehr beim Schreiben (das 2-Fache des Input-Preises statt des 1,25-Fachen), zahlt sich aber beim ersten verhinderten Miss aus, weil ein Miss das gesamte Präfix zum vollen Preis erneut sendet und es erneut schreibt.

Die Einrichtung erfordert wenig Arbeit. Automatisches Caching platziert Breakpoints für dich; andernfalls kann der Claude API Skill, der mit Claude Code ausgeliefert wird, Caching mit einem einzigen Prompt zu einer bestehenden Integration hinzufügen. Der folgende Auszug zeigt, wie der Skill es zu dem Harness hinzufügt, das diese Messungen erzeugt hat:

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

Diese Breakpoint-Platzierungen folgen dem Standardmuster in Explizite Cache-Breakpoints.

Drei Einstellungen können deinen Cache während einer Aufgabe brechen. Das Ändern von effort zwischen Anfragen invalidiert das gecachte Präfix; ändere es also nur dort, wo du ohnehin neu cachen würdest, etwa an einer Compaction-Grenze. Das Ändern eines Task-Budgets mittendrin bewirkt dasselbe; setze es also einmal, bei der ersten Anfrage. Jeder Context-Editing-Durchlauf invalidiert das Präfix ab dem Punkt, an dem er löscht, und die nächste Anfrage zahlt dafür, alles danach neu zu cachen; lösche also in wenigen großen Batches statt in vielen kleinen. Nimm alle drei Änderungen an natürlichen Unterbrechungen vor und bestätige dann, dass die Cache-Reads nicht gesunken sind; falls doch, zeigt die Cache-Diagnose, wo das Präfix abgewichen ist.



Input- und Kontext-Token trimmen

Die meisten Agent-Anfragen tragen Token mit sich, die die Antwort nie beeinflussen. Sie zu trimmen kostet nichts an Ausgabequalität, obwohl nicht jeder Hebel hier bei der Messung Geld sparte. Zwei Stellen, an denen du suchen kannst:

• Input-Trimming. Dynamisches Filtern im Web-Fetch-Tool hält Boilerplate aus abgerufenen Seiten heraus, Bildgrößenanpassung dimensioniert Vision-Inputs richtig, und Tool-Suche mit verzögertem Laden lädt Tool-Definitionen nur bei Bedarf. Programmatisches Tool-Calling lässt Claude mehrere Tool-Aufrufe aus Code heraus ausführen, sodass nur das gefilterte Ergebnis in den Kontext gelangt; seine Dokumentation berichtet von 24 % weniger Input-Token auf agentischen Such-Benchmarks, bei höherer Punktzahl. Tool-Kontext verwalten vergleicht Tool-Suche, programmatisches Tool-Calling, Prompt-Caching und Context Editing.
• Kontext-Lebenszyklus. Context Editing löscht veraltete Tool-Ergebnisse, und automatische Compaction mit ihrem Schwellenwert verhindert, dass lange Schleifen ihre gesamte Historie mitschleppen.

Die Hebel interagieren mit dem Cache und miteinander; beurteile sie also nach ihrem Nettoeffekt und verwende die Cache-Diagnose, um zu bestätigen, dass dein gecachtes Präfix jede Änderung überlebt. Anthropic schaltete die Hebel einzeln nacheinander für einen Issue-Triage-Agenten ein, der 20 echte Bug-Reports mit Screenshots aus einem öffentlichen Repository durcharbeitete (und, für das zweite Panel, eine längere Variante derselben Aufgabe):

Caching leistete fast die gesamte Arbeit, und Trimming brachte die Gesamtsumme auf 88 %. Jeder Balken ist ein Lauf, sodass Unterschiede von 0,10 $ Rauschen sind; die hier gezeigten sind es nicht. Compaction braucht eine Session, die lang genug ist, um sie auszulösen: Der 20-Issue-Lauf erreichte die 50.000-Token-Untergrenze nie, nachdem seine Inputs getrimmt waren, aber bei der längeren Variante des zweiten Panels wurde sie einmal ausgelöst und senkte die Rechnung um weitere 38 %.

Context Editing ist der eine Hebel hier, der nicht kostenlos ist. Jeder Löschdurchlauf schreibt die gecachte Konversation neu, was dem Prompt-Caching entgegenwirkt; in diesem Lauf kostete Context Editing mehr, als es einsparte. Verwende es, um Platz im Kontextfenster zu schaffen, und lösche in wenigen großen Batches.



Arbeit batchen, die warten kann

Die Batch API nimmt 50 % von jedem Token einer Anfrage, einschließlich gecachter, im Austausch dafür, dass Ergebnisse irgendwann innerhalb von 24 Stunden eintreffen. Leite jede Anfrage, auf die niemand wartet, durch einen Batch, und behalte den interaktiven Pfad für den Rest. Batching ist nach Caching der zweitgrößte kostenlose Hebel für unbeaufsichtigte Agent-Arbeit: Evaluierungsläufe, Backfills und geplante Jobs wie ein wiederkehrender Lauf des Issue-Triage-Agenten aus der Token-Trimming-Messung. Es lässt sich mit allem auf dieser Seite kombinieren außer Interaktivität, ist aber nicht für Claude Managed Agents Sessions verfügbar, die von Natur aus interaktiv sind (siehe Claude Managed Agents Preise).



Prompts gegen das aktuelle Modell auditieren

Jede Modellgeneration reagiert anders auf Prompts, sodass ein Prompt Text ansammelt, der für ein Modell geschrieben wurde, das du nicht mehr verwendest. Der übliche Fall ist eine überspezifische Anweisung, die hinzugefügt wurde, um ein älteres Modell zu kompensieren: „verify twice", „be maximally thorough", ein verpflichtendes Schritt-für-Schritt-Verfahren oder ein selbstgebautes Reasoning-Scratchpad. Ein neueres Modell befolgt diese wortwörtlich und erzeugt zusätzliche Tool-Runden und zusätzlichen Text, sodass die Rechnung steigt, ohne Gewinn an Genauigkeit. Prompts gegen das Modell zu auditieren, das du jetzt betreibst, und erneut, wann immer du Modelle wechselst, ist ein kostenloser Gewinn.

Das Audit ist ein einziger Befehl. Der Claude API Skill, der mit Claude Code ausgeliefert wird, hat einen prompt-audit-Befehl, der die Prompts und den Anfrage-Code eines Projekts liest und berichtet, was für ein anderes Modell geschrieben wurde. Dieser gekürzte Auszug zeigt ihn, ausgeführt gegen einen Support-Desk-Prompt und Anfrage-Code, die diese Muster enthalten:

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

Der Befehl schlägt dann seine Änderungen als Diff vor (ein Hunk gezeigt) und listet auf, was er bewusst unangetastet ließ: das Rückerstattungsfenster, die Tonanforderung und die Qualitätsmesslatte. Du prüfst einen Patch, keine Neufassung.

Der Effekt ist messbar. Auf einer Support-Desk-Evaluierung¹⁴ kosteten für Claude Opus 4.8 geschriebene Prompts auf Claude Opus 5 36 % mehr pro Ticket, ohne Änderung der Genauigkeit. Das Audit über dieselben Prompts laufen zu lassen, machte Opus 5 sowohl günstiger als die nicht auditierte Version (um 14 %) als auch genauer (97 % der Tickets, gegenüber 92 %, ein Gewinn außerhalb des Rauschens). Bei der Migration von Claude Sonnet 4.6 zu Claude Sonnet 5 nahm das Audit 14 % bei gleicher Genauigkeit weg:

Die zwei Arten von veraltetem Text haben unterschiedliche Kosten. Anweisungen, die das neue Modell zu wörtlich befolgt, kosten Geld: Das Entfernen von „verify twice" senkte die Kosten pro Ticket von Opus 5 um ein Drittel, und das Entfernen von „be maximally thorough" fast ebenso viel. Text, der nicht mehr zum Modell passt, kostet stattdessen Genauigkeit: Eine eingestellte Thinking-Einstellung, widersprüchliche Regeln und ein selbstgebautes Scratchpad, das mit dem eigenen Denken des Modells kollidiert, stellten beim Entfernen jeweils 7 bis 11 Punkte auf Opus 5 wieder her:

Dieselben Muster tauchen in Tool-Beschreibungen und Skills auf und sind auch dort das Entfernen wert.



Kosten gegen Intelligenz abwägen

Diese Hebel legen fest, wo ein einzelnes Modell zwischen Kosten und Intelligenz liegt: Modellwahl, Effort, das Wiederholen von Fehlschlägen mit einer höheren Einstellung sowie die Budgets und Obergrenzen, innerhalb derer es arbeitet. Beginne mit einem Effort-Sweep auf deinem aktuellen Modell (Effort abstimmen). Von den niedrigsten zu den höchsten Kosten und Fähigkeiten sind die aktuellen Modelle Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5 und Claude Fable 5 (das Frontier-Modell); die Modellübersicht enthält das vollständige Lineup und die Preise.



Modelle nach Kosten pro Aufgabe vergleichen

Preislisten sind pro Token geschrieben, und pro Token sieht das Frontier-Modell teuer aus: Der Pro-Token-Preis von Claude Fable 5 ist ein Mehrfaches dessen von Claude Sonnet 5. Du zahlst jedoch für abgeschlossene Aufgaben; vergleiche Modelle also nach Kosten pro abgeschlossener Aufgabe. Ein leistungsfähigeres Modell erledigt eine Aufgabe mit weniger Arbeit: weniger Turns, weniger Suchen, weniger erneutes Lesen des eigenen Kontexts und weniger Zurückrudern. Der Pro-Token-Aufschlag wird routinemäßig dadurch überkompensiert, dass von allem weniger getan wird.

Anthropic maß dies direkt auf DeepResearch Bench II⁷, einem Recherche-Bericht-Benchmark, der schwer genug ist, um die Modelle zu trennen:

Das Frontier-Modell mit low Effort war genauer und etwa 10 % günstiger pro Aufgabe als das Mittelklasse-Modell, trotz der Pro-Token-Lücke. Es gewinnt jedoch nicht immer. Auf der SWE-bench Pro³-Teilmenge dieser Seite, die beide Modelle weitgehend sättigen und deren Punktzahlen nicht mit dem öffentlichen Leaderboard vergleichbar sind, erreichte Claude Opus 5 allein das Niveau von Claude Fable 5 allein (91,7 % gegenüber 91,3 %, innerhalb des Lauf-zu-Lauf-Rauschens) bei etwa 60 % seiner Kosten. Bei schwierigerer Arbeit, wie den DeepResearch Bench II-Aufgaben, taucht Fables Vorteil wieder auf.

Für die meisten Agent-Workloads beginne mit Claude Opus 5: Pro Token kostet es die Hälfte von Fable 5 und das 2,5-Fache von Sonnet 5, und auf dieser Coding-Teilmenge erreichte es Fables Genauigkeit. Am anderen Ende beantwortete Claude Haiku 4.5 GPQA Diamond⁹-Fragen zu etwa einem Zehntel der Kosten pro Frage von Opus 5, mit 63 % Genauigkeit gegenüber 92 % für Opus, und fiel bei langen Coding-Aufgaben viel weiter zurück. Es passt zu hochvolumiger Arbeit mit prüfbaren Ausgaben, nicht zu langen agentischen Schleifen.

Die Rangfolge kehrt sich je nach Workload um, und keine Preisliste sagt dir, in welche Richtung. Bepreise jeden Kandidaten in Kosten pro abgeschlossener Aufgabe auf deinem eigenen Traffic, einschließlich Claude Opus 5 und des Frontier-Modells mit reduziertem Effort.

Bepreise den Tail deines Workloads, nicht den Median: Vergleiche Modelle auf dem schwierigsten Zehntel deiner Aufgaben, nicht auf der typischen. Bei der typischen Aufgabe sieht jedes Modell ähnlich aus und das günstigste sieht am besten aus, aber die Rechnung wird von den Aufgaben entschieden, bei denen das günstigere Modell scheitert, denn eine gescheiterte Aufgabe rechnet trotzdem ihre Token ab, dann den Wiederholungsversuch, dann was auch immer der Fehlschlag nachgelagert kostet. Der Tail ist auch dort, wohin das Geld fließt, selbst wenn nichts scheitert. Bei einem WideSearch¹-Lauf mit 20 Problemen trugen zwei Probleme 43 % der Ausgaben:

Die Multi-Modell-Strategien existieren, um Frontier-Intelligenz für diesen Tail auszugeben, ohne Frontier-Tarife für den Rest zu zahlen.



Effort abstimmen

Effort ist der direkteste Weg, ein Modell auf deine Aufgabe abzustimmen. Der effort-Parameter steuert, wie viel Denken, Tool-Calling und Selbstverifikation das Modell betreibt, und der Standard (high) passt zu anspruchsvollen Aufgaben. Die Kosten skalieren mit all dieser Aktivität; die Genauigkeit skaliert nur mit dem Teil, den deine Aufgabe braucht. Unterhalb der Obergrenze des Modells zahlen die höchsten Effort-Stufen für Tiefe, die die Aufgabe nie nutzt.

Auf den Recherche- und Wissensarbeits-Benchmarks (WideSearch¹, DeepWideSearch⁶, BrowseComp⁴ und GDPval², alle mit Claude Fable 5) ist die Kurve von Genauigkeit gegen Kosten nahezu flach: low gab 1 bis 3 Punkte auf für ein Drittel bis die Hälfte weniger Kosten pro Aufgabe, medium erreichte die Genauigkeit des Standards bei 70 % bis 85 % seiner Kosten, und der Standard brachte auf keinem der vier etwas Messbares gegenüber medium. Auf DeepWideSearch erreichte low außerdem das Niveau eines Orchestrators mit einem Claude Sonnet 5 Worker bei 20 % niedrigeren Kosten: Den Effort zu senken schlug eine Architekturänderung.

Niedrigere Einstellungen sind auch schneller, was zählt, wenn Latenz die Einschränkung ist. In diesen Läufen brauchte low 4,5 Minuten pro Problem auf DeepWideSearch, gegenüber 7,9 Minuten beim Standard. Auf dem Korpus-Benchmark, dessen Input in kein einzelnes Kontextfenster passt, brauchte Fable 5 7,9, 9,1 und 11,4 Stunden pro Episode bei low, medium und dem Standard.

Langfristiges Coding ist die andere Form. Auf SWE-bench Pro³ gab Claude Opus 5 bei medium etwa 2 Punkte für die Hälfte der Kosten auf und bei low etwa 8 Punkte für ein Viertel davon: eine echte Abwägung, die das Wiederholen von Fehlschlägen mit höherem Effort wieder in eine Einsparung verwandelt. Dieses Diagramm stellt Genauigkeit gegen Kosten für die Recherche- und Wissensarbeits-Benchmarks und für SWE-bench Pro dar:

Zwei Konsequenzen folgen daraus. Erstens: Zeichne diese Kurve für deinen eigenen Workload, bevor du ein zweites Modell hinzufügst; in diesen internen Messungen kostete eine Multi-Modell-Konfiguration, die günstiger aussah als das Standard-Einzelmodell, mehr als dasselbe Modell mit niedrigerem Effort. Zweitens: Diese Kurve ist die Einzelmodell-Baseline, die jede Multi-Modell-Strategie schlagen muss, weshalb Schritt 2 des Messens auf deinem eigenen Workload Baselines über Effort-Stufen hinweg erstellt.

Niedrigerer Effort kostet durchaus Genauigkeit bei Workloads, die die Obergrenze des Modells erreichen, wo Genauigkeit tatsächlich mit der Reasoning-Tiefe skaliert. Auf DeepResearch Bench II⁷, wo jeder Bericht tiefes Reasoning pro Unterthema belohnt, brachte jeder Effort-Schritt etwa 2,4 Punkte Rubrik-Punktzahl; auf dieser Kurve gibt es keine kostenlose Kostensenkung:

Die Aufgabenbeschreibung allein verrät nicht, welche Art von Workload du hast; sweepe also zwei oder drei Effort-Stufen auf einer Stichprobe deines eigenen Traffics und lies die Antwort von der Kurve ab. Teste jede Stufe in einer separaten Session: Den Effort mitten in der Session zu ändern invalidiert den Cache (siehe Wiederholten Kontext cachen) und verzerrt den Vergleich. Für Parameterdetails siehe Effort.



Fehlschläge mit höherem Effort wiederholen

Wenn das Ergebnis einer Aufgabe prüfbar ist, ist die günstigste Strategie auf der Effort-Kurve keine feste Einstellung: Führe jede Aufgabe mit einer niedrigen Einstellung aus und wiederhole nur die Fehlschläge mit einer höheren.

Anthropic berechnete diese Strategie Aufgabe für Aufgabe aus den Effort-Läufen auf der SWE-bench Pro³-Teilmenge in Effort abstimmen. Mit Claude Opus 5 bei low scheiterten 16 % der Aufgaben; mit diesen beim Standard wiederholt bestanden etwa 93 % für etwa 0,70 $ pro Stück, gegenüber 91,7 % für 1,39 $, wenn alles beim Standard lief: dieselbe Erfolgsquote für die Hälfte der Kosten, die gescheiterten günstigen Versuche mitgezählt. Stattdessen bei medium zu beginnen löste etwa 94 % für etwa 0,95 $. Der größte Teil des kleinen Zugewinns ist der zweite Versuch (die eigenen Fehlschläge des Standards beim Standard zu wiederholen erzielt etwa dieselbe Punktzahl, für mehr Geld); nutze diese Strategie also für die Einsparung, nicht für den Zugewinn:

Zwei Bedingungen gelten. Erstens brauchst du ein Fehlschlagsignal (hier die eigenen Tests des Benchmarks); ein Checker, der schlechte Arbeit durchlässt, lässt diese Fehlschläge durch. Zweitens braucht jeder Fehlschlag im ersten Durchgang die Wall-Clock-Zeit von zwei Läufen, sodass die Einsparung bei den Fehlschlägen mit Latenz bezahlt wird.



Budgets und Ausgabe-Obergrenzen festlegen

Die meisten agentischen Aufgabenläufe sind günstig, aber eine Minderheit gibt ein Vielfaches der Mediankosten für Suchen, erneutes Verifizieren und übermäßiges Testen aus. Ein Task-Budget zielt auf diesen Tail. Das Modell sieht einen Live-Token-Countdown für die gesamte Aufgabe und reguliert sich selbst, indem es Suchen mit geringem Wert kürzt, redundante Verifikation überspringt und abschließt, statt sich zu verzetteln.

Anthropic maß Erfolgsquote und Kosten pro Aufgabe auf SWE-bench Pro³ mit Claude Fable 5, während das Budget enger wurde:

Ein großzügiges Budget gab etwa 2,7 Punkte Erfolgsquote für eine Kosteneinsparung von 18 % auf, und das engste erlaubte Budget gab 4,4 Punkte für eine Einsparung von 47 % auf. Budgets kauften hier Effizienz, nicht Genauigkeit.

Drei Steuerungen erledigen drei verschiedene Aufgaben. Ein Task-Budget spart Geld, weil das Modell es sieht. max_tokens ist eine Sicherheitsobergrenze, die nichts spart. Auf Claude Managed Agents ist ein Session-Budget der harte Dollar-Stopp hinter beiden. Setze alle drei: ein Task-Budget, ein hohes max_tokens und eine Session-Obergrenze für den Lauf, den du nie auf einer Rechnung sehen willst, mit einem Workspace-Ausgabenlimit als letzter Absicherung.

• Task-Budgets sind in Beta (Beta-Header task-budgets-2026-03-13) auf Claude Opus 5, Claude Fable 5, Claude Opus 4.8 und Claude Opus 4.7, aber nicht auf Claude Sonnet 5; prüfe zuerst die Support-Tabelle. Beginne nahe der 90.-Perzentil-Token-Nutzung deiner Schleife und ziehe dann enger (Ein Budget wählen zeigt, wie du diese Verteilung erhebst). Budgets unterhalb der aktuellen 20.000-Token-Untergrenze werden abgelehnt, und sehr enge Budgets können verweigerungsähnliches Verhalten erzeugen. Setze das Budget einmal, bei der ersten Anfrage, weil eine Änderung mitten in der Aufgabe den Cache invalidiert. Das Budget ist beratend, es lenkt das Modell, statt es zu stoppen; verifiziere also die Einhaltung auf deinem Workload.
• max_tokens begrenzt eine einzelne Antwort, unsichtbar für das Modell, sodass das Senken das Modell nicht zum Sparen bringt. Die Turns, die den Platz brauchten, werden verworfen und trotzdem abgerechnet. Auf einem internen Repository-Aufgaben-Benchmark¹² beendete eine 16.384-Token-Obergrenze 15 % der Versuche von Claude Opus 5 und ein Drittel derer von Claude Fable 5, keiner davon gelöst. Begrenzte Läufe gaben weniger pro Versuch aus, kauften aber proportional weniger Lösungen, sodass die Kosten pro gelöster Aufgabe dieselben waren wie bei 64.000. Bei dieser Einstellung wurde nichts abgeschnitten, und Fable löste 54,6 % der Aufgaben statt 36,6 % bei den Problemen, die beide Läufe bewerteten (auf einem separaten Ausschnitt der SWE-bench Pro³-Teilmenge, beschrieben in Referenz 12, 92 % statt 90 %). Begrenzte Versuche zu wiederholen fügt nur Kosten hinzu: Bei derselben Obergrenze gelangen sie nie, und bei einer höheren zahlst du zusätzlich für den verschwendeten Versuch. Setze max_tokens für agentische Arbeit auf 64.000 (128.000, das Maximum, bei xhigh oder max Effort), streame Antworten dieser Größe, behandle stop_reason: max_tokens als Fehlschlag und spare Geld mit Effort und Task-Budgets, die das Modell sehen kann.
• Session-Budgets auf Claude Managed Agents sind der harte Stopp. Ein Session-Budget ist eine Dollar-Obergrenze für eine Session zu Listenpreisen für Token, Suchen und Session-Zeit. An der Obergrenze pausiert die Session mit stop_reason: budget_reached; das Erhöhen des Budgets setzt sie fort. Es wird von der Plattform durchgesetzt, funktioniert auf jedem Modell mit einem Listenpreis (einschließlich Claude Sonnet 5) und lässt sich mit dem beratenden Task-Budget kombinieren. Deployments wenden dasselbe Feld auf jeden Lauf an.

Das erste von zwei max_tokens-Diagrammen stellt die Kosten pro Versuch und pro gelöster Aufgabe bei jeder Obergrenze dar:

Das zweite stellt die Ausgabelänge pro Turn gegen die Obergrenzen dar:



Modelle kombinieren

Multi-Modell-Architekturen passen zu Workloads, deren Aufgabenkomplexität stark genug variiert, dass verschiedene Schritte am besten von verschiedenen Modellen bedient werden. Wenn dein Traffic Routinearbeit, die ein kleineres Modell zuverlässig bewältigt, mit schwierigeren Schritten mischt, die Frontier-Fähigkeiten brauchen, hält das Aufteilen der Arbeit Frontier-Intelligenz dort, wo sie zählt, während die meisten Token zu Tarifen kleinerer Modelle abgerechnet werden. Wenn einem Workload diese Mischung fehlt, weil seine Schwierigkeit gleichförmig ist oder er eine einzige abhängige Kette ist, ist ein einzelnes gut abgestimmtes Modell meist die bessere Wahl. Jeder Strategie-Abschnitt gibt die Regel an, um die beiden Fälle zu unterscheiden.

Zwei Strategien decken die meisten Workloads ab, und sie unterscheiden sich darin, welches Modell die Hauptschleife hält:



Advisor-Strategie: schwierige Entscheidungen eskalieren

In der Advisor-Strategie führt ein kostengünstigeres „executor"-Modell (ausführendes Modell) die Agentenschleife aus und übernimmt die meisten Züge. Wenn es auf eine Entscheidung stößt, die tieferes Urteilsvermögen erfordert, etwa die Wahl eines Ansatzes oder die Erholung nach einem Fehlschlag, ruft es ein intelligenteres „advisor"-Modell (Berater-Modell) für strategische Orientierung auf und fährt dann fort. Die meisten Token werden zu Executor-Tarifen abgerechnet und nur die gelegentlichen Konsultationen zu Advisor-Tarifen.

Um sie zu nutzen, füge das Advisor-Tool zu deiner Anfrage hinzu. Dieses Beta-Feature führt die gesamte Strategie serverseitig in einer einzigen /v1/messages-Anfrage aus: Der Executor gibt einen Tool-Aufruf aus, Anthropic führt die Advisor-Inferenz aus, und der Executor fährt mit dem Rat fort; du schreibst keinen Orchestrierungscode. Auf Claude Managed Agents gibst du der Session einen Advisor, indem du einen advisor-Eintrag zum multiagent-Roster des Agenten hinzufügst; der primäre Thread der Session konsultiert ihn auf dieselbe Weise. Claude Code unterstützt sie ebenfalls; siehe schwierige Entscheidungen mit dem Advisor-Tool eskalieren.

Was den Ertrag bestimmt. Der Advisor sieht die Aufgabe nur durch die Aufrufe des Executors, daher entscheiden zwei Dinge, wie viel er hilft.

Das erste ist die Lücke zwischen den Modellen. Der Advisor kann nur Fähigkeiten weitergeben, die dem Executor fehlen: Auf GPQA Diamond⁹ gewann ein Claude Haiku 4.5 Executor sehr viel durch einen Claude Opus 5 Advisor, ein Claude Sonnet 5 Executor gewann ein paar Punkte und ein Frontier-Executor fast nichts.

Das zweite, und das fragile, ist, ob der Executor tatsächlich fragt (die „consult rate" (Konsultationsrate)). Ein Executor bei niedrigem „effort" (Aufwand) kann aufhören zu bemerken, dass er feststeckt: Eine Paarung, die beim Standard-Effort bei den meisten Aufgaben konsultiert, kann bei gesenktem Effort dazu übergehen, bei fast keiner zu konsultieren, und erzielt dann weniger Punkte als der Executor allein. Die Rate variiert auch je nach Aufgabe: Auf DeepSWE¹⁰ fragte ein Sonnet 5 Executor mit niedrigem Effort weiter und gewann 23 Punkte; auf SWE-bench Pro³ hörte derselbe Executor auf. Wenn der Executor fragt, kommt er den größten Teil des Weges voran. Über die Paarungen im folgenden Diagramm hinweg schloss der Advisor 60 % bis 90 % der Lücke zum stärkeren Modell, während dieses Modell nur für die Konsultationen bezahlt wurde, was die Kostenfälle möglich macht:

Die Konsultationsrate reagiert auf Prompting. Nur mit der eingebauten Beschreibung des Tools rufen Executors zu selten auf, besonders bei Coding-Arbeit, daher gibt die Dokumentation des Advisor-Tools einen System-Prompt vor, der einen Aufruf vor substanzieller Arbeit und einen vor dem Abschluss verlangt, etwa zwei bis drei Aufrufe pro Aufgabe. Die als Nächstes gemessene Coding-Paarung lief in diesem Rhythmus, etwa zwei Konsultationen bei jeder Aufgabe. Diese Seite behandelt auch, wie man einen zu selten aufrufenden Executor anstößt und Aufrufe clientseitig begrenzt, um die Kosten zu deckeln. Beobachte also die Konsultationsrate: Prompte dafür, miss sie und stelle den Effort des Executors wieder her, wenn sie einbricht.

Wann es sich bei den Kosten auszahlt. Ein Advisor spart Geld, wenn ein paar kurze Konsultationen, abgerechnet zum Tarif des Advisors, den Betrieb des Advisor-Modells für die gesamte Aufgabe ersetzen. Das funktioniert am besten, wenn das Modell des Advisors deutlich über dem des Executors bepreist ist, sodass die kosteneffektivste Konfiguration ein Frontier-Advisor über einem Executor der mittleren Klasse ist. Eine Paarung kann sich sogar am oberen Ende der Spanne behaupten, weil Rat auch Executor-Token spart: Ein Executor, dem der richtige Ansatz mitgeteilt wird, erkundet weniger Sackgassen, was die Konsultationen decken kann.

Auf einem internen Agentic-Coding-Benchmark¹¹, ausgeführt mit einem einfachen API-Agenten, war ein Claude Opus 5 Executor mit einem Claude Fable 5 Advisor die genaueste gemessene Konfiguration: 85,7 % der Versuche gelöst für 8,40 $ pro Versuch. Sie liegt über der Linie durch die eigenen Effort-Einstellungen jedes Modells, aber nur einen oder zwei Punkte über der besten davon (Opus allein bei der Standardeinstellung, 84,4 % für 8,50 $, und Fable allein bei medium, 83,4 % für 8,20 $), was ein einzelner Lauf nicht vom Rauschen trennt. Fable allein bei medium-Effort erreicht etwa dieselbe Genauigkeit wie die Paarung (83,4 % gegenüber 85,7 %) für etwa dasselbe Geld (8,20 $ gegenüber 8,40 $ pro Versuch):

Eine frühere Messung über den Advisor-Modus von Claude Code ergab dieselbe Reihenfolge. Lies dieses Ergebnis als eine Form, die du auf deinem Workload testen solltest, nicht als Einsparung: Am oberen Ende der Spanne kauft der Advisor ein wenig Genauigkeit zum Frontier-Preis, und der Kostenfall gehört zu Paarungen mit einer größeren Fähigkeitslücke, wie dem folgenden Fall zum Lesen von Diagrammen. Die Latenzkosten sind die Konsultationen selbst: etwa zwei zusätzliche Frontier-Modell-Aufrufe pro Aufgabe auf diesem Benchmark, jeder auf dem kritischen Pfad der Aufgabe.

Wann es sich statt einer Effort-Erhöhung auszahlt. Wo die Fähigkeitslücke größer ist und die Genauigkeit eines Workloads auf Effort reagiert, kann ein Executor mit niedrigem Effort, der einen Advisor konsultiert, ein günstigerer Schritt nach oben sein als die Erhöhung des eigenen Efforts des Executors, weil der Advisor nur bei Aufgaben bezahlt wird, die ihn brauchen.

Auf Chartography¹³, einem öffentlichen Benchmark zum Lesen von Diagrammen, ausgeführt auf Claude Managed Agents mit dessen Advisor, erzielte ein Claude Opus 5 Executor bei low-Effort mit einem Claude Fable 5 Advisor 67,5 für 0,60 $ pro Aufgabe. Das liegt über der Linie durch die eigenen Effort-Einstellungen beider Modelle (Opus allein stieg zwischen low und medium von 49 auf 75 für 0,38 $ bis 0,94 $), obwohl die eigenen medium- und Standardeinstellungen des Executors immer noch die Spitzenwerte halten, zum 1,6- und 3,3-fachen Preis:

Der Executor mit niedrigem Effort konsultierte den Advisor bei 86 % der Aufgaben, die Bedingung, die die SWE-bench-Pro-Paarung nicht erfüllte. Miss die Konsultationsrate in deiner Agentenschleife, bevor du dich auf diese Konfiguration verlässt.

Welche Paarung auch immer, bepreise zuerst das Modell des Advisors allein bei niedrigem Effort; das ist die Baseline, die es zu schlagen gilt. Prüfe bei jedem Modell-Release erneut, denn Releases verschieben sowohl die Fähigkeitslücke als auch das Preisverhältnis.

Wann sie passt. Die Advisor-Strategie eignet sich für Workloads, bei denen die Züge größtenteils mechanisch sind, aber ein exzellenter Plan zählt: Coding-Agenten, Computer Use und mehrstufige Recherche-Pipelines. Sie passt schlecht, wenn jeder Zug tatsächlich Frontier-Fähigkeiten braucht, wenn es nichts zu planen gibt (Single-Turn-Q&A) oder wenn dein Executor bereits nahe an der Fähigkeit des Advisors liegt.



Orchestrator-Strategie: Massenarbeit delegieren

In der Orchestrator-Strategie hält das Frontier-Modell die Schleife. Es zerlegt die Aufgabe, verteilt Teilaufgaben an kostengünstigere „worker"-Modelle (Arbeiter-Modelle) und führt deren Ergebnisse zusammen. Das eigene Transkript des „orchestrator" (Orchestrators) bleibt kurz, weil die Worker die tokenintensive Erkundung übernehmen, sodass die meisten Token zu Worker-Tarifen abgerechnet werden, während Plan und Synthese weiterhin vom Frontier-Modell kommen.

Um eine zu bauen, verwende Multiagent-Orchestrierung in Claude Managed Agents: Konfiguriere einen Koordinator-Agenten (den Orchestrator) und ein Roster von Worker-Agenten, jeder mit seinem eigenen Modell. Ein vollständiges funktionierendes Beispiel mit einem Claude Fable 5 Koordinator und Claude Sonnet 5 Workern findest du im Claude Cookbook-Rezept Coordinator pattern: big models for planning, small models for execution.

Dieses Muster spart reale Laufzeit, wenn Worker parallel laufen können: Auf dem Korpus-Benchmark⁸ dauerte eine Episode etwas über 2 Stunden, wenn der Koordinator das dokumentierte Limit der Plattform von 25 gleichzeitigen Workern ausführte, gegenüber 11,4 Stunden solo. Geld sparte es nur in zwei gemessenen Situationen. Bei Arbeit, die ein einzelnes Modell allein bewältigen konnte, war dasselbe Modell bei niedrigerem Effort jedes Mal günstiger.

Fall 1: Versicherung gegen den Kosten-Tail bei Routinearbeit. Ein allein laufendes Frontier-Modell verrennt sich gelegentlich bei einem Routineproblem, das es normalerweise lösen würde. Weil du nicht im Voraus sagen kannst, welche das sein werden, dominieren ein paar solcher Läufe die Rechnung. Ein Koordinator, der Routinearbeit an einen kostengünstigeren Worker übergibt, deckelt diesen Tail, weil jedes Verrennen nun zu Worker-Tarifen geschieht.

Anthropic hat dies auf einem bewusst einfachen Ausschnitt von BrowseComp⁴ gemessen (10 Probleme, die das Solo-Modell zuverlässig löst; 50 delegierte und 70 Solo-Läufe). Ein Claude Fable 5 Koordinator mit einem Claude Sonnet 5 Worker kostete im Durchschnitt etwas weniger als halb so viel wie Fable allein und etwa ein Drittel so viel beim 90. Perzentil (12 $ gegenüber 33 $), und der einzelne teuerste Lauf des Solo-Modells, bei 84 $, war zudem falsch:

Delegation zahlte sich beim routinemäßigen, normalerweise lösbaren Anteil der Arbeit aus, das Gegenteil der Intuition, dass Worker für schwierige Probleme da sind. Auf dem vollständigen, schwierigeren BrowseComp-Set kehrte sich die Wirtschaftlichkeit um. Wenn dein Traffic einen langen Kosten-Tail bei Routineaufgaben hat, ist dies der Orchestrator-Fall, den du zuerst messen solltest.

Fall 2: Arbeit, die größer als ein Kontextfenster ist. Ein Solo-Modell muss eine so große Eingabe seriell durcharbeiten, ein „context window" (Kontextfenster) nach dem anderen, und bezahlt bei jedem Durchgang dafür, seinen eigenen Zustand erneut zu lesen. Worker lesen jeweils ihre eigene Partition, parallel und zu Worker-Tarifen. Leseintensive Arbeit, die noch in ein Kontextfenster passt, ist ein Problem der Modellwahl, kein Delegationsproblem: Allein bei den Lesekosten liegt der Orchestrator nur vorn, wenn kein einzelner Kontext die Arbeit fassen kann.

Anthropic hat für diesen Fall einen Benchmark gebaut⁸: einen Korpus von 21,6 Millionen Token aus 14 öffentlichen Python-Paketen mit 130 eingebauten Defekten, zu groß für jedes Kontextfenster. Den Effort zu senken kann nicht helfen, weil die Rechnung das Lesen des Korpus selbst ist: Claude Fable 5 solo kostete bei jeder Effort-Einstellung 720 $ bis 764 $ pro Episode, und nur seine Genauigkeit bewegte sich. Die Koordinator-Konfiguration kostete mehr als 60 % weniger als jede dieser Einstellungen und erzielte 2 bis 6 Punkte weniger als Fable bei medium oder dem Standard, während sie eine Claude Sonnet 5 Solo-Baseline klar schlug:

Die Token-Abrechnung zeigt, warum. Beide Rechnungen bestehen größtenteils aus Korpus-Lesen, das aus dem Cache bedient wird: Die Koordinator-Konfiguration las etwa 570 Millionen gecachte Token pro Episode, fast dreimal so viel wie die rund 200 Millionen des Solo-Modells, und kostete trotzdem weniger als halb so viel, weil ihre Lesevorgänge zum Cache-Read-Tarif von Claude Sonnet 5 statt dem von Claude Fable 5 abgerechnet wurden. Fable 5 bei Standard-Effort hält immer noch die Spitzengenauigkeit, zum 2,8-fachen der Kosten der Koordinator-Konfiguration, sodass Delegation hier den größten Teil der Genauigkeit kauft, nicht die gesamte.

Wann sich Delegation nicht auszahlt. Ein Orchestrator kauft nur dann etwas, wenn es Masse zum Übergeben gibt: viele unabhängige Teile, idealerweise zu viele für ein Kontextfenster. Wenn die Arbeit eine abhängige Kette ist oder in einen einzelnen Kontext passt, bezahlt der Orchestrator für einen Plan, eine Übergabe und eine Zusammenführung, die ein einzelnes Modell kostenlos bekommt. In jedem solchen gemessenen Fall lag das Modell des Koordinators allein bei niedrigerem Effort vorn.

BrowseComp⁴ zeigt die Grenze innerhalb eines Benchmarks. Delegation zahlte sich beim Routineausschnitt aus und verlor beim vollständigen, schwierigeren Set, wo das Frontier-Modell allein die Genauigkeit der Koordinator-Konfiguration zu 22 % bis 30 % niedrigeren Kosten erreichte. Unabhängige externe Arbeit berichtet dasselbe Muster⁵. Wenn die Arbeit eine Kette ist, ohne langen Kosten-Tail in einen Kontext passt oder ein einzelnes Modell bei niedrigerem Effort deine Messlatte bereits erreicht, baue keinen Orchestrator.



Zwischen den Strategien wählen

Die meisten Fälle laufen auf eine Frage hinaus: Zerfällt die Arbeit in unabhängige Teile, oder ist sie eine Antwort, die über eine Kette abhängiger Schritte erreicht wird? Die Strategietabelle ordnet die beiden Antworten den beiden Strategien zu.

Wenn du unsicher bist, baue noch nichts:

1. Variiere zuerst den Effort auf deinem aktuellen Modell. Es ist das günstigste Experiment auf dieser Seite, und die meisten Workloads enden dort.
2. Wenn die Variation eine Lücke zeigt, bepreise das stärkere Modell allein bei niedrigem Effort. Das ist die Zahl, die eine Advisor-Paarung schlagen muss, und die Paarungen auf dieser Seite, die sie schlugen, waren diejenigen, deren Executor tatsächlich konsultierte.

Die Multi-Modell-Ergebnisse auf dieser Seite wurden gegen dasselbe Modell bei niedrigerem Effort und gegen das nächstkleinere Modell allein laufend beurteilt. Das ist der Vergleich, den du auf deinem eigenen Workload durchführen solltest, und der Grund, warum der erste Schritt eine Effort-Variation ist.

Wenn du einen Advisor hinzufügst, ist es eine Tool-Definition und keine Neuarchitektur.



Auf deinem eigenen Workload messen

Die Zahlen auf dieser Seite stammen aus Juli und August 2026, zu den damaligen Listenpreisen, und werden sich verschieben, wenn sich Modelle und Preise ändern. Deine Eskalationsrate, wie sauber sich Aufgaben aufteilen lassen, und die Transkriptlänge verschieben sie ebenfalls. Die Methode bleibt dieselbe:

1. Ziehe ein paar Aufgaben aus Produktionslogs, gewichtet wie echter Traffic, und schreibe Ergebnisprüfungen für jede: Tests bestehen, Ticket geschlossen, Zeilenanzahl korrekt. Notiere die Kosten pro Aufgabe neben dem Score: Bepreise die vier Token-Zählungen im usage jeder Antwort zu ihren jeweiligen Tarifen, summiert über die Anfragen der Aufgabe (die Usage and Cost API meldet das Aggregat).
2. Erstelle eine Baseline der Modellklassen über Effort-Stufen hinweg, nicht nur beim Standard, und trage Score gegen Ausgaben auf. Eine Multi-Modell-Konfiguration muss die gesamte Kurve des Einzelmodells schlagen.
3. Wenn die Kurve eine Lücke zeigt, die Effort nicht schließen kann, füge die passende Multi-Modell-Strategie hinzu und führe die Suite erneut aus.
4. Lass den Gewinner vor der Umstellung im Shadow-Modus auf einem Traffic-Ausschnitt laufen und halte die Suite dann am Laufen.

Das folgende Beispiel berechnet die Kosten aus Schritt 1 für eine Anfrage zu den Listenpreisen von Claude Opus 5:

# Preise pro Million Token von der Preisseite; ändere diese beiden für ein anderes Modell.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # Cache-Schreibvorgänge kosten das 1,25-Fache des Input-Preises (5-Minuten-Cache); Cache-Lesevorgänge das 0,1-Fache.
    + (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

In Agentenschleifen ist der Cache-Read-Term üblicherweise der größte der vier; wenn nicht, prüfe, ob Caching aktiv ist. Wenn das Advisor-Tool oder Compaction aktiviert ist, werden einige Token nur in usage.iterations und nicht in den Gesamtsummen auf oberster Ebene gemeldet, summiere also stattdessen über usage.iterations und bepreise advisor_message-Einträge zu den Tarifen des Advisor-Modells.

Die folgende Tabelle listet die Hebel in der Reihenfolge auf, in der du sie ausprobieren solltest:



Referenzierte Benchmarks

Alle Messungen sind Anthropic-interne Läufe dieser Benchmarks. Sofern nicht anders angegeben, sind die Kosten in USD zu Listenpreisen vom August 2026; Zahlen für Claude Sonnet 5 verwenden 2 $ und 10 $ pro Million Eingabe- und Ausgabe-Token. Diagramme mit der Beschriftung „notional USD" bepreisen die Token-Zählungen jeder Anfrage zu diesen Tarifen, statt Rechnungen zu berichten.

1. WideSearch: Wong et al., „WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025. Breite Web-Recherche-Aufgaben, bewertet nach Vollständigkeit und Genauigkeit einer vielzeiligen Tabelle; 200 Probleme, 3 Läufe pro Konfiguration. Die Caching- und Effort-Diagramme stammen aus getrennten Läufen, daher unterscheiden sich die Kosten pro Problem leicht. Das Kostenkonzentrations-Diagramm ist ein separater Lauf mit 20 Problemen, 3 Läufe pro Problem, bepreist aus Abrechnungsdatensätzen pro Anfrage.
2. GDPval: OpenAI, „GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025. Wissensarbeits-Ergebnisse, bewertet gegen Aufgaben-Rubriken; ein Lauf mit 210 Aufgaben des veröffentlichten Gold-Sets, ein Versuch pro Aufgabe. Ein Claude-Modell bewertet, daher können absolute Scores von veröffentlichten Ergebnissen abweichen.
3. SWE-bench Pro: Scale AI, „SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025. Eine Teilmenge von 482 Problemen, ausgewählt nach Kompatibilität mit Anthropics Evaluierungs-Harness; Scores sind nicht mit dem öffentlichen Leaderboard vergleichbar. Claude Opus 5 beim Standard-Effort mittelt zwei Läufe; Einstellungen mit reduziertem Effort sind Einzelläufe. Eskalationszahlen stammen Aufgabe für Aufgabe aus diesen Läufen: zuerst low, dann der Standard bei dessen Fehlschlägen, löste 92,5 % bis 93,6 % über Lauf-Paarungen hinweg für etwa 0,70 $; zuerst medium, 93,8 % bis 94,2 % für etwa 0,95 $; der Standard erneut ausgeführt bei seinen eigenen Fehlschlägen, 94,0 % für 1,58 $; alles beim Standard, 90,9 % bis 92,5 % für 1,39 $. Die Claude Sonnet 5 Executor-Paarungen im Advisor-Diagramm stammen aus derselben Serie vom August 2026 auf dieser Teilmenge: Die Sonnet-plus-Opus-Paarung wurde zweimal ausgeführt (ein Lauf und eine exakte Replikation) und die Paarung mit niedrigem Effort einmal; die Task-Budget-Zahlen sind ein Lauf pro Budget auf derselben Teilmenge. Die Claude Fable 5 Zahl in Modelle vergleichen ist ein einzelner Lauf vom Juli 2026, zugleich die unbudgetierte Baseline des Task-Budget-Diagramms; jeder budgetierte Lauf schloss alle 482 Probleme ohne Harness-Fehler ab.
4. BrowseComp: Wei et al., „BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025. Effort-Zahlen verwenden einen Ausschnitt von 500 Problemen, ein bis drei Läufe pro Einstellung. Das Kostenversicherungs-Diagramm verwendet 10 zuverlässig gelöste Probleme aus einem Ausschnitt von 26 Problemen, 50 delegierte und 70 Solo-Läufe (6,45 $ gegenüber 11,99 $ pro Lauf im Erwartungswert); delegierte Zahlen tragen ein Messband von etwa 20 %.
5. Agent-Architektur-Skalierung: Kim et al., „Towards a Science of Scaling Agent Systems," arXiv:2512.08296, 2025. Unabhängige externe Studie, zitiert nur für die Richtung des Befunds, wann sich Delegation nicht auszahlt, nicht für irgendeine Zahl.
6. DeepWideSearch: „DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking," arXiv:2510.20168, 2025. Die 220 Fragen umfassen 15 Domänen, jede kombiniert vielzeilige Sammlung mit Multi-Hop-Retrieval; gemessen auf dem stehenden Zeilen-Set des Benchmarks, 3 Läufe pro Konfiguration.
7. DeepResearch Bench II: Li et al., „DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026. Seine 132 Recherche-Aufgaben über 22 Domänen werden gegen von Experten abgeleitete binäre Rubriken bewertet; gemessen auf einer Teilmenge von 50 Aufgaben, stratifiziert über alle Themen, ein Versuch pro Aufgabe, 3 Läufe, bewertet auf Aufgaben, die keine Konfiguration ablehnte. Claude Opus 4.6 urteilt nach dem Rubrik-Protokoll des Benchmarks; das Original verwendet einen anderen Richter, und ein Anthropic-Richter könnte den Hausstil bevorzugen. Die Läufe liegen vor Claude Opus 5, daher dessen Fehlen im Diagramm Modelle vergleichen. Die Sonnet 5 Kosten unterscheiden sich leicht zwischen dem Caching-Diagramm (Inferenzkosten, mit und ohne Caching) und jenem Diagramm (Gesamtkosten, Caching an); beide stammen aus denselben Läufen.
8. Korpus-Defekt-Sweep: Anthropic-intern, für Arbeit, die größer als ein Kontextfenster ist: ein Korpus von 21,6 Millionen Token aus 14 öffentlichen Python-Paketquellen mit 130 eingebauten Defekten und deterministischer Bewertung; Protokoll vor den Läufen festgelegt und intern geprüft; drei Läufe pro Konfiguration. Jede Konfiguration lief auf Claude Managed Agents. Die dargestellte Team-Konfiguration ist ein Lauf vom August 2026, in dem der Claude Fable 5 Koordinator den gesamten Sweep innerhalb der Plattform an ihrem dokumentierten Limit von 25 gleichzeitigen Claude Sonnet 5 Workern ausführte; seine drei Episoden erzielten F1 0,842, 0,805 und 0,810 für 263 $, 299 $ und 261 $. Die Solo-Konfigurationen sind Läufe vom Juli 2026 auf demselben Korpus-Build. Absolutes F1 ist spezifisch für diesen Korpus-Build, nicht über Benchmarks hinweg vergleichbar; Konfigurationsvergleiche sind gleich zu gleich.
9. GPQA Diamond: Rein et al., „GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023. Die Diamond-Teilmenge mit 198 Fragen, gemessen August 2026, zwei Läufe pro Konfiguration, modellbewertet gegen Referenzantworten, Advisor-Token pro Anfrage gemessen. Eine Sicherheitsprüfung der Plattform lehnte zwei Biologie-Fragen bei den Sonnet- und Opus-Executors ab; ihr Ausschluss ändert keinen Vergleich um mehr als einen Punkt.
10. DeepSWE: Datacurve, „DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026. Gemessen August 2026: 113 originale Aufgaben über fünf Sprachen mit programmbasierten Verifizierern. Paarungen sind jeweils zwei Läufe mit pro Anfrage gemessenen Advisor-Token und verwendeten eine clientseitige Advisor-Schleife statt des Advisor-Tools, mit identischer Abrechnung. Einzelmodell-Effort-Sweeps sind Einzelläufe, bepreist aus Token-Zählungen, eine Cache-bewusste Näherung. Kosten pro Aufgabe sind Lauf-Gesamtsummen geteilt durch 113.
11. Interner Agentic-Coding-Benchmark: Anthropic-intern: 370 Repository-Aufgaben, bewertet durch die eigenen Tests der Repositories. Die API-Zahlen (Opus 5 allein, Fable 5 allein und die Paarung) wurden August 2026 beim Standard-Effort mit einer Ausgabe-Obergrenze von 128.000 Token gemessen, ein Lauf pro Konfiguration: fünf Versuche pro Aufgabe bei den Standardeinstellungen und für die Paarung, einer bei low und medium; die Paarung mittelte etwa zwei Advisor-Konsultationen pro Versuch; Kosten sind pro Versuch. Die Claude Code Zahlen sind Läufe vom Juli 2026 derselben Aufgaben, ein Lauf pro Konfiguration, Kosten ungefähr.
12. Interner Repository-Aufgaben-Benchmark (Obergrenzen-Messung): Ein separates Anthropic-internes Set von etwa 130 Repository-Aufgaben, ausgeführt August 2026 mit einer einfachen API-Agentenschleife, ein Versuch pro Aufgabe. Die Zahlen bei 16.384 Token mitteln zwei Läufe pro Modell; die Zahlen bei 64.000 Token sind Einzelläufe (124 Aufgaben bewertet für Opus 5; 108 für Claude Fable 5, da die Umgebung den Rest übersprungen hatte, bevor das Modell lief). Etwa die Hälfte der Fable-Versuche, die die Obergrenze von 16.384 beendet hatte, wurde bei 64.000 gelöst; ein weiterer Fable-Lauf bei 128.000 erzielte 56,1 %, innerhalb des Rauschens des Laufs bei 64.000. Die SWE-bench-Pro-Obergrenzen-Zahlen sind ein Claude Fable 5 Lauf pro Obergrenze beim Standard-Effort auf einer Teilmenge von 100 Problemen, stratifiziert aus dem 482-Probleme-Set von Referenz 3, nicht mit dessen Scores vergleichbar. Die Pro-Zug-Verteilungen des Diagramms stammen aus dem Opus-Lauf bei 64.000 und dem Fable-Lauf bei 128.000, sodass keiner durch seine eigene Obergrenze abgeschnitten wird.
13. Chartography: Surge AI, „Chartography," 2026. Das vollständige veröffentlichte Set mit 100 Fragen, gemessen August 2026 mit Anthropics Implementierung auf Claude Managed Agents (Standard-Cloud-Sandbox; Advisor-Konfigurationen verwenden den Managed Agents Advisor). Claude Sonnet 4.6 bewertet anstelle des Referenzrichters und der Benchmark läuft mit Tools, daher sind Scores hier über Konfigurationen hinweg vergleichbar, aber nicht mit dem veröffentlichten Leaderboard. Zwei Läufe pro Konfiguration, gepoolt; Lauf-zu-Lauf-Streuungen betrugen 4 bis 10 Punkte. Kosten schließen Sandbox-Zeit aus, die unter 1 % hinzufügte. Der Konsultationsraten-Vergleich stammt aus der erneuten Ausführung derselben Konfigurationen auf der Messages API mit einem Container-Tool-Set.
14. Support-Desk-Prompt-Audit-Evaluierung: Ein von Anthropic konstruiertes Set von 44 Support-Tickets mit deterministischer Bewertung, ausgeführt August 2026 unter sechs System-Prompts, von denen jeder demselben sauberen Prompt ein Muster hinzufügt, das in für Claude Opus 4.8 und Claude Sonnet 4.6 geschriebenen Prompts üblich ist. Jeder Diagrammpunkt ist einer von drei Fällen (älteres Modell, neueres Modell mit demselben Prompt, neueres Modell nach dem Audit), gemittelt über die sechs Prompts und 44 Tickets. Der Genauigkeitsgewinn von Opus 5 hat ein 95-%-Konfidenzintervall von 3 bis 8 Punkten; die Sonnet-Genauigkeitsunterschiede liegen innerhalb des Rauschens.



Nächste Schritte