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 (Aufwandsstufe) und die Architektur für jede Anfrage, wodurch du einen Workload fast überall auf der Kosten-Intelligenz-Grenze platzieren kannst.

Kosten und Intelligenz werden üblicherweise als eine Grenze dargestellt, auf der das eine das andere erkauft. Die erste Gruppe von Hebeln auf dieser Seite bewegt einen Workload in Richtung dieser Grenze, indem sie Kosten senkt, ohne die Qualität anzutasten; nur die zweite Gruppe bewegt sich entlang der Grenze:

Die Hebel gibt es in zwei Arten:

• „Free wins“ (kostenlose Gewinne) senken die Ausgaben, ohne die Qualität anzutasten: „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 einen Faktor von 2,7 bis 5,3 und senkte 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 zahlte sich in zwei Formen aus, als Advisor und als Orchestrator.

Hier beginnen

Ordne deine Situation einer Zeile zu.

Diese Ergebnisse sind Anthropic-intern (Referenzierte Benchmarks) und richtungsweisend, keine Garantien, also miss 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

Warum Caching zuerst kommt

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 40-Turn-Aufgabe 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,25x-Cache-Write-Tarif nur für das, was neu ist.

Wie gut aussieht. Über einen ganzen Tag echten Traffics lasen Agent-Schleifen im Median 84 % ihres Inputs aus dem Cache, und die obersten 10 % der Harnesses, ob Coding oder nicht, lasen 94 % oder mehr¹⁷. Tief in einer Aufgabe zahlt eine gut gebaute Schleife den vollen Preis für unter 1 % ihres Inputs. Unter etwa 80 % suche nach etwas, das den Cache bricht (siehe Was den Cache bricht).

Ü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 die DeepResearch Bench II⁷-Läufe 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 Läufe des Caching-Diagramms lasen 79 % bis 90 % ihrer Input-Token aus dem Cache. Die Einsparung variiert mit der Episodentiefe, weil kürzere Schleifen weniger erneut lesen, aber Caching blieb auf jedem gemessenen Modell und Benchmark der größte Einzelhebel.

Cache-Dauer wählen

Wenn deine Schleife zwischen den Turns auf eine Person wartet, verwende die 1-Stunden-Cache-Dauer. Sie kostet mehr beim Schreiben (2x den Input-Preis statt 1,25x). Ein Miss bei einer der beiden Dauern rechnet das gesamte Präfix zum Write-Preis statt zum Read-Preis ab, sodass sich die längere Dauer auszahlt, sobald einige Turns pro Session auf eine Pause zwischen 5 Minuten und einer Stunde folgen.

Um zu entscheiden, zähle die Lücken zwischen aufeinanderfolgenden Anfragen in einer Konversation:

• Mehr als etwa 1 von 20 Lücken fällt zwischen 5 Minuten und eine Stunde, und Lücken über eine Stunde sind selten: Verwende die 1-Stunden-Dauer.
• Turns kommen Sekunden auseinander an: Bleib beim 5-Minuten-Standard. Wenn nichts pausierte, kostete er 15 % weniger als die 1-Stunden-Einstellung auf Claude Sonnet 5 und 11 % weniger auf Claude Opus 5.
• Lücken über eine Stunde sind häufig: Bleib beim Standard. Eine Lücke über eine Stunde lässt beide Dauern ablaufen, und die 1-Stunden-Einstellung schreibt das Präfix dann zu ihrem höheren Write-Preis neu, sodass sie bei jeder dieser Lücken verliert. Wenn von deinen Pausen, die länger als 5 Minuten sind, etwa 60 % oder mehr auch über eine Stunde laufen, bleib beim Standard; die 1-Stunden-Dauer zahlt sich nur aus, wenn mindestens etwa 40 % der langen Pausen innerhalb der Stunde enden.

Anthropic maß den Triage-Job aus Input- und Kontext-Token trimmen mit vor einigen Turns eingefügten Pausen, um die Verzögerung einer Person zu simulieren¹⁶. Auf beiden gemessenen Modellen wurde der 1-Stunden-Cache zur günstigeren Einstellung, sobald etwa 1 von 30 Turns auf eine Pause folgte, sodass die 1-von-20-Regel einen Spielraum lässt, und der Abstand wächst jenseits des Kreuzungspunkts schnell, weil jeder pausierte Turn bei der 5-Minuten-Einstellung das gesamte Präfix neu schreibt. Jedes aktuelle Modell verwendet dieselben Cache-Write-Multiplikatoren, und jedes Modell außer Claude Fable 5.1 und Claude Mythos 5.1 denselben Read-Preis, sodass der Kreuzungspunkt auf den anderen Modellen im selben Bereich liegt; Fable 5.1 ist der als Nächstes behandelte Fall. Die Genauigkeit blieb in jeder Zelle innerhalb des Lauf-zu-Lauf-Rauschens. Der Turn nach einer Pause behielt bei der 1-Stunden-Einstellung seine Warm-Cache-Latenz. Das folgende Diagramm stellt die Kosten pro Session gegen den Anteil pausierter Turns auf Claude Sonnet 5 dar:

Anthropic maß auch zusätzliche Anfragen, die den 5-Minuten-Cache warm halten. Auf Claude Sonnet 5 und Claude Opus 5 sparten sie bei keinem Anteil pausierter Turns etwas Messbares gegenüber der 1-Stunden-Dauer und kosteten mit einer Pause vor jedem Turn mehr, also verwende stattdessen die Dauer.

Auf Claude Fable 5.1 ist die günstigste Einstellung eine andere. Sein Cache-Read kostet 0,025x den Input-Preis (0,25 $ pro Million Token), während seine Cache-Writes die Standard-Multiplikatoren behalten, sodass eine Keep-Alive-Anfrage, die das Präfix erneut liest, günstig ist und der Write-Aufschlag der 1-Stunden-Dauer die größere Rechnung ist. Anthropic maß den Triage-Job auf Claude Fable 5.1 mit denselben drei Einstellungen¹⁹. Den 5-Minuten-Cache warm zu halten kostete 13 % bis 20 % weniger pro Session als der 1-Stunden-Cache, wann immer Pausen Minuten dauerten; nur bei Pausen nahe 45 Minuten gewann der 1-Stunden-Cache, um etwa 12 Cent pro Session. Auf Claude Fable 5.1 halte den 5-Minuten-Cache warm, während eine Person für Minuten weg ist, und kaufe die 1-Stunden-Dauer, wenn Pausen gegen eine Stunde gehen:

Um den Cache warm zu halten, sende die vorherige Anfrage erneut mit max_tokens auf 0 gesetzt innerhalb von 4 Minuten nach dem Start der vorherigen Anfrage und danach alle 4 Minuten, wobei du stream weglässt, falls es gesetzt war. Zähle ab dem Start der Anfrage, nicht ab dem Ende ihrer Antwort: Die 5-Minuten-Lebensdauer des Caches läuft ab dem Start der Anfrage, die den Eintrag geschrieben oder aufgefrischt hat, sodass die Zeit, die die Antwort mit Generieren verbracht hat, dagegen zählt. Das ist die Pre-Warming-Anfrage: Sie frischt die Lebensdauer des Caches auf, generiert nichts und rechnet nur den Cache-Read ab. Ändere kein Byte des Präfixes, und verwende nicht max_tokens: 1, was ohne Grund ein Token sampelt. Sende die Header der Anfrage ebenso erneut wie ihren Body: Wenn deine Anfragen einen anthropic-beta-Header tragen (etwa für ein Task-Budget), braucht die Keep-Alive-Anfrage denselben Header, sonst werden die Beta-gesperrten Felder im wiedergegebenen Body abgelehnt. Eine max_tokens: 0-Anfrage wird abgelehnt, wenn die Anfrage thinking.type: "enabled" setzt (das standardmäßige adaptive Denken auf Claude Fable 5.1 ist in Ordnung), strukturierte Ausgaben oder eine erzwungene Tool-Wahl (ihre Einschränkungen); auf diesen Workloads kaufe stattdessen die 1-Stunden-Dauer.

# Innerhalb von 4 Minuten nach Beginn der letzten Anfrage (Generierungszeit zählt
# gegen die Cache-Lebensdauer) sende diese Anfrage erneut mit max_tokens auf
# 0 gesetzt, ohne stream (eine Anfrage mit max_tokens: 0 kann nicht streamen). Sende dieselben
# Header wie bei der ursprünglichen Anfrage, einschließlich eines etwaigen anthropic-beta-Headers.
jq '.max_tokens = 0 | del(.stream)' last_request.json | \
  curl https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    --data-binary @-

Caching einschalten

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, der 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.

Was den Cache bricht

Mehrere Dinge können deinen Cache während einer Aufgabe brechen. Alles, was sich pro Anfrage ändert, wie ein Zeitstempel oder eine Warteschlangenposition, vor dem stabilen Präfix platziert, macht jede Anfrage zu einem vollständigen Cache-Write: Beim Triage-Lauf in Input- und Kontext-Token trimmen kostete eine 25-Token-Statuszeile am Anfang des System-Prompts 4,24 $ pro Lauf statt 0,59 $, mehr als der Betrieb mit ausgeschaltetem Caching. Halte anfragespezifischen Text im neuesten User-Turn.

Der Cache ist ein byte-exakter Präfix-Abgleich über die Anfrage in Reihenfolge (Tools, dann System-Prompt, dann Messages), sodass eine Änderung irgendwo alles danach invalidiert. Das Ändern von effort oder der Thinking-Konfiguration zwischen Anfragen invalidiert den Cache ab diesem Punkt, und auf manchen Modellen auch die Tools und den System-Prompt davor; jede Bearbeitung des System-Prompts invalidiert den Cache ab diesem Punkt; das Setzen oder Ändern eines Ausgabeformats invalidiert den Cache für die gesamte Konversation; das Hinzufügen, Entfernen oder Umordnen einer Tool-Definition invalidiert alles. Die Seite zum Prompt-Caching listet diese Fälle auf, abgesehen vom Ausgabeformat, das strukturierte Ausgaben behandelt. Auf den neuesten Modellen ändere Anweisungen mit einer System-Message mitten in der Konversation, einer an messages angehängten {"role": "system"}-Message, statt das Top-Level-Feld system zu bearbeiten: Das gecachte Präfix bleibt intakt. Prüfe auf jener Seite, welche Modelle es unterstützen. Auf Modellen, die es unterstützen, lässt eine Effort-Änderung pro Message das gecachte Präfix ebenfalls intakt. Am meisten steht auf Claude Fable 5.1 und Claude Mythos 5.1 auf dem Spiel: Ein Bruch schreibt das Präfix zu 1,25x dem Input-Preis neu, statt es zu 0,025x zu lesen, sodass bei einem 100.000-Token-Präfix ein gebrochener Turn 1,25 $ statt 0,03 $ kostet, das 50-Fache des Reads, gegenüber dem 12,5-Fachen (0,63 $ statt 0,05 $) auf Claude Opus 5.

Anthropic maß dies an den langen Sessions des Triage-Agenten¹⁸. Eine Effort-Änderung und ein hinzugefügtes Tool mitten in der Session schrieben 39.000 und 60.000 gecachte Token neu, und diese Sessions kosteten 0,95 $ pro Session. Dieselben zwei Änderungen bei der ersten Anfrage nach der Compaction kosteten 0,75 $, und bei der Anfrage, die die Compaction auslöste, 0,92 $, weil der Zusammenfassungsdurchlauf der Compaction dann den 81.000-Token-Kontext zum Cache-Write-Preis erneut verarbeitete: Dieser Zusammenfassungsdurchlauf kostete 0,21 $, gegenüber 0,04 $, wenn dieselben Änderungen eine Anfrage später kamen, mit Genauigkeit innerhalb des Lauf-zu-Lauf-Rauschens in jedem Arm:

Das Ändern eines Task-Budgets mittendrin invalidiert jedes gecachte Präfix, das den Budgetwert enthält, also setze es einmal, bei der ersten Anfrage. Jeder Context-Editing-Durchlauf invalidiert das Präfix ab dem Punkt, den er löscht, und die nächste Anfrage zahlt dafür, alles danach erneut zu cachen, also lösche in wenigen großen Batches statt in vielen kleinen. Auf Claude Fable 5.1 und Claude Mythos 5.1 kostet jedes davon das 50-Fache des Read-Preises pro Token, sodass sie dort am meisten zählen. Nimm jede cache-invalidierende Änderung an natürlichen Unterbrechungen vor und bestätige dann, dass die Cache-Reads nicht gefallen sind; falls doch, zeigt Cache-Diagnostik, wo das Präfix abwich.

Input- und Kontext-Token trimmen

Die meisten Agent-Anfragen tragen Token, die die Antwort nie beeinflussen. Sie zu trimmen kostet selten 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 bringt Vision-Inputs auf die richtige Größe, und Tool-Suche mit verzögertem Laden lädt Tool-Definitionen nur bei Bedarf (später in diesem Abschnitt gemessen). Programmatisches Tool-Calling lässt Claude mehrere Tool-Aufrufe aus Code ausführen, sodass nur das gefilterte Ergebnis in den Kontext gelangt; seine Dokumentation berichtet 24 % weniger Input-Token auf agentischen Such-Benchmarks, bei einem höheren Score. 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 untereinander, also beurteile sie nach Nettoeffekt, und verwende Cache-Diagnostik, um zu bestätigen, dass dein gecachtes Präfix jede Änderung überlebt. Anthropic maß sie an einem Issue-Triage-Agenten, der 20 echte Bug-Reports mit Screenshots aus einem öffentlichen Repository durcharbeitete, und an einer längeren Variante desselben Jobs mit dem 2,6-Fachen der Token. Mit eingeschaltetem Caching nahm Input-Trimming (Bildgrößenanpassung und Tool-Suche) weitere 26 % vom kurzen Lauf und 21 % vom langen.

Ungenutzte Tool-Definitionen verzögern

Jede an eine Anfrage angehängte Tool-Definition ist bei jedem Turn Input, und ein paar MCP-Server summieren sich auf Hunderte davon. Anthropic betrieb den Triage-Agenten mit seinen eigenen zwei Tools plus einem Katalog echter Tool-Definitionen von öffentlichen MCP-Servern, für insgesamt bis zu 502 Tools, wobei alle geladen oder die Extras hinter Tool-Suche als defer_loading markiert wurden:

Mit jeder geladenen Definition verdoppelten sich die Laufkosten fast, als der Katalog wuchs, den Schema-Token bei jeder Anfrage folgend. Mit Tool-Suche blieben sie bei jeder Kataloggröße flach, 45 % weniger bei 502 Tools. Die Genauigkeit lag in jeder Zelle so oder so bei 15 bis 18 von 20, und das Modell rief nie ein falsches Tool auf, sodass der Katalog in diesem Maßstab Geld kostet, nicht Korrektheit. Dasselbe gilt für Tools, die über den MCP-Connector kommen: Mit einem angehängten öffentlichen GitHub-MCP-Server senkte das Verzögern seines Toolsets (default_config: {defer_loading: true}) den Lauf um 20 % bei gleicher Genauigkeit.

Datendateien aus dem Prompt heraushalten

Wenn das Modell über eine Tabelle rechnen muss, lade sie mit der Files API hoch und lass das Modell sie mit Code-Ausführung abfragen, statt sie einzufügen. Anthropic stellte 25 Aggregatfragen¹⁵ (Summen, gefilterte Zählungen, Group-bys und einen Datumsfilter) über eine öffentliche CSV mit 1.862 Zeilen, wobei die Antworten von pandas berechnet wurden:

In den Prompt eingefügt umfasst die Tabelle etwa 91.000 Input-Token bei jeder Anfrage, und Claude Sonnet 5 beantwortete 6 von 25 Fragen korrekt. Hochgeladen, mit Code-Ausführung, beantwortete es alle 25, und der Lauf kostete etwa ein Zwölftel so viel. Claude Opus 5 zeigte dasselbe Muster.

Den Kontext-Lebenszyklus verwalten

Die Kontext-Hebel zahlen sich nur bei einer Session aus, die lang genug ist, um sie zu brauchen:

Beim 20-Issue-Lauf sparten sie nichts, und Context Editing kostete 74 % mehr. Beim langen Lauf sparte das Pruning 39 % und Compaction 32 %, während Context Editing nichts änderte. Das Pruning sind ein paar Zeilen, die du selbst schreibst: Ersetze an jeder Aufgabengrenze große veraltete Tool-Ergebnisse durch einen einzeiligen Extrakt. Es cacht gut, weil die Bearbeitungen am Ende der Konversation sitzen, wo die nächste Aufgabe ohnehin neuen Inhalt hinzufügt: 89 % Cache-Reads bei der ersten Anfrage nach einer Grenze und 81 % bei den Anfragen zwischen Grenzen. Über den gesamten Lauf cachen das Pruning und Context Editing etwa gleich gut. Das Pruning ist günstiger, weil Context Editing mitten in der Aufgabe Inhalt neu schreibt, den das Pruning löscht (etwa zwei Drittel des Abstands), und weil es den Kontext etwa halb so groß hält (das andere Drittel). Wenn du Context Editing verwendest, lösche in wenigen großen Batches. Das Pruning, aus dem Harness adaptiert:

import re

PRUNED = "[pruned at issue boundary]"


def prune_task_boundary(messages, tool_name_by_id, threshold=2000):
    """Call once per task boundary. Replaces large, stale search results with a one-line extract."""
    for message in messages:
        if message["role"] != "user" or not isinstance(message["content"], list):
            continue
        for block in message["content"]:
            if not (isinstance(block, dict) and block.get("type") == "tool_result"):
                continue
            if tool_name_by_id.get(block.get("tool_use_id")) != "search_issues":
                continue
            result_text = block.get("content")
            if not isinstance(result_text, str) or len(result_text) <= threshold:
                continue
            if result_text.startswith(PRUNED):
                continue  # already pruned on an earlier boundary
            # einzeilige Ergebnisse begrenzen, damit der Auszug kurz bleibt
            first_line = result_text.split("\n", 1)[0].strip()[:200]
            refs = re.findall(r"#(\d+)", result_text)[:5]
            extract = f"{PRUNED} {first_line}"
            if refs:
                extract += " kept refs: " + " ".join("#" + r for r in refs)
            block["content"] = extract

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 kombiniert sich mit allem auf dieser Seite außer Interaktivität, ist aber nicht für Claude Managed Agents Sessions verfügbar, die von Haus 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“, eine verpflichtende Schritt-für-Schritt-Prozedur oder ein selbstgebautes Reasoning-Scratchpad. Ein neueres Modell befolgt diese buchstabengetreu und erzeugt zusätzliche Tool-Runden und zusätzliches Schreiben, 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 Anfragecode 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 Anfragecode, der diese Muster enthält:

$ 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 Bearbeitungen als Diff vor (ein Hunk gezeigt) und listet auf, was er bewusst unangetastet ließ: das Rückerstattungsfenster, die Tonvorgabe 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, von 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 veralteten Texts 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 tendenziell in Tool-Beschreibungen und Skills auf, die ebenfalls ein Audit wert sind.

Kosten gegen Intelligenz abwägen

Diese Hebel legen fest, wo ein einzelnes Modell zwischen Kosten und Intelligenz sitzt: Modellwahl, Effort, das Wiederholen von Fehlschlägen bei 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.1 (das Frontier-Modell); die Modellübersicht hat 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.1 ist ein Mehrfaches dessen von Claude Sonnet 5. Du zahlst jedoch für abgeschlossene Aufgaben, also vergleiche Modelle nach Kosten pro abgeschlossener Aufgabe. Ein leistungsfähigeres Modell beendet eine Aufgabe mit weniger Arbeit: weniger Turns, weniger Suchen, weniger erneutes Lesen seines eigenen Kontexts und weniger Zurückrudern. Der Pro-Token-Aufschlag wird oft dadurch überwogen, dass von allem weniger getan wird.

Anthropic maß dies auf dem SWE-bench Pro³-Subset, bepreist, wie ein Kunde abgerechnet wird:

Claude Fable 5.1 bei low Effort löste 88,6 % der Aufgaben für 0,54 $ pro gelöster Aufgabe, gegenüber 77,4 % für 0,84 $ von Claude Sonnet 5 bei seinem Standard: 11 Punkte mehr für 35 % weniger pro gelöster Aufgabe, trotz eines fünfmal höheren Pro-Token-Preises. Es gewinnt jedoch nicht immer. Auf demselben Subset, das beide Modelle weitgehend sättigen und dessen Scores nicht mit dem öffentlichen Leaderboard vergleichbar sind, erreichte Claude Opus 5 allein Claude Fable 5.1 allein beim Standard (91,7 % verglichen mit 92,1 %, innerhalb des Lauf-zu-Lauf-Rauschens) bei etwa 15 % weniger pro gelöster Aufgabe (1,01 $ gegenüber 1,19 $), und Opus 5 bei low löste 84,0 % für 0,25 $. Und bei langen Recherche-Schleifen leistet das Frontier-Modell mehr Arbeit, nicht weniger: Auf DeepResearch Bench II⁷ erzielte Fable 5.1 bei low 10 Punkte über Sonnet 5 (66 % gegenüber 56 %) bei etwa dem Vierfachen der Kosten pro Aufgabe (4,66 $ gegenüber 1,20 $), weil es eine längere Recherche-Schleife über einen größeren Kontext ausführt. Claude Opus 5 bei seinem Standard erzielte auf derselben Basis 71 % für 6,71 $ pro Aufgabe, über Fable 5.1 bei seinem Standard (65 % für 7,12 $), sodass Fable 5.1 auch bei Recherche seinen Preis nur bei low verdient.

Für die meisten Agent-Workloads beginne mit Claude Fable 5.1 bei low Effort und erhöhe Effort, wo es danebenliegt. Pro Token kostet es bei ungecachtem Input das Doppelte von Claude Opus 5, aber bei gecachtem Input die Hälfte (0,25 $ gegenüber 0,50 $ pro Million), und in einer Agent-Schleife ist gecachter Input der größte Posten. Auf dem Coding-Benchmark in Advisor-Strategie erreichte Fable 5.1 bei medium Opus 5 bei seinem Standard für etwa ein Drittel der Kosten pro Versuch (2,91 $ gegenüber 8,50 $). Auf Chartography¹³, einem Diagramm-Lese-Benchmark, erzielte Fable 5.1 bei low 62,5 für 0,15 $ pro Diagramm, verglichen mit 49 für 0,38 $ von Opus 5 bei low. Auf dem SWE-bench Pro-Subset bleibt Claude Opus 5 bei seinem Standard der günstigere Weg zum Top-Score, wie zuvor angemerkt. 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 verglichen mit 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 kippt je nach Workload, 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 bei 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 das Scheitern nachgelagert kostet. Der Tail ist auch, wohin das Geld geht, selbst wenn nichts scheitert. Bei einem 20-Probleme-WideSearch¹-Lauf 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.

Modell upgraden

Wenn du ein oder zwei Modelle zurückliegst, ist der günstigste Hebel der Modell-String. Anthropic ließ aktuelle Claude Opus-, Claude Sonnet- und Claude Fable-Modelle durch denselben Harness auf dem SWE-bench Pro³-Subset laufen, jedes bei seinen ausgelieferten Standards und zu Listenpreisen bepreist, und ließ die Opus-Linie erneut auf Terminal-Bench 3²⁰ laufen:

Anthropic bepreist die Opus-Linie pro Token über Versionen hinweg identisch, sodass jeder Unterschied daraus kommt, wie viel Arbeit jedes Modell pro Aufgabe leistet: Bepreist, wie ein Kunde abgerechnet wird, löst Claude Opus 4.8 denselben Anteil an Aufgaben wie Claude Opus 4.7 für 14 % weniger pro gelöster Aufgabe, und Claude Opus 5 löst dann 12 Punkte mehr an Aufgaben bei 21 % mehr pro gelöster Aufgabe. Claude Opus 5 bei low Effort schlägt den Standard von Opus 4.8 auf diesem Benchmark für etwa 30 % seiner Kosten pro gelöster Aufgabe, sodass das günstigste Upgrade das neue Modell bei einer niedrigeren Einstellung ist. Die Einsparung von Sonnet 5 kommt von seinem niedrigeren Pro-Token-Preis, der die zusätzlichen Token, die es pro Aufgabe im Vergleich zu Sonnet 4.6 verwendet, mehr als ausgleicht: 15 % weniger pro gelöster Aufgabe für 5 Punkte mehr. Die Frontier-Stufe gewann auf dieselbe Weise: Claude Fable 5.1 erreicht den Score von Claude Fable 5 für 43 % weniger pro gelöster Aufgabe, das meiste davon der niedrigere Cache-Read-Preis. Diese Richtung ist nicht garantiert: Auf DeepResearch Bench II⁷ kostet dasselbe Upgrade 41 % mehr pro Aufgabe bei high (79 % mehr bei low) für seine 2 bis 3 zusätzlichen Punkte auf den in jedem Arm sauberen Aufgaben (Referenz 7), weil das neue Modell dort mehr Arbeit pro Aufgabe leistet. Die Input- und Output-Preise sind dieselben und der Cache-Read ist 4x günstiger, also miss das Upgrade auf deinem eigenen Workload, bevor du annimmst, dass es spart.

Bei schwierigerer Arbeit wächst der Abstand. Auf Terminal-Bench 3²⁰, wo die Aufgaben schwierig genug sind, dass die Erfolgsquote statt der Token die Rechnung bestimmt, geben Claude Opus 4.7, Opus 4.8 und Opus 5 jeweils 8 $ bis 15 $ pro Aufgabe aus, lösen aber 7 %, 15 % und 41 % der Aufgaben, sodass die Kosten pro gelöster Aufgabe die Leiter hinauf von 183 $ auf 63 $ auf 28 $ fallen. Der 21-%-Aufschlag, den Claude Opus 5 gegenüber Opus 4.8 auf dem gesättigten Coding-Subset trägt, wird auf Terminal-Bench 3, wo das ältere Modell meist scheitert, zu einer 56-%-Einsparung: Je mehr dein Workload das alte Modell überfordert, desto mehr spart das Upgrade pro Ergebnis.

Vergleiche nach Kosten pro gelöster Aufgabe, nicht pro Token: Derselbe Text kostet auf Claude Opus 4.7 und später etwa 30 % mehr Token, sodass ein Pro-Token-Vergleich die neueren Modelle konstruktionsbedingt teurer aussehen lässt.

Effort abstimmen

„Effort“ (Aufwand) ist der direkteste Weg, ein Modell auf deine Aufgabe abzustimmen. Der Parameter effort bestimmt, wie viel Denken, Tool-Aufrufe und Selbstverifikation das Modell betreibt, und der Standardwert (high) eignet sich für anspruchsvolle Aufgaben. Die Kosten skalieren mit all dieser Aktivität; die Genauigkeit skaliert nur mit dem Teil, den deine Aufgabe braucht. Unterhalb der Leistungsobergrenze des Modells bezahlen die höchsten Effort-Stufen für eine 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 der Genauigkeit gegen die Kosten nahezu flach: low gab 1 bis 3 Punkte ab für ein Drittel bis die Hälfte weniger Kosten pro Aufgabe, medium erreichte die Genauigkeit des Standards bei etwa 70 % bis 87 % seiner Kosten, und der Standard brachte auf keinem der vier etwas Messbares gegenüber medium. Auf DeepWideSearch zog low außerdem mit einem Orchestrator mit einem Claude-Sonnet-5-Worker gleich, bei 29 % niedrigeren Kosten: Den Effort zu senken schlug eine Architekturänderung.

Niedrigere Effort-Einstellungen sind oft schneller, was zählt, wenn „latency“ (Latenz) die Einschränkung ist. In diesen Läufen brauchte low auf DeepWideSearch 4,5 Minuten pro Problem, verglichen mit 7,9 Minuten beim Standard. Auf dem Korpus-Benchmark, dessen Eingabe in kein einzelnes Kontextfenster passt, brauchte Fable 5.1 bei low, medium und high 15,2, 17,5 und 19,9 Stunden pro Episode.

Coding mit langem Horizont ist der Bereich, in dem Effort tatsächlich Genauigkeit kauft. Auf SWE-bench Pro³ gab Claude Opus 5 bei medium etwa 2 Punkte für die Hälfte der Kosten ab und bei low etwa 8 Punkte für ein Viertel davon: ein echter Kompromiss, den das erneute Ausführen von Fehlschlägen mit höherem Effort wieder in eine Ersparnis verwandelt. Dieses Diagramm trägt Genauigkeit gegen Kosten für die Recherche- und Wissensarbeits-Benchmarks und für SWE-bench Pro auf:

Daraus folgen zwei Konsequenzen. Erstens: Zeichne diese Kurve für deinen eigenen „Workload“ (Arbeitslast), 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 bei niedrigerem Effort. Zweitens: Diese Kurve ist die Einzelmodell-Baseline, die jede Multi-Modell-Strategie schlagen muss, daher erstellt Schritt 2 der Messung auf deinem eigenen Workload Baselines über Effort-Stufen hinweg.

Schwere Arbeit braucht nicht automatisch hohen Effort. Auf DeepResearch Bench II⁷ erzielte Claude Fable 5.1 bei low, medium und high nahezu dieselbe Punktzahl, während die Kosten pro Aufgabe von 4,66 $ auf 7,12 $ stiegen, sodass das Erhöhen des Efforts in diesem Fall die Qualität der Ausgabe nicht merklich steigert; auf den 21 Aufgaben, die in jedem Arm sauber waren (Referenz 7), war Claude Fable 5 ebenfalls über den Effort hinweg flach, obwohl die 33-Aufgaben-Basis des Diagramms, die die eigenen abgebrochenen Versuche jedes Modells weglässt, es ansteigend zeigt. Miss die Kurve auf dem Modell, das du auslieferst, nicht auf dem, das du zuletzt gemessen hast:

Die Aufgabenbeschreibung allein verrät nicht, welche Art von Workload du hast, also durchlaufe 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: Das Ändern des Top-Level-Efforts mitten in einer Session macht den Cache ungültig (siehe Wiederholten Kontext cachen) und verzerrt den Vergleich. Details zum Parameter findest du unter Effort.

Fehlschläge mit höherem Effort erneut ausführen

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

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 schlugen 16 % der Aufgaben fehl; wurden diese beim Standard erneut ausgeführt, bestanden etwa 93 % für etwa 0,45 $ pro Aufgabe, gegenüber 91,7 % für 0,93 $, wenn alles beim Standard lief: dieselbe Erfolgsquote für die Hälfte der Kosten, die fehlgeschlagenen günstigen Versuche mitgezählt. Stattdessen bei medium zu beginnen löste etwa 94 % für etwa 0,61 $. Der größte Teil des kleinen Zugewinns ist der zweite Versuch (die eigenen Fehlschläge des Standards beim Standard erneut auszuführen erzielt etwa dieselbe Punktzahl, für mehr Geld), also nutze diese Strategie für die Ersparnis, nicht für den Zugewinn:

Zwei Bedingungen gelten. Erstens brauchst du ein Fehlschlagsignal (hier die eigenen Tests des Benchmarks); ein Prüfer, der schlechte Arbeit bestehen lässt, lässt diese Fehlschläge durch. Zweitens braucht jeder Fehlschlag im ersten Durchgang die Wanduhrzeit von zwei Läufen, sodass die Ersparnis 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 Median-Kosten für Suchen, erneutes Verifizieren und übermäßiges Testen aus. Ein „task budget“ (Aufgabenbudget) zielt auf diesen Ausläufer. 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 in eine Spirale zu begeben.

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

Ein großzügiges Budget senkte die Kosten pro Aufgabe um 44 % für etwa 3 Punkte Erfolgsquote, am Rand des Rauschens von Lauf zu Lauf, und das engste erlaubte Budget senkte sie um 58 % für 6 Punkte. Budgets kauften hier Effizienz, zu einem Preis bei der Erfolgsquote, der wächst, je enger das Budget wird.

Drei Steuerungen erledigen drei verschiedene Aufgaben. Ein Task-Budget spart Geld, weil das Modell es sieht. max_tokens ist eine Sicherheitsobergrenze: Es zu senken reduzierte die Kosten pro Versuch, ohne die Kosten pro gelöster Aufgabe zu senken. 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 der Beta (Beta-Header task-budgets-2026-03-13) auf den neuesten Modellen; prüfe in der Support-Tabelle, auf welchen. Beginne nahe der Token-Nutzung des 90. Perzentils deiner Schleife und ziehe dann enger (Ein Budget wählen zeigt, wie du diese Verteilung erhebst). Budgets unter der aktuellen Untergrenze von 20.000 Token werden abgelehnt, und sehr enge Budgets können verweigerungsähnliches Verhalten erzeugen. Setze das Budget einmal, bei der ersten Anfrage, denn eine Änderung mitten in der Aufgabe macht den Cache ungültig. Das Budget ist beratend, es lenkt das Modell, statt es zu stoppen, also überprüfe die Einhaltung auf deinem Workload.
• max_tokens begrenzt eine einzelne Antwort, unsichtbar für das Modell, sodass es zu 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 Obergrenze von 16.384 Token 15 % der Versuche von Claude Opus 5 und 43 % der von Claude Fable 5.1 beim Standard-Effort, und nur 9 der 117 begrenzten Fable-Versuche bestanden noch. Begrenzte Läufe gaben weniger pro Versuch aus, kauften aber proportional weniger Lösungen, sodass die Kosten pro gelöster Aufgabe etwa dieselben waren wie bei 64.000 (21 $ gegenüber 22 $). Bei 64.000 wurden noch 2 von etwa 14.000 Turns beim Standard-Effort abgeschnitten, und Fable 5.1 löste 58,5 % der Aufgaben statt 36,3 % (auf einem separaten Ausschnitt der SWE-bench-Pro³-Teilmenge, beschrieben in Referenz 12, kein Unterschied: 94 von 100 bei beiden Obergrenzen). Begrenzte Versuche zu wiederholen hilft selten: Bei derselben Obergrenze schlagen die meisten erneut fehl, und bei einer höheren bezahlst du zusätzlich für den verschwendeten Versuch. Setze max_tokens für agentische Arbeit auf 64.000 oder auf 128.000, das Maximum, wenn ein einzelner abgeschnittener Versuch teuer ist; bei 128.000 löste Fable 5.1 60,0 % bei denselben Kosten pro gelöster Aufgabe. Nutze Streaming für 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. Bei Erreichen der Obergrenze pausiert die Session mit stop_reason: budget_reached; das Budget zu erhöhen setzt sie fort. Es wird von der Plattform durchgesetzt, funktioniert auf jedem Modell mit einem Listenpreis, einschließlich Modellen, bei denen Task-Budgets noch nicht verfügbar sind, und lässt sich mit dem beratenden Task-Budget kombinieren. Deployments wenden dasselbe Feld auf jeden Lauf an.

Bitte um kürzere Antworten. Output-Token kosten bei Claude Sonnet 5 das Fünffache von Input-Token, und in einer Agentenschleife kommt jedes Token, das das Modell schreibt, bei jedem späteren Turn als Input zurück, sodass du für eine lange Antwort immer wieder bezahlst. Anthropic führte den Triage-Job unter drei Anweisungen für die endgültige Antwort aus, jeweils drei Läufe, mit demselben Modell und denselben Tools. Das Original bat um zwei Zeilen:

4. Finish with exactly two lines:
LABEL: <one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish>
SUMMARY: <one or two sentences for the engineering team>

Die kürzere Variante bat um eine:

4. Finish with exactly one line in this form:
DECISION | LABEL | REASON
where DECISION is one of: triage-now, needs-info, close-duplicate; LABEL is one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish; REASON is one clause under 15 words. Output nothing after that line.

Die längere Variante bat um ein Memo mit fünf überschriebenen Abschnitten: Problemzusammenfassung, Belege, Duplikatprüfung, empfohlenes Label und nächste Schritte. Für ein Issue, einen in die Warteschlange gestellten Prompt, der nach einer übersprungenen Frage nie gesendet wird, lauteten die ersten beiden Antworten:

LABEL: bug-confirmed
SUMMARY: When a user submits a new prompt instead of answering an agent's pending question, the question is cancelled/skipped but the new prompt remains stuck in "QUEUED" state indefinitely since it's waiting on a response to the now-cancelled question; the queued prompt should be processed immediately after cancellation.

triage-now | bug-confirmed | Clear repro steps show prompt queues indefinitely after cancelled question.

Die einzeilige Antwort verbrauchte 39 % weniger Output-Token als das zweizeilige Original und kostete 14 % weniger pro Lauf. Das Memo verbrauchte das Sechsfache an Output-Token und kostete das 2,8-Fache der einzeiligen Antwort. Alle drei lagen gegenüber den Gold-Labels innerhalb des Rauschens von Lauf zu Lauf zueinander, sodass sich die Formate weit mehr darin unterscheiden, was du bezahlst, als darin, was sie richtig machen. Bitte um die Antwort, die du lesen wirst, nicht um die, die gründlich aussieht.

Bei der niedrigeren max_tokens-Obergrenze geben beide Modelle weniger pro Versuch aus, lösen aber proportional weniger Aufgaben, sodass sich die Kosten pro gelöster Aufgabe kaum bewegen:

Fast jeder Turn endet weit unter beiden Obergrenzen. Der seltene lange Turn ist das, was die höhere Obergrenze kauft:

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 erledigt, 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 den Preisen des kleineren Modells 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 Strategieabschnitt gibt die Regel an, mit der sich die beiden Fälle unterscheiden lassen.

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

Advisor-Strategie: schwere Entscheidungen eskalieren

In der Advisor-Strategie führt ein günstigeres „Executor“-Modell (ausführendes Modell) die Agentenschleife aus und erledigt die meisten Turns. Wenn es auf eine Entscheidung trifft, die tieferes Urteilsvermögen braucht, etwa die Wahl eines Ansatzes oder die Erholung von einem Fehlschlag, ruft es ein intelligenteres „Advisor“-Modell (Beratermodell) für strategische Anleitung auf und fährt dann fort. Die meisten Token werden zu Executor-Preisen abgerechnet und nur die gelegentlichen Konsultationen zu Advisor-Preisen.

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 es ebenfalls; siehe schwere 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 einige Punkte und ein Frontier-Executor fast nichts.

Das zweite, und das fragile, ist, ob der Executor tatsächlich fragt (die Konsultationsrate). Ein Executor bei niedrigem Effort kann aufhören zu erkennen, 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 als der Executor allein. Die Rate variiert auch 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, holt er einen Großteil der Lücke auf. Über die Paarungen im folgenden Diagramm hinweg, deren Executor weiter fragte, schloss der Advisor mindestens die Hälfte der Lücke zum stärkeren Modell (die Coding-Paarung schlug das stärkere Modell sogar direkt), und du bezahlst das stärkere Modell nur bei den Konsultationen, was die Kostenfälle überhaupt 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 an, der um einen Aufruf vor substanzieller Arbeit und einen vor dem Abschluss bittet, etwa zwei bis drei Aufrufe pro Aufgabe. Die als Nächstes gemessene Coding-Paarung lief in diesem Takt, etwa zwei Konsultationen bei jeder Aufgabe. Diese Seite behandelt auch, wie du 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 lohnt. Ein Advisor spart Geld, wenn einige kurze Konsultationen, abgerechnet zum Preis des Advisors, das Ausführen 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 Mid-Tier-Executor ist. Eine Paarung kann sich sogar am oberen Ende der Spanne behaupten, weil Rat auch Executor-Token spart: Ein Executor, dem der richtige Ansatz gesagt wird, erkundet weniger Sackgassen, was die Konsultationen decken kann.

Auf einem internen Benchmark für agentisches Coding¹¹, ausgeführt mit einem einfachen API-Agenten, war ein Claude-Opus-5-Executor mit einem Claude-Fable-5.1-Advisor die genaueste gemessene Konfiguration, bei 7,69 $ pro Versuch. Sie liegt über der Linie durch die eigenen Effort-Einstellungen jedes Modells: 3,5 Punkte über Opus 5 allein bei der Standardeinstellung für etwas weniger Geld, eine Lücke, die fünf Versuche pro Aufgabe tatsächlich vom Rauschen trennen, und etwa 2,5 Punkte über dem Modell des Advisors allein für etwa anderthalbmal so viel Geld:

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: Der Advisor kauft einige Punkte zu etwa dem eigenen Preis des Executors. Eine größere Fähigkeitslücke garantiert kein besseres Geschäft. 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 das stärkere Modell allein der bessere Schritt ist. Wo die Genauigkeit eines Workloads auf Effort reagiert, vergleiche die Paarung mit dem Modell des Advisors allein bei einer reduzierten Einstellung, bevor du sie baust: Der Advisor wird nur bei Aufgaben bezahlt, die ihn brauchen, aber eine Konsultation, die bei den meisten Aufgaben ausgelöst wird, kostet mehr als das stärkere Modell selbst auszuführen. Auf Chartography¹³ zog dieselbe Paarung mit Claude Fable 5.1 allein bei medium innerhalb des Rauschens von Lauf zu Lauf gleich (65,0 gegenüber 67,5), bei etwa dem 2,6-Fachen der Kosten pro Aufgabe, weil der Advisor bei fast jeder Aufgabe konsultiert wurde. Miss zuerst deine eigene Konsultationsrate: Wenn der Executor bei den meisten seiner Aufgaben fragt, bezahlst du Advisor-Preise über den gesamten Workload, und das Modell des Advisors selbst auszuführen ist der günstigere Weg zur selben Punktzahl.

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

Wann es passt. Die Advisor-Strategie eignet sich für Workloads, bei denen Turns überwiegend mechanisch sind, aber ein exzellenter Plan zählt: Coding-Agenten, Computer Use und mehrstufige Recherche-Pipelines. Sie passt schlecht, wenn jeder Turn wirklich 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 günstigere Worker-Modelle und führt deren Ergebnisse zusammen. Das eigene Transkript des Orchestrators bleibt kurz, weil Worker die tokenintensive Erkundung absorbieren, sodass die meisten Token zu Worker-Preisen abgerechnet werden, während Plan und Synthese weiterhin vom Frontier-Modell kommen.

Um einen zu bauen, nutze 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 Frontier-Koordinator und Claude-Sonnet-5-Workern findest du im Claude-Cookbook-Rezept Koordinator-Muster: große Modelle für die Planung, kleine Modelle für die Ausführung.

Dieses Muster spart Wanduhrzeit, wenn Worker parallel laufen können: Auf dem Korpus-Benchmark⁸ dauerte eine Episode etwa 2,3 Stunden, wenn der Koordinator das dokumentierte Plattformlimit von 25 gleichzeitigen Workern ausführte, verglichen mit 15 bis 20 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 Kostenausläufer bei Routinearbeit. Ein allein laufendes Frontier-Modell gerät gelegentlich bei einem Routineproblem, das es normalerweise lösen würde, in eine Spirale. Weil du nicht im Voraus sagen kannst, welche das sein werden, dominieren einige solche Läufe die Rechnung. Ein Koordinator, der Routinearbeit an einen günstigeren Worker übergibt, deckelt diesen Ausläufer, weil jede Spirale nun zu Worker-Preisen stattfindet.

Anthropic maß dies auf einem bewusst leichten Ausschnitt von BrowseComp⁴ (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 etwa halb so viel wie Claude Fable 5 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 außerdem falsch:

Delegation lohnte sich beim routinemäßigen, normalerweise lösbaren Anteil der Arbeit, das Gegenteil der Intuition, dass Worker für schwere Probleme da sind. Auf dem vollständigen, schwereren BrowseComp-Set kehrte sich die Wirtschaftlichkeit um. Wenn dein Traffic einen langen Kostenausläufer 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 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-Preisen. 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 baute einen Benchmark für diesen Fall⁸: einen Korpus von 21,6 Millionen Token aus 14 öffentlichen Python-Paketen mit 130 platzierten 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.1 solo kostete über die drei Effort-Einstellungen hinweg 468 $ bis 552 $ pro Episode, und nur seine Genauigkeit bewegte sich. Die Koordinator-Konfiguration, ein Claude-Fable-5.1-Lead über 25 Claude-Sonnet-5-Workern, kostete etwa halb so viel wie diese Einstellungen (47 % bis 55 % weniger) und erzielte 10 bis 12 Punkte weniger als sie, in etwa 2,3 Stunden pro Episode gegenüber 15 bis 20, während sie eine Claude-Sonnet-5-Solo-Baseline klar schlug:

Die Token-Abrechnung zeigt das Ausmaß des Lesens: Die Koordinator-Konfiguration las etwa 560 Millionen gecachte Token pro Episode, etwa anderthalbmal so viel wie die rund 365 Millionen des Solo-Modells, fast alle davon zum Cache-Read-Preis von Claude Sonnet 5, und kostete insgesamt trotzdem etwa halb so viel. Fable 5.1 bei high-Effort hält weiterhin die Spitzengenauigkeit, bei etwa dem 2,2-Fachen der Kosten der Koordinator-Konfiguration, sodass Delegation hier den Großteil der Genauigkeit kauft, nicht alles davon.

Wann sich Delegation nicht lohnt. 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 einzige 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.

Die Grenze ist die Aufgabenschwierigkeit, nicht der Benchmark: Auf dem vollständigen, schwereren BrowseComp⁴-Set erreichte Claude Fable 5 allein die Genauigkeit der Koordinator-Konfiguration bei 22 % bis 30 % niedrigeren Kosten. Unabhängige externe Arbeiten berichten dasselbe Muster⁵. Wenn die Arbeit eine einzige Kette ist, ohne langen Kostenausläufer 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: Teilt sich die Arbeit in unabhängige Teile, oder ist sie eine einzige 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. Durchlaufe zuerst den Effort auf deinem aktuellen Modell. Es ist das günstigste Experiment auf dieser Seite, und die meisten Workloads enden dort.
2. Wenn der Durchlauf 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 ein Effort-Durchlauf ist.

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

Auf deinem eigenen Workload messen

Die Zahlen auf dieser Seite spiegeln Listenpreise zum Zeitpunkt der Messung wider und werden sich verschieben, wenn sich Modelle und Preise ändern. Deine Eskalationsrate, wie sauber sich Aufgaben teilen und die Transkriptlänge bewegen sie ebenfalls. Die Methode bleibt dieselbe:

1. Ziehe einige 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 der Punktzahl: Bepreise die fünf bepreisten Token-Zählungen in der usage jeder Antwort zu ihren jeweiligen Preisen (ungecachter Input, 5-Minuten- und 1-Stunden-Cache-Writes zum 1,25-Fachen und 2-Fachen des Input-Preises, Cache-Reads und Output), summiert über die Anfragen der Aufgabe (die Usage and Cost API meldet das Aggregat).
2. Erstelle Baselines der Modellstufen über Effort-Stufen hinweg, nicht nur beim Standard, und trage Punktzahl 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 drei für ein anderes Modell.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
# 0,1x des Input-Preises; 0,025x bei Claude Fable 5.1 und Claude Mythos 5.1
CACHE_READ_PER_MTOK = 0.50
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
cache_writes = usage.cache_creation
writes_1h = cache_writes.ephemeral_1h_input_tokens if cache_writes else 0
writes_5m = cache_writes.ephemeral_5m_input_tokens if cache_writes else 0
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # 1-Stunden-Cache-Schreibvorgänge kosten 2x den Input-Preis, 5-Minuten 1,25x; Lesevorgänge zum Cache-Read-Preis.
    + writes_1h * INPUT_PER_MTOK * 2.0
    + writes_5m * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * CACHE_READ_PER_MTOK
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

In Agentenschleifen ist der Cache-Read-Term meist der größte der fünf; 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 Top-Level-Summen gemeldet, also summiere stattdessen über usage.iterations und bepreise advisor_message-Einträge zu den Preisen des Advisor-Modells.

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

Referenzierte Benchmarks

Sofern eine Referenz nichts anderes angibt, handelt es sich bei den Messungen um Anthropic-interne Durchläufe dieser Benchmarks. Sofern nicht anders vermerkt, sind die Kosten in USD zu den Listenpreisen angegeben, die zum Zeitpunkt des jeweiligen Benchmark-Durchlaufs galten; die Zahlen für Claude Sonnet 5 verwenden 2 $ und 10 $ pro Million Input- bzw. Output-Token. Diagramme mit der Bezeichnung „notional USD“ (nominale USD) bepreisen die Token-Zahlen jeder Anfrage zu diesen Sätzen, anstatt Rechnungen wiederzugeben.

1. WideSearch: Wong et al., „WideSearch: Benchmarking Agentic Broad Info-Seeking,“ arXiv:2508.07999, 2025. Breit angelegte Web-Recherche-Aufgaben, bewertet nach Vollständigkeit und Genauigkeit einer vielzeiligen Tabelle; 200 Probleme, 3 Durchläufe pro Konfiguration, durchgeführt vom 1. bis 2. August 2026. Das Kostenkonzentrations-Diagramm ist ein separater Durchlauf mit 20 Problemen, 3 Durchläufe pro Problem, durchgeführt vom 3. bis 4. August 2026, mit Kosten aus den Abrechnungsdatensätzen pro Anfrage.
2. GDPval: OpenAI, „GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks,“ 2025. Ergebnisse aus Wissensarbeit, bewertet anhand von Aufgaben-Rubriken; ein Durchlauf mit 210 Aufgaben des veröffentlichten Gold-Sets, ein Versuch pro Aufgabe, durchgeführt am 2. August 2026. Ein Claude-Modell bewertet, daher können absolute Werte 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; die Werte sind nicht mit dem öffentlichen Leaderboard vergleichbar. Claude Opus 5 beim Standard-Effort ist der Mittelwert aus zwei Durchläufen; Einstellungen mit reduziertem Effort sind Einzeldurchläufe; alle liefen am 4. August 2026. Die Eskalationszahlen stammen Aufgabe für Aufgabe aus diesen Durchläufen: zuerst low, dann der Standard bei dessen Fehlschlägen, löste 92,5 % bis 93,6 % über die Durchlauf-Paarungen hinweg für etwa 0,45 $; zuerst medium, 93,8 % bis 94,2 % für etwa 0,61 $; der Standard erneut auf seinen eigenen Fehlschlägen ausgeführt, 94,0 % für 1,06 $; alles beim Standard, 90,9 % bis 92,5 % für 0,93 $. Die Kosten auf dieser Teilmenge sind so bepreist, wie die Organisation eines Kunden abgerechnet wird: der vorherige Prompt jeder Anfrage als Cache-Lesevorgang und ihre neuen Token als 5-Minuten-Cache-Schreibvorgang, aus den eigenen Nutzungsdatensätzen der Durchläufe, abgeglichen mit einem Kunden-Ledger; die eigene Abrechnung der Evaluierungsorganisation, die den Cache in Seiten von 8.192 Token abrechnet, ergab 1,4- bis 1,8-mal höhere Zahlen. Die Claude Sonnet 5-Executor-Paarungen im Advisor-Diagramm stammen aus derselben Messreihe auf dieser Teilmenge: Die Sonnet-plus-Opus-Paarung wurde zweimal ausgeführt (7. August und 8. August 2026, ein Durchlauf und eine exakte Replikation), die Low-Effort-Paarung einmal (8. August 2026) und Claude Sonnet 5 allein zweimal (77,4 %, die Baseline für beide Pro-Zeilen). Der Claude Fable 5-Punkt in „Das Modell upgraden“ ist der Mittelwert aus drei Durchläufen beim Standard-Effort, durchgeführt am 26. August 2026, auf dieselbe Weise bepreist. Die Task-Budget-Zahlen für Claude Fable 5.1 sind ein Durchlauf pro Budget (zwei bei 35.000 Token) auf derselben Teilmenge beim Standard-Effort, durchgeführt am 26. August 2026, mit einem unbudgetierten Durchlauf am selben Tag (92,1 %, 1,10 $ pro Aufgabe) als Baseline; ein früherer Satz bei low-Effort, durchgeführt am 21. August 2026, erzielte unbudgetiert 88,6 % bei 0,48 $ pro Aufgabe. Der Vergleich unter Modelle vergleichen paart diesen Einzeldurchlauf mit den zwei gepoolten Claude Sonnet 5-Durchläufen aus derselben Teilmenge; beim Standard-Effort von Fable 5.1 liest sich das Paar umgekehrt, 41 % mehr pro gelöster Aufgabe als Sonnet 5. Die Upgrade-Leiter ist ein Durchlauf pro Modell bei seinen ausgelieferten Standardeinstellungen (jeweils zwei für Opus 5 und Sonnet 5, und der Fable 5-Punkt wie oben beschrieben), wobei die Opus- und Sonnet-Durchläufe in derselben Woche in einem Harness und einer Organisation liefen.
4. BrowseComp: Wei et al., „BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents,“ OpenAI, 2025. Die Effort-Zahlen verwenden einen Ausschnitt von 500 Problemen, ein bis drei Durchläufe pro Einstellung, durchgeführt am 3. August 2026, wobei der Standard-Punkt zwei Durchläufe vom 26. bis 27. Juli 2026 poolt. Das Kostenversicherungs-Diagramm verwendet 10 zuverlässig gelöste Probleme aus einem Ausschnitt von 26 Problemen, 50 delegierte Durchläufe (1. bis 2. August 2026) und 70 Solo-Durchläufe (50 vom 2. bis 3. August 2026; 20 archiviert vom 12. bis 13. Juli und 1. August 2026), 6,45 $ gegenüber 11,99 $ pro Durchlauf im Erwartungswert; delegierte Zahlen tragen ein Messband von etwa 20 %.
5. Skalierung von Agenten-Architekturen: Kim et al., „Towards a Science of Scaling Agent Systems,“ arXiv:2512.08296, 2025. Unabhängige externe Studie, nur für die Richtung des Befunds zitiert, wann sich Delegation nicht lohnt, 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, wobei jede die Sammlung vieler Zeilen mit Multi-Hop-Retrieval kombiniert; gemessen auf dem stehenden Zeilensatz des Benchmarks, 3 Durchläufe pro Konfiguration, durchgeführt am 2. August 2026 (der Team-Punkt mit einem einzelnen Worker lief vom 26. bis 27. Juli 2026).
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 anhand von aus Expertenberichten abgeleiteten binären Rubriken bewertet; gemessen auf einer Teilmenge von 50 Aufgaben, stratifiziert über alle Themen, ein Versuch pro Aufgabe, 3 Durchläufe pro Einstellung, auf Claude Managed Agents mit den eigenen Web-Such- und Fetch-Tools der Plattform (26. bis 27. August 2026); bewertet auf den 33 Aufgaben, die keine Konfiguration ablehnte, wobei Versuche, die von den Produktions-Sicherheitsklassifikatoren abgebrochen wurden, entfernt wurden; die Kosten sind das, was einem Kunden in Rechnung gestellt wird, die Anfragen der Plattform plus Web-Such-Gebühren. Die Werte sind der Mittelwert jedes Modells auf der 33-Aufgaben-Basis, wobei seine eigenen vorzeitig abgebrochenen Aufgaben entfernt wurden; auf den 21 Aufgaben, die in jedem Arm sauber sind, hält Claude Fable 5.1 auf jeder Effort-Stufe einen Vorsprung von 2 bis 3 Punkten gegenüber Claude Fable 5, und beide Modelle sind über den Effort hinweg flach. Das Caching-Diagramm bepreist dieselben Anfragen neu, mit jedem Input-Token zum ungecachten Satz. Claude Opus 4.6 bewertet nach dem Rubrik-Protokoll des Benchmarks; das Original verwendet einen anderen Bewerter, und ein Anthropic-Bewerter könnte den Hausstil bevorzugen. Claude Opus 5 bei seinem Standard-Effort lief auf derselben Oberfläche und Teilmenge, drei Durchläufe, am 28. August 2026: 68,8 % auf den rohen 50 Aufgaben, 70,8 % auf der 33-Aufgaben-Basis und 71,1 % auf dem 21-Aufgaben-Satz, bei 6,71 $ pro Aufgabe (23,72 $ ohne Caching); keiner seiner Versuche wurde von den Sicherheitsklassifikatoren abgebrochen, unter einem Safeguards-Deployment, das neuer ist als das, unter dem die anderen Modelle liefen.
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 platzierten Defekten und deterministischer Bewertung; Protokoll vor den Durchläufen festgelegt und intern geprüft; drei Durchläufe pro Konfiguration. Jede Konfiguration lief auf Claude Managed Agents. Die im Diagramm dargestellte Team-Konfiguration ist ein Durchlauf, in dem der Claude Fable 5.1-Koordinator den gesamten Sweep innerhalb der Plattform an ihrem dokumentierten Limit von 25 gleichzeitigen Claude Sonnet 5-Workern ausführte, durchgeführt am 30. August 2026; seine drei Episoden erzielten F1 0,764, 0,825 und 0,791 nach dem Extras-Audit (roh 0,751, 0,821 und 0,781) für 225 $, 234 $ und 283 $. Die Claude Sonnet 5-Solo-Konfiguration lief vom 3. bis 4. August 2026; die Claude Fable 5.1-Solo-Konfigurationen liefen vom 24. bis 25. August 2026 unter den Launch-Serving-Einstellungen der Plattform, drei Seeds pro Effort-Einstellung, auf demselben Korpus-Build. Das Sandbox-Image enthielt installierte Kopien eines Teils des Korpus, und der abschließende Assemblierungsschritt von Claude Fable 5.1 verglich in 7 von 9 Episoden mit diesen; eine Neubewertung ohne diese Ergänzungen verschob die betroffenen Seeds um bis zu 3 Punkte. Der absolute F1-Wert ist spezifisch für diesen Korpus-Build und 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, zwei Durchläufe pro Konfiguration, durchgeführt am 7. August 2026, modellbewertet anhand von Referenzantworten, Advisor-Token pro Anfrage abgerechnet. Eine Sicherheitsprüfung der Plattform lehnte zwei Biologie-Fragen auf den Sonnet- und Opus-Executors ab; ihr Ausschluss verä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. Der Satz umfasst 113 originale Aufgaben in fünf Sprachen mit programmbasierten Verifizierern. Paarungen sind jeweils zwei Durchläufe, durchgeführt am 7. August 2026, mit pro Anfrage abgerechneten Advisor-Token, und verwendeten eine clientseitige Advisor-Schleife anstelle des Advisor-Tools, mit identischer Abrechnung. Effort-Sweeps mit einem einzelnen Modell sind Einzeldurchläufe, bepreist aus Token-Zahlen, eine Cache-bewusste Näherung. Die Kosten pro Aufgabe sind Durchlauf-Gesamtsummen geteilt durch 113.
11. Interner Agentic-Coding-Benchmark: Anthropic-intern: 370 Repository-Aufgaben, bewertet durch die eigenen Tests der Repositories. Die API-Zahlen wurden mit einer Output-Obergrenze von 128.000 Token gemessen, ein Durchlauf pro Konfiguration: Opus 5 allein beim Standard-Effort vom 9. bis 10. August 2026, Claude Fable 5.1 allein bei fünf explizit gesetzten Effort-Werten am 20. August 2026 und die Paarung vom 24. bis 25. August 2026. Versuche pro Aufgabe: fünf für die Paarung und die Opus-allein-Kontrolle, einer für die Einzelmodell-Punkte; die Paarung kam im Durchschnitt auf etwa zwei Advisor-Konsultationen pro Versuch; die Kosten sind pro Versuch. Die Claude Code-Zahlen sind Durchläufe derselben Aufgaben vom 8. bis 23. Juli 2026, ein Durchlauf pro Konfiguration, Kosten näherungsweise.
12. Interner Repository-Aufgaben-Benchmark (Obergrenzen-Messung): Ein separater Anthropic-interner Satz von etwa 130 Repository-Aufgaben, durchgeführt vom 8. bis 10. August 2026 (Claude Opus 5) und am 20. August 2026 (Claude Fable 5.1), mit einer einfachen API-Agenten-Schleife, ein Versuch pro Aufgabe. Die Claude Fable 5.1-Durchläufe sind 135 Aufgaben pro Obergrenze beim explizit gesetzten Standard-Effort: Die 16.384-Token-Zahl ist der Mittelwert aus zwei Durchläufen (36,3 % bei beiden); die Zahlen für 64.000 und 128.000 sind Einzeldurchläufe (58,5 % und 60,0 %). Sechs Probleme zogen in jedem Durchlauf eine Sicherheitsablehnung auf sich und zählen als Fehlschläge. Die 16.384-Token-Zahl für Opus 5 ist der Mittelwert aus zwei Durchläufen und seine 64.000-Zahl ist ein Einzeldurchlauf (124 Aufgaben bewertet). Die SWE-bench Pro-Obergrenzen-Zahlen sind ein Claude Fable 5.1-Durchlauf pro Obergrenze beim Standard-Effort, durchgeführt am 26. August 2026, auf einer Teilmenge von 100 Problemen, stratifiziert aus dem 482-Problem-Satz von Referenz 3, nicht mit dessen Werten vergleichbar; die beiden Obergrenzen erzielten beim Standard denselben Wert. Die Pro-Turn-Verteilungen des Diagramms stammen aus dem Opus-Durchlauf bei 64.000 und dem Claude Fable 5.1-Durchlauf bei 128.000; kein Opus-Turn erreichte seine Obergrenze, und ein Fable 5.1-Turn erreichte 128.000 (0,46 % seiner Turns überschritten 16.384).
13. Chartography: Surge AI, „Chartography,“ 2026. Der vollständige veröffentlichte Satz von 100 Fragen, gemessen vom 8. bis 10. 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 Referenz-Bewerters und der Benchmark läuft mit Tools, daher sind die Werte hier über Konfigurationen hinweg vergleichbar, aber nicht mit dem veröffentlichten Leaderboard. Zwei Durchläufe pro Konfiguration, gepoolt; die Streuungen von Durchlauf zu Durchlauf betrugen 4 bis 10 Punkte. Die Kosten schließen Sandbox-Zeit aus, die unter 1 % hinzufügte. Die Claude Fable 5.1-Solo-Durchläufe stammen vom 24. August 2026, unter den Launch-Serving-Einstellungen der Plattform, zwei Durchläufe pro Einstellung; sechs Versuche erreichten die 15-Minuten-Session-Obergrenze und erzielen 0, und zwei Diagramme pro Durchlauf wurden nach einer Sicherheitsablehnung von Claude Opus 5 beantwortet. Der Claude Opus 5-Low-Effort-Executor mit einem Claude Fable 5.1-Advisor lief zweimal am 30. August 2026 unter denselben Einstellungen (63,0 und 67,0, Mittelwert 65,0, bei 0,72 $ pro Diagramm; der Advisor wurde in jedem Durchlauf bei 88 % der Aufgaben konsultiert, und 4 seiner 219 Antworten kamen stattdessen von Claude Opus 5, jeweils nachdem ein Produktions-Sicherheitsfilter die eigene Antwort des Advisors gestoppt hatte). Der Konsultationsraten-Vergleich für die früheren Paarungen stammt aus der erneuten Ausführung derselben Konfigurationen auf der Messages API mit einem Container-Tool-Set, 10. bis 11. August 2026.
14. Support-Desk-Prompt-Audit-Evaluierung: Ein von Anthropic erstellter Satz von 44 Support-Tickets mit deterministischer Bewertung, durchgeführt Anfang August 2026 und berichtet am 8. 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 Genauigkeitsunterschiede bei Sonnet liegen innerhalb des Rauschens.
15. Datendatei-Fragensatz: Ein von Anthropic erstellter Satz von 25 Aggregat-Fragen über einen Ausschnitt von 1.862 Zeilen einer öffentlichen CSV-Datei mit Spirituosenverkäufen, mit von pandas berechneter Ground Truth und Exact-Match-Bewertung, ausgeführt auf Claude Sonnet 5 und Claude Opus 5 mit deaktiviertem Denken (der In-Context-Arm kann beim Standard nicht abschließen), einer Output-Obergrenze von 4.000 Token und ohne Prompt-Caching, drei Durchläufe pro Konfiguration, durchgeführt am 19. August 2026. Der Datei-Arm lädt die CSV über die Files API hoch und verwendet das Tool code_execution_20260120.
16. Cache-Dauer-Messung: Der Triage-Job mit 20 Issues aus Input- und Kontext-Token kürzen, durchgeführt am 23. August 2026 auf Claude Sonnet 5 und Claude Opus 5 auf der Messages API mit demselben Harness, die Claude Opus 5-Zellen mit auf 4.096 erhöhtem max_tokens, mit Pausen, die vor einem zufällig gewählten Anteil der Turns eingefügt wurden (keine, 5 %, 10 % und jeder Turn bei 6 Minuten auf allen 20 Issues auf beiden Modellen, plus jeder Turn bei 2 Minuten auf Claude Sonnet 5; 20-Minuten-Pausen auf einer Teilmenge von 5 Issues auf beiden Modellen; 45-Minuten-Pausen auf einer Teilmenge von 5 Issues nur auf Claude Sonnet 5). Drei Durchläufe pro Zelle, Kosten berechnet aus den usage-Feldern jeder Antwort auf einer kundenabgerechneten Organisation zu Listenpreisen, Genauigkeit anhand derselben Gold-Labels. Der Kreuzungspunkt liegt bei etwa 3,3 % der Turns auf beiden Modellen: der Median des Break-even-Anteils jeder Session, berechnet durch das Kostenmodell aus den Turn-für-Turn-Kontextgrößen dieser Session, über alle 45 Claude Sonnet 5- und 36 Claude Opus 5-Sessions mit zwanzig Issues in der Analyse (jeder Pausenplan auf dem vollständigen Job ausgeführt, unter allen drei Cache-Einstellungen, jeweils drei Durchläufe; die 5-Issue-Zellen sind nicht enthalten). Die 5-%-Zelle ergab auf Claude Sonnet 5 ein Unentschieden, weil die Pausen dieser Ziehung auf kleine Präfixe fielen. Die 1-von-20-Regel der Seite liegt über dem gemessenen Kreuzungspunkt. Anthropic hat Keep-alive-Anfragen, die den 5-Minuten-Cache auffrischen, nur als Vergleichsgröße gemessen. Sie erreichten bestenfalls die 1-Stunden-Einstellung und kosteten mit einer Pause vor jedem Turn mehr, verwende sie also nicht auf diesen beiden Modellen; auf Claude Fable 5.1 kehrt sich die Rechnung um (Referenz 19).
17. Cache-Lese-Anteil in der Produktion: Aggregierte First-Party-Nutzung der Claude API für die 14 Tage bis zum 23. August 2026, nur direktes API-Produkt, Anthropic-interne Organisationen ausgeschlossen, keine Organisation identifiziert. Ein Organisationstag zählt als Agenten-Schleife, wenn seine Anfragen Tool-Definitionen und Tool-Ergebnisse tragen, seine Prompts im Durchschnitt 9 oder mehr vorherige Tool-Aufrufe enthalten, Caching verwendet wurde und er mindestens 10 solche Anfragen stellte (die API hat keine Konversationskennung, daher steht dies stellvertretend für die Konversationslänge): 303.003 Organisationstage über 106.487 Organisationen, medianer Cache-Lese-Anteil 84,2 % aller Input-Token, oberes Quartil 91,7 %. Use-Case-Labels (der deklarierte Use Case der Organisation oder andernfalls ihr klassifizierter) decken 74 % dieser Organisationstage und 99 % ihrer Token ab; Coding-Organisationen liefern 87 % der agentischen Input-Token und lesen im Median 88,5 % (90,9 % bei 25 oder mehr vorherigen Tool-Aufrufen), oberes Quartil 93,4 %, wobei etwa 72 % der Coding-Organisationstage bei 80 % oder mehr liegen; Support-, Recherche- und Daten-Agenten lesen 84 % bis 85 %. Das oberste Dezil der Organisationstage liest 95,9 % oder mehr für Coding und 94,2 % bis 94,8 % für Support-, Recherche-, Daten- und andere Agenten. Die Aufteilung auf Anfrageebene bei 25 oder mehr vorherigen Tool-Aufrufen stammt aus einer sechsstündigen Stichprobe: Coding 92 % Lesen, 7 % Schreiben, unter 1 % ungecacht. Nicht gelabelte Organisationen, meist klein, lesen im Median 11 %. Organisationstage ohne Tool-Definitionen lesen im Median 34,6 %. Eine unabhängige Abfrage über dasselbe Zeitfenster, die Konversationen von 10 oder mehr Anfragen rekonstruiert, anstatt Organisationstage zu bewerten, setzt den Median bei 90,2 % an; der Unterschied liegt im Umfang, nicht in den Daten.
18. Compaction-Timing-Messung: Die lange Variante des Triage-Agenten aus Input- und Kontext-Token kürzen, durchgeführt am 24. August 2026 auf Claude Sonnet 5 mit dem 5-Minuten-Cache, Kosten aus den Usage-Feldern zu Listenpreisen, fünf Sessions pro Arm: ein Arm ohne Änderung durchgehend beim Standard-Effort (0,81 $ pro Session) und zwei Arme, die bei Low-Effort beginnen und dieselben zwei Cache-brechenden Änderungen vornehmen, einen Wechsel zum Standard-Effort und ein hinzugefügtes Tool, entweder mitten in der Session bei den Anfragen 12 und 17 (0,95 $) oder zusammen bei der ersten Anfrage nach der ersten Compaction (0,75 $). Ein vierter Arm mit sechs Sessions, durchgeführt am 25. August 2026, nahm dieselben zwei Änderungen bei der Anfrage vor, die die erste Compaction auslöste (0,92 $ pro Session): Der Zusammenfassungsdurchgang dieser Anfrage schrieb den 81.000-Token-Kontext in den Cache, anstatt ihn zu lesen, sodass dieser Durchgang 0,21 $ kostete gegenüber 0,04 $ für denselben Durchgang im Grenz-Arm. Sessions führten die erste Compaction bei Anfrage 21 bis 25 durch (16 der 21 Sessions bei Anfrage 22), sobald der Prompt den Compaction-Auslöser von 80.000 Token überschritt, und zwei Sessions ohne Änderung führten gegen Ende eine zweite Compaction durch. Die niedrigere Gesamtsumme des Grenz-Arms gegenüber dem Arm ohne Änderung spiegelt seine Low-Effort-Anfragen vor der Änderung und diese zweiten Compactions wider, nicht das Caching: Die Neuschreibkosten der beiden Arme unterscheiden sich um weniger als einen Cent. Der Arm mit Änderung mitten in der Session zahlte 0,23 $ pro Session an Cache-Neuschreibungen; der Unterschied zwischen dem Arm mitten in der Session und dem Grenz-Arm betrug 0,20 $ mit einem 95-%-Konfidenzintervall von 0,11 $ bis 0,29 $. Eine Session mitten in der Session lief günstig (0,82 $), nachdem ihr Modell das Such-Tool nach der Compaction falsch aufgerufen und leere Ergebnisse erhalten hatte; sie ist enthalten, und ohne sie liegt der Arm im Durchschnitt bei 0,98 $. Die Genauigkeit lag im Durchschnitt bei 14,2 von 20 Labels in jedem Arm vom 24. August und bei 14,7 im Arm vom 25. August; Cache-Lesevorgänge machten 91 % der Prompt-Token ohne Änderungen aus, 85 % mitten in der Session, 91 % an der Grenze und 86 % mit den Änderungen bei der auslösenden Anfrage.
19. Cache-Dauer-Messung auf Claude Fable 5.1: Derselbe Triage-Job mit 20 Issues und dasselbe Harness wie Referenz 16, durchgeführt am 23. August und 26. August 2026 auf dem Claude Fable 5.1-Launch-Snapshot zu seinen Launch-Preisen (10 $ Input, 12,50 $ 5-Minuten-Schreibvorgang, 20 $ 1-Stunden-Schreibvorgang, 0,25 $ Cache-Lesevorgang, 50 $ Output pro Million Token), drei Einstellungen pro Plan: der 5-Minuten-Cache, der 1-Stunden-Cache und der 5-Minuten-Cache, der durch eine max_tokens: 0-Anfrage auf dem unveränderten Präfix alle 4 Minuten Leerlaufzeit warm gehalten wird (die Durchläufe vom 23. August pingten mit max_tokens: 1; jeder Ping vom 26. August frischte den Cache auf und rechnete keinen Output ab). Pläne: keine Pausen, 10 % der Turns und jeder Turn bei 6 Minuten auf allen 20 Issues sowie 45-Minuten-Pausen auf der Teilmenge von 5 Issues; drei Durchläufe pro Zelle, Kosten berechnet aus den usage-Feldern jeder Antwort zu Listenpreisen, Genauigkeit anhand derselben Gold-Labels (12 bis 17 exakte Labels von 20). Mittelwerte pro Session am 26. August für die 5-Minuten-, 1-Stunden- und Keep-alive-Einstellungen: keine Pausen 2,42 $, 3,09 $, 2,29 $; 10 % pausiert 4,50 $, 2,96 $, 2,36 $; jeder Turn 22,89 $, 3,01 $, 2,62 $; die Zellen vom 23. August stimmen innerhalb von 6 % überein. Die 45-Minuten-Zahlen (1,68 $, 0,59 $ und 0,71 $ pro 5-Issue-Session) stammen aus einem sauberen erneuten Durchlauf am 26. August, nachdem ein Cache-Abrechnungsvorfall die ersten Zellen dieses Tages verdorben hatte; die Durchläufe vom 23. August ergaben 1,67 $, 0,58 $ und 0,70 $. Der Kreuzungspunkt zwischen der 5-Minuten- und der 1-Stunden-Einstellung liegt bei 3,1 % der Turns, dasselbe Maß wie in Referenz 16.
20. Terminal-Bench 3: die 74 Aufgaben des öffentlichen Terminal-Agenten-Benchmarks, ausgeführt auf Claude Managed Agents mit zwei benutzerdefinierten Tools, einer Shell und einem Datei-Editor, die das Evaluierungs-Harness im eigenen Container jeder Aufgabe ausführt, anstelle der integrierten Tools der Plattform, und ansonsten bei den Standardeinstellungen der Plattform für externe Konten, zwei Durchläufe pro Modell bei high-Effort, 27. bis 28. August 2026. Die Werte sind rohe Bestehensquoten über die 148 Versuche pro Modell; Einzeldurchläufe schwanken um 5 bis 11 Punkte. Die Kosten sind das, was einem Kunden zu Listenpreisen in Rechnung gestellt würde, Anfrage für Anfrage aus den Nutzungsdatensätzen der Durchläufe mit der 5-Minuten-Cache-Lebensdauer neu bepreist. Claude Opus 4.7 beendete 11 seiner 148 Versuche an seiner Output-Obergrenze.

Nächste Schritte