Zum Hauptinhalt springen

Claude Sonnet 5: Der Feldführer

Fortgeschritten

Am 30. Juni 2026 lieferte Anthropic Claude Sonnet 5 (claude-sonnet-5) aus und machte es still zum Default-Modell in Claude Code. Auf dem Papier ist es ein Drop-in für Sonnet 4.6 zum gleichen Listenpreis. In der Praxis werden drei API-Einschränkungen naive Migrationen mit 400 Bad Request zurückgeben lassen, ein neuer Tokenizer erzeugt grob 30% mehr Tokens für denselben Text (was sowohl dein Kontextbudget als auch deine Kosten pro Request ändert), und die Effort-Skala hat sich genug verschoben, dass "alles gleich lassen" nicht dasselbe ist. Warst du auf Sonnet 4.6 mit high, ist Sonnet 5 mit high näher an Sonnet 4.6 mit max.

Diese Seite ist der praktische Feldführer: was sich änderte, was bricht, die genaue Migrations-Checkliste, die Preismathematik zum Tokenizer-Shift und die Prompting-Muster, die die meisten Teams zuerst neu tunen.

What you'll learn
  • Verstehe, was Sonnet 5 tatsächlich ist — 1M Kontext by default, adaptives Denken an by default, das erste Sonnet mit echtzeit-Cybersecurity-Safeguards
  • Kenne die drei API-Einschränkungen, die deinen bestehenden Code mit 400 abweisen, und den Einzeiler-Fix für jeden
  • Modelliere die Preismathematik des neuen Tokenizers: derselbe $/Token, aber ~30% mehr Tokens = eine andere Rechnung pro Request
  • Rekalibriere Effort-Level: Sonnet 5 medium ≈ Sonnet 4.6 high, und Sonnet 5 high ≈ Sonnet 4.6 max
  • Passe die Prompting-Muster an, die sich am stärksten verschieben: Verbosität, Tool-Use-Triggering, Code-Review-Recall und Design-Defaults

Die Ein-Absatz-Version​

Sonnet 5 ist die ausgewogene "Start-hier"-Sonnet-Stufe, über Sonnet 4.6 zum gleichen Listenpreis positioniert und jetzt Claude-Code-Default. Es unterstützt das 1M-Token-Kontextfenster by default (es gibt keine kleinere Kontext-Variante), 128k max Output und adaptives Denken by default. Drei API-Verträge brechen bei der Migration: manuelles Extended Thinking (thinking: {type: "enabled", budget_tokens: N}) wurde entfernt und gibt 400 zurück, nicht-default Sampling-Parameter (temperature, top_p, top_k) geben 400 zurück, und der Tokenizer änderte sich — derselbe Eingabetext erzeugt grob 30% mehr Tokens als auf Sonnet 4.6. Priority Tier ist auf Sonnet 5 nicht verfügbar. Das ist die ganze Form des Releases.

Warum "Drop-in" ein Sternchen braucht​

Anthropics eigene Docs beschreiben Sonnet 5 als "Drop-in-Ersatz für Claude Sonnet 4.6" — und für Prompt-Inhalte stimmt das. Aber die API-Oberfläche änderte sich genug, dass "Model-String tauschen und ausliefern" auf Requests, die gestern gut liefen, Fehler produziert. Vier Dinge beißen dich, in der Reihenfolge, wie oft wir sie Integrationen brechen sehen:

  • temperature, top_p oder top_k auf nicht-default Werte gesetzt geben jetzt 400 zurück. Nicht still ignoriert. Nicht geklippt. Ein harter Fehler. Das ist neu für Sonnet-Class-Modelle; Opus 4.7 führte dieselbe Einschränkung ein. Wenn dein SDK-Wrapper immer temperature: 0.7 sendet, wird er jetzt immer fehlschlagen.
  • Manuelles Extended Thinking wurde entfernt. thinking: {type: "enabled", budget_tokens: N} war auf 4.6 deprecated und gibt auf Sonnet 5 400 zurück. Nutze stattdessen adaptives Denken mit dem Effort-Parameter.
  • Adaptives Denken ist by default an. Requests ohne thinking-Feld auf Sonnet 4.6 liefen ohne Denken; auf Sonnet 5 laufen sie mit adaptivem Denken. max_tokens ist ein harter Cap auf Gesamt-Output — Denken plus Antwort-Text — sodass ein für "nur die Antwort" auf Sonnet 4.6 dimensioniertes Limit die Antwort auf Sonnet 5 abschneiden kann.
  • Der neue Tokenizer erzeugt grob 30% mehr Tokens für denselben Text. Keine API-Änderung — Request- und Response-Shapes sind identisch — aber alles, was du in Tokens misst oder budgetierst, misst jetzt höher.

Die API-Einschränkungen, die dich mit 400 abweisen​

Guided walkthrough1 of 4
  1. Entferne jegliches temperature, top_p oder top_k, das nicht der API-Default ist. Braucht deine App stilistische Vielfalt, nutze System-Prompt-Anweisungen statt temperature (das ist jetzt der einzige Hebel). Brauchst du diverse Design-Outputs, bitte das Modell, N distinkte Richtungen vorzuschlagen und eine zu wählen — das gibt dir Vielfalt über Runs hinweg selbst mit festem Sampling.

Minimale sichere Migration — ein Diff

# Before (Sonnet 4.6) — worked
response = client.messages.create(
  model="claude-sonnet-4-6",
  max_tokens=4096,
  temperature=0.7,                          # 400 on Sonnet 5
  thinking={"type": "enabled",
            "budget_tokens": 8000},         # 400 on Sonnet 5
  messages=[...],
)

# After (Sonnet 5) — one-liner replacements
response = client.messages.create(
  model="claude-sonnet-5",
  max_tokens=8192,                          # raise: thinking now shares the budget
  # temperature removed — use system prompt instead
  # thinking removed — adaptive is on by default
  extra_body={"effort": "high"},            # was implicit in budget_tokens
  messages=[...],
)

Der Tokenizer-Shift ist eine Preisgeschichte, keine API-Geschichte​

Der neue Tokenizer ist die Änderung, die dein Finance-Team am wahrscheinlichsten überrascht. Requests und Responses sehen über die Leitung identisch aus, aber derselbe Eingabetext erzeugt grob 30% mehr Tokens als auf Sonnet 4.6. Der genaue Multiplier hängt vom Inhalt ab — Code, englische Prosa, nicht-englischer Text und strukturierte Daten shiften alle anders — aber 30% ist die Zahl, die Anthropic zitiert.

Drei Dinge ändern sich gleichzeitig:

  • Kosten pro Request. Pro-Token-Preis ist unverändert gegenüber Sonnet 4.6 bei $3 / $15 pro MTok Standard (und $2 / $10 bis 31. August 2026). Aber wenn derselbe Text 30% mehr Tokens erzeugt, kostet derselbe Text nach Anlauf des Standardtarifs etwa 30% mehr.
  • Kontextkapazität in Textbegriffen. Das Kontextfenster ist immer noch 1M Tokens, aber jeder Token deckt im Schnitt weniger Text ab. Dasselbe Dokument nimmt ~30% mehr deines Fensters ein.
  • max_tokens-Truncation-Risiko. Ein für "grob so viel Text" auf Sonnet 4.6 getunter Output-Cap kann äquivalenten Output auf Sonnet 5 still abschneiden. Überprüfe jedes Limit, das nah an deiner erwarteten Output-Länge liegt.

Die Preismathematik, ehrlich aufgezeichnet:

ZeitraumListenpreisDerselbe Text → Kosten vs. Sonnet 4.6
Jetzt → 31. Aug 2026 (Einführung)$2 in / $10 outGrob 13% günstiger (30% mehr Tokens × $2 vs. Sonnet 4.6 bei $3)
Ab 1. Sep 2026 (Standard)$3 in / $15 outGrob 30% teurer für äquivalenten Text

Wenn du eine App auf Einführungspreis-Tokens kalkulierst und den 1.-September-Flip nicht modelliert hast, wirst du es merken.

Zähle deine Prompts unter dem neuen Tokenizer neu

# Recount before you migrate — don't trust old numbers
count = client.messages.count_tokens(
  model="claude-sonnet-5",     # count under the NEW tokenizer
  messages=[{"role": "user", "content": your_prompt}],
  system=your_system,
)
print(count.input_tokens)        # roughly 30% higher than on claude-sonnet-4-6

Die Effort-Skala verschob sich — rekalibriere vor dem Vergleich​

Der Effort-Parameter (low / medium / high / xhigh / max) hat immer noch dieselben fünf Werte, aber Anthropic gibt bei Migration eine explizite Cross-Modell-Zuordnung, die die meisten Teams beim ersten Lesen verpassen:

  • Sonnet 5 mit medium ≈ Sonnet 4.6 mit high.
  • Sonnet 5 mit high ≈ Sonnet 4.6 mit max.
  • xhigh wird für die härtesten Coding- und Agentic-Tasks empfohlen.
  • max entfernt Token-Ausgabe-Constraints komplett.

Zwei Implikationen:

  • Warst du auf Sonnet 4.6 mit high und tauschst das Modell ohne Effort-Änderung, läufst du jetzt mit mehr Denken, mehr Tokens und wahrscheinlich besseren Outputs — aber einer größeren Rechnung. Erwäge, auf medium zu droppen.
  • Warst du auf Sonnet 4.6 mit max und tauschst auf Sonnet 5 mit max, zahlst du vielleicht für Headroom, den du nicht brauchst. Probiere zuerst xhigh.

Anthropic warnt auch, Sonnet 5 respektiert Effort strikt, besonders am unteren Ende. low und medium scopen Arbeit auf das Gefragte; sie gehen nicht "über das Übliche hinaus". Das ist gut für Latenz und Kosten, aber bei mäßig komplexen Tasks mit low besteht ein echtes Risiko von Under-Thinking. Der empfohlene Fix ist, Effort zu erhöhen, statt drumherum zu prompten.

Sonnet 5 ist jetzt Claude-Code-Default — was sich ändert​

Ab Claude Code v2.1.197 (30. Juni 2026) ist claude-sonnet-5 das Default-Modell. Setzt du nichts, laufen deine Sessions auf Sonnet 5. Praktische Konsequenzen:

  • Du bekommst 1M Kontext, aber deine max_tokens und Effort-Einstellungen sind geerbt. Claude Codes Defaults sind auf das neue Modell getunt; custom CLAUDE.md-Configs, die max_tokens pinnten oder ein Effort-Override setzten, sollten re-verifiziert werden.
  • Schnelleres, agentischeres Default-Verhalten. Sonnet 5 ist out of the box agentischer als Sonnet 4.6 — es greift bereitwilliger zu Tools und läuft Self-Verification-Loops. Warst du gewohnt, dass Claude Code beim Ausführen von Kommandos konservativ ist, erwarte mehr Initiative.
  • Regelmäßige nutzer-sichtbare Fortschritts-Updates. Sonnet 5 liefert schon hochwertigere Zwischen-Updates auf langen Traces. Prompt-Scaffolding wie "nach je 3 Tool-Aufrufen Fortschritt zusammenfassen" kann meist entfernt werden.
  • Sonnet 4.6 ist jetzt ein Legacy-Modell. Weiter verfügbar (pinne claude-sonnet-4-6, falls du einen Grund hast), aber nicht mehr die On-Ramp.

Die vier Prompting-Muster, die die meisten Teams neu tunen​

1. Verbosität kalibriert sich zur Task-Komplexität​

Sonnet 5 wählt Antwortlänge basierend auf der Task-Komplexität, statt auf eine feste Verbosität zu defaulten. Einfache Lookups bekommen kürzere Antworten; offene Analyse bekommt längere. Willst du in deinem Produkt einen konsistenten Stil, tune den Prompt — Anthropics eigener Snippet funktioniert:

Zähme Verbosität, wenn du eine feste Stimme brauchst

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

Positive Beispiele ("so formulierst du das prägnant") funktionieren besser als negative ("nicht überklären").

2. Tool-Use-Triggering ist agentischer — und lässt sich dialen​

Sonnet 5 greift bereitwilliger zu Tools als 4.6. Zwei Hebel:

  • Effort. high oder xhigh zeigen substanziell mehr Tool-Nutzung in Agentic-Search- und Coding-Workloads. low und medium scopen die Arbeit eng.
  • Denken aus. Mit thinking: {type: "disabled"} greift das Modell weniger wahrscheinlich zu Tools. Deaktivierst du Denken, verlässt dich aber weiter auf Tool-Aufrufe, füge einen expliziten Nudge im System-Prompt hinzu.

3. Code-Review-Harnesses können Recall-Drop sehen — das ist das Modell, das wörtlicher ist​

Sagt dein Review-Prompt "nur High-Severity-Issues melden" oder "nicht nitpicken", kann Sonnet 5 das treu befolgen — genauso gründlich untersuchen, dieselben Bugs finden, dann Funde nicht melden, die es unter deiner erklärten Schwelle beurteilt. Präzision steigt typischerweise, Recall kann scheinbar fallen. Anthropics empfohlener Fix trennt Find-Phase von Ranking-Phase:

Recall-orientierter Code-Review-Prompt für Sonnet 5

Report every issue you find, including ones you are uncertain about or consider low-severity.
Do not filter for importance or confidence at this stage - a separate verification step will do that.
Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug.
For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

Du musst den zweiten Schritt gar nicht bauen, damit der Prompt hilft — das Verschieben des Confidence-Filterns aus der Find-Phase heraus ändert das Verhalten.

4. Design-Defaults setzen sich zu einem "Haus-Stil" — überschreib ihn explizit​

Auf offenen Frontend- und Design-Briefings tendiert Sonnet 5 zu einem konsistenten Default-Visual-Style. Das liest sich gut für manche Produkte, falsch für Dashboards, Dev-Tools, Fintech, Healthcare oder Enterprise-Apps. Generisches Zurückschieben ("mach es weniger generisch") verschiebt das Modell tendenziell zu einem anderen festen Stil, statt Vielfalt zu erzeugen. Zwei Muster, die funktionieren:

  • Spezifiziere eine konkrete Alternative — Hex-Codes, Typeface-Namen, Layout-Regeln. Sonnet 5 folgt expliziten Specs präzise.
  • Bitte das Modell, N Optionen vor dem Bauen vorzuschlagen. Da nicht-default temperature 400 zurückgibt, ist das jetzt der empfohlene Weg, um bedeutungsvoll unterschiedliche Design-Richtungen über Runs hinweg zu erzeugen.

Erzwinge Design-Vielfalt ohne temperature

Before building, propose 4 distinct visual directions tailored to this brief
(each as: bg hex / accent hex / typeface, plus a one-line rationale).
Ask the user to pick one, then implement only that direction.

Cybersecurity-Safeguards: Refusals als HTTP 200​

Sonnet 5 ist das erste Sonnet-Tier-Modell mit echtzeit-Cybersecurity-Safeguards. Wird ein Request abgelehnt, kommt es als erfolgreicher HTTP 200 mit stop_reason: "refusal" zurück — kein Fehler. Hast du keinen Refusal-Handling-Zweig gebaut, wird deine App die leere Response als erfolgreiche leere Antwort behandeln und still an den Nutzer ausliefern.

Der Fix ist ein Zweig auf der Response:

Refusals sauber behandeln

resp = client.messages.create(model="claude-sonnet-5", messages=[...])
if resp.stop_reason == "refusal":
  # Show a graceful message. Optionally retry on a fallback model
  # (Opus 4.8 is a common choice). You are NOT billed for a refusal
  # returned before any output was generated.
  return handle_refusal(resp)
# Otherwise process resp.content as normal

Das ist dieselbe Form wie Fable 5s In-Band-Refusals — bearbeitest du die schon, bist du abgedeckt. Bist du neu darin, siehe den Fable 5 Feldführer für das vollere Muster inklusive des fallbacks-Parameters.

Priority Tier ist nicht verfügbar — plane drumherum​

Jedes andere aktuelle Anthropic-Modell unterstützt Priority Tier für reservierte Kapazität und vorhersagbare Latenz. Sonnet 5 tut das nicht. Hast du eine Enterprise-Workload, die heute von Priority-Tier-Zusagen abhängt, sind deine Optionen:

  • Halte die Workload auf Sonnet 4.6 (weiter supported, weiter auf Priority Tier).
  • Migriere die Workload auf Opus 4.8, das auf Priority Tier ist und das Modell, gegen das Sonnet 5 für harte Tasks sowieso verglichen wird.
  • Wechsle auf Standard-Tier auf Sonnet 5 und akzeptiere unreservierte Kapazität.

Es gibt keinen Beta-Header-Workaround. Ist Priority Tier für dich load-bearing, ist das der Migrationsblocker, um den du zuerst planen musst.

Sonnet 5 vs. Sonnet 4.6 vs. Opus 4.8 — die Wahl​

WahlNimm es, wenn
Sonnet 5Default für alles Neue. Coding, Agentic-Tasks, 1M Kontext und Preissensitivität zeigen alle hierhin.
Sonnet 4.6Du brauchst Priority Tier, hast Prompts, die auf nicht-default Sampling-Parameter angewiesen sind, die du noch nicht umschreiben kannst, oder du bist mitten in einem Eval und willst eine stabile Baseline.
Opus 4.8Reasoning-Tiefe oder Long-Run-Stabilität, die Sonnet 5 nicht erreicht, oder du brauchst Priority Tier am oberen Ende. Paare mit einem Effort-Override — xhigh auf Opus 4.8 ist ein gängiger Sweet Spot.
Fable 5 / Mythos 5Du hast validiert, dass Opus 4.8 nicht reicht, und bist bereit, 5× Sonnet 5 Output-Preis für mehrtägige autonome Runs zu zahlen. Siehe den Fable 5 Feldführer.

Migrations-Checkliste​

Guided walkthrough1 of 6
  1. Nutze die Token-Counting-API mit model="claude-sonnet-5" für jeden Prompt, dessen Länge zählt. Überall wo du gegen ein festes 1M-Token-Budget vergleichst, gehe von ~30% mehr Verbrauch aus. Überall wo max_tokens knapp ist, erhöhe.

Schnellcheck​

Check yourself

0/5
  1. Dein bestehender Sonnet-4.6-Code setzt temperature: 0.7 und thinking: {type: "enabled", budget_tokens: 8000}. Du tauschst das Modell auf claude-sonnet-5. Was passiert?
  2. Du hast einen System-Prompt bei 40.000 Tokens auf Sonnet 4.6 gemessen. Wie viele Tokens sollte derselbe Text auf Sonnet 5 grob zählen?
  3. Du hast eine Enterprise-Workload auf Sonnet 4.6 mit einer Priority-Tier-Zusage. Du willst zu Sonnet 5 migrieren. Was ist der Blocker?
  4. Laut Anthropics Cross-Modell-Effort-Mapping ist Sonnet 5 auf effort=medium grob vergleichbar in Intelligenz mit welcher Sonnet-4.6-Einstellung?
  5. Dein Sonnet-5-Request gibt eine HTTP-200-Response mit content: [] und stop_reason: "refusal" zurück. Was ist NICHT passiert?

Quellen & weiterführende Lektüre​