Claude Platform Docs
Modelle & PreiseClaude Fable 5.1

Migration zu Claude Fable 5.1 und Claude Mythos 5.1

Migriere von Claude Fable 5, Claude Mythos 5, Claude Opus 5 oder Claude Opus 4.8 zu Claude Fable 5.1 und Claude Mythos 5.1: Modell-IDs, Breaking Changes und Migrations-Checklisten.

Claude Fable 5.1 folgt auf Claude Fable 5 zu denselben Input- und Output-Preisen, wobei Cache-Lesevorgänge nur ein Viertel kosten. Es ist verfügbar über die Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud und Microsoft Foundry. Claude Mythos 5.1 verfügt über dieselben Fähigkeiten und wird nur zugelassenen Kunden in Project Glasswing angeboten. Zu Verhaltensunterschieden und Prompting-Mustern siehe Prompting für Claude Fable 5.1.

Die Basiseinstellungen, die claude-fable-5-1 und claude-mythos-5-1 gemeinsam haben:

  • Thinking: „Adaptive thinking“ (adaptives Denken) ist immer aktiv, unverändert gegenüber Claude Fable 5. Das Modell entscheidet, wann und wie viel es nachdenkt. Es ist keine thinking-Konfiguration erforderlich. Sowohl thinking: {type: "disabled"} als auch manuelles „extended thinking“ (erweitertes Denken) (thinking: {type: "enabled", budget_tokens: N}) geben einen 400-Fehler zurück.
  • Prefill: Das Vorbefüllen der Assistant-Nachricht gibt einen 400-Fehler zurück, unverändert gegenüber Claude Fable 5. Verwende stattdessen Anweisungen im System-Prompt.
  • Tool-Auswahl: {type: "auto"} (der Standard) und {type: "none"} werden unterstützt. Das Erzwingen eines Tool-Aufrufs mit {type: "any"} oder {type: "tool", name: "..."} gibt einen 400-Fehler zurück. Siehe Breaking Changes.
  • Erhaltenes Thinking über Modelle hinweg: Claude Fable 5.1 liest Thinking-Blöcke von Claude Opus 5, Claude Fable 5, Claude Mythos 5 und früheren Claude-Modellen. Keines dieser Modelle kann die Blöcke von Claude Fable 5.1 lesen. Siehe Breaking Changes.
  • Kontextfenster und Output: Standardmäßig ein „context window“ (Kontextfenster) von 1M Token und bis zu 128k Output-Token pro Anfrage.
  • Preise: 10 $ pro Million Input-Token und 50 $ pro Million Output-Token, genau wie bei Claude Fable 5. Prompt-Cache-Lesevorgänge kosten 0,25 $ pro Million Token, ein Viertel des Satzes von Claude Fable 5. Siehe Claude-Preise.
  • Datenaufbewahrung: Beide Modelle erfordern eine 30-tägige Datenaufbewahrung, sind nicht unter „zero data retention“-Vereinbarungen (keine Datenaufbewahrung), oder ZDR, verfügbar, sofern nicht ausdrücklich von Anthropic genehmigt, und sind als Covered Models eingestuft, genau wie Claude Fable 5 und Claude Mythos 5. Auf der Claude API gibt eine Anfrage von einer Organisation oder einem Workspace ohne 30-tägige Aufbewahrung einen 400 invalid_request_error zurück. Organisationen mit einer ZDR-Vereinbarung sollten ihr Anthropic-Account-Team kontaktieren oder die Aufbewahrung pro Workspace konfigurieren. Siehe Modellspezifische Anforderungen an die Datenaufbewahrung für Details pro Plattform.

Wo sich die beiden Modelle unterscheiden:

  • Verfügbarkeit: Claude Fable 5.1 erfordert keine Zugriffsgenehmigung. Claude Mythos 5.1 ist nur für zugelassene Kunden in Project Glasswing verfügbar. Kontaktiere dein Anthropic-Account-Team für den Zugriff.
  • Sicherheitsklassifikatoren: Claude Fable 5.1 führt Sicherheitsklassifikatoren aus, die dieselben stop_details-Kategorien abdecken wie Claude Fable 5. Eine abgelehnte Anfrage gibt stop_reason: "refusal" mit einer stop_details.category zurück und kann mit dem Parameter fallbacks oder einem clientseitigen Retry auf ein anderes Modell zurückfallen. Siehe Ablehnungen und Fallback.
  • Priority Tier: Keines der beiden Modelle wird im Priority Tier unterstützt. Claude Fable 5 hingegen schon.

Migration von Claude Fable 5 zu Claude Fable 5.1

Die Migration ist größtenteils ein Drop-in-Ersatz. Die API-Oberfläche, Limits, Preise pro Token, der Tokenizer, das immer aktive adaptive Denken, die Behandlung von Ablehnungen und die stop_details-Kategorien entsprechen alle Claude Fable 5. Was sich ändert: Erzwungene Tool-Auswahl gibt einen 400-Fehler zurück, Thinking-Blöcke werden nur für das Modell erhalten, das sie erzeugt hat, oder ein neueres, und nur in der Konversation, die sie erzeugt hat, Cache-Lesevorgänge kosten weniger, und das Verhalten in Agent-Schleifen unterscheidet sich in drei Punkten. Dieselben Änderungen gelten für Claude Mythos 5.1, mit Ausnahme der Konversationsprüfung bei Thinking-Blöcken, die Claude Mythos 5.1 nicht durchführt.

Aktualisiere deinen Modellnamen

model = "claude-fable-5"  # Before
model = "claude-fable-5-1"  # After

# Oder, für das Project-Glasswing-Modell mit denselben Fähigkeiten:
model = "claude-mythos-5-1"  # After

Breaking Changes

  1. Erzwungene Tool-Auswahl wird nicht unterstützt: Claude Fable 5 akzeptiert tool_choice auto, none, any und tool. Auf claude-fable-5-1 geben {type: "any"} und {type: "tool", name: "..."} einen 400 invalid_request_error zurück:

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

    Die Prüfung gilt für die Messages API, die Message Batches API und den Endpunkt zur Token-Zählung.

    Vorher (Claude Fable 5):

    client = anthropic.Anthropic()
    
    record_summary_tool = {
        "name": "record_summary",
        "description": "Record the structured summary of the document.",
        "input_schema": {
            "type": "object",
            "properties": {"summary": {"type": "string"}},
            "required": ["summary"],
        },
    }
    
    response = client.messages.create(
        model="claude-fable-5",
        max_tokens=16000,
        tools=[record_summary_tool],
        tool_choice={"type": "tool", "name": "record_summary"},
        messages=[{"role": "user", "content": "Summarize: The meeting moved to Thursday."}],
    )
    print(response.content)

    Nachher (Claude Fable 5.1): Belasse tool_choice auf auto, nenne das Tool in der Anweisung und setze strict: true, damit der Aufruf deinem Schema entspricht. (In einer CMEK-Organisation, in der strukturierte Ausgaben, einschließlich strict: true, auf Claude Fable-Modellen nicht verfügbar sind, verlasse dich allein auf die Anweisung.) Zum Beispiel:

    client = anthropic.Anthropic()
    
    record_summary_tool = {
        "name": "record_summary",
        "description": "Record the structured summary of the document.",
        "strict": True,
        "input_schema": {
            "type": "object",
            "properties": {"summary": {"type": "string"}},
            "required": ["summary"],
            "additionalProperties": False,
        },
    }
    
    response = client.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        tools=[record_summary_tool],
        tool_choice={"type": "auto"},
        messages=[
            {
                "role": "user",
                "content": "Summarize: The meeting moved to Thursday. Call the record_summary tool with your result.",
            }
        ],
    )
    print(response.content)

    Siehe Strikte Tool-Nutzung und Tool-Nutzung erzwingen. Wenn du ein Tool nur erzwungen hast, um schemakonformes JSON zu erhalten, verwende stattdessen JSON-Ausgaben (output_config.format).

    Wenn deine Anwendung, und nicht der Nutzer, im aktuellen Zug einer mehrzügigen Konversation einen bestimmten Tool-Aufruf benötigt, hänge nach dem letzten user-Zug eine System-Nachricht mitten in der Konversation an. Nenne das Tool, sage, dass der Aufruf für diesen Zug erforderlich ist, und weise Claude an, seine Antwort damit zu beginnen. Da die Nachricht angehängt und nicht in den system-Prompt auf oberster Ebene geschrieben wird, bleiben frühere Züge byte-identisch und behalten ihre Treffer im Prompt-Cache:

    client = anthropic.Anthropic()
    
    search_help_center_tool = {
        "name": "search_help_center",
        "description": "Search the help center for policy and troubleshooting articles.",
        "strict": True,
        "input_schema": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"],
            "additionalProperties": False,
        },
    }
    
    response = client.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        system="You are a customer support assistant for an online electronics store.",
        tools=[search_help_center_tool],
        messages=[
            {
                "role": "user",
                "content": "My headphones from order A1234 arrived yesterday.",
            },
            {
                "role": "assistant",
                "content": "Thanks for confirming. How can I help with order A1234?",
            },
            {"role": "user", "content": "I opened the box. Can I still return them?"},
            # Die Anwendung verlangt eine Help-Center-Abfrage vor jeder
            # Richtlinienantwort. Wird die Anforderung als Systemnachricht angehängt,
            # bleiben die früheren Turns unverändert.
            {
                "role": "system",
                "content": "Tool-use requirement for the current turn: the application requires a call to the search_help_center tool in your response to the user's latest message. Begin your response with the search_help_center tool call. Do not reply with text only.",
            },
        ],
    )
    print(response.content)

    Behalte die role: "system"-Nachricht bei späteren Anfragen im Verlauf, wie jeden anderen Zug. System-Nachrichten mitten in der Konversation benötigen keinen Beta-Header. tool_choice: {"type": "none"} funktioniert weiterhin für einen Zug, der keine Tools aufrufen darf.

  2. Thinking-Blöcke werden nur für das Modell erhalten, das sie erzeugt hat, oder ein neueres: Jeder thinking-Block zeichnet auf, welches Modell ihn erzeugt hat. Claude Fable 5.1 liest seine eigenen Blöcke und die von Claude Mythos 5.1, Claude Opus 5, Claude Fable 5, Claude Mythos 5 und früheren Claude-Modellen. Eine Konversation, die von einem dieser Modelle auf claude-fable-5-1 wechselt, behält ihre früheren Überlegungen. Die Bedingung gilt nur in eine Richtung: Abgesehen von Claude Mythos 5.1 kann keines dieser Modelle die Blöcke von Claude Fable 5.1 lesen.

    Eine Konversation, die auf Claude Fable 5.1 lief, kann durch einen Router-Wechsel, einen clientseitigen Retry oder einen Fallback bei Klassifikator-Ablehnung, einschließlich eines serverseitigen Fallbacks, auf einem älteren Modell landen. Die API entfernt die Blöcke, die dieses Modell nicht lesen kann, bevor es sie sieht, die Anfrage ist erfolgreich, und die verworfenen Input-Token werden dir nicht berechnet. Das Zielmodell plant ohne diese Überlegungen neu, was Kosten und Latenz im ersten Zug nach dem Wechsel erhöhen kann. Um zu sehen, was verworfen wurde, sende den Beta-Header thinking-binding-controls-2026-08-01: Antworten enthalten dann ein input_transformations-Array, das jeden verworfenen Block mit reason: "model_binding_mismatch" benennt. Siehe Erhaltenes Thinking.

  3. Das Bearbeiten früherer Züge macht Thinking-Blöcke ungültig: Jeder thinking-Block von Claude Fable 5.1 ist nur gegenüber dem system-Prompt, den tools und dem Konversationsverlauf gültig, die ihm vorausgingen. Wenn Claude Code, claude.ai, Claude Managed Agents oder das Claude Agent SDK deinen Konversationsverlauf verwaltet, hält es dieses Präfix bereits intakt. Wenn dein Code das messages-Array selbst aufbaut, betrifft dich dieser Punkt, und Erhaltenes Thinking ist der vollständige Integrationsleitfaden. Wo die Prüfung durchgesetzt wird, wird eine Anfrage, die den Block zurücksendet, nachdem sich eines dieser Elemente geändert hat, mit einem 400-Fehler abgelehnt:

    messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

    Die API setzt die Prüfung für neue Accounts durch, die am oder nach dem 31. August 2026 erstellt wurden. Für früher erstellte Accounts zeichnet die API die Abweichung auf, handelt aber nicht danach, es sei denn, die Anfrage setzt thinking.block_binding.prefix_mismatch_behavior, was die Durchsetzung aktiviert. Anthropic plant, die Prüfung bei zukünftigen Modellen für jeden Account durchzusetzen, also mache deine Anwendung jetzt kompatibel: Dieselben Muster halten den Prompt-Cache warm, und du kannst von jedem Account aus gegen die Prüfung testen, indem du prefix_mismatch_behavior sendest. Wenn du ein Tool oder Framework auslieferst, das Leute mit ihrem eigenen API-Key ausführen, teste vor dem Launch auf diese Weise: Dein Key gehört wahrscheinlich zu einem älteren Account, und deine Nutzer auf neuen Accounts stoßen vor dir auf die Prüfung. Um zu sehen, ob dein eigener Account standardmäßig der Durchsetzung unterliegt, sende eine Anfrage, die den Verlauf bearbeitet, ohne den Beta-Header: Ein 400, der den Header nennt, bedeutet, dass dies der Fall ist.

    Der Fehler ist für diesen Request-Body dauerhaft: Eine automatische Retry-Schleife behebt ihn nicht. Um ohne die ungültig gewordenen Überlegungen fortzufahren, statt fehlzuschlagen, entferne die thinking-Blöcke aus dem Verlauf und versuche es einmal erneut, oder sende den Beta-Header thinking-binding-controls-2026-08-01 und setze prefix_mismatch_behavior auf "drop_block" (der Standard ist "error"). Mit "drop_block" verwirft die API den abweichenden Block und jeden Thinking-Block danach in der Konversation und meldet jeden mit reason: "prefix_binding_mismatch" im input_transformations-Array der Antwort:

    client = anthropic.Anthropic()
    
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        thinking={
            "type": "adaptive",
            "block_binding": {"prefix_mismatch_behavior": "drop_block"},
        },
        messages=[
            {
                "role": "user",
                "content": "What is the greatest common divisor of 1071 and 462?",
            }
        ],
        betas=["thinking-binding-controls-2026-08-01"],
    )
    
    for block in response.content:
        if block.type == "text":
            print(block.text)
    
    print(f"Input transformations: {len(response.input_transformations or [])}")

    Der Endpunkt zur Token-Zählung führt dieselbe Prüfung durch. Siehe Steuerungen für nicht erhaltene Blöcke (Beta) für die Antwortstruktur und die Platzierung beim Streaming.

    Muster, die spätere Thinking-Blöcke ungültig machen, und was du stattdessen tun solltest:

    • Bearbeiten, Umordnen oder Entfernen früherer Züge. Dazu gehören das Löschen alter Tool-Ergebnisse, das Herausschneiden von Zügen aus der Mitte des Transkripts und clientseitige Compaction, die aktuelle Züge und ihre Thinking-Blöcke wörtlich hinter einer Zusammenfassung behält (einschließlich Hintergrund-Compaction, die ihre Zusammenfassung einige Züge später einsetzt). Verwende stattdessen serverseitige Compaction oder Kontextbearbeitung (Löschen von Tool-Ergebnissen für alte Tool-Ergebnisse) oder eine der clientseitigen Compaction-Formen in Kontext auf dem Server kürzen.
    • Einfügen von Inhalten, die du nicht dauerhaft speicherst, zum Beispiel eine Erinnerung pro Zug, die nach den tool_result-Blöcken angehängt und bei der nächsten Anfrage entfernt wird. Sende die Erinnerung stattdessen als zugbezogene System-Nachricht und belasse sie im Verlauf.
    • Neuaufbau des system-Prompts auf oberster Ebene oder des tools-Arrays zwischen Anfragen in derselben Konversation, zum Beispiel um das aktuelle Datum zu aktualisieren oder ein Tool hinzuzufügen oder zu entfernen. Hänge stattdessen eine System-Nachricht mitten in der Konversation an, die die neue Anweisung („The current date is 2026-09-14.“) oder tool_addition- und tool_removal-Blöcke enthält.
    • Eine Bild- oder Dokument-URL, die bei einer späteren Anfrage andere Bytes liefert. Die Prüfung bezieht sich auf die Bytes, nicht auf den URL-String, daher ist eine rotierende signierte URL für dieselbe Datei in Ordnung. Für Inhalte, auf die du über mehrere Züge hinweg verweist, lade sie einmal mit der Files API hoch und sende die file_id, oder sende base64.

    Jeder Ersatz hält außerdem frühere Züge byte-identisch und bewahrt die Treffer im Prompt-Cache, die durch das Bearbeiten des Verlaufs, des system-Prompts oder des tools-Arrays verloren gingen.

    Muster, die weiterhin funktionieren:

    • Nur anhängende Verläufe: Züge hinzufügen und frühere Züge genau so zurückgeben, wie sie gesendet und empfangen wurden, einschließlich angehängter role: "system"-Nachrichten.
    • Entfernen von Thinking-Blöcken aus früheren Assistant-Zügen, die ältesten zuerst.
    • Ändern von effort, max_tokens oder jedem anderen Request-Parameter außerhalb von system, tools und messages sowie Hinzufügen oder Verschieben von cache_control-Markern.
    • Serverseitige Compaction und Kontextbearbeitung, einschließlich Löschen von Thinking-Blöcken. Sie zählen nicht als Bearbeitungen, da die Prüfung die Konversation so vergleicht, wie du sie gesendet hast.

    Um eine bestehende Integration zu prüfen:

    1. Erfasse die exakten Request-Bodies, die sie über einige normale Züge hinweg sendet, einschließlich einer Compaction oder einer Tool-Änderung, falls dein Produkt diese hat. Vergleiche für jedes Paar aufeinanderfolgender Anfragen den system-Prompt, das tools-Array und das gemeinsame Präfix von messages. Sie sollten bis zu den neu angehängten Zügen byte-identisch sein.
    2. Führe eine normale mehrzügige Sitzung gegen claude-fable-5-1 mit dem Beta-Header thinking-binding-controls-2026-08-01 und prefix_mismatch_behavior: "drop_block" aus und protokolliere input_transformations bei jeder Antwort. Ein leeres Array in jedem Zug bedeutet, dass der Verlauf intakt ist. Ein Eintrag mit reason: "prefix_binding_mismatch" bedeutet, dass sich etwas vor dem Block bei path seit der vorherigen Anfrage geändert hat. Ein Eintrag mit reason: "model_binding_mismatch" bedeutet, dass die Konversation das Modell gewechselt hat, was kein Bug in deinem Code ist. Dies funktioniert von jedem Account aus, da das Setzen des Feldes die Anfrage für die Durchsetzung aktiviert. Setze in CI stattdessen "error", damit eine Bearbeitung den Lauf fehlschlagen lässt.
    3. Wähle eine Produktionseinstellung. Belasse den Standard "error", wenn eine Präfix-Abweichung nur einen Bug in deinem Code bedeuten kann, oder setze "drop_block", um die betroffenen Blöcke zu verwerfen, statt fehlzuschlagen, und überwache in beiden Fällen die 400er oder die input_transformations-Einträge.

    Das einmalige Verwerfen von Thinking-Blöcken, zum Beispiel an einer Compaction-Grenze, hat wenig Auswirkung. Eine Integration, die vorheriges Thinking bei jeder Anfrage ungültig macht, startet den Prompt-Cache jedes Mal neu, was die Kosten pro Aufgabe erhöhen kann (siehe Halte den Konversationsverlauf nur anhängend).

Verhaltensänderungen

  1. Weniger parallele Tool-Aufrufe in langen Agent-Schleifen: In lang laufenden Schleifen, in denen die nächsten unabhängigen Lesevorgänge nur durch die Aufgabe impliziert sind (benutzerdefinierte Coding-Agents, Bash-und-Editor-Harnesses, Computer Use), gibt Claude Fable 5.1 möglicherweise einen Tool-Aufruf pro Zug aus. Jeder zusätzliche Zug kostet Token, einen Roundtrip und Echtzeit. Hänge nach jeder User-Nachricht eine einsätzige Batching-Anweisung als zugbezogene System-Nachricht (clear_at: "next_user_message", Beta) an, oder, ohne die Beta, in einem Textblock nach den tool_result-Blöcken, und belasse die früheren Kopien bei späteren Anfragen im Verlauf. Siehe Unabhängige Tool-Aufrufe in Agent-Schleifen bündeln.

  2. Weniger Fortschrittsmeldungen zwischen Tool-Aufrufen: Claude Fable 5.1 schreibt während langer Tool-Sequenzen weniger Status-Updates als Claude Fable 5, und seine Zusammenfassungen beim agentischen Coding sind kürzer. Wenn deine Oberfläche diese Updates darstellt, setze thinking.display auf "updates" (Beta, Claude API) oder "summarized" und fordere sie explizit per Prompt an. Siehe Fortschritts-Updates zwischen Tool-Aufrufen und Nach nutzerseitigen Fortschritts-Updates fragen.

  3. Weniger Such- und Retrieval-Aufrufe bei niedrigem Effort: Bei low Effort antwortet Claude Fable 5.1 häufiger aus dem Gedächtnis als Claude Fable 5, statt ein Such- oder Retrieval-Tool aufzurufen. Wenn dein Produkt bei niedrigem Effort auf Retrieval angewiesen ist, erhöhe den Effort für diese Anfragen oder sage dem Modell, wann es suchen soll. Siehe Auslösen von Suchen bei niedrigem Effort.

Zu den Unterschieden bei Prosadichte, Chat-Formatierung, Zitaten in Zusammenfassungen und Dateibearbeitungen, die die API-Integration nicht betreffen, siehe Geändert gegenüber Claude Fable 5.

Diese Änderungen sind nicht erforderlich, aber jede senkt Kosten oder Latenz oder beseitigt einen Fehlermodus:

  1. Effort mitten in der Konversation ändern (Beta): Auf Claude Fable 5 gilt output_config.effort auf Request-Ebene, und eine Änderung zwischen Anfragen verwirft gecachte Präfixe aus früheren Zügen. Auf claude-fable-5-1 erhöht eine role: "system"-Nachricht, die nur output_config enthält, den Effort für einen schwierigen Schritt oder senkt ihn für Routineschritte, ohne den Prompt-Cache ungültig zu machen:

    client = anthropic.Anthropic()
    
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=4096,
        output_config={"effort": "high"},
        messages=[
            {
                "role": "user",
                "content": "Plan a migration from SQLite to PostgreSQL in three short steps.",
            },
            {
                "role": "assistant",
                "content": "1. Export the SQLite data. 2. Create the PostgreSQL schema. 3. Import the data and verify row counts.",
            },
            # Reine Effort-Systemnachricht: Die neue Stufe gilt ab dem nächsten User-Turn.
            {"role": "system", "content": [], "output_config": {"effort": "low"}},
            {"role": "user", "content": "Summarize the plan in one sentence."},
        ],
        betas=["mid-conversation-output-config-2026-07-01"],
    )
    
    for block in response.content:
        if block.type == "text":
            print(block.text)

    Der Wert gilt für den folgenden User-Zug und jeden späteren Zug, bis eine weitere role: "system"-Nachricht ihn ändert. Nur die benannten Stufen werden akzeptiert (low, medium, high, xhigh, max), und der Beta-Header mid-conversation-output-config-2026-07-01 ist erforderlich. Siehe Effort pro Nachricht.

  2. Anweisungen und Tools mit System-Nachrichten mitten in der Konversation ändern: Um Anweisungen oder Tools mitten in einer Sitzung zu ändern, hänge eine role: "system"-Nachricht an, mit tool_addition- und tool_removal-Blöcken für Tool-Änderungen (Beta-Header mid-conversation-tool-changes-2026-07-01, wobei der vollständige Tool-Satz zu Sitzungsbeginn in tools deklariert wird). Dies bewahrt Prompt-Cache-Treffer bei früheren Zügen und hält den Konversationsverlauf nur anhängend. Dieselbe Nachricht ersetzt erzwungenes tool_choice, wenn ein bestimmtes Tool im aktuellen Zug ausgeführt werden muss (siehe Breaking Changes). Für eine Erinnerung, die nur für einen Zug gilt, sende sie als separate reine Text-role: "system"-Nachricht mit clear_at: "next_user_message" (zugbezogene System-Nachrichten, Beta-Header mid-conversation-system-clear-at-2026-08-21) und belasse sie im Verlauf: Sie wird nach der nächsten User-Nachricht nicht mehr gerendert und kostet nach dem Löschen keine Token. Eine Nachricht, die tool_addition- oder tool_removal-Blöcke enthält, kann nicht zugbezogen sein.

  3. Verwende fallbacks: "default" für Ablehnungen: Behandle weiterhin stop_reason: "refusal" und lies stop_details.category vor dem Antwortinhalt. Um abgelehnte Anfragen automatisch auf einem anderen Modell erneut auszuführen, setze fallbacks: "default" (Beta, Header server-side-fallback-2026-07-01). "default" wiederholt eine abgelehnte Anfrage auf dem Modell, das Anthropic für diese Kategorie empfiehlt. Die zulässigen Fallback-Ziele für Claude Fable 5.1 sind Claude Opus 4.8 (claude-opus-4-8) und Claude Opus 5 (claude-opus-5). Eine explizite fallbacks-Liste kann eines der beiden nennen. Das Fallback-Modell erhält die Thinking-Blöcke von Claude Fable 5.1 nicht. Wenn du den Retry selbst baust, gilt die Fallback-Gutschrift zu denselben Bedingungen wie bei Claude Fable 5. Siehe Ablehnungen und Fallback.

  4. Beginne bei high Effort und führe einen Sweep durch: Der Standard des Effort-Parameters ist high, und alle fünf Stufen werden unterstützt. Behalte die Empfehlung für Claude Fable 5 bei: high für die meisten Arbeiten und medium als Kostenkontrolle, die einen Test wert ist. Die Zugewinne von Claude Fable 5.1 gegenüber Claude Fable 5 sind bei xhigh und max am größten, aber diese Stufen erhöhen auch die Denkzeit und die Zeit bis zur ersten Antwort, also steige für die fähigkeitssensibelsten Aufgaben und dort, wo deine Evals den Zugewinn zeigen, auf sie um. Führe einen neuen Sweep auf deinen eigenen Evals durch, statt eine für Claude Fable 5 abgestimmte Einstellung zu übernehmen. Siehe Empfohlene Effort-Stufen für Claude Fable 5.1.

  5. Kürze Kontext auf dem Server oder kompaktiere in einer Form, die kein veraltetes Thinking mitführt: Wenn dein Code ältere Züge auf dem Client abschneidet oder zusammenfasst, ist die einfachste Lösung, diese Arbeit auf serverseitige Compaction oder Kontextbearbeitung zu verlagern. Keines von beiden zählt als Bearbeitung, da die Verlaufsprüfung die Konversation so vergleicht, wie du sie gesendet hast, sodass nichts, was sie entfernen, spätere Thinking-Blöcke ungültig macht, und der instructions-Parameter der Compaction akzeptiert deinen eigenen Zusammenfassungs-Prompt. Wenn du die Compaction auf dem Client behältst, wähle eine von drei Formen:

    • Einfache Compaction (empfohlen): Ersetze den gesamten Verlauf durch eine Zusammenfassungsnachricht plus den neuen User-Zug und spiele nichts anderes erneut ab. Es werden keine Thinking-Blöcke übernommen, also schlägt nichts fehl. Claude-Modelle werden mit diesem Schema auf Aufgaben mit langem Horizont trainiert, und es schneidet für die meisten Workloads vergleichbar mit aufwendigeren Schemata ab.
    • Keep-Tail-Compaction: Wenn du die aktuellsten Züge wörtlich hinter einer Zusammenfassung behältst, entferne die thinking- und redacted_thinking-Blöcke aus diesen Zügen (Text und Tool-Aufrufe können bleiben) oder setze prefix_mismatch_behavior: "drop_block". Ihr Thinking wurde gegenüber dem vollständigen Verlauf erzeugt und schlägt andernfalls hinter der Zusammenfassung fehl.
    • Hintergrund-Compaction: Wenn du die Zusammenfassung abseits des kritischen Pfads erstellst und sie später einsetzt, trägt jeder in der Zwischenzeit erzeugte Zug Thinking, das vor dem Austausch entstanden ist. Sende "drop_block" bei jeder Anfrage, die noch Thinking-Blöcke enthält, die vor dem Austausch erzeugt wurden (oder entferne diese Blöcke selbst; input_transformations in der ersten Antwort nach dem Austausch listet genau auf, welche), oder kompaktiere synchron.

    Schneide keine einzelnen Züge aus der Mitte des Transkripts heraus: Das macht jeden späteren Thinking-Block ungültig, und keine clientseitige Form vermeidet das. Verwende eine System-Nachricht mitten in der Konversation für die Anweisungsänderung, die du vornehmen wolltest, oder serverseitige Kontextbearbeitung für selektives Entfernen. Siehe Compaction-Blöcke zurückgeben.

Migrations-Checkliste

  • Aktualisiere den Modellnamen von claude-fable-5 auf claude-fable-5-1 (oder claude-mythos-5 auf claude-mythos-5-1).
  • Ersetze erzwungenes tool_choice ({type: "any"} oder {type: "tool", ...}). Es gibt einen 400-Fehler zurück. Verwende {type: "auto"} plus eine explizite Anweisung und strict: true-Tools oder JSON-Ausgaben. Platziere die Anweisung im user-Turn oder in einer role: "system"-Nachricht mitten im Gespräch, wenn deine Anwendung den Aufruf erfordert.
  • Gib thinking-Blöcke weiterhin in jedem Turn unverändert zurück, einschließlich leerer Blöcke. Claude Fable 5.1 liest Blöcke von Claude Opus 5, Claude Fable 5, Claude Mythos 5 und früheren Modellen. Wenn ein Gespräch von Claude Fable 5.1 auf ein früheres Modell verschoben wird, werden dessen Blöcke verworfen (Claude Mythos 5.1 liest sie).
  • Wenn dein Code das messages-Array selbst aufbaut, prüfe, ob er frühere Turns bearbeitet: Führe eine Sitzung mit dem Beta-Header thinking-binding-controls-2026-08-01 und prefix_mismatch_behavior: "drop_block" aus, protokolliere input_transformations und behebe jeden prefix_binding_mismatch. model_binding_mismatch-Einträge nach einem Modellwechsel sind zu erwarten.
  • Halte den Gesprächsverlauf append-only: Friere system und tools beim Sitzungsstart ein und verschiebe Änderungen während der Sitzung in role: "system"-Nachrichten und tool_addition- / tool_removal-Blöcke, sende Erinnerungen pro Turn als Turn-bezogene Systemnachrichten, die du nie entfernst, kürze den Kontext serverseitig oder entferne Thinking-Blöcke aus allen Turns, die du über eine clientseitige Zusammenfassung hinweg mitnimmst, und referenziere Turn-übergreifende Dateien per file_id.
  • Wähle ein prefix_mismatch_behavior für die Produktion (standardmäßig "error" oder "drop_block") und überwache es. Wenn du ein Tool pflegst, das andere mit ihrem eigenen API-Key ausführen, teste mit gesetztem Feld: Neue Konten werden standardmäßig durchgesetzt, auch wenn deines es nicht ist.
  • Überprüfe Agent-Schleifen auf das Verhalten „ein Tool-Aufruf pro Turn“ und füge die Batching-Anweisung hinzu.
  • Wenn deine Oberfläche Fortschrittstext zwischen Tool-Aufrufen rendert, setze thinking.display auf "updates" (Beta) oder "summarized" und fordere per Prompt Updates an.
  • Wenn du den Effort zwischen Anfragen änderst, verschiebe die Änderung in eine role: "system"-Nachricht mit Effort pro Nachricht (Beta), um Cache-Treffer beizubehalten.
  • Behandle stop_reason: "refusal" und lies stop_details.category. Erwäge fallbacks: "default" (Beta).
  • Bewerte effort mit einem neuen Sweep neu, beginnend bei high, und erstelle eine neue Baseline für Kosten und Latenz auf deinen eigenen Workloads. Die Token-Anzahlen sind ungefähr unverändert. Prompt-Cache-Lesevorgänge kosten ein Viertel des Claude Fable 5-Tarifs.

Migration zu Claude Fable 5.1 von Claude Opus 5

Claude Fable 5.1 verwendet dieselben Muster der Messages API und der Tool-Nutzung wie Claude Opus 5. Es behält standardmäßig das Kontextfenster von 1M Token, 128k maximale Output-Token, das Prompt-Caching-Minimum von 512 Token und die Unterstützung für Systemnachrichten mitten im Gespräch bei. Die Prefill-Einschränkung, die Einschränkung der Sampling-Parameter und der Standardwert "omitted" für thinking.display werden ebenfalls übernommen. Wende alles aus Migration zu Claude Fable 5.1 von Claude Fable 5 an, plus das Folgende.

Aktualisiere deinen Modellnamen

model = "claude-opus-5"  # Before
model = "claude-fable-5-1"  # After

# Oder für das Project-Glasswing-Modell mit denselben Fähigkeiten:
model = "claude-mythos-5-1"  # After

Was sich geändert hat

  1. Thinking kann nicht mehr deaktiviert werden: Claude Opus 5 akzeptiert thinking: {type: "disabled"} bei einem Effort-Level von high oder niedriger. Auf claude-fable-5-1 und claude-mythos-5-1 ist adaptives Denken immer aktiv, und thinking: {type: "disabled"} gibt bei jedem Effort-Level einen 400-Fehler zurück. Entferne das Feld, steuere den Token-Verbrauch mit niedrigeren Effort-Levels und überprüfe max_tokens für Workloads, die mit deaktiviertem Thinking liefen.

  2. Erzwungene Tool-Auswahl wird nicht unterstützt: Claude Opus 5 akzeptiert tool_choice any und tool. claude-fable-5-1 gibt einen 400-Fehler zurück. Siehe Breaking Changes.

  3. Erhaltenes Thinking über Modelle hinweg: Claude Fable 5.1 liest die Thinking-Blöcke von Claude Opus 5: Gespräche, die von claude-opus-5 zu claude-fable-5-1 wechseln, behalten ihr Reasoning. Claude Opus 5 kann die Blöcke von Claude Fable 5.1 nicht lesen. Die Blöcke von Claude Fable 5.1 verlieren außerdem ihre Gültigkeit, wenn sich frühere Turns ändern: Wenn dein Code frühere Nachrichten bearbeitet, system oder tools neu aufbaut oder zwischen Anfragen auf dem Client komprimiert, hat Claude Opus 5 nicht widersprochen, aber claude-fable-5-1 lehnt jeden späteren Thinking-Block ab oder verwirft ihn. Führe die dreistufige Prüfung in diesem Abschnitt durch, bevor du den Traffic umstellst. Siehe Breaking Changes.

  4. Text zwischen Tool-Aufrufen wird in Thinking-Blöcken zurückgegeben: Auf Claude Opus 5 kommt Text, den das Modell zwischen Tool-Aufrufen schreibt, als text-Blöcke zurück. Auf claude-fable-5-1 kommt diese Erzählung, wie bei Claude Fable 5, als Fortschritts-Update-thinking-Blöcke zurück, jeweils einer vor jedem Tool-Aufruf. Unter dem Standardwert "omitted" für thinking.display enthalten sie keinen lesbaren Text. Wenn deine Oberfläche diese Erzählung rendert, setze display: "updates" (Beta, Claude API), um Fortschritts-Updates als Text zu erhalten, während das Reasoning verborgen bleibt, oder "summarized", um beides zu erhalten. Rendere dann die nicht leeren thinking-Blöcke zwischen tool_use-Blöcken. Siehe Fortschritts-Updates zwischen Tool-Aufrufen.

  5. Sicherheitsklassifikatoren und Fallback-Routing: Claude Fable 5.1 führt Sicherheitsklassifikatoren aus, die dieselben stop_details-Kategorien wie Claude Fable 5 abdecken, eine breitere Menge als die rein auf Cybersicherheit ausgerichteten Klassifikatoren von Claude Opus 5. Erwarte stop_details.category-Werte über "cyber" hinaus, wie "bio" und "reasoning_extraction"; siehe die Tabelle der Ablehnungskategorien für die vollständige Menge. Zur fallbacks-Konfiguration und zu zulässigen Zielen siehe Verwende fallbacks: "default" für Ablehnungen.

  6. Preise: 10 $ (USD) pro Million Input-Token und 50 $ (USD) pro Million Output-Token, verglichen mit 5 $ (USD) und 25 $ (USD) für Claude Opus 5. Prompt-Cache-Lesevorgänge kosten 0,25 $ (USD) pro Million Token, die Hälfte des Claude Opus 5-Tarifs. Siehe Claude-Preise.

  7. Datenaufbewahrung: Claude Fable 5.1 und Claude Mythos 5.1 erfordern eine 30-tägige Datenaufbewahrung, sind unter Zero-Data-Retention-Vereinbarungen (ZDR) nicht verfügbar, sofern nicht ausdrücklich von Anthropic genehmigt, und sind als Covered Models eingestuft. Claude Opus 5 ist unter ZDR verfügbar. Siehe Modellspezifische Anforderungen an die Datenaufbewahrung.

Migrations-Checkliste

  • Wenn deine Organisation eine Zero-Data-Retention-Vereinbarung (ZDR) hat, bestätige zuerst die Berechtigung: Diese Modelle sind unter ZDR nicht verfügbar, sofern nicht ausdrücklich von Anthropic genehmigt. Siehe Modellspezifische Anforderungen an die Datenaufbewahrung.
  • Aktualisiere den Modellnamen von claude-opus-5 auf claude-fable-5-1 (oder claude-mythos-5-1).
  • Entferne jegliche thinking: {type: "disabled"}-Konfiguration: Sie gibt auf claude-fable-5-1 einen 400-Fehler zurück. Steuere den Token-Verbrauch mit niedrigeren Effort-Levels und überprüfe max_tokens.
  • Ersetze erzwungenes tool_choice (any oder tool) durch auto plus eine explizite Anweisung (user-Turn oder Systemnachricht mitten im Gespräch) und strict: true-Tools oder durch JSON-Ausgaben.
  • Wenn deine Oberfläche Text zwischen Tool-Aufrufen rendert, setze display: "updates" (Beta) oder "summarized" und rendere die nicht leeren thinking-Blöcke.
  • Wende die Punkte zu erhaltenem Thinking, Verlaufsbearbeitung, Verhalten, Effort und Fallback aus der Claude Fable 5-Checkliste an.
  • Erstelle eine neue Kosten-Baseline auf deinen eigenen Workloads. Die Token-Anzahlen sind ungefähr unverändert. Die Preise pro Token unterscheiden sich.

Migration zu Claude Fable 5.1 von Claude Opus 4.8 oder früher

Wende zuerst Migration zu Claude Mythos 5 und Claude Fable 5 von Claude Opus 4.8 für die Änderungen auf API-Ebene gegenüber Claude Opus 4.8 an. Es behandelt adaptives Denken, Thinking-Ausgabe, Ablehnungen, Effort, das Caching-Minimum, Preise und Datenaufbewahrung. Wende dann das verbleibende Delta aus Migration zu Claude Fable 5.1 von Claude Fable 5 an. Bei Claude Opus 4.7 oder früher beginne mit dem passenden Abschnitt in Migration zu Claude Opus 5.

Aktualisiere deinen Modellnamen

model = "claude-opus-4-8"  # Before
model = "claude-fable-5-1"  # After

# Oder für das Project-Glasswing-Modell mit denselben Fähigkeiten:
model = "claude-mythos-5-1"  # After

Migrations-Checkliste

  • Wenn deine Organisation eine Zero-Data-Retention-Vereinbarung (ZDR) hat, bestätige zuerst die Berechtigung: Diese Modelle sind unter ZDR nicht verfügbar, sofern nicht ausdrücklich von Anthropic genehmigt. Claude Opus 4.8 ist unter ZDR verfügbar.
  • Aktualisiere den Modellnamen von claude-opus-4-8 auf claude-fable-5-1 (oder claude-mythos-5-1).
  • Entferne jegliche thinking: {type: "disabled"}-Konfiguration und überprüfe max_tokens. Anfragen ohne thinking-Feld laufen mit adaptivem Denken.
  • Ersetze erzwungenes tool_choice (any oder tool) durch auto plus eine explizite Anweisung (user-Turn oder Systemnachricht mitten im Gespräch) und strict: true-Tools oder durch JSON-Ausgaben.
  • Gib thinking-Blöcke unverändert zurück und behandle ihren Text als reine Anzeige. Claude Fable 5.1 liest die Thinking-Blöcke von Claude Opus 4.8: Ein Gespräch, das auf claude-fable-5-1 wechselt, behält sein früheres Reasoning. Claude Opus 4.8 kann die Blöcke von Claude Fable 5.1 nicht lesen.
  • Wenn dein Code das messages-Array selbst aufbaut, prüfe, ob er frühere Turns bearbeitet. Integrationen, die für Claude Opus 4.8 und früher geschrieben wurden, kürzen oft alte Turns, entfernen oder bauen frühere Nachrichten neu auf oder aktualisieren den system-Prompt bei jeder Anfrage, und Claude Opus 4.8 hat nie widersprochen. Auf claude-fable-5-1 macht jede dieser Aktionen spätere Thinking-Blöcke ungültig.
  • Behandle stop_reason: "refusal", lies stop_details.category und erwäge fallbacks: "default" (Beta).
  • Wende die Punkte zu erhaltenem Thinking, Verlaufsbearbeitung, Verhalten, Effort pro Nachricht und Fortschritts-Updates aus der Claude Fable 5-Checkliste an.
  • Bewerte effort neu (beginne bei high), überprüfe Prompts nahe dem Caching-Minimum von 512 Token und erstelle eine neue Baseline für Kosten und Latenz. Die Preise pro Token unterscheiden sich.

Migration zu Claude Mythos 5.1 von Claude Mythos 5

Claude Mythos 5.1 ist das zugangsbeschränkte Gegenstück zu Claude Fable 5.1. Bestätige den Zugang deiner Organisation mit deinem Anthropic-Account-Team, bevor du die Modell-IDs wechselst.

Das Delta auf API-Ebene entspricht Migration zu Claude Fable 5.1 von Claude Fable 5: Erzwungene Tool-Auswahl gibt einen 400-Fehler zurück, und Thinking-Blöcke werden nur für das Modell erhalten, das sie erzeugt hat, oder ein neueres (Claude Mythos 5.1 liest die Blöcke von Claude Mythos 5, nicht umgekehrt). Anders als Claude Fable 5.1 führt Claude Mythos 5.1 die Gesprächsprüfung nicht aus, sodass das Bearbeiten früherer Turns Thinking-Blöcke nicht ungültig macht, obwohl es den Prompt-Cache dennoch neu startet.

Aktualisiere deinen Modellnamen

model = "claude-mythos-5"  # Before
model = "claude-mythos-5-1"  # After

Migrations-Checkliste

  • Aktualisiere den Modellnamen von claude-mythos-5 auf claude-mythos-5-1.
  • Ersetze erzwungenes tool_choice (any oder tool) durch auto plus eine explizite Anweisung (user-Turn oder Systemnachricht mitten im Gespräch) und strict: true-Tools oder durch JSON-Ausgaben.
  • Behandle stop_reason: "refusal" und lies stop_details.category vor dem Antwortinhalt. Siehe Ablehnungen und Fallback.
  • Gib thinking-Blöcke weiterhin in jedem Turn unverändert zurück, einschließlich leerer Blöcke.
  • Wenn dein Code das messages-Array selbst aufbaut, halte den Gesprächsverlauf append-only, um den Prompt-Cache warm zu halten. Claude Mythos 5.1 führt die Gesprächsprüfung nicht aus, sodass Bearbeitungen seine Thinking-Blöcke nicht ungültig machen.
  • Wende die Verhaltensänderungen und empfohlenen Änderungen aus dem Claude Fable 5-Abschnitt an, mit Ausnahme der Punkte zur Verlaufsbearbeitung, die für Claude Mythos 5.1 nicht gelten.
  • Bewerte effort mit einem neuen Sweep neu und erstelle eine neue Baseline für Kosten und Latenz. Prompt-Cache-Lesevorgänge kosten ein Viertel des Claude Mythos 5-Tarifs.

Was this page helpful?