Zum Hauptinhalt springen

Claude Sonnet 5.5: Der Praxisleitfaden

Fortgeschritten

Am 28. September 2026 veröffentlichte Anthropic Claude Sonnet 5.5 (claude-sonnet-5-5) — das zweite Modell der 5.5-Familie, nach Opus 5.5 sechs Tage zuvor. Die Preisliste ist genau deshalb der interessante Teil, weil sie sich nicht bewegt hat: 2 $ rein / 10 $ raus pro MTok, Byte für Byte die Preise von Sonnet 5, derselbe Tokenizer, dieselben Cache- und Batch-Preise. Anthropics Behauptung lautet dennoch: Output mehr als 30 % schneller und bis zu 30 % weniger pro Aufgabe.

Beides kann gleichzeitig zutreffen, und zu verstehen warum, ist der ganze Sinn dieser Seite: Bei Sonnet 5.5 liegt die Einsparung in der Token-Anzahl und der Anzahl der Turns, niemals im Preis pro Token. Das verändert, was du messen musst, und es verändert, an welchem Knopf du zuerst drehst.

Das zweite, was man am ersten Tag wissen sollte: Das günstige Modell liegt nicht durchgängig hinter dem teuren. Auf Terminal-Bench 4.0 erreicht Sonnet 5.5 70,6 % gegen die 66,4 % von Opus 5.5 — die eine veröffentlichte Zeile, in der das halb so teure Modell vorn liegt. Und beim Elo für Wissensarbeit sind die beiden statistisch gleichauf. Die verbleibende Lücke konzentriert sich an einer bestimmten Stelle, und diese Seite sagt, wo.

What you'll learn
  • Die echten Zahlen kennen: 2 $/10 $ pro MTok unverändert gegenüber Sonnet 5, 1M Kontext, 128K max. Output (300K über Batches), Wissensstand Juni 2026, Standard-Effort high
  • Die fünf Breaking Changes beheben, die in einer Sonnet-5-Codebasis 400er auslösen, und den sechsten, der 200 liefert und dein Fortschritts-UI verstummen lässt
  • between_tools richtig nutzen — den Ersatz für thinking disabled, der bei xhigh und max Effort abgelehnt wird und jedes Begleitfeld zurückweist
  • Die Launch-Tabelle ehrlich lesen: wo Sonnet 5.5 Opus 5.5 schlägt, wo es 8 Punkte zurückliegt und warum eine Zeile 10,3 % ausweist
  • Effort von Grund auf neu kalibrieren, statt eine Einstellung mitzunehmen, und das ~1/3 der Sitzungskosten zurückholen, das max Effort für selbst gestartete Reviews ausgibt
  • Die leiseren Fehlermodi handhaben: Structured-Output-Requests, die bis max_tokens denken, Tool-Namen mit falscher Groß-/Kleinschreibung und echte Nutzernachrichten, die für Prompt Injection gehalten werden

Specs und die vier Zahlen, die sich geändert haben​

Sonnet 5Sonnet 5.5Opus 5.5
Claude-API-IDclaude-sonnet-5claude-sonnet-5-5claude-opus-5-5
Input / Output pro MTok2 $ / 10 $2 $ / 10 $4 $ / 20 $
Cache-Lesen / 5-Min.-Schreiben0,20 $ / 2,50 $0,20 $ / 2,50 $0,20 $ / 5 $
Min. cachefähiger Prompt1.024 Tokens512 Tokens—
Kontext1M1M1M
Max. Output (synchron)128K128K128K
Akzeptierte Thinking-Einstellungenadaptive, disabledadaptive, between_toolsnur adaptive
Standard-Efforthighhighmedium
Verlässlicher Wissensstand—Jun 2026Jun 2026
Abkündigung nicht vor—28. Sep. 202722. Sep. 2027

Vier Dinge in dieser Tabelle sind wirklich neu, und nur eines davon ist irgendwo eine Schlagzeile:

  1. Der minimal cachefähige Prompt hat sich halbiert, 1.024 → 512 Tokens. Wenn dein System-Prompt im Bereich 600–1.000 Tokens liegt, war er auf Sonnet 5 still nicht cachefähig und ist es jetzt, zu 10 % des Input-Preises beim Lesen. Keine Codeänderung, kein Beta-Header. Das ist der günstigste Gewinn auf der ganzen Seite.
  2. thinking: {"type": "disabled"} ist weg, ersetzt durch between_tools. Sonnet 5.5 sitzt zwischen Sonnet 5 (das disabled akzeptierte) und Opus 5.5 (das keines von beiden akzeptiert) — es kann vorgeschaltetes Thinking noch überspringen, nur unter neuem Namen und mit neuen Grenzen.
  3. Der Standard-Effort blieb high — beachte, dass das höher ist als der medium-Standard von Opus 5.5. Das günstigere Modell denkt von Haus aus pro Turn mehr als das teure.
  4. temperature, top_p und top_k liefern 400 bei jedem Wert außer dem Standard, wie beim Rest der 5.x-Linie. Sampling-Parameter-Sweeps sind hier keine Tuning-Oberfläche; effort ist es.

Der Tokenizer ist unverändert gegenüber Sonnet 5, derselbe Text erzeugt also dieselben Token-Zahlen. Jede Änderung, die du in deiner Rechnung messen kannst, ist eine Änderung daran, wie viele Tokens das Modell zu emittieren gewählt hat.

Warum die Rechnung sinkt, obwohl der Preis es nicht tut​

Das ist der Teil, den die meiste Launch-Berichterstattung auf „30 % günstiger“ zusammenstaucht und dabei subtil falsch wiedergibt. Die Preisliste ist identisch. Anthropics Behauptung zerlegt sich in drei separate Effekte, und sie sind nicht gleich leicht einzufangen:

Guided walkthrough1 of 3
  1. Output ist die teure Seite mit 10 $/MTok gegen 2 $ Input. Sonnet 5.5 erreicht dasselbe Ergebnis mit weniger Output-Tokens als Sonnet 5, und dazu zählen Thinking-Tokens — Thinking wird als Output abgerechnet, selbst wenn sein Text dir nie zurückgegeben wird. Diesen Effekt bekommst du gratis, mit demselben Code.

Effekt 1 und 2 sind genau das, was eine mitgeschleppte effort-Einstellung zunichtemachen kann. Deshalb ist der nächste Abschnitt der, den du liest, bevor du deine Modell-ID änderst.

Effort: neu kalibrieren, nicht übernehmen​

Anthropic sagt ausdrücklich, dass Effort-Level neu kalibriert wurden — ein Level kauft nicht dieselbe Menge Thinking, die es auf Sonnet 5 gekauft hat. Es gibt absichtlich keine Umrechnungstabelle. Fahre deinen Sweep erneut.

Die veröffentlichten Startpunkte sind nicht der Standard:

WorkloadStarte beiWarum
Allgemein / unsicherhighDer API-Standard.
Agentisches Coding, mehrstufige Tool-Nutzung, gut spezifiziertmediumDann für schwierigere oder längere Aufgaben auf high gehen.
Chat, latenzsensibelmedium oder lowHöherer Effort bedeutet eine längere Wartezeit, bis die Antwort beginnt.
Allesxhigh / maxNur dort, wo du einen Qualitätsgewinn gemessen hast.

Drei Konsequenzen, die in Produktion wehtun:

  • Das effort-Feld auf oberster Ebene zwischen Requests zu ändern, invalidiert den Prompt-Cache. Wenn du eine günstige interaktive Sitzung willst, die bei harten Turns eskaliert, nutze die Beta für Effort pro Nachricht (output_config.effort an einer Nachricht), die den Cache erhält. Diese Beta ist neu in 5.5 und war auf Sonnet 5 nicht verfügbar.
  • max_tokens muss Thinking plus Antwort abdecken. Thinking zählt dagegen, selbst wenn der Thinking-Text in der Antwort weggelassen wird. Ein Limit, das für einen Request ohne Thinking bemessen ist, wird abschneiden. Für agentisches Coding ist Anthropics Vorgabe unmissverständlich: Setze max_tokens auf 128.000 und streame.
  • Das Modell zu bitten, weniger zu denken, funktioniert nicht zuverlässig. Das Effort-Level zu senken schon. Ab medium denkt es vor fast jeder Antwort; bei low überspringt es Thinking bei den meisten einfachen Anfragen.

Die Review-Steuer bei max Effort​

Bei xhigh und max hört Sonnet 5.5 nicht auf, wenn die Aufgabe erledigt ist. Es startet eigene Runden von Review und Verifikation, und wenn dein Harness Subagenten anbietet, startet es Reviewer-Subagenten — ungefragt. Anthropic hat die Lösung veröffentlicht und, ungewöhnlich, auch deren Größe: In ihren Tests bei Coding-Aufgaben mit max Effort hat der Absatz unten die Sitzungskosten um etwa ein Drittel gesenkt, ohne Qualitätsänderung.

Selbst gestartete Review-Runden bei xhigh und max Effort stoppen

When the work the user asked for is done and its checks pass, stop and report. Don't start extra
rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user
asked for a review. If you think a deeper review is worth doing, say so at the end.

Es macht selbst gestartete Reviews seltener, nicht unmöglich. Das Spiegelbild-Problem gibt es am unteren Ende des Bereichs: Bei low und medium bricht das Modell bei langen agentischen Aufgaben häufiger ab und fragt vor dem Abschluss nach, und bei low meldet es manchmal eine Codeänderung als erledigt, ohne eine Prüfung laufen zu lassen, die sie tatsächlich ausübt.

Die fünf Breaking Changes​

Jeder davon liefert HTTP 400 invalid_request_error bei Code, der auf Sonnet 5 funktionierte.

1. disabled → between_tools​

thinking: {"type": "disabled"} liefert 400 mit einer Meldung, die den Ersatz benennt:

"thinking.type.disabled" is not supported for this model. Use "thinking.type.between_tools" for the
lowest thinking setting, or "thinking.type.adaptive" and "output_config.effort" to control thinking
behavior.

between_tools ist die niedrigste Thinking-Einstellung auf Sonnet 5.5. Es braucht keinen Beta-Header und funktioniert auf jeder Plattform, die das Modell anbietet. Aber es ist heikler, als disabled es je war:

  • Akzeptiert bei low, medium, high. Bei xhigh oder max liefert es 400 — diese Level erfordern adaptives Thinking (thinking weglassen oder thinking: {"type": "adaptive"} senden; das ist gleichwertig).
  • Effort kann sich nicht mitten in der Konversation ändern. Ein output_config.effort pro Nachricht, das von dem geltenden Level abweicht, liefert 400. Effort pro Turn braucht adaptives Thinking.
  • Es nimmt kein Begleitfeld. display, budget_tokens oder block_binding daneben gesendet liefert 400. Manuelle Budgets (thinking: {"type": "enabled", "budget_tokens": N}) liefern ebenfalls 400.
  • Mit serverseitigem Fallback läuft ein between_tools-Request, der auf Sonnet 5 zurückfällt, dort mit thinking: {"type": "disabled"} — die Einstellungen werden über den Fallback für dich abgebildet.

Noch eine Falle: Mit between_tools entferne jede Anweisung, die dem Modell sagt, nicht zu denken. Solche Zeilen machen es wahrscheinlicher, dass es interne XML-Tags in seinen sichtbaren Output schreibt.

Eine Integration mit abgeschaltetem Thinking migrieren — Sonnet 5 zu Sonnet 5.5

# Before — accepted on Sonnet 5
client.messages.create(
  model="claude-sonnet-5",
  max_tokens=16000,
  thinking={"type": "disabled"},
  output_config={"effort": "xhigh"},      # fine with disabled on Sonnet 5
  messages=[{"role": "user", "content": "..."}],
)

# After — on Sonnet 5.5: rename the type AND drop effort to high or below
client.messages.create(
  model="claude-sonnet-5-5",
  max_tokens=16000,
  thinking={"type": "between_tools"},     # xhigh/max with this -> 400
  output_config={"effort": "high"},
  messages=[{"role": "user", "content": "..."}],
)

# If you need xhigh or max, use adaptive thinking instead of between_tools:
#   thinking={"type": "adaptive"}   (or omit the field entirely)

# SDKs that predate between_tools fail type checking on the literal.
# Update the SDK, or pass the value as raw JSON.

2. Erzwungene Tool-Nutzung wird abgelehnt​

tool_choice auf {"type": "any"} oder {"type": "tool", "name": "..."} gesetzt liefert 400:

tool_choice: type "tool" and "any" are not supported for this model.

auto (der Standard) und none funktionieren weiterhin. Dieselbe Prüfung gilt auf dem Token-Counting-Endpoint, was in einer Testsuite, die nur /v1/messages ausübt, leicht zu übersehen ist.

Erzwungene Tool-Nutzung erledigte zwei Aufgaben; trenne sie:

  • Schema-Gültigkeit kommt von strikter Tool-Nutzung (strict: true am Tool) oder von Structured Outputs.
  • Steuerung — das Modell überhaupt zum Tool-Aufruf zu bringen — kommt daraus, dass der Prompt sagt, wann das Tool zutrifft.

3. Thinking-Blöcke sind an Modell, Konversation und Account gebunden​

Jeder Thinking-Block hält fest, welches Modell ihn erzeugt hat, und Modelle lesen nur die Blöcke einiger anderer Modelle. Der Graph ist asymmetrisch und nicht intuitiv:

Blöcke erzeugt vonKann Sonnet 5.5 sie lesen?
Sonnet 5.5 selbstJa
Sonnet 5, Opus 4.8, Haiku 4.5 und früherJa
Opus 5, Opus 5.5Nein
Jedes Fable- oder Mythos-ModellNein

Und in der anderen Richtung: kein anderes Modell liest die Thinking-Blöcke von Sonnet 5.5. Eine Konversation, die aufwärts von Sonnet 5 zu Sonnet 5.5 migriert, behält also ihr Reasoning; eine Konversation, die weg von Sonnet 5.5 zu irgendetwas anderem wechselt — einschließlich Opus 5.5, einem verlockenden Eskalationspfad — läuft jeden folgenden Turn ohne es. Unlesbare Blöcke werden verworfen, bevor das Modell sie sieht, der Request gelingt, und verworfene Blöcke werden nicht abgerechnet. Mit dem Beta-Header thinking-binding-controls-2026-08-01 werden die verworfenen Blöcke in einem input_transformations-Array auf oberster Ebene aufgeführt.

Zwei weitere Bindungen kommen obendrauf:

  • Konversationspräfix. Die API prüft, ob sich der system-Prompt, die tools-Liste oder irgendeine frühere Nachricht geändert hat, seit ein Sonnet-5.5-Thinking-Block erzeugt wurde. Sie erzwingt das standardmäßig für Accounts, die am oder nach dem 31. August 2026, 00:00 UTC, erstellt wurden auf der Claude API, Bedrock und Google Cloud — einen Block nach so einer Änderung erneut zu senden liefert dort 400. Um die betroffenen Blöcke stattdessen zu verwerfen, sende thinking-binding-controls-2026-08-01 und setze thinking.block_binding.prefix_mismatch_behavior auf "drop_block". Beachte: block_binding funktioniert nur mit adaptivem Thinking; unter between_tools bleiben dir nur eine rein anfügende Historie oder das Entfernen der Thinking-Blöcke ab dem geänderten Turn.
  • Account. Die Thinking-Blöcke von Sonnet 5.5 funktionieren nur in dem Account, der sie erzeugt hat, oder einem verknüpften. Ein anderer Account, der sie sendet, bekommt sie verworfen, mit reason: "organization_binding_mismatch" unter der Binding-Controls-Beta. Blöcke früherer Modelle sind nicht betroffen.
Guided walkthrough1 of 5
  1. Claude Code, claude.ai, Claude Managed Agents und das Claude Agent SDK tun das bereits. Rein anfügende Integrationen brauchen keine Änderung.

4. computer_20251124 wird abgelehnt — auf zwei von drei Plattformen​

Auf der Claude API und Google Cloud unterstützt Sonnet 5.5 Computer Use nur über das Toolset computer_toolset_20260801. Das ältere Tool computer_20251124 zu deklarieren liefert 400:

'claude-sonnet-5-5' does not support tool types: computer_20251124.

Auf Amazon Bedrock akzeptiert Sonnet 5.5 weiterhin computer_20251124. Diese Asymmetrie ist genau die Art von Sache, die ein plattformübergreifendes Deployment in einer Cloud die CI bestehen und in einer anderen scheitern lässt. Migrieren bedeutet: den alten Beta-Header entfernen, den tools-Eintrag durch {"type": "computer_toolset_20260801"} ersetzen und die Agent-Schleife für Member-tool_use-Blöcke, Batch-Aktionen und toolset_name an Ergebnissen aktualisieren. Integrationen, die bereits auf dem Toolset sind, und alles, was das Browser-Use-Tool verwendet, brauchen keine Änderung.

5. Advisor-Paarungen eingeschränkt​

Mit dem Advisor-Tool (Beta) akzeptiert ein Sonnet-5.5-Executor Mythos 5.1, Fable 5.1, Mythos 5, Fable 5, Opus 5.5, Opus 5 oder Sonnet 5.5 selbst als Advisor. Opus 4.8, Opus 4.7 und Sonnet 5 werden mit 400 abgelehnt — alle drei funktionierten als Advisor für einen Sonnet-5-Executor. Jeder Advisor, den Sonnet 5.5 akzeptiert, liefert seinen Rat verschlüsselt zurück, als advisor_redacted_result-Block, dein Client kann den Text des Rats also nicht lesen.

Die sechste Änderung: HTTP 200, und dein UI verstummt​

Diese lässt nichts scheitern und erreicht am wahrscheinlichsten deine Nutzer, bevor sie deine Logs erreicht.

Zwischen Tool-Aufrufen schreibt Sonnet 5.5 an die Nutzer gerichtete Notizen darüber, was es gerade gefunden hat und was es als Nächstes tut. Notizen, die länger als ein oder zwei Sätze sind, kommen jetzt als Progress-Update-thinking-Blöcke zurück; kürzere Bemerkungen bleiben text. Beim Standardwert display: "omitted" ist das Textfeld eines Progress-Update-Blocks leer. Ein Client, der nur text-Blöcke rendert, zeigt während eines langen agentischen Turns daher gar nichts — kein Fehler, keine Warnung, nur Stille dort, wo früher Erzählung war.

Drei Auswege, sortiert danach, wie wenig Arbeit sie machen:

  1. Nutze between_tools. Die Notizen kommen mit ihrem Zusammenfassungstext zurück, ohne dass ein display-Feld nötig ist (und es wird auch keines akzeptiert).
  2. Setze display: "updates" mit dem Beta-Header thinking-display-updates-2026-08-18. Du bekommst eine kurze Zusammenfassung jedes Progress-Updates, während das Reasoning selbst verborgen bleibt.
  3. Gib dem Modell ein Tool, um dem Nutzer eine Nachricht zu senden, für die Fälle, in denen es mitten im Turn exakten Text zeigen muss — ein Code-Snippet, eine Frage, die beantwortet werden muss. Sage ihm, es soll dieses Tool nur für solche Inhalte nutzen, und deklariere das Tool im ersten Request, damit sich tools später nie ändert.

Räume dann drumherum auf: lösche Anweisungen wie „halte alle Erkenntnisse für die Abschlussantwort zurück“, und wenn du Updates an vorhersehbaren Punkten willst, frage sie explizit an — eine Zeile vor dem ersten Tool-Aufruf, eine Zusammenfassung am Ende. Dem folgt das Modell.

Wenn lange Turns weiterhin verstummen, kann dein Harness anstoßen — vorsichtig. Zähle aufeinanderfolgende Tool-aufrufende Schritte, die dem Nutzer keinen Text gesendet haben, und hänge nach mehreren (sagen wir fünf) eine Erinnerung für einen Turn nach den letzten Tool-Ergebnissen an, als Turn-bezogene System-Nachricht:

Harness-Anstoß für einen stillen agentischen Turn

The user hasn't heard from you in a while — say in a few words what you're doing, then continue.

Höre nach dem zweiten oder dritten Mal auf, wenn es nicht greift. Häufiger Harness-Text nach Tool-Ergebnissen lässt das Modell eine Prompt Injection vermuten — das ist der nächste Abschnitt. Weil die Erinnerung angehängt und nicht eingefügt und später entfernt wird, überleben sowohl der Prompt-Cache als auch das erhaltene Thinking. Anthropics Messung: bei high Effort mit einem verfügbaren Tool zum Nachrichtensenden verkürzt das die längsten stillen Strecken, ohne messbare Änderung der Aufgabenqualität.

Die Launch-Tabelle ehrlich lesen​

BenchmarkSonnet 5Sonnet 5.5Opus 5.5Sonnet 5.5 als % von Opus 5.5
Terminal-Bench 4.010,3 %70,6 %66,4 %106 %
GDPval-AA v2.1 (Elo)14491844184699,9 %
AA-Briefcase v1.1 (Elo)13591811182299,4 %
OSWorld 2.1 (Teilpunkte)—80,1 %81,8 %98 %
CursorBench 4.034,1 %55,5 %57,8 %96 %
Chartography (ohne Tools)—61,6 %64,4 %96 %
Humanity's Last Exam (mit Tools)54,9 %64,5 %67,7 %95 %
FrontierCode 1.1 (max Effort)42,4 %46,2 %54,4 %85 %

Vier ehrliche Lesarten dieser Tabelle:

  • Die Lücke ist nicht gleichmäßig, und sie wegzumitteln verbirgt das nützliche Signal. Beim Elo für Wissensarbeit liegen die beiden Modelle innerhalb des Rauschens. Beim härtesten Coding-Benchmark, FrontierCode 1.1, liegt Sonnet 5.5 8,2 Punkte zurück — 85 % von Opus 5.5. Diese einzelne Zeile ist die ehrliche Grundlage für Anthropics eigene Darstellung, dass Opus 5.5 bei komplexer, offener Arbeit, die anhaltendes Urteilsvermögen erfordert, klar stärker bleibt.
  • Terminal-Bench 4.0 ist die eine Zeile, in der das halb so teure Modell gewinnt, 70,6 % gegen 66,4 %. Dieser Benchmark ist der nächstliegende veröffentlichte Stellvertreter für „lass einen Agenten in einer Shell laufen, bis der Job erledigt ist“ — genau dort, wo weniger Tool-Aufrufe und weniger Tokens kumulieren.
  • Behandle die 10,3 % von Sonnet 5 auf Terminal-Bench 4.0 mit Misstrauen, nicht mit Staunen. Ein Sprung von 60 Punkten zwischen Generationen bei einer Benchmark-Version sagt dir mindestens so viel über das Harness und die Scoring-Version wie über das Modell. Nutze es, um zu schließen: „diese Version dieses Benchmarks bestraft das Agentenverhalten von Sonnet 5“ — nicht „Sonnet 5.5 ist bei agentischem Coding siebenmal besser“.
  • Die Quellen widersprechen sich bei FrontierCode am oberen Ende des Effort-Bereichs. Anthropics Tabelle berichtet 46,2 % bei max Effort; mindestens ein Aggregator berichtet höhere 52,1 % bei xhigh. Wir konnten die zweite Zahl nicht gegen die Primärtabelle bestätigen, lies sie also als unverifiziert — aber beachte, dass „mehr Effort erzielte weniger Punkte“ mit dem Rat der Doku selbst übereinstimmt, xhigh und max für Fälle vorzuhalten, in denen du einen Gewinn gemessen hast, statt monotone Verbesserung anzunehmen.

Unabhängige Messungen landen bei agentischen Benchmarks wie immer niedriger als Herstellermessungen. Fahre deine eigenen Evals, bevor du eine Zahl auf eine Folie schreibst.

Die leisen Fehlermodi​

Keiner davon wirft einen Fehler. Alle kosten dich Genauigkeit oder Vertrauen.

Structured Outputs, die denken, bis nichts mehr übrig ist​

Verlange eine JSON-Antwort auf eine Aufgabe, die ein paar Schritte Rechnen braucht — Summen aus einem Dokument bilden, eine Regel anwenden, Elemente ranken — und Sonnet 5.5 antwortet oft ohne vorher zu denken, besonders bei low und medium Effort. Mit Structured Outputs enthält der Antworttext nur das JSON, die Zwischenrechnung hat also nirgends Platz außer im Thinking; überspringe das Thinking und die Genauigkeit sinkt.

  • Mit adaptivem Thinking bringt das Anhängen von Think the problem through before you answer. an den System-Prompt die Genauigkeit bei high Effort nahe an xhigh, bei moderatem Anstieg der Output-Tokens.
  • between_tools ist für diese Requests die falsche Einstellung: ohne Tools im Spiel bedeutet es überhaupt kein Thinking, und diese Zeile hat keine Wirkung.
  • Bei low und medium mit Structured Outputs denkt das Modell gelegentlich weiter, bis es max_tokens erreicht. Behandle jede Antwort mit stop_reason: "max_tokens" als fehlgeschlagen und wiederhole sie, selbst wenn ihr Text zufällig gültiges JSON enthält. Das ist der wahrscheinlichste Weg, eine selbstsicher falsche Zahl auszuliefern.

Wenn du keine Structured Outputs nutzen kannst und im Prompt nach JSON fragst, arbeitet das Modell das Problem meist im Antworttext aus und setzt das JSON ans Ende. Schneide nicht von der ersten { bis zur letzten } — es schreibt gelegentlich einen Entwurf vor der endgültigen Antwort, und du würdest beides erfassen.

Den endgültigen JSON-Wert aus einer gemischten Antwort extrahieren

# Read only text blocks. Treat stop_reason == "max_tokens" as a failure and retry.
# Starting at each { or [, try to parse a JSON value; continue from the END of a value
# that parses, so values nested inside it are not counted on their own. Keep the LAST one.

import json

def last_json_value(text):
  dec, best, i = json.JSONDecoder(), None, 0
  while i < len(text):
      if text[i] in "{[":
          try:
              value, end = dec.raw_decode(text, i)
          except ValueError:
              i += 1
              continue
          best, i = value, end          # jump past it: skip nested values
      else:
          i += 1
  return best

# Then check the fields you expect are present, and retry once if they are not.

Echte Nutzernachrichten, die als Prompt Injection gelesen werden​

Sonnet 5.5 ist darauf trainiert, indirekter Prompt Injection zu widerstehen — Anweisungen, die über Tool-Ergebnisse und andere Inhalte ankommen, die es mitten in der Aufgabe liest. Manchmal klassifiziert es eine echte Nutzernachricht so, teilt dem Nutzer mit, das Tool-Ergebnis habe Text enthalten, der sich als Nachricht von ihm ausgibt, und ignoriert sie entweder oder bittet um Bestätigung. Der Auslöser ist die Platzierung: Text, der unmittelbar nach Tool-Ergebnissen ankommt, besonders bei jedem Schritt.

  • Setze Nutzertext niemals in einen tool_result-Block. Das ist die Platzierung, die es am häufigsten falsch liest.
  • Liefere Nutzereingaben mitten im Turn als User-Turn: hänge ihre Worte als Textblock in der User-Nachricht an, die die tool_result-Blöcke trägt, nach dem letzten tool_result.
  • Halte Harness-Hinweise in einer separaten System-Nachricht mitten in der Konversation, nach den Worten des Nutzers. Setze niemals einen Hinweis und die Worte des Nutzers in denselben Block.
  • Lass deinen eigenen Token-/Budget-Countdown nach Tool-Ergebnissen weg in interaktiven Sitzungen, in denen Nutzer mitten im Turn tippen können. Ein Countdown pro Schritt ist die klassische Ursache. Die Task-Budgets-Beta fügt einen ähnlichen Countdown hinzu, hat diese Fehldeutung aber nachweislich nicht ausgelöst.

Tool-Namen mit falscher Groß-/Kleinschreibung​

Sonnet 5.5 ruft gelegentlich ein deklariertes Tool mit einem Namen auf, der sich nur in der Groß-/Kleinschreibung unterscheidet — bash statt Bash — oder übergibt einen bekannten Parameter unter einem leicht abweichenden Namen. Behandle das nicht als fatal. Akzeptiere entweder den Aufruf, wenn die Zuordnung eindeutig ist, oder gib ein tool_result mit is_error: true zurück, das den exakt erwarteten Namen nennt; das Modell korrigiert sich im nächsten Turn meist selbst.

Diagramme: gib ihm Tools, bevor du ihm Effort gibst​

Für dichte Diagramme und technische Zeichnungen gib dem Modell eine Möglichkeit, das Bild zu beschneiden, zu zoomen oder Code darauf auszuführen. Das gemessene Ergebnis lohnt sich zu verinnerlichen: mit Tools bei high Effort las es Diagramme genauer als ohne Tools bei max Effort, zu einem Bruchteil der Kosten. Bei technischen Zeichnungen helfen die Tools erst ab high, und am meisten bei xhigh und max. Greife zum Tool, nicht zum Regler.

Ablehnungen: fünf Kategorien, und nur zwei werden erneut versucht​

Ein abgelehnter Request ist HTTP 200 mit stop_reason: "refusal" und einem stop_details-Objekt, das die Kategorie benennt. Sonnet 5.5 ist das erste Sonnet, das mit Cyber-Schutzmaßnahmen auf dem Niveau von Anthropics leistungsfähigsten Modellen erscheint, und das erste mit Klassifikatoren, die Reasoning-Extraktion blockieren.

stop_details-KategorieWas sie abdecktWiederholt serverseitiger Fallback sie auf Sonnet 5?
cyberKönnte Cyber-Schaden ermöglichen — Malware, Exploit-Entwicklung. Schwachstellen in Quellcode zu finden ist erlaubt; Dual-Use-Arbeit mit hohem Risiko nicht.Ja
frontier_llmKönnte die Entwicklung konkurrierender KI-Modelle unterstützen.Ja
bioKönnte biologischen Schaden ermöglichen. Alltägliche Gesundheits- und Bildungsfragen sind nicht betroffen.Nein
reasoning_extractionVerlangt vom Modell, sein internes Reasoning im Antworttext wiederzugeben.Nein
general_harmsEin anderer Bereich der Nutzungsrichtlinien. Auch harmlose Arbeit kann das auslösen.Nein

Zwei praktische Hinweise. Erstens: Wenn deine Prompts das Modell bitten, sein Reasoning in die Antwort aufzunehmen, entferne diese Zeilen — sie laden reasoning_extraction-Ablehnungen ein. Lies Reasoning stattdessen aus zusammengefassten Thinking-Blöcken (display: "summarized"). Zweitens: ob eine Ablehnung, die vor jeglichem Output ankommt, abgerechnet wird, hängt von ihrer Kategorie ab, und sie zählt in beiden Fällen gegen deine Rate Limits.

Legitime lebenswissenschaftliche Arbeit, die vom bio-Klassifikator blockiert wird, kann sich für Anthropics Life Sciences Verification Program bewerben.

Welches Modell betreibst du also wirklich?​

Guided walkthrough1 of 5
  1. Alltagsaufgaben, Bugfixes, mehrstufige Tool-Nutzung, polierte Dokumente und Tabellen. Starte bei medium Effort für agentisches Coding, high für allgemeine Arbeit, und messe. Mit 2 $/10 $ und 1M Kontext ist es das günstigste Modell der Reihe, das bei Wissensarbeit noch frontier-nah ist.

Die Migration selbst ist ein Austausch der Modell-ID plus sechs Prüfungen, und Anthropic liefert eine Automatisierung dafür: In Claude Code wendet /claude-api migrate this project to claude-sonnet-5-5 den ID-Austausch und die brechenden Parameteränderungen über eine Codebasis hinweg an und gibt dir eine Checkliste dessen, was du von Hand verifizieren musst. Es bittet dich, den Umfang zu bestätigen, bevor es irgendetwas editiert. Wenn du Claude Managed Agents statt der Messages API direkt nutzt, ist der Modellname die einzige erforderliche Änderung.

Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 10

Check yourself

0/6
  1. Sonnet 5.5 berechnet exakt die Preise von Sonnet 5 — 2 $/10 $ pro MTok, dieselben Cache-Preise, derselbe Tokenizer. Anthropic behauptet trotzdem bis zu 30 % weniger pro Aufgabe. Woher kommt die Einsparung?
  2. Deine Integration läuft mit Sonnet 5 mit thinking: {"type": "disabled"} und output_config effort "xhigh". Was ist die minimale korrekte Änderung für Sonnet 5.5?
  3. Nach der Migration eines Chat-Produkts auf Sonnet 5.5 melden Nutzer, der Assistent wirke während langer Tool-nutzender Turns eingefroren, obwohl die Abschlussantwort einwandfrei ankommt und keine Fehler geloggt werden. Was ist passiert?
  4. In einer Sonnet-5.5-Konversation kommt ein harter Turn und du willst mehr Tiefe. Welche Option erhält das bisher angesammelte Reasoning?
  5. Du nutzt Structured Outputs bei medium Effort, um Summen aus Rechnungen zu extrahieren. Eine Antwort kommt mit stop_reason "max_tokens" zurück, aber ihr Text parst als gültiges JSON mit plausiblen Zahlen. Was sollte dein Code tun?
  6. Welche Aussage über die Launch-Benchmark-Tabelle ist korrekt?

Weiter​

Quellen & weiterführende Literatur​