claude-regelwerk/AI/Regelwerk/fable-5-1.md

---
type: resource
status: reference
title: Prompting-Hinweise für Claude Fable 5.1
summary: Verhaltensunterschiede und Prompt-Muster von Claude Fable 5.1 (Teil A) sowie Spezifikation, API-Brüche, neue Funktionen, Preise und Datenhaltung (Teil B) aus der Anthropic-Doku — gilt nur, wenn Fable 5.1 das Modell ist; andere Modelle entscheiden selbst.
tags: [regelwerk, modelle, fable, prompting]
created: 2026-09-05
updated: 2026-10-09
source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1
---

# Prompting-Hinweise für Claude Fable 5.1

> **Geltungsbereich — bitte zuerst lesen.**
> Diese Datei gilt **nur für Claude Fable 5.1** (und das baugleiche Claude Mythos 5.1). Läufst du als Fable 5.1, berücksichtigst du die Punkte unten als Teil deiner Arbeitsweise.
> Läufst du als **Opus 5, Opus 5.5, Sonnet 5, Sonnet 5.5, Haiku 4.5 oder Haiku 5.5** (Haiku 5.5: [[AI/Regelwerk/haiku-5-5|haiku-5-5.md]]), dann sind das keine Anweisungen an dich. Diese Modelle arbeiten nach ihren eigenen Optimierungen und entscheiden selbst, ob sie einen Punkt übernehmen. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]], „Agenten & Modelle") bleibt unverändert.
> Angeordnet am 2026-09-05. Quellen: Anthropic-Doku „Prompting Claude Fable 5.1" (Teil A), „What's new in Claude Fable 5.1" (Teil B) und der Migrationsleitfaden (Teil C), alle abgerufen am 2026-09-05. Die Aussagen stammen aus diesen Seiten, nicht aus eigener Messung — wo die Doku eine Bedingung nennt, steht sie hier mit. Die modellübergreifenden Techniken stehen in [[AI/Regelwerk/prompting|prompting.md]].

## Wozu diese Datei

Fable 5.1 verhält sich an einigen Stellen anders als Fable 5 und als die Opus/Sonnet-Modelle, auf die der Rest des Regelwerks zugeschnitten ist. Die meisten Unterschiede sind im Alltag harmlos. Ein paar kosten still Tokens, Zeit oder Präzision, wenn niemand sie kennt. Die Doku ordnet sie nach dem Symptom, das man beobachtet — diese Reihenfolge ist übernommen, damit du beim Auftreten eines Symptoms direkt den passenden Abschnitt findest.

| Beobachtung | Abschnitt |
|---|---|
| Unklar, welche Effort-Stufe passt; Latenz oder Kosten höher als die Aufgabe rechtfertigt | 1 |
| Wenig oder kein Text zwischen Werkzeugaufrufen | 2 |
| Ein Werkzeugaufruf pro Runde in Agentenschleifen | 3 |
| Fehler `bound to a different conversation`; Harness ändert frühere Runden | 4 |
| Prosa lang und dicht | 5 |
| Chat-Antworten weniger strukturiert, als der Inhalt braucht | 6 |
| Zusammenfassungen übernehmen Quellwortlaut ohne Zitatkennzeichnung | 7 |
| Runde endet vor Abschluss; Modell fragt um Erlaubnis für schon beauftragte Arbeit | 8 |
| Client-seitige Kompaktierung verliert Vorgaben, Entscheidungen, exakte Details | 9 |
| Ungefragte Korrekturen oder Erweiterungen; mehr Testdateien als nötig | 10 |
| Antwort aus dem Gedächtnis statt Suche bei niedrigem Effort | 11 |
| Harmlose Code-Anfragen enden mit `stop_reason: "refusal"` | 12 |
| Ganze Dateien für kleine Änderungen neu geschrieben | 13 |
| Lange Ergebnisse bei `xhigh`/`max` dauern lange oder laufen in `max_tokens` | 14 |
| Leitagent wartet untätig, während Subagenten laufen | 15 |
| Antworten zu Diagrammen und dichten Bildern verfehlen Details | 16 |

Zwei Sorten von Punkten sind hier gemischt, und das ist Absicht: Manche greifen **direkt in dieser Claude-Code-Sitzung** (2, 3, 5, 6, 7, 8, 10, 11, 13, 15). Andere gelten erst, **wenn wir selbst eine Integration gegen die Claude-API bauen** — ein eigener Agent, ein Harness, ein Tool in einem Code-Projekt (1, 4, 9, 12, 14, 16). Bei jedem Abschnitt steht dabei, welche Sorte er ist.

## 1 Alle Effort-Stufen prüfen (API-Integrationen)

Effort ist bei Fable 5.1 der Hauptregler zwischen Intelligenz, Latenz und Kosten. Die Doku empfiehlt: mit der Vorgabe `high` starten, dann `low`, `medium`, `xhigh` und `max` gegen eigene Evals messen. Ein Sweep von Fable 5 lässt sich nicht übertragen, weil die Stufennamen über Modelle hinweg nicht dieselbe Denkmenge bedeuten.

Was die Doku dazu behauptet, ohne dass wir es nachgemessen hätten: Bei `medium` entspricht das Ergebnis ungefähr Fable 5 bei geringeren Kosten. Bei `low` ist Fable 5.1 laut Doku oft konkurrenzfähig mit Opus und Sonnet beim Preis je Aufgabe und schneidet dabei besser ab. Für unsere Rollentabelle heißt das: **nichts ändern, bis wir es selbst gemessen haben.** Eine gerechnete Ersparnis ist keine gemessene — dieselbe Regel wie in [[AI/Regelwerk/codeworkflow|codeworkflow.md]].

Zwei Stufen haben Sonderverhalten: bei `low` sucht das Modell seltener (Abschnitt 11), bei `xhigh` und `max` denkt es länger vor langen Ergebnissen (Abschnitt 14).

## 2 Fortschrittsmeldungen für den Nutzer (Sitzung)

Fable 5.1 schreibt bei langen Werkzeugketten von sich aus weniger Zwischentext als Fable 5 — je höher der Effort und je länger die Kette, desto ausgeprägter. Für den Nutzer sieht das aus, als wäre der Agent minutenlang still, oder die Abschlussnachricht deckt nur den letzten Schritt ab statt die ganze Aufgabe.

Für dich als Fable 5.1 in dieser Sitzung heißt das: **Vor dem Start in einem Satz sagen, was du gleich tust. Während der Arbeit kurze Zwischenstände. Am Ende eine Zusammenfassung, die für sich steht** — was gefunden, was getan, was als Nächstes kommt —, damit jemand, der nur die letzte Nachricht sieht, das ganze Bild hat. Das ist genau die Zeile, die die Doku als System-Prompt vorschlägt:

```text
Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own — what you found, what you did, and what's next — so a reader who only sees the last message has the full picture.
```

Für eigene Integrationen zusätzlich: Die Zwischennotizen kommen als `thinking`-Blöcke vom Typ Fortschrittsmeldung zurück und sind unter der Voreinstellung `thinking.display: "omitted"` leer. Wer sie anzeigen will, setzt `display: "updates"` (Beta, Header `thinking-display-updates-2026-08-18`) oder `"summarized"`. Und: Zeilen im System-Prompt wie „hold all findings for the final response" stammen aus der Zeit, als ältere Modelle zu viel erzählt haben — bei Fable 5.1 erst solche Zeilen entfernen, dann etwas hinzufügen.

Wenn die Oberfläche Werkzeugausgaben einklappt oder verbirgt, dem Modell das sagen — sonst führt es Befehle aus, um dem Nutzer etwas zu „zeigen", das die Oberfläche nie anzeigt. Die Doku schlägt dafür eine rundenbezogene System-Nachricht vor:

```text
Only you see that command's output — the user's terminal shows at most a few lines of it. If the user needs to read any of it, put it in your reply.
```

## 3 Unabhängige Werkzeugaufrufe bündeln (Sitzung)

Wenn eine Anfrage mehrere Dinge ausdrücklich nennt, ruft Fable 5.1 sie parallel ab. Die Ausnahme sind Coding- und Computer-Use-Schleifen, in denen die nächsten unabhängigen Aufrufe nur aus der Aufgabe folgen, nicht aus der Anfrage — dort setzt es manchmal einen Aufruf pro Runde ab. Die Antwortqualität leidet nicht, aber jede zusätzliche Runde kostet Tokens, einen Roundtrip und Wartezeit.

Für dich als Fable 5.1: **Vor jedem Werkzeugblock still auflisten, was du als Nächstes brauchst, und alles, was nicht vom Ergebnis eines anderen Aufrufs abhängt, in derselben Antwort anfordern.** Die Doku-Formulierung:

```text
First privately list what you need next; then request every item that doesn't depend on another's result in this one response.
```

Für eigene Integrationen: Diese Zeile nach jeder Rückgabe von Werkzeugergebnissen als rundenbezogene System-Nachricht anhängen (`role: "system"`, `clear_at: "next_user_message"`, Beta-Header `mid-conversation-system-clear-at-2026-08-21`). Ohne Beta stattdessen als Textblock hinter die `tool_result`-Blöcke derselben Nutzernachricht. Jede Runde eine frische Kopie anhängen und **die alten Kopien byte-genau stehen lassen** — Löschen oder Umschreiben wäre eine Änderung früherer Runden und löst Abschnitt 4 aus.

## 4 Gesprächsverlauf nur anhängen, nie ändern (API-Integrationen)

Jede Assistentenrunde exakt so in den Verlauf übernehmen, wie die API sie zurückgibt, Thinking-Blöcke eingeschlossen, und frühere Runden zwischen zwei Anfragen nicht anfassen. Für Konten, die ab dem 31.08.2026 angelegt wurden, sind Thinking-Blöcke von Fable 5.1 nur in genau dem Gespräch gültig, das sie erzeugt hat: Eine Anfrage, die einen Thinking-Block nach geändertem Präfix (System-Prompt, Werkzeugliste, frühere Nachricht) erneut sendet, liefert einen 400 — oder verwirft die betroffenen Blöcke, wenn `thinking.block_binding.prefix_mismatch_behavior: "drop_block"` gesetzt ist (Beta, Header `thinking-binding-controls-2026-08-01`). Die Doku erwartet, dass künftige Modelle das für alle Konten erzwingen; das Muster also jetzt übernehmen, auch wenn unser Konto heute nicht betroffen ist.

Was den Check auslöst, ist dasselbe, was den Prompt-Cache neu startet: Erinnerungen pro Runde einfügen und wieder entfernen, ältere Runden an Ort und Stelle zusammenfassen, den System-Prompt mitten in der Sitzung ändern. Stattdessen:

- Erinnerungen pro Runde als rundenbezogene System-Nachrichten senden.
- Anweisungen oder Werkzeuge per Mid-Conversation-System-Nachricht ändern, nicht durch Umschreiben von `system` oder `tools`.
- Kürzen der serverseitigen Kompaktierung oder dem Context Editing überlassen.
- Bei Kompaktierung auf dem Client: den ganzen Verlauf durch **eine** Zusammenfassungsnachricht plus die neue Nutzerrunde ersetzen und sonst nichts erneut senden. Dann trägt kein Thinking-Block über, nichts schlägt fehl, das Modell denkt auf dem kompaktierten Gespräch neu.

Weil Cache-Lesezugriffe bei Fable 5.1 günstiger geworden sind, ist frühes Kompaktieren zum Sparen laut Doku möglicherweise nicht mehr der richtige Kompromiss — spätere Kompaktierungspunkte ausprobieren.

Um herauszufinden, welche Änderungen ein bestehender Harness heute macht: eine Sitzung mit `prefix_mismatch_behavior: "drop_block"` fahren und `input_transformations` loggen, oder die tatsächlich gesendeten Anfragen über ein paar Runden mitschneiden und prüfen, dass aufeinanderfolgende Anfragen bis auf die angehängten Runden byte-identisch sind.

## 5 Schreibdichte (Sitzung)

Fable 5.1 schreibt laut Doku insgesamt besser als frühere Modelle — weniger Floskeln, weniger unerklärter Jargon. In manchen Fällen wird die Prosa aber **dichter** als bei Fable 5: längere Sätze, weniger Absatzbrüche. Dagegen hilft eine Anweisung, die das Gegenmuster benennt: „manierierte Prosa", also Metapher und Zierde an Stelle der direkten Aussage („a dial worth turning" statt „a parameter worth varying"). Die Doku empfiehlt, sie bevorzugt in die Nutzernachricht zu setzen, sonst in den System-Prompt:

```text
Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying," the mannered writer produces "a dial worth turning." Instead of "this point still matters," they write "this point earns its keep." The phrases exist to display the writer, not to convey the idea, and readers can tell. That is why mannered prose irritates: it makes the reader work harder so the writer can perform. It is also imprecise. Metaphors drag in connotations the writer did not choose and cannot control. The fix is to say what you mean. When a literal phrase is available, use it.
```

Die Kurzform tut es laut Doku meist auch: `Please remove all mannered prose.`

Für dich als Fable 5.1 im Vault: Das deckt sich mit [[AI/Regelwerk/schreibstil|schreibstil.md]] — sag, was du meinst; wenn eine wörtliche Formulierung da ist, nimm sie. Zusätzlich gilt für dich ausdrücklich: **Liste statt Absatz, Sätze kurz halten.** Der Schreibstil verlangt Stichpunkte mit ganzer Aussage, keine Textblöcke.

## 6 Formatierung im Chat (Sitzung)

Frühere Modelle haben Aufzählungen und Fettdruck im Chat überstrapaziert, und viele Prompts enthalten deshalb Anti-Formatierungsregeln. Fable 5.1 neigt in die andere Richtung: weniger Fettdruck, seltener Überschriften, Listen oder Anführungszeichen. Steht in einem Prompt Anti-Formatierungssprache, entfernen oder durch eine Regel ersetzen, die sagt, **wann** Formatierung passt. Der Doku-Vorschlag:

```text
Use lists and bullet points when asked to, or when the content is multifaceted enough that they help with clarity. If the person explicitly requests minimal formatting, always format your responses without bullet points, headers, lists, or bold emphasis, as requested. In conversational, personal, or emotional exchanges, keep to plain prose.
```

Für dich als Fable 5.1: Wenn der Inhalt vielgliedrig ist — Befunde, Schritte, Optionen, Dateien —, nimm eine Liste, auch wenn dein Impuls die Prosa ist. Ein Punkt oder eine Argumentationslinie bleibt Prosa.

## 7 Zitieren aus abgerufenen Quellen (Sitzung)

Beim Zusammenfassen von Dokumenten übernimmt Fable 5.1 eher als Fable 5 Passagen des Quelltexts, ohne sie als Zitat zu kennzeichnen. Abhilfe laut Doku: **ein vollständiges Beispiel einer korrekten Antwort** in den System-Prompt — Anfrage, Antwort und ein Satz, warum die Antwort korrekt ist. Das Muster aus der Doku (die beiden `[web_search: ...]`-Zeilen durch den Namen des eigenen Suchwerkzeugs ersetzen, damit das Modell sie als Werkzeugausgabe liest und nicht als Text zum Ausgeben):

```text
<example>
<user>look up how the Riverton Ledger and the Coast Dispatch each covered the Harbor Bridge closure and compare their reporting</user>
<response>
[web_search: Harbor Bridge closure Riverton Ledger]
[web_search: Harbor Bridge closure Coast Dispatch]
Both outlets agree on the basics: the bridge closed on March 3 after inspectors found cracked welds, and the state expects repairs to take about eight months. Where they differ is emphasis. The Ledger treats it as a local-economy story. The Dispatch frames it as a funding failure; its editorial calls the closure "entirely foreseeable." Read together, the Ledger explains who is affected now and the Dispatch explains how it came to this — neither account alone gives the whole picture.
</response>
<rationale>CORRECT: The response is organized around where the two outlets agree and differ, not as a walk through either article. Each outlet's reporting is conveyed in one or two sentences of the assistant's own indirect speech. One short marked phrase from one source; every other claim is reworded. The response is still specific and complete.</rationale>
</example>
```

Für dich als Fable 5.1: Bei Recherche-Zusammenfassungen, Importen aus `/Import` und Finanzanalysen mit Quellenpflicht gilt — **Quellwortlaut entweder als Zitat kennzeichnen oder in eigenen Worten wiedergeben.** Ein unmarkiert übernommener Satz ist beides nicht. Das trifft die Quellenpflicht aus [[AI/Regelwerk/finanzanalyse|finanzanalyse.md]] und die Grenze „Nichts erfinden" aus dem Schreibstil gleichermaßen.

## 8 Die ganze Aufgabe zu Ende bringen (Sitzung)

Fable 5.1 kann sehr lange Aufgaben ohne viel methodische Führung abarbeiten, wenn das Ziel klar ist. Bei komplexen asynchronen Arbeiten neigt es aber dazu, die Runde vor dem Abschluss zu beenden: Es beschreibt den nächsten Schritt („Next, I'll …") statt ihn zu tun, oder fragt um Erlaubnis für etwas, das der Auftrag schon abdeckt („Shall I apply this?"). Der Nutzer muss dann „weiter" antworten. Das passt zum Pair-Programming, nutzt aber die Langstreckenfähigkeit nicht aus.

Die Doku empfiehlt zwei System-Prompt-Blöcke, beide zusammen. Muss der Prompt kurz bleiben, nur den ersten — er trägt den Großteil der Wirkung, und darin vor allem der Eröffnungssatz, dass der Nutzer nicht zuschaut. Der erste Block:

```text
You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to…?' or 'Shall I…?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.

Exception: when the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one.

Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ('I'll…', 'let me know when…'), do that work now with tool calls. That includes retrying after errors and gathering missing information yourself. Do not stop because the context or session is long. End your turn only when the task is complete or you are blocked on input only the user can provide.

Before running a command that changes system state (such as restarts, deletes, or config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.
```

Braucht ein Produkt bestimmte Bestätigungen, direkt nach dem Eröffnungssatz einen Satz mit der Liste einfügen. Vorbehalt der Doku: Der Block kann dazu führen, dass das Modell bei mehrdeutigen Anfragen seltener nachfragt — den Kompromiss an eigenen Aufgaben prüfen.

Der zweite Block definiert den Auftrag als Umfang des Ergebnisses:

```text
# Delivering work
The user's request — or the plan they approved — sets the scope, and the scope is the deliverable: don't quietly narrow, widen, or swap it. Read ambiguity the way a careful colleague would: make routine judgment calls yourself, and check in only when different readings would lead to materially different work. If you see a real problem with the task as specified, say so in a sentence or two and keep building under stated assumptions; if the user hears the concern and reaffirms, that is their decision, so deliver the full request.

If a question comes up partway, first do everything that doesn't depend on the answer; then state the assumption you made, or — when going ahead on a wrong guess would be unsafe or would make the work useless — put the question at the end of a turn that also delivers that progress. If one part turns out to be blocked, complete every other part in full and say exactly what you left out and why — the whole task is the deliverable, and scaling it down is the user's call, not yours. A step you have decided on is something to run, not to announce: describing the next step and ending the turn leaves it undone until the user replies.

Keep changes to what the request needs. Something else you notice worth doing — cleanup or documentation the task didn't call for, a change to a file the task didn't require — is a suggestion to make at the end, not a change to make; actions clearly beyond what the ask implies, and risky or destructive ones, still need the user's go-ahead.
```

Für dich als Fable 5.1 im Vault, in eigenen Worten: **Ein Schritt, den du entschieden hast, wird ausgeführt, nicht angekündigt.** Bevor du die Runde beendest, lies deinen letzten Absatz. Ist er ein Plan, eine Frage oder ein Versprechen, dann ist die Arbeit nicht fertig. Die Ausnahme bleibt: Wer ein Problem beschreibt oder laut denkt, bekommt eine Einschätzung, keine Änderung. Und die harten Grenzen des Stamms — Commit nur auf Anweisung, Selbstoptimierungen mit `pending-review`, Bookstack-Upload erst nach `#review-done` — sind genau die „Bestätigungen", die auch unter Autonomie stehen bleiben.

## 9 Was eine Kompaktierungs-Zusammenfassung behalten muss (API-Integrationen)

Fable 5.1 reagiert gut darauf, wenn man ihm ausdrücklich sagt, was die Zusammenfassung bei einer Kompaktierung behalten muss. Die serverseitige Kompaktierung tut das schon. Wer auf dem Client kompaktiert, nimmt laut Doku diese Anweisung:

```text
Summarize the transcript inside <summary></summary> tags. Include relevant information in the summary such that this conversation will be continued by a new context window without needing to redo work or be reprovided with relevant constraints or context. Be sure to preserve: (1) any difficulties or problems that came up, and how they were handled or resolved; (2) any possibilities, options, or approaches that were raised, tried, or set aside, and why; (3) anything that was asked for, decided, agreed, ruled out, or established as a preference, constraint, or boundary — stated exactly; (4) exactly where things stand now — what has been covered, settled, or completed so far; (5) anything still open, unresolved, promised, or expected to happen next; (6) specific details that would be hard to reconstruct — names, numbers, dates, exact wording, links or references — kept exactly. Be complete on these even at the cost of length; keep everything else concise. Weight the two voices differently: keep what the user said, asked for, shared, or established carefully and close to their own words; your own explanations and reasoning can be condensed much further, to what they concluded or produced — as long as nothing in the six items above is dropped.
```

Die sechs Punkte sind nebenbei eine brauchbare Checkliste für unsere **Sitzungszusammenfassungen unter `AI/sessions/` und die Secondbrain-Dumps**: Schwierigkeiten und ihre Lösung, verworfene Ansätze mit Grund, Entscheidungen im Wortlaut, Stand, Offenes, schwer rekonstruierbare Details. Das ist kein Fable-Sonderfall, sondern gilt für jedes Modell — und es steht hier, weil die Liste in der Doku vollständiger ist als unsere bisherige Praxis.

## 10 Änderungen und Tests auf den Auftrag beschränken (Sitzung)

Bei offenen Feature-Aufträgen liefert Fable 5.1 das Verlangte und manchmal mehr: repariert benachbarten Code, erweitert Verhalten, das der Auftrag nicht nannte, committet mehr Testdateien, als die Änderung rechtfertigt. Es reagiert gut auf ausdrückliche Anweisungen, was wegzulassen ist — laut Doku sinken damit ungefragte Zusätze und committeter Testcode deutlich, ohne messbare Änderung der Erfolgsquote:

```text
If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Where the task is ambiguous, implement the reading its wording and the surrounding code most directly support, state that assumption in your summary, and don't build for the other readings as well. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files — roughly one focused test per stated behavior — and don't turn scratch checks into additional permanent test files. This is about extras only: implement every behavior the task asks for, completely.
```

Für dich als Fable 5.1: Das ist inhaltlich die Auftragsgrenze des Executers aus `.claude/agents/executer.md` — nur die genannten Zieldateien, keine Scope-Erweiterung, Beobachtetes im Bericht statt im Code. Neu ist die Testregel: **Tests nur, wo der Auftrag sie verlangt oder das Repo sie für diese Art Änderung schon führt, in der Größe der Nachbardateien, etwa ein Test je genannter Anforderung.** Prüfskripte für die eigene Verifikation dürfen weg.

**Was diese Regel nicht einschränkt — und das ist die eigentliche Grenze:** Sie betrifft ausschließlich *ungefragte Zusätze*. Was das Regelwerk selbst verlangt, ist beauftragt, auch wenn der einzelne Auftragstext es nicht wiederholt. Das sind mindestens drei Dinge:

- Der **Regressionsfall je Nachbesserung** aus Schritt 5 der Standardschleife in [[AI/Regelwerk/codeworkflow|codeworkflow.md]] — jede Korrektur ist neuer Code und bekommt in derselben Runde ihren eigenen Test, mit beobachtetem Fehlschlag vor der Implementierung.
- Der **Test-zuerst-Block je Task** im Plan des Planers — steht er im Plan, ist er Auftrag.
- Der **Regressionsnachweis für Prüfwerkzeuge** aus [[AI/Regelwerk/pruefwerkzeuge|pruefwerkzeuge.md]] — ein Skript, das beurteilt, gilt erst als Gate, wenn es an kaputter Eingabe angeschlagen hat.

Im Zweifel gilt: Ein Test, der ein gemeldetes Fehlerbild festnagelt, ist nie „Beiwerk". Weggelassen werden nur Tests, die kein genanntes Verhalten und keinen Befund abdecken.

## 11 Suche bei niedrigem Effort (Sitzung)

Bei `low` ruft Fable 5.1 seltener als Fable 5 ein Such- oder Abrufwerkzeug auf und antwortet eher aus dem Gedächtnis. Manchmal reicht es, den Effort für die betroffenen Runden zu erhöhen statt für das ganze Gespräch. Sonst hilft ein Hinweis im System-Prompt, dass einen Namen zu kennen nicht dasselbe ist wie seinen aktuellen Stand zu kennen:

```text
When a query centers on a name you do not confidently recognize, or recognize from a fast-moving area like AI models and developer tools where the landscape shifts within months, the name itself is the thing to verify: search before answering, and include the name as the user wrote it in at least one query alongside any reformulations. This holds even when you have some background on it — partial background is exactly what makes an out-of-date answer sound authoritative, so familiarity is not a reason to skip the search.
```

Für dich als Fable 5.1: Das ist die Quellenpflicht aus dem Codeworkflow („Prüfaufträge mit Quellenpflicht") in Modellform. **Vertrautheit mit einem Namen ist kein Grund, die Suche zu überspringen** — gerade das halbe Hintergrundwissen lässt eine veraltete Antwort belastbar klingen. Den Namen so, wie der Nutzer ihn geschrieben hat, in mindestens eine Anfrage übernehmen.

## 12 Fehlalarme der Schutzklassifikatoren (API-Integrationen, teils Sitzung)

Fable 5.1 führt Sicherheitsklassifikatoren aus und kann `stop_reason: "refusal"` zurückgeben. Laut Doku gibt es weniger Fehlalarme als bei Fable 5 zum Start, und das Finden von Schwachstellen in Quellcode ist erlaubt. Drei Situationen machen Fehlalarme wahrscheinlicher:

- **Compile-Check-Formulierung.** Statt „Does this program compile without errors?" fragen: „Are there any bugs in this program?"
- **Wenig bekannte Programmiersprachen.** Kontext mitgeben, was die Sprache ist und wie sie funktioniert — etwa Zugriff auf ihre Dokumentation.
- **Base64 in Werkzeugausgaben.** Werkzeuge, die base64-kodierte Daten in den Kontext liefern, lösen Fehlalarme aus; die empfohlene Abhilfe ist, sie zu entfernen.

Für uns relevant, weil wir Prüfskripte und Security-Compliance-Projekte fahren: Der dritte Punkt betrifft eigene Werkzeuge in Code-Projekten. Die ersten beiden betreffen, wie Aufträge an Subagenten formuliert werden.

## 13 Gezielte Edits statt Komplett-Neuschrieb (Sitzung)

Fable 5.1 schreibt eher als Fable 5 eine ganze Textdatei neu, statt gezielt zu ändern. Das Ergebnis ist meist dasselbe, aber sofern die Datei nicht kurz ist oder sich der Großteil ändert, kostet ein Neuschrieb mehr Ausgabetokens und Zeit. Die Doku-Anweisung (an den System-Prompt oder die erste Nutzernachricht anhängen):

```text
The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.
```

Für dich als Fable 5.1: **Edit vor Write.** Eine bestehende Datei wird punktgenau geändert, nicht neu geschrieben — es sei denn, sie ist kurz oder der Großteil ändert sich. Das passt zur Werkzeugdisziplin im Codeworkflow (positionsgenau ersetzen, kein globales Ersetzen in gemischten Dateien) und zu [[AI/Regelwerk/codedoku|codedoku.md]], wo ein Neuschrieb den Dateikopf und das CHANGELOG still mitreißen würde.

## 14 Platz für lange Ausgaben bei xhigh und max (API-Integrationen)

Bei `xhigh` und besonders `max` denkt Fable 5.1 länger, bevor es zu schreiben beginnt. Verlangt eine einzelne Anfrage ein langes Ergebnis — etwa die Komplettüberarbeitung eines langen Dokuments —, entwirft es unter Umständen einen Großteil davon im Thinking und schreibt ihn dann in der Antwort erneut: längere Wartezeit, mehr Ausgabetokens. Am einfachsten: solche Anfragen bei `high` fahren und nur dort auf `xhigh`/`max` gehen, wo ein Qualitätsgewinn gemessen wurde. Wer es doch tut:

- `max_tokens` so setzen, dass Thinking **und** Antwort Platz haben, nicht nur die erwartete Antwortlänge.
- Folgende Notiz ans Ende der Nutzernachricht hängen, `[max_tokens]` durch den tatsächlichen Wert ersetzt (z. B. 64.000). Laut Doku verkürzt sie das Thinking bei Prosa- und Codeanfragen deutlich:

```text
Everything produced in one reply, including any reasoning or drafting done before the reply, counts toward a single limit of about [max_tokens] tokens. If that limit is reached before the reply is finished, the person receives a cut-off response and has to start over. Composing an entire output or deliverable in full as reasoning and then again as a reply would double the length of the turn without improving the result, so don't do that.

Instead, when the person has asked for a long or effort-intensive deliverable such as a multi-section document, a large table or dataset, or a complete code file, spend extra effort on understanding the request, checking the inputs the answer depends on, settling the structure and other difficult decisions, and otherwise using the reasoning space to reason and the output space to write an output. Usually it is not needed to draft an output multiple times.
```

Für dich als Fable 5.1 in der Sitzung gilt der Kern auch ohne API: **Den Denkraum zum Entscheiden nutzen, den Ausgaberaum zum Schreiben.** Ein langes Dokument einmal im Kopf und einmal in der Antwort zu schreiben, macht die Runde doppelt so lang, ohne sie besser zu machen. Bei Dokumentensets nach [[AI/Regelwerk/dokumentations-grossprojekte|dokumentations-grossprojekte.md]] betrifft das jeden Subagenten, der ein langes Dokument am Stück schreibt.

## 15 Leitagent arbeitet weiter, während Subagenten laufen (Sitzung, teils API)

Wenn ein Coding-Agent Arbeit an Subagenten delegiert, sollte der Leitagent nicht gezwungen sein, auf jeden zu warten. Laut Doku senkt das bei Coding-Aufgaben die durchschnittliche Fertigstellungszeit bei ähnlicher Qualität, ähnlichem Tokenverbrauch und ähnlichen Kosten. Für eigene Harnesses: das Start-Werkzeug kehrt sofort zurück, das Ergebnis kommt später als `user`-Nachricht, und ein separates Werkzeug erlaubt gezieltes Warten. Das Modell wartet trotzdem oft — die Ersparnis kommt aus den Läufen, in denen es weiterarbeitet.

Für dich als Fable 5.1 in dieser Sitzung: Subagenten laufen hier standardmäßig im Hintergrund. **Solange ein Executer tippt, tust du das, was nicht von seinem Ergebnis abhängt** — den nächsten Task vorbereiten, den Prüfauftrag formulieren, `tasks/lessons.md` lesen. Was du nicht tust: das Ergebnis vorhersagen oder Schritt 4 der Standardschleife anfangen, bevor der Bericht da ist. Die Standardschleife aus [[AI/Regelwerk/codeworkflow|codeworkflow.md]] bleibt in ihrer Reihenfolge; nur die Wartezeit wird genutzt.

## 16 Bildarbeit: Zuschneiden und Zoomen (API-Integrationen)

Fable 5.1 sieht laut Doku von Haus aus besser, und bei komplexen visuellen Eingaben wie dichten Diagrammen arbeitet es am besten, wenn es iterativ analysieren, zuschneiden und das Gesehene prüfen kann. Voller Nutzen: das Modell als Agent mit Zugriff auf einen Container, der die Rohbilder oder Videos hält und Bildbibliotheken wie PIL und OpenCV vorinstalliert hat. Ist ein Container zu viel Aufwand, bringt ein einzelnes Zuschneide-Werkzeug — gewählter Bildausschnitt, zugeschnitten und vergrößert zurückgegeben — laut Doku den größten Teil des Gewinns. Ein fertiges Werkzeug beschreibt das Cookbook-Rezept „multimodal-crop-tool".

In dieser Sitzung entspricht dem die `zoom`-Aktion des Browser-Werkzeugs für Screenshots.

---

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

Aus der Anthropic-Seite „What's new in Claude Fable 5.1", abgerufen am 2026-09-05. Teil A oben ist das Verhalten; das hier sind Spezifikation, Brüche, neue Funktionen, Preise und Verfügbarkeit. Die Sitzung braucht davon wenig. Ein Code-Projekt, das gegen die API baut, braucht alles.

## B1 Einordnung und Spezifikation

Anthropic selbst empfiehlt: **Für die meisten Arbeiten mit Opus 5 anfangen.** Fable 5.1 ist für anspruchsvolles Schließen und lange agentische Arbeit gedacht, oder wenn Opus 5 bei höherem Effort in den eigenen Evals noch nicht reicht. Das stützt die Rollentabelle im Stamm, nicht umgekehrt. Mythos 5.1 ist baugleich und nur für Teilnehmer von „Project Glasswing" verfügbar.

| | Fable 5.1 / Mythos 5.1 |
|---|---|
| API-ID | `claude-fable-5-1` / `claude-mythos-5-1` |
| Kontextfenster | 1M Tokens (Standard und Maximum), Standardpreis über das ganze Fenster |
| Maximale Ausgabe | 128k Tokens |
| Thinking | adaptiv, immer an; Tiefe über `effort` |
| Tokenizer | wie Fable 5 (seit Opus 4.7); gegenüber älteren Modellen rund 30 % mehr Tokens für denselben Text |

Fähigkeitsgewinne gegenüber Fable 5 liegen laut Doku vor allem in sechs Bereichen: agentisches Codieren über Stunden (Mehrdatei-Features, große Refactorings, Debugging, Review über Sitzungen), Wissensarbeit mit Dokumenten, Tabellen und Folien, mehrstufige Recherche, Bildverständnis (dichte Diagramme, Tabellen in PDFs), Arbeit über das volle 1M-Fenster, und Computer Use mit besserer Erholung nach Fehlschritten. Mehrsprachigkeit auf dem Stand von Fable 5. Der Abstand ist bei höherem Effort am größten.

## B2 Drei Brüche gegenüber Fable 5 (API-Integrationen)

**Erzwungene Werkzeugwahl geht nicht mehr.** `tool_choice` mit `{"type": "any"}` oder `{"type": "tool", "name": "…"}` liefert 400 `invalid_request_error`; `auto` (Standard) und `none` bleiben. Gilt auch für den Token-Zähl-Endpunkt. Grund: Thinking ist immer an, ein erzwungener Aufruf würde es überspringen und das Modell schriebe sein Nachdenken in die Werkzeugargumente. Ersatz: für schemagültiges JSON `tool_choice: auto` plus `strict: true` (Strict Tool Use) oder Structured Outputs; damit das Modell ein Werkzeug statt Text nimmt, im Prompt sagen, wann es gilt („Use the `get_weather` tool to answer") — Fable 5.1 folgt dem laut Doku verlässlich.

**Frühere Modelle lesen Fable-5.1-Thinking nicht.** Jeder Thinking-Block trägt sein Erzeugermodell. Fable 5.1 liest die Blöcke älterer Modelle; kein älteres Modell liest die von Fable 5.1. Wechselt ein Gespräch von Fable 5.1 auf Opus 5 oder älter, gehen die Denkschritte für diese Runden verloren — die API wirft die Blöcke vor dem Modell weg, still, unbepreist. Mit Beta-Header `thinking-binding-controls-2026-08-01` meldet sie den Wegfall in `input_transformations`. Für uns relevant, sobald ein Router oder Fallback mitten im Gespräch das Modell wechselt.

**Frühere Runden ändern macht Thinking ungültig.** Die Regel aus Abschnitt 4 oben, hier mit der vollständigen Liste der Doku. Ungültig wird jeder spätere Block bei: Bearbeiten, Umsortieren oder Entfernen einer früheren Runde; Einfügen von Text pro Anfrage (Erinnerung, Statuszeile), der beim nächsten Mal wieder entfernt wird; Neuaufbau von `system` oder `tools` zwischen Anfragen; einem Bild- oder Dokument-URL, der später andere Bytes liefert (die Prüfung gilt den Bytes, nicht dem URL — rotierende signierte URLs für dieselbe Datei sind in Ordnung). Gültig bleibt alles bei: Entfernen einer führenden Folge von Thinking-Blöcken (älteste zuerst), serverseitiger Kompaktierung oder Context Editing, Verschieben von `cache_control`-Markern, Ändern von `effort`. Ein Block aus der Mitte entfernt macht alle danach ungültig. Mythos 5.1 führt die Prüfung nicht aus. **Claude Code, claude.ai, Managed Agents und das Agent SDK halten das Präfix von sich aus intakt** — betroffen ist nur eigener Code, der `messages` selbst baut. Erzwungen für Konten ab 31.08.2026; ältere Konten sehen die Abweichung nur, wenn `prefix_mismatch_behavior` gesetzt ist.

## B3 Fünf neue Funktionen

**Effort mitten im Gespräch (Beta).** Header `mid-conversation-output-config-2026-07-01`. Eine System-Nachricht mit leerem `content` und `output_config: {"effort": "low"}` senkt oder hebt den Effort ab der nächsten Nutzerrunde, ohne den Prompt-Cache zu verlieren. Hoch für den schweren Schritt, runter für Routine. Unterstützt von Fable 5.1, Mythos 5.1 und Opus 5.

**Rundenbezogene System-Nachrichten (Beta).** Header `mid-conversation-system-clear-at-2026-08-21`. Eine `role: "system"`-Nachricht mit `clear_at: "next_user_message"` hat für die laufende Runde System-Prompt-Gewicht und wird nicht mehr gerendert, sobald eine spätere Nutzernachricht existiert. Sie bleibt im Array und wird unverändert mitgesendet — Cache bleibt warm, spätere Thinking-Blöcke bleiben gültig, eine gelöschte Nachricht kostet keine Tokens. Gedacht für Erinnerungen pro Runde („check your inbox before running more code", „the user can't see that tool output"). Das ist der Mechanismus, den Abschnitt 3 oben nutzt.

**Fortschrittsmeldungen zwischen Werkzeugaufrufen (Beta).** Header `thinking-display-updates-2026-08-18`, `thinking.display: "updates"`. Jede Meldung kommt als eigener `thinking`-Block direkt vor dem Werkzeugaufruf; unter dem Standard `"omitted"` sind sie leer. Mit `"updates"` kommen sie als Text, das Reasoning bleibt verborgen; `"summarized"` liefert beides gemischt. Siehe Abschnitt 2 oben.

**Günstigere Cache-Lesezugriffe.** Siehe B6.

**Herkunftskennzeichnung.** Text von Fable 5.1 und Mythos 5.1 trägt auf jeder Plattform Anthropics statistisches Text-Wasserzeichen. Bild-, Video- und Audiodateien, die Claude erzeugt (etwa über das Code-Execution-Tool), tragen signierte C2PA-Content-Credentials, wenn man sie über die Files API abruft. Das Wasserzeichen ändert laut Doku weder Bedeutung noch Qualität, fügt keine Tokens oder versteckten Zeichen hinzu und trägt keine Information über den Nutzer. **Für den Vault:** Was Fable 5.1 schreibt, ist als KI-Text erkennbar. Bei Kundendokumenten ist das eine Frage, die Pascal kennt, bevor sie ein Kunde stellt. Der Skill `remove-ai-marks` existiert im Harness; ob und wann er eingesetzt wird, ist Pascals Entscheidung, nicht die des Agenten.

## B4 Unverändert gegenüber Fable 5

`thinking: enabled` mit `budget_tokens` und `thinking: disabled` liefern 400 — weglassen oder `adaptive`. `thinking.display` ist standardmäßig `omitted`, `summarized` verfügbar, roher Gedankengang nie. Reasoning zwischen Werkzeugaufrufen kommt als Thinking-Block, Interleaved Thinking ist automatisch. Prefill liefert 400. `temperature`, `top_p`, `top_k` abseits der Standardwerte liefern 400. Mindestlänge für Caching 512 Tokens. Mid-Conversation-System-Nachrichten und Werkzeugänderungen werden unterstützt.

## B5 Ablehnungen, Fallback, Abrechnung

Die Sicherheitsklassifikatoren decken dieselben `stop_details`-Kategorien wie Fable 5 ab. Eine abgelehnte Anfrage kommt als HTTP 200 mit `stop_reason: "refusal"` und einem `stop_details`-Objekt, das den Politikbereich nennt. Fallback: serverseitig, per SDK-Middleware oder eigenem Retry; `fallbacks: "default"` (Beta) wiederholt auf dem von Anthropic empfohlenen Modell. **Erlaubte Fallback-Ziele für Fable 5.1: Opus 4.8 und Opus 5.** Eine Ablehnung vor jeder Ausgabe wird nicht berechnet; das Fallback-Guthaben erstattet die Prompt-Cache-Kosten des Modellwechsels. Wann Fehlalarme wahrscheinlicher werden: Abschnitt 12 oben.

## B6 Preise (USD, Stand 2026-09-05)

| Basis-Eingabe | Cache-Schreiben 5 min | Cache-Schreiben 1 h | Cache-Lesen | Ausgabe |
|---|---|---|---|---|
| 10 $ / MTok | 12,50 $ / MTok | 20 $ / MTok | 0,25 $ / MTok | 50 $ / MTok |

Gleich wie Fable 5 bis auf das Cache-Lesen: 0,025-fache des Basispreises statt 0,1-fach bei anderen Claude-Modellen — lange agentische Sitzungen, die ein gecachtes Präfix erneut lesen, zahlen ein Viertel des Fable-5-Satzes. Batch-Verarbeitung 5 $ Eingabe, 25 $ Ausgabe je Million Tokens. Das ist der Grund für den Hinweis in Abschnitt 4 oben, spätere Kompaktierungspunkte auszuprobieren.

## B7 Verfügbarkeit und Datenhaltung

Claude API (`claude-fable-5-1`), Amazon Bedrock (`anthropic.claude-fable-5-1`) und Claude Platform on AWS, Google Cloud Vertex (`claude-fable-5-1`), Microsoft Foundry auf Anthropic-Infrastruktur. Mythos 5.1 nur für freigegebene Glasswing-Kunden.

**Datenhaltung: 30 Tage.** Fable 5.1 und Mythos 5.1 sind nicht unter Zero Data Retention verfügbar, sofern Anthropic es nicht ausdrücklich genehmigt; beide sind „Covered Models". **Für den Vault ist das der wichtigste Satz dieses Teils:** Wer in einem Kundenprojekt mit ZDR-Zusage arbeitet, prüft vor der Modellwahl, ob Fable 5.1 dort überhaupt zulässig ist. Das steht nicht im Ermessen des Agenten.

## B8 Umstieg von Fable 5 — Prüfliste

Modell-ID auf `claude-fable-5-1` setzen, dann: (1) `tool_choice` `any`/`tool` entfernen, Schema-Erzwingung auf Strict Tool Use oder Structured Outputs. (2) Thinking-Blöcke unverändert zurückgeben, Verlauf nur anhängen; baut der Code `messages` selbst, den Drei-Schritt-Check aus dem Migrationsleitfaden fahren, Erinnerungen auf rundenbezogene System-Nachrichten umstellen, `system`/`tools`-Änderungen auf Mid-Conversation-Nachrichten, Kontext serverseitig kürzen, dann ein produktives `prefix_mismatch_behavior` wählen und `input_transformations` beobachten. (3) Effort ab `high` neu abstimmen, mitten im Gespräch wechseln statt eine Stufe halten. (4) In Agentenschleifen auf einen Aufruf pro Runde achten und die Bündel-Notiz ergänzen. (5) Evals neu fahren — Ablehnungsbehandlung, Fallback, Guthaben und Tokenzählung tragen unverändert über.

Was der Migrationsleitfaden darüber hinaus sagt, auch für den Umstieg von Opus 5 und älter: Teil C unten.

---

# Teil C — Migrationsleitfaden

Aus „Migrating to Claude Fable 5.1 and Claude Mythos 5.1", abgerufen am 2026-09-05. Gilt für Code gegen die Messages API. Wer Claude Managed Agents nutzt, ändert nur den Modellnamen. Was Teil B schon sagt, steht hier nicht nochmal — nur das, was der Leitfaden zusätzlich bringt.

## C1 Werkzeug für den Umstieg

In Claude Code gibt es `/claude-api migrate this project to claude-fable-5-1`. Der Skill tauscht die Modell-ID, ändert brechende Parameter, ersetzt Prefill, kalibriert Effort und erzeugt eine Liste manuell zu prüfender Punkte. Er fragt vor dem Bearbeiten nach dem Umfang (Arbeitsverzeichnis, Unterordner, Dateiliste) und erkennt Bedrock- und AWS-Clients. Im Vault ist der Skill `claude-api` geladen. **Ein Skill, der Dateien ändert, läuft trotzdem unter der Standardschleife:** Ergebnis gegenprüfen, nicht glauben.

## C2 Datenhaltung — was konkret passiert

Eine Anfrage von einer Organisation oder einem Workspace **ohne 30-Tage-Retention** liefert auf der Claude API einen 400 `invalid_request_error`. Organisationen mit ZDR-Vereinbarung wenden sich an ihr Anthropic-Account-Team oder konfigurieren die Retention **je Workspace**. Das ist der Weg, wenn ein ZDR-Kunde und ein Fable-Projekt zusammenkommen: getrennter Workspace, nicht Ausnahme für die ganze Organisation.

Ergänzend aus dem Opus-5-Abschnitt des Leitfadens: **Opus 5 ist unter ZDR verfügbar, ebenso Opus 4.8.** Damit ist die Frage aus Teil B beantwortet — Sonnet 5 und Opus 5 gehen unter ZDR, Fable 5.1 nicht.

## C3 Erzwungene Werkzeugwahl ersetzen — die drei Wege

1. `tool_choice: auto`, Werkzeug in der Anweisung nennen, `strict: true` am Werkzeug plus `additionalProperties: false` im Schema. **Vorbehalt:** In CMEK-Organisationen sind Structured Outputs einschließlich `strict: true` auf Fable-Modellen nicht verfügbar — dort bleibt nur die Anweisung.
2. Wer ein Werkzeug nur für schemagültiges JSON erzwungen hat: JSON Outputs über `output_config.format`.
3. Wenn die **Anwendung** (nicht der Nutzer) auf der aktuellen Runde einen bestimmten Aufruf braucht: eine Mid-Conversation-System-Nachricht nach dem letzten `user`-Turn anhängen, die das Werkzeug nennt, den Aufruf für diese Runde verlangt und sagt, die Antwort damit zu beginnen. Kein Beta-Header nötig. Die Nachricht bleibt im Verlauf. `tool_choice: none` funktioniert weiter für Runden ohne Werkzeuge.

## C4 Thinking-Bindung — was der Leitfaden über Teil B hinaus sagt

**Zwei Fehlergründe in `input_transformations`:** `model_binding_mismatch` heißt Modellwechsel (Router, Client-Retry, Klassifikator-Fallback) — kein Fehler im eigenen Code, aber das Zielmodell plant ohne das Reasoning neu, was die erste Runde nach dem Wechsel teurer und langsamer macht. `prefix_binding_mismatch` heißt, etwas vor dem Block an `path` hat sich seit der letzten Anfrage geändert — das ist ein Fehler im eigenen Code.

**Der 400 ist dauerhaft für diesen Request-Body.** Eine automatische Retry-Schleife räumt ihn nicht weg. Weiterkommen ohne das ungültige Reasoning: Thinking-Blöcke aus dem Verlauf streichen und einmal wiederholen, oder `prefix_mismatch_behavior: "drop_block"`. Mit `drop_block` fallen der betroffene Block **und alle Thinking-Blöcke danach**. Der Token-Zähl-Endpunkt führt dieselbe Prüfung aus.

**Wer ein Werkzeug baut, das andere mit eigenem API-Key betreiben:** vor dem Launch mit gesetztem Feld testen. Der eigene Key liegt wahrscheinlich auf einem älteren Konto, die Nutzer auf neuen — die treffen die Prüfung zuerst. Ob das eigene Konto erzwungen ist, sieht man an einer Anfrage, die den Verlauf ändert, ohne Beta-Header: ein 400, der den Header nennt, heißt ja.

**Zusätzliche Muster, die Blöcke ungültig machen** (über Teil B hinaus): alte `tool_result`-Blöcke löschen; Keep-Tail-Kompaktierung, die jüngste Runden samt Thinking hinter einer Zusammenfassung wörtlich behält; Hintergrund-Kompaktierung, die ihre Zusammenfassung Runden später einwechselt. Für Inhalte, die über Runden referenziert werden: einmal über die Files API hochladen und `file_id` senden, oder base64 — nicht einen URL, der später andere Bytes liefert.

**Drei Formen der Client-Kompaktierung**, wenn serverseitig nicht geht:

- **Einfach (empfohlen):** ganzer Verlauf durch eine Zusammenfassungsnachricht plus neue Nutzerrunde ersetzt, sonst nichts erneut gesendet. Kein Thinking trägt über, nichts schlägt fehl. Claude-Modelle sind laut Doku auf lange Aufgaben mit diesem Schema trainiert und schneiden damit für die meisten Arbeiten vergleichbar mit aufwendigeren Schemata ab.
- **Keep-Tail:** jüngste Runden wörtlich hinter der Zusammenfassung — dann `thinking`- und `redacted_thinking`-Blöcke aus diesen Runden streichen (Text und Werkzeugaufrufe bleiben) oder `drop_block` setzen.
- **Hintergrund:** Zusammenfassung abseits des kritischen Pfads gebaut und später eingewechselt — jede Runde dazwischen trägt Thinking von vor dem Wechsel; `drop_block` auf jede Anfrage, die noch solche Blöcke trägt (die `input_transformations` der ersten Antwort nach dem Wechsel listen genau welche), oder synchron kompaktieren.

Einzelne Runden aus der Mitte schneiden geht in keiner Form. Dafür Mid-Conversation-System-Nachrichten oder serverseitiges Context Editing.

**Die Drei-Schritt-Prüfung** aus Teil B, hier mit dem Zusatz: In CI `"error"` setzen, damit eine Verlaufsänderung den Lauf fehlschlagen lässt. Und die Kostenwarnung: Thinking einmal an einer Kompaktierungsgrenze zu verwerfen, hat wenig Wirkung; eine Integration, die es bei jeder Anfrage verwirft, startet jedes Mal den Prompt-Cache neu.

## C5 Empfohlene Änderungen — was neu ist

- **Effort mitten im Gespräch** gilt ab der folgenden Nutzerrunde und für alle weiteren, bis eine andere System-Nachricht es ändert. Nur die benannten Stufen. Bei Fable 5 war Effort request-weit, und ein Wechsel zwischen Anfragen warf gecachte Präfixe weg.
- **Werkzeugänderungen** per `tool_addition`- und `tool_removal`-Blöcken in einer System-Nachricht (Beta-Header `mid-conversation-tool-changes-2026-07-01`), wobei der volle Werkzeugsatz zu Sitzungsbeginn in `tools` deklariert ist. Eine Nachricht mit solchen Blöcken kann **nicht** rundenbezogen sein.
- **Fallback bekommt kein Thinking.** Das Fallback-Modell (Opus 4.8 oder Opus 5) sieht Fable-5.1-Thinking-Blöcke nicht. Eine explizite `fallbacks`-Liste darf beide nennen.
- **Effort-Sweep:** Die Gewinne gegenüber Fable 5 sind bei `xhigh` und `max` am größten, aber diese Stufen erhöhen Denkzeit und Zeit bis zur ersten Antwort. `medium` bleibt als Kostenkontrolle testwürdig.

## C6 Umstieg von Opus 5 — was zusätzlich gilt

Alles aus dem Fable-5-Abschnitt plus:

- **Thinking lässt sich nicht mehr abschalten.** Opus 5 akzeptiert `disabled` bis Effort `high`; Fable 5.1 liefert bei jeder Stufe 400. Feld entfernen, Tokens über niedrigeren Effort steuern, `max_tokens` für Arbeiten prüfen, die ohne Thinking liefen.
- **Text zwischen Werkzeugaufrufen kommt als Thinking-Block, nicht als Text.** Bei Opus 5 kam Erzählung zwischen Aufrufen als `text`-Block. Bei Fable 5.1 als Fortschritts-`thinking`-Block vor jedem Aufruf, unter `omitted` ohne lesbaren Inhalt. Wer das rendert: `display: "updates"` oder `"summarized"` und die nicht-leeren `thinking`-Blöcke zwischen den `tool_use`-Blöcken anzeigen.
- **Breitere Klassifikatoren.** Opus 5 hat nur Cyber-Klassifikatoren; Fable 5.1 deckt die Kategorien von Fable 5 ab — `stop_details.category` kann über `"cyber"` hinaus etwa `"bio"` und `"reasoning_extraction"` liefern.
- **Preis:** 10 $ / 50 $ statt 5 $ / 25 $. Cache-Lesen 0,25 $ — die Hälfte des Opus-5-Satzes.
- **Vor allem anderen:** ZDR-Berechtigung prüfen, wenn die Organisation eine ZDR-Vereinbarung hat.

## C7 Umstieg von Opus 4.8 oder älter

Erst den Leitfaden „Migrating to Claude Mythos 5 and Claude Fable 5 from Claude Opus 4.8" für die API-Änderungen (adaptives Thinking, Thinking-Ausgabe, Refusals, Effort, Cache-Minimum, Preise, Datenhaltung), dann das Delta aus dem Fable-5-Abschnitt. Bei Opus 4.7 oder älter mit dem passenden Abschnitt des Opus-5-Leitfadens beginnen ([[AI/Regelwerk/opus-5|opus-5.md]], Teil C). Besonderheit: Integrationen für Opus 4.8 und älter kürzen oft alte Runden, bauen frühere Nachrichten um oder erneuern den System-Prompt bei jeder Anfrage — Opus 4.8 hat nie widersprochen, Fable 5.1 macht damit jeden späteren Thinking-Block ungültig.

## C8 Mythos 5.1

Zugang beim Anthropic-Account-Team bestätigen, bevor die ID gewechselt wird. API-Delta wie Fable 5.1, mit einem Unterschied: **Mythos 5.1 führt die Konversationsprüfung nicht aus** — das Ändern früherer Runden macht seine Thinking-Blöcke nicht ungültig, startet aber den Prompt-Cache neu. Mythos 5.1 liest Mythos-5-Blöcke, nicht umgekehrt.

## Wohin die Punkte im Regelwerk zeigen

Eine Regel steht an genau einer Stelle — hier. Die anderen Dateien tragen nur einen markierten Verweis:

| Regelwerk-Datei | Verweist auf Abschnitt |
|---|---|
| [[CLAUDE|Claude.md]] (Stamm, „Agenten & Modelle") | Geltungsbereich, Gesamtdatei |
| [[AI/Regelwerk/codeworkflow|codeworkflow.md]] | 3, 8, 10, 13, 15 |
| [[AI/Regelwerk/schreibstil|schreibstil.md]] | 5, 6, 7 |
| [[AI/Regelwerk/dokumentations-grossprojekte|dokumentations-grossprojekte.md]] | 7, 14 |
| `.claude/agents/executer.md`, `planer.md`, `pruefer.md` | 8, 10, 13 bzw. 11 |
| `.claude/skills/plan-executer-pruefung/SKILL.md` | 3, 8, 15 |

## Referenzen

- [[CLAUDE|↑ Claude.md (Stamm)]]
- [[AI/Regelwerk/prompting|prompting.md]] — die allgemeinen Prompt-Techniken für alle aktuellen Modelle, aus „Prompting best practices"
- [[AI/Regelwerk/opus-5|opus-5.md]], [[AI/Regelwerk/sonnet-5|sonnet-5.md]] — die Modelle, an die Fable 5.1 als Koordinator Aufträge schreibt
- Anthropic-Doku Teil A: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1 (Stand 2026-09-05)
- Anthropic-Doku Teil B: https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1 (Stand 2026-09-05)
- Anthropic-Doku Teil C: https://platform.claude.com/docs/en/models/fable-5-1/migration-guide (Stand 2026-09-05)
- [[AI/Regelwerk/api-mechanik|api-mechanik.md]] — Preserved Thinking, Effort, Compaction, Task Budgets, Fast Mode in voller Fassung
- Nicht abgerufen: der Fable-5-Leitfaden von Opus 4.8. „Refusals and fallback" und „Context editing" stehen in api-mechanik.md, Abschnitte 8 und 9.