claude-regelwerk/AI/Regelwerk/sonnet-5.md

---
type: resource
status: reference
title: Prompting-Hinweise für Claude Sonnet 5
summary: Verhaltensunterschiede und Prompt-Muster von Claude Sonnet 5 (Teil A) sowie Spezifikation, API-Brüche, Tokenizer, Cyber-Schutz, ZDR-Fähigkeit (Teil B) aus der Anthropic-Doku. Betrifft den Executer und die Recherche-Agenten.
tags: [regelwerk, modelle, sonnet, prompting]
created: 2026-09-05
updated: 2026-09-05
source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5
---

# Prompting-Hinweise für Claude Sonnet 5

> **Geltungsbereich.** Diese Datei beschreibt, wie sich **Claude Sonnet 5** verhält und wie man Aufträge an es formuliert. Im Vault läuft Sonnet 5 als `executer` und als Recherche-Agent (`Explore`, `general-purpose`). Zwei Leser: (1) **Fable 5.1**, wenn es als Koordinator einen Auftrag an einen Sonnet-Subagenten schreibt — dann ist das hier verbindlich für die Formulierung. (2) **Sonnet 5 selbst** — es arbeitet nach seinen eigenen Optimierungen und entscheidet selbst, ob es einen Punkt übernimmt. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]]) bleibt unverändert.
> Angeordnet am 2026-09-05. Quellen: „Prompting Claude Sonnet 5" (Teil A), „What's new in Claude Sonnet 5" (Teil B) und der Migrationsleitfaden (Teil C), alle abgerufen am 2026-09-05. Aussagen stammen aus der Doku, nicht aus eigener Messung.

## Wozu diese Datei

Sonnet 5 läuft laut Doku auf bestehenden Sonnet-4.6-Prompts gut. Der für uns wichtigste Satz steht in Abschnitt 5: **Sonnet 5 nimmt Anweisungen wörtlich und verallgemeinert nicht still.** Das ist genau die Eigenschaft, auf die die Standardschleife baut — ein Executer, der nur tut, was der Plan sagt —, und zugleich der Grund, warum ein Plan mit Lücke bei Sonnet 5 nicht „irgendwie" gefüllt wird, sondern liegen bleibt.

## 1 Antwortlänge

Sonnet 5 richtet die Länge nach der Komplexität der Aufgabe: kurz bei einfachen Nachschlagefragen, länger bei offener Analyse. Wer eine bestimmte Länge braucht, sagt es. Zum Kürzen:

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

Bei bestimmten Arten von Weitschweifigkeit (Über-Erklären) gezielt dagegen anweisen. **Positive Beispiele der gewünschten Knappheit wirken besser als Verbote.**

## 2 Effort und Thinking-Tiefe

Effort ist bei Sonnet 5 standardmäßig `high`, wie bei Sonnet 4.6. Die Stufen laut Doku: `max` ohne Tokengrenze; `xhigh` empfohlen für die schwersten Coding- und Agentenaufgaben; `high` als Standard; `medium` für kostenempfindliche Fälle mit Intelligenzabstrich; `low` nur für kurze, eng umrissene, latenzkritische Aufgaben, die keine Intelligenz brauchen.

Grobe Zuordnung beim Umstieg: **Sonnet 5 bei `medium` entspricht etwa Sonnet 4.6 bei `high`; Sonnet 5 bei `high` etwa Sonnet 4.6 bei `max`.** Beim Benchmarken nach beobachteter Thinking-Länge abgleichen, nicht nach Stufennamen.

**Sonnet 5 hält Effort-Stufen strikt ein, besonders unten.** Bei `low` und `medium` beschränkt es sich auf das Verlangte und geht nicht darüber hinaus — gut für Latenz und Kosten, bei mäßig komplexen Aufgaben auf `low` aber ein Risiko für Unterdenken. Zeigt sich flaches Schließen bei komplexen Problemen: **Effort erhöhen statt drumherum prompten.** Muss `low` bleiben:

```text
This task involves multistep reasoning. Think carefully through the problem before responding.
```

**Adaptives Thinking ist an**, wenn das `thinking`-Feld fehlt — bei Sonnet 4.6 lief dieselbe Anfrage ohne Thinking. Ganz aus: `thinking: {type: "disabled"}`. `max_tokens` ist eine harte Grenze für Thinking plus Antwort — für Arbeiten, die bei 4.6 ohne Thinking liefen, neu bemessen. Wer bei 4.6 ohne Thinking arbeitete, probiert bei Sonnet 5 Thinking an mit niedrigem Effort. Zu häufige Thinking-Blöcke (bei großen System-Prompts) lassen sich steuern:

```text
Thinking adds latency and should only be used when it will meaningfully improve answer quality, typically for problems that require multistep reasoning. When in doubt, respond directly.
```

Manuelles Extended Thinking mit `budget_tokens` liefert 400 — war bei 4.6 abgekündigt, ist jetzt entfernt.

**Kopfraum in `max_tokens`.** Bei `high`, `xhigh` oder `max` kann adaptives Thinking auf langen Aufgaben einen großen Teil des Budgets belegen; bei knappem Budget kommt eine Antwort, die fast nur aus Thinking besteht, mit abgeschnittenem Text und `stop_reason: "max_tokens"`. Abhilfe: `max_tokens` erhöhen oder auf `medium`. Dazu der **neue Tokenizer: rund 30 Prozent mehr Tokens für denselben Text** — `max_tokens`-Werte von Sonnet 4.6 schneiden gleichwertige Ausgaben ab.

## 3 Werkzeugauslösung

Sonnet 5 ist von sich aus agentischer als 4.6: greift bereitwilliger zu Werkzeugen und fährt Selbstprüfschleifen. **Mit Thinking aus** greift es seltener zu Werkzeugen und erwägt seltener eine Suche — wer Werkzeugaufrufe ohne Thinking braucht, ergänzt einen ausdrücklichen Hinweis im System-Prompt. Effort ist auch hier ein Hebel: `high` und `xhigh` zeigen deutlich mehr Werkzeugnutzung bei Suche und Codieren. Wird ein Werkzeug nicht genutzt (etwa Websuche), beschreiben, warum und wie es eingesetzt werden soll.

## 4 Fortschrittsmeldungen

Sonnet 5 liefert von sich aus regelmäßige, bessere Updates über lange agentische Abläufe. Gerüst, das Zwischenmeldungen erzwingt („After every 3 tool calls, summarize progress"), **entfernen**. Passt Länge oder Inhalt nicht, beschreiben, wie Updates aussehen sollen, mit Beispielen.

## 5 Wörtliches Befolgen

**Sonnet 5 interpretiert Prompts wörtlich und ausdrücklich, besonders bei niedrigem Effort.** Es verallgemeinert eine Anweisung nicht still von einem Element aufs nächste und erschließt keine Bitten, die nicht gestellt wurden. Der Gewinn ist Präzision — es arbeitet laut Doku besser bei sorgfältig abgestimmten Prompts, strukturierter Extraktion und Pipelines mit vorhersagbarem Verhalten. **Soll eine Anweisung breit gelten, den Geltungsbereich ausdrücklich nennen:** „Apply this formatting to every section, not just the first one."

Für den Vault ist das die Doku-Bestätigung zweier Regeln des Codeworkflows: Der Plan nennt Zieldateien, Verbote und Verifikationsbefehl **je Task** und verlässt sich nicht darauf, dass der Executer eine Vorgabe aus Task 1 auf Task 3 überträgt. Und wo ein Plan eine Lücke lässt, meldet Sonnet 5 sie eher, als sie zu füllen — das ist gewollt und im Executer-Prompt als „Blockade statt Raten" verankert.

## 6 Ton und Schreibstil

Prosa-Stil bei langen Texten kann sich verschieben; Stil-Prompts gegen die neue Grundlinie neu bewerten. Für einen wärmeren Ton:

```text
Use a warm, collaborative tone. Acknowledge the user's framing before answering.
```

**`temperature`, `top_p`, `top_k` abseits der Standardwerte liefern 400** — neu für die Sonnet-Klasse. Wer darüber stilistische Vielfalt erzeugt hat, entfernt die Parameter und steuert Ton und Varianz über den System-Prompt.

## 7 Design- und Frontend-Voreinstellungen

Sonnet 5 fällt bei offenen Design-Briefings in einen festen Hausstil, der für Dashboards, Dev-Tools, Fintech, Gesundheit oder Enterprise-Apps unpassend wirken kann. Allgemeine Anweisungen („nicht diese Farbe", „clean und minimal") verschieben nur zur nächsten festen Palette. Zwei Wege, die laut Doku verlässlich funktionieren:

1. **Konkrete Alternative vorgeben.** Das Modell folgt expliziten Spezifikationen präzise — Farbtöne als Hex-Werte, Eckenradius, Schriftcharakter, Abschnittsfolge, Hover-Verhalten. Die Doku zeigt als Beispiel ein vollständiges Briefing für eine Landingpage in kaltem Monochrom mit fünf genannten Hex-Werten.
2. **Optionen vorschlagen lassen, bevor gebaut wird.** Weil `temperature` nicht mehr geht, ist das der empfohlene Weg zu wirklich verschiedenen Richtungen:

```text
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.
```

Gegen den generischen „AI slop"-Look ein kurzer Block im System-Prompt; die vollständige Fassung ist der Frontend-Design-Skill im Claude-Code-Repo:

```text
<frontend_aesthetics>
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white or dark backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character. Use unique fonts, cohesive colors and themes, and animations for effects and micro-interactions.
</frontend_aesthetics>
```

## 8 Interaktive Coding-Produkte

Tokenverbrauch und Verhalten unterscheiden sich zwischen autonomen Agenten mit einer Nutzerrunde und interaktiven mit vielen. Für Leistung und Effizienz: `xhigh` oder `high`, autonome Modi anbieten, Rückfragen an den Nutzer reduzieren. **Aufgabe, Absicht und Randbedingungen vorab in der ersten Nutzerrunde vollständig angeben** — das maximiert Autonomie und Intelligenz und minimiert Tokens nach jeder Nutzerrunde. Unterbestimmte Prompts, die sich über mehrere Runden nachschieben, kosten Effizienz und manchmal Leistung. Das ist die Doku-Fassung von Schritt 1 der Standardschleife: klären *vor* dem Plan, nicht mittendrin.

## 9 Code-Review-Harnesses

War ein Review-Harness auf ein älteres Modell abgestimmt, kann die **Trefferquote bei Sonnet 5 zunächst sinken — ein Harness-Effekt, keine Fähigkeitsregression.** Sagt der Prompt „only report high-severity issues", „be conservative" oder „don't nitpick", befolgt Sonnet 5 das treuer als Vorgänger: gleiche Untersuchungstiefe, aber weniger gemeldete Funde, besonders bei geringer Schwere. Präzision steigt, gemessene Trefferquote fällt. Empfohlene Formulierung:

```text
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.
```

Der Block funktioniert auch ohne echten zweiten Schritt. Gibt es eine getrennte Verifikations-, Dedup- oder Ranking-Stufe, dem Modell sagen, dass seine Aufgabe in der Fundstufe Abdeckung ist, nicht Filterung. Wer in einem Durchgang filtern will, benennt die Schwelle konkret: „report any bugs that could cause incorrect behavior, a test failure, or a misleading result; only omit nits like pure style or naming preferences." Gegen eine Teilmenge der Evals auf Trefferquote oder F1 prüfen.

Derselbe Punkt steht für Opus 5 in [[AI/Regelwerk/opus-5|opus-5.md]], Abschnitt 8 — die Regel für `pruefer`-Aufträge ist dort festgehalten und gilt für beide Modelle.

## 10 Computer Use

Sonnet 5 unterstützt das Toolset `computer_toolset_20260801` (Claude API und Google Cloud) und die ältere Toolversion `computer_20251124`, dazu auf Claude API und Google Cloud das Browser-Use-Tool `browser_toolset_20260801`. Auflösung bis 2576 px / 3,75 MP; laut interner Messung ist **1080p** der gute Kompromiss aus Leistung und Kosten, für kostenempfindliche Arbeiten 720p oder 1366×768. Eigene Tests fahren; Effort mitvariieren.

---

# Teil B — Was sich an Modell und API geändert hat

Aus der Anthropic-Seite „What's new in Claude Sonnet 5", abgerufen am 2026-09-05. Teil A ist das Verhalten; das hier sind Spezifikation, Brüche, Tokenizer, Preise und Verfügbarkeit.

## B1 Einordnung und Spezifikation

Sonnet 5 ist laut Anthropic ein Drop-in-Ersatz für Sonnet 4.6 mit drei Verhaltensänderungen und einem neuen Tokenizer. Es ist die Option für Arbeiten, die mehr brauchen als Sonnet 4.6, ohne auf ein Opus-Modell zu wechseln. Die größten Gewinne liegen bei Coding und agentischen Aufgaben; Benchmarks stehen im Transparency Hub, nicht auf der Seite.

| | Sonnet 5 |
|---|---|
| API-ID | `claude-sonnet-5` |
| Kontextfenster | 1M Tokens (Standard und Maximum, keine kleinere Variante) |
| Maximale Ausgabe | 128k Tokens |
| Thinking | adaptiv, standardmäßig an; abschaltbar mit `disabled` |
| Priority Tier | nicht unterstützt |
| Preis | 2 $ Eingabe, 10 $ Ausgabe je Million Tokens (Sonnet 4.6: 3 $ / 15 $) |
| Werkzeuge | wie Sonnet 4.6, zusätzlich Browser-Use-Tool und `computer_toolset_20260801` (Claude API und Google Cloud) |

## B2 Drei Brüche gegenüber Sonnet 4.6 (API-Integrationen)

- **Adaptives Thinking standardmäßig an.** Eine Anfrage ohne `thinking`-Feld lief bei 4.6 ohne Thinking, bei Sonnet 5 mit. Aus: `thinking: {type: "disabled"}`. `max_tokens` ist harte Grenze für Thinking plus Antwort — für Arbeiten, die ohne Thinking liefen, neu bemessen.
- **Sampling-Parameter nicht mehr akzeptiert.** `temperature`, `top_p`, `top_k` abseits des Standards liefern 400. Entfernen; Verhalten über den System-Prompt steuern. Neu für die Sonnet-Klasse, bei Opus seit 4.7.
- **Manuelles Extended Thinking entfernt.** `thinking: {type: "enabled", budget_tokens: N}` liefert 400 — bei 4.6 abgekündigt, jetzt weg, wie bei Opus 4.7 und 4.8. Stattdessen `{type: "adaptive"}` und `effort`.

Unverändert aus 4.6: Prefill des Assistant-Turns liefert 400 — Structured Outputs, System-Prompt oder `output_config.format` nutzen.

## B3 Neuer Tokenizer

Derselbe Text erzeugt **rund 30 Prozent mehr Tokens** als bei Sonnet 4.6; der genaue Wert hängt vom Inhalt ab. Keine API-Änderung — Anfragen, Antworten und Streaming behalten ihre Form. Betroffen ist alles, was in Tokens gemessen oder budgetiert wird:

- `usage`-Felder und Token-Zählung sind höher — nicht die Zahlen älterer Modelle wiederverwenden, gegen Sonnet 5 neu zählen.
- Das 1M-Fenster fasst **weniger Text** als bei 4.6, weil jeder Token weniger Text deckt.
- `max_tokens`-Grenzen, die nah an der erwarteten Ausgabelänge liegen, schneiden ab.
- **Die Kosten je Anfrage sinken nicht im Verhältnis der Tokenpreise.** 2 $ statt 3 $ je Million Eingabetokens bei 30 Prozent mehr Tokens ergibt für denselben Text keine Ersparnis von einem Drittel. Wer die Ersparnis der Rollentabelle auf Sonnet 5 nachrechnet, rechnet mit Text, nicht mit Tokens.

## B4 Cybersecurity-Schutzmechanismen

**Sonnet 5 ist das erste Sonnet-Modell mit Echtzeit-Cybersecurity-Schutz.** Anfragen zu verbotenen oder hochriskanten Sicherheitsthemen können abgelehnt werden; die Ablehnung kommt als HTTP 200 mit `stop_reason: "refusal"`, nicht als Fehler. Für legitime Sicherheitsarbeit gibt es laut Doku ein „Cyber Verification Program".

**Für den Vault ist das der wichtigste Satz dieses Teils.** Die Security-Compliance-Projekte, das Kickstart-Härtungsprojekt und die After-Install-Skripte lassen Sonnet als Executer laufen. Bekommt ein Executer-Auftrag zu Härtung, Scanning oder Angriffslisten (etwa die Angriffsliste aus [[AI/Regelwerk/pruefwerkzeuge|pruefwerkzeuge.md]]) eine Ablehnung, ist das kein Executer-Fehler und keine Planlücke, sondern dieser Schutzmechanismus. Dann: Auftrag im Bericht als abgelehnt führen, nicht umformulieren, bis es durchgeht, und Pascal entscheiden lassen — der Sicherheitskontext (Kundenauftrag, eigene Systeme) gehört in den Auftrag, nicht in einen Umgehungsversuch.

**Was der Support-Artikel „Real-time cyber safeguards on Claude Opus and Sonnet" dazu sagt** (abgerufen am 2026-09-05; der Abruf lieferte eine Zusammenfassung, keinen Volltext — Wortlaut der Listen also nicht belegt). Das ist die eine Stelle im Regelwerk für diesen Mechanismus; Opus 5 hat ihn seit Opus 4.7 ebenfalls ([[AI/Regelwerk/opus-5|opus-5.md]] C4), und die Regeln hier gelten für beide.

Zwei Kategorien von Blockaden:

- **Verbotene Nutzung — immer blockiert.** Tätigkeiten mit kaum legitimer Anwendung; der Artikel nennt Massen-Datenexfiltration und Ransomware-Entwicklung. Keine Freischaltung hebt das auf.
- **Hochriskante Doppelverwendung — standardmäßig blockiert.** Aufgaben mit defensiver Anwendung; genannt sind Schwachstellentests und die Entwicklung von Sicherheitswerkzeugen. Das ist die Kategorie, in die unsere Härtungs- und Prüfarbeit fallen kann.

**Cyber Verification Program (CVP).** Kostenloses Programm für legitime Sicherheitsfachleute; die Freischaltung hebt nur die Doppelverwendungs-Blockaden auf, nie die verbotene Kategorie. Identitätsprüfung ist Pflicht, Entscheidung laut Artikel meist innerhalb von zwei Werktagen, die Freigabe hängt an konkreten Organisations-IDs. Bewerbungsweg je Zugangsart: Claude.ai, API und Claude Code über das Verification Portal; Microsoft Foundry über das Cyber Use Case Form mit Azure-Zugang; Claude Platform on AWS durch Verknüpfen des AWS-Kontos im Portal; **Amazon Bedrock und Google Vertex: derzeit kein CVP.** Fehlanwendungen einer Blockade lassen sich über ein eigenes Formular anfechten.

**Die Einschränkung, die für uns zählt: Organisationen mit Zero Data Retention sind für das CVP nicht berechtigt.** Das trifft genau die Kombination, die ein Sicherheitsdienstleister mit ZDR-Kunden hat — Sonnet 5 und Opus 5 sind ZDR-fähig (B5), aber unter ZDR gibt es keine Freischaltung für Doppelverwendungs-Aufgaben. Wer beides braucht, muss es trennen: ZDR-Workspace für Kundendaten, Nicht-ZDR-Workspace mit CVP für Sicherheitsarbeit. Das ist eine Entscheidung von Pascal, nicht des Agenten.

## B5 Verfügbarkeit und Datenhaltung

Claude API, Amazon Bedrock (auch über `InvokeModel`; die Legacy-Integration für Opus 4.6 und älter führt es nicht), Claude Platform on AWS, Google Cloud, Microsoft Foundry.

**Sonnet 5 unterstützt Zero Data Retention** für Organisationen mit ZDR-Vereinbarung — anders als Fable 5.1 (30 Tage, kein ZDR ohne Genehmigung). Opus 5 ist laut Fable-5.1-Migrationsleitfaden ebenfalls unter ZDR verfügbar. In einem Kundenprojekt mit ZDR-Zusage sind damit Sonnet 5 und Opus 5 die Modelle, die ohne Rückfrage bei Anthropic gehen — die ganze Rollentabelle außer Fable.

## B6 Umstieg von Sonnet 4.6

Modell-ID auf `claude-sonnet-5`, dann drei Punkte: (1) Tokenbudgets und -zählungen neu messen, `max_tokens` nachziehen. (2) `budget_tokens` auf adaptives Thinking umstellen. (3) Sampling-Parameter entfernen. Werkzeugdefinitionen und Antwortformen sind unverändert. Was der Migrationsleitfaden darüber hinaus sagt, auch für Sonnet 4.5, Claude 3.x und Haiku 4.5: Teil C unten.

---

# Teil C — Migrationsleitfaden

Aus „Migrating to Claude Sonnet 5", abgerufen am 2026-09-05. Abschnitte je Ausgangsmodell: Sonnet 4.6, Sonnet 4.5 und älter, Claude 3.x, **Haiku 4.5**. Hier nur, was über Teil B hinausgeht. In Claude Code gibt es `/claude-api migrate this project to claude-sonnet-5`; für den Skill gilt dasselbe wie in [[AI/Regelwerk/fable-5-1|fable-5-1.md]] C1.

## C1 Von Sonnet 4.6 — Ergänzungen

- **`thinking.display` hat den Standard gewechselt: `summarized` bei 4.6, `omitted` bei Sonnet 5.** Wer bei 4.6 Thinking anzeigte, bekommt jetzt leere `thinking`-Felder — `display: "summarized"` explizit setzen. Eine stille Änderung, die nicht als Fehler auffällt.
- Inhaltsblöcke nach `type` auswählen, nicht `content[0].text`; Thinking-Blöcke in Tool-Schleifen unverändert zurückgeben, auch leere — bearbeitete liefern 400.
- Thinking-Tokens werden als Ausgabe berechnet, auch wenn der Text nicht zurückkommt. Kosten vor Produktivbetrieb neu messen.
- `max_tokens` bis 128k anheben, wo sinnvoll — unverändert gegenüber 4.6, aber mit dem neuen Tokenizer bemessen.
- `stop_reason: "refusal"` behandeln, wenn die Arbeit Cyber-Themen berühren kann.

## C2 Von Sonnet 4.5 und älter

- **Effort-Standard `high` — bei 4.5 gab es keinen Effort-Parameter.** Wer nichts setzt, sieht höhere Latenz als gewohnt.
- **Prefill entfernt** (seit 4.6, 400). Ersatz je Zweck wie in [[AI/Regelwerk/prompting|prompting.md]] Abschnitt 2.
- **JSON-Escaping in Werkzeugargumenten kann abweichen.** Standard-Parser kommen damit klar; eigene String-Parser brauchen Prüfung.
- Wer 4.5 ohne Extended Thinking fuhr und das behalten will: `thinking: {type: "disabled"}`.

Von Claude 3.x zusätzlich: Sampling-Parameter entfernen; Werkzeugversionen `text_editor_20250728` und `code_execution_20260521`, `undo_edit` entfernen; `refusal` behandeln; Prompts an den knapperen, direkteren Stil der 4er-Modelle anpassen.

## C3 Von Haiku 4.5 — für den Vault der wichtigste Abschnitt

Haiku 4.5 ist unser Modell für reine Abschrift-Tasks ([[AI/Regelwerk/codeworkflow|codeworkflow.md]], Schritt 3). Der Leitfaden benennt, wie weit Haiku 4.5 und Sonnet 5 auf API-Ebene auseinanderliegen — weiter als benachbarte Modelle einer Klasse:

| | Haiku 4.5 | Sonnet 5 |
|---|---|---|
| Thinking | manuelles Extended Thinking, standardmäßig aus; `adaptive` wird abgelehnt | adaptiv, standardmäßig an; `budget_tokens` → 400 |
| Effort | nicht verfügbar | Standard `high` |
| Kontext / Ausgabe | 200k / 64k | 1M / 128k |
| Sampling | `temperature` **oder** `top_p` (nicht beide) | keine, 400 |
| Prefill | funktioniert | 400 |
| Preis | 1 $ / 5 $ | 2 $ / 10 $ |
| Tokenizer | älter | neu, Tokens neu zählen |
| Cyber-Schutz | — | ja |

Was das für uns heißt: Ein Executer-Auftrag, der für Haiku geschrieben ist, läuft in Claude Code auf Sonnet ohne Änderung — das Harness abstrahiert die API. **Ein eigener Harness in einem Code-Projekt, der zwischen Haiku 4.5 und Sonnet 5 umschaltet, muss die Thinking-Konfiguration je Modell setzen**, weil jedes die des anderen mit 400 ablehnt. `budget_tokens` hat auf Sonnet 5 keinen direkten Ersatz; `effort` gibt es auf Haiku 4.5 nicht. Und 64k Ausgabe bei Haiku heißt: ein Task, dessen Abschrift länger ist, bricht dort ab, wo er auf Sonnet durchliefe.

## Wohin die Punkte im Regelwerk zeigen

| Regelwerk-Datei | Verweist auf Abschnitt |
|---|---|
| [[CLAUDE|Claude.md]] (Stamm, Regelwerk-Liste) | Gesamtdatei |
| [[AI/Regelwerk/codeworkflow|codeworkflow.md]] (Rollen und Subagenten) | 2, 5 |
| `.claude/agents/executer.md` | 5 |

## Referenzen

- [[CLAUDE|↑ Claude.md (Stamm)]]
- [[AI/Regelwerk/prompting|prompting.md]] — die modellübergreifenden Techniken
- [[AI/Regelwerk/fable-5-1|fable-5-1.md]] und [[AI/Regelwerk/opus-5|opus-5.md]] — die Schwestermodelle
- Anthropic-Doku Teil A: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5 (Stand 2026-09-05)
- Anthropic-Doku Teil B: https://platform.claude.com/docs/en/models/sonnet-5/whats-new-sonnet-5 (Stand 2026-09-05)
- Anthropic-Doku Teil C: https://platform.claude.com/docs/en/models/sonnet-5/migration-guide (Stand 2026-09-05)
- Support-Artikel: https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude-opus-and-sonnet (Stand 2026-09-05, nur als Zusammenfassung abgerufen)
- [[AI/Regelwerk/api-mechanik|api-mechanik.md]] — Effort je Modell; Task Budgets gibt es auf Sonnet 5 nicht
- Nicht abgerufen: Transparency Hub, „Migrate from computer_20251124".