Claude Platform Docs
Modelle & PreiseClaude Fable 5.1

Migrationsleitfaden für Claude Fable 5.1 und Claude Mythos 5.1

Wechsle mit diesem Migrationsleitfaden 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. Die Anleitung zur Aktivierung von Claude Fable 5.1 und Claude Mythos 5.1 umfasst Modell-IDs, Breaking Changes und Migrations-Checklisten.

Claude Fable 5.1 ist der Nachfolger von Claude Fable 5 zu denselben Input- und Output-Preisen, wobei Cache-Lesevorgänge nur ein Viertel kosten. Es ist über die Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud und Microsoft Foundry verfügbar. Claude Mythos 5.1 verfügt über dieselben Fähigkeiten und ist nur für Organisationen verfügbar, die über die Verifizierungsprogramme von Anthropic verifiziert wurden, etwa das Cyber Verification Program. Informationen zu Verhaltensunterschieden und Prompting-Mustern findest du unter Prompting für Claude Fable 5.1.

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

  • Nachdenken: Adaptive thinking (adaptives Nachdenken) ist immer aktiviert, unverändert gegenüber Claude Fable 5. Das Modell bestimmt, wann und wie viel es nachdenkt. Es ist keine thinking-Konfiguration erforderlich. Sowohl thinking: {type: "disabled"} als auch manuelles erweitertes Nachdenken (thinking: {type: "enabled", budget_tokens: N}) geben einen 400-Fehler zurück.
  • Prefill: Das Vorausfü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.
  • Bewahrtes Nachdenken ü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 Ausgabe: Standardmäßig ein Kontextfenster mit 1M Token und bis zu 128k Output-Token pro Anfrage.
  • Preise: 10 $ USD pro Million Input-Token und 50 $ USD pro Million Output-Token, genauso wie bei Claude Fable 5. Prompt-Cache-Lesevorgänge kosten 0,25 $ USD pro Million Token, ein Viertel des Tarifs von Claude Fable 5. Siehe Claude-Preise.
  • Datenaufbewahrung: Beide Modelle erfordern eine 30-tägige Datenaufbewahrung, sind unter Vereinbarungen zur „zero data retention" (Null-Datenaufbewahrung), oder ZDR, nicht verfügbar, sofern dies nicht ausdrücklich von Anthropic genehmigt wurde, und sind als Covered Models eingestuft, genauso wie Claude Fable 5 und Claude Mythos 5. Über die 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 sich an ihr Anthropic-Account-Team wenden oder die Aufbewahrung pro Workspace konfigurieren. Details pro Plattform findest du unter Modellspezifische Anforderungen an die Datenaufbewahrung.

Wo sich die beiden Modelle unterscheiden:

  • Verfügbarkeit: Claude Fable 5.1 erfordert keine Zugangsgenehmigung. Claude Mythos 5.1 ist nur für Organisationen verfügbar, die über die Verifizierungsprogramme von Anthropic verifiziert wurden, etwa das Cyber Verification Program. Um Zugang zu beantragen, bewirb dich für das Programm, das deinen Anwendungsfall abdeckt, oder wende dich an dein Anthropic-Account-Team.
  • Priority Tier: Keines der beiden Modelle wird auf Priority Tier unterstützt. Claude Fable 5 schon.

Migration von Claude Fable 5 zu Claude Fable 5.1

Die Migration ist weitgehend ein direkter Austausch. API-Oberfläche, Limits, Preise pro Token, Tokenizer, das immer aktive adaptive Nachdenken, 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; nur Claude Fable 5.1 und Claude Mythos 5.1 lesen die Thinking-Blöcke von Claude Fable 5.1, und zwar nur in der Konversation, in der sie erzeugt wurden; 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 für Thinking-Blöcke, 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 Claude Mythos 5.1, das verifizierten Organisationen dieselben Funktionen bietet:
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. Bei 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, für Claude-Fable-Modelle 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 Benutzer, einen bestimmten Tool-Aufruf im aktuellen Turn einer Multi-Turn-Konversation erfordert, hänge nach dem letzten user-Turn eine Systemnachricht mitten in der Konversation an. Nenne das Tool, gib an, dass der Aufruf für diesen Turn 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 Turns byte-identisch und behalten ihre Prompt-Cache-Treffer:

    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 vor jeder Richtlinien-Antwort eine Suche im
        # Hilfe-Center. Wird die Anforderung als System-Nachricht 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 Turn. Systemnachrichten mitten in der Konversation benötigen keinen Beta-Header. tool_choice: {"type": "none"} funktioniert weiterhin für einen Turn, in dem keine Tools aufgerufen werden dürfen.

  2. Nur Claude Fable 5.1 und Claude Mythos 5.1 lesen die Thinking-Blöcke von Claude Fable 5.1: Jeder thinking-Block hält fest, welches Modell ihn erzeugt hat. Claude Fable 5.1 liest seine eigenen Blöcke sowie 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 zu claude-fable-5-1 wechselt, behält ihr früheres Reasoning. 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 anderen Modell landen, älter oder neuer. 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 dieses Reasoning neu, was Kosten und Latenz im ersten Turn 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 Modellwechsel mitten im Gespräch.

  3. Das Bearbeiten früherer Turns macht Thinking-Blöcke ungültig: Jeder thinking-Block von Claude Fable 5.1 ist nur in Bezug auf den system-Prompt, die tools und den Konversationsverlauf gültig, die ihm vorausgingen. Wenn Claude Code, claude.ai, Claude Managed Agents oder das Claude Agent SDK deinen Konversationsverlauf verwaltet, bleibt dieses Präfix bereits intakt. Wenn dein Code das messages-Array selbst aufbaut, betrifft dich dieser Punkt, und Erhaltenes Nachdenken ist der vollständige Integrationsleitfaden. Wo die Prüfung durchgesetzt wird, wird eine Anfrage, die den Block zurücksendet, nachdem sich eines davon 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 Konten durch, die am oder nach dem 31. August 2026 erstellt wurden. Bei früher erstellten Konten protokolliert die API die Abweichung, reagiert aber nicht darauf, es sei denn, die Anfrage setzt thinking.block_binding.prefix_mismatch_behavior, womit die Durchsetzung aktiviert wird. Wenn du bei diesen Konten den Beta-Header thinking-binding-controls-2026-08-01 sendest und dieses Feld nicht setzt, listet die Antwort jeden Block, der die Prüfung nicht bestanden hat, in input_transformations als thinking_mismatch_allowed-Eintrag auf. Mache deine Anwendung unabhängig vom Alter deines Kontos mit der Prüfung kompatibel: Dieselben Muster halten den Prompt-Cache warm, und du kannst von jedem Konto 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 auf diese Weise vor dem Launch: Dein Key gehört wahrscheinlich zu einem älteren Konto, und deine Benutzer mit neuen Konten stoßen vor dir auf die Prüfung. Um zu sehen, ob die Prüfung für dein eigenes Konto standardmäßig durchgesetzt wird, sende eine Anfrage, die den Verlauf bearbeitet, ohne den Beta-Header: Ein 400-Fehler, der den Header nennt, bedeutet, dass dies der Fall ist.

    Der Fehler ist für diesen Anfrage-Body dauerhaft: Eine automatische Retry-Schleife behebt ihn nicht. Um ohne das ungültig gewordene Reasoning 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 Steuerung für nicht bewahrte Blöcke (Beta) für die Form der Antwort 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 Turns. Dazu gehören das Löschen alter Tool-Ergebnisse, das Herausschneiden von Turns aus der Mitte des Transkripts und clientseitige Compaction, die aktuelle Turns und ihre Thinking-Blöcke wörtlich hinter einer Zusammenfassung behält (einschließlich Hintergrund-Compaction, die ihre Zusammenfassung einige Turns 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 unter Kontext auf dem Server kürzen.
    • Einfügen von Inhalten, die du nicht persistierst, zum Beispiel eine Erinnerung pro Turn, die nach den tool_result-Blöcken angehängt und bei der nächsten Anfrage entfernt wird. Sende die Erinnerung stattdessen als turn-bezogene Systemnachricht 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 Systemnachricht mitten in der Konversation an, die die neue Anweisung („Das aktuelle Datum ist 2026-09-14.“) oder tool_addition- und tool_removal-Blöcke enthält. Ein Tool, das zu Beginn nicht in tools deklariert wurde, kann innerhalb des tool_addition-Blocks definiert werden (Beta-Header inline-tools-2026-09-15).
    • Eine Bild- oder Dokument-URL, die bei einer späteren Anfrage andere Bytes liefert. Die Prüfung umfasst die Bytes, nicht den URL-String, daher ist eine rotierende signierte URL für dieselbe Datei in Ordnung. Für Inhalte, auf die du über mehrere Turns 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 Turns byte-identisch und bewahrt die Prompt-Cache-Treffer, die durch das Bearbeiten des Verlaufs, des system-Prompts oder des tools-Arrays verloren gehen würden.

    Muster, die weiterhin funktionieren:

    • Append-only-Verläufe: Turns hinzufügen und frühere Turns 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-Turns, beginnend mit den ältesten.
    • Ändern von effort, max_tokens oder einem anderen Anfrageparameter außerhalb von system, tools und messages sowie Hinzufügen oder Verschieben von cache_control-Markierungen.
    • 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.

    So prüfst du eine bestehende Integration:

    1. Erfasse die genauen Anfrage-Bodys, die sie über einige normale Turns 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 Turns byte-identisch sein. Eine erwartete Ausnahme ist eine Anfrage, die einen signierten compaction-Block aus On-Demand-Compaction einsetzt: Der Block ersetzt die Nachrichten, die er zusammenfasst, am Anfang von messages, und alles danach sollte weiterhin übereinstimmen.
    2. Führe eine normale Multi-Turn-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 bei jedem Turn bedeutet, dass der Verlauf intakt ist. Ein Eintrag mit reason: "prefix_binding_mismatch" bedeutet, dass sich seit der vorherigen Anfrage etwas vor dem Block bei path geändert hat. Ein Eintrag mit reason: "model_binding_mismatch" bedeutet, dass die Konversation das Modell gewechselt hat, was kein Fehler in deinem Code ist. Dies funktioniert von jedem Konto aus, da das Setzen des Feldes die Durchsetzung für die Anfrage 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 Fehler 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 400-Fehler 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 bei jeder Anfrage vorheriges Nachdenken ungültig macht, startet den Prompt-Cache jedes Mal neu, was die Kosten pro Aufgabe erhöhen kann (siehe Den Gesprächsverlauf append-only halten).

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 Statusupdates 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) oder "summarized" und fordere sie explizit im Prompt an. Siehe Fortschrittsupdates zwischen Tool-Aufrufen und Nach benutzerseitigen Fortschrittsupdates fragen.

  3. Weniger Such- und Abrufaufrufe bei niedrigem Effort: Bei low Effort antwortet Claude Fable 5.1 häufiger als Claude Fable 5 aus dem Gedächtnis, statt ein Such- oder Abruf-Tool aufzurufen. Wenn dein Produkt bei niedrigem Effort auf Abruf 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 eine Fehlerquelle:

  1. Effort mitten in der Konversation ändern (Beta): Bei Claude Fable 5 gilt output_config.effort auf Anfrageebene, und eine Änderung zwischen Anfragen verwirft gecachte Präfixe aus früheren Turns. Bei 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)

    Wird die Nachricht wie hier zwischen einem assistant-Turn und dem nächsten user-Turn platziert, wirkt sie ab diesem user-Turn. Wird sie direkt nach einem user-Turn mit neuem Input platziert, legt sie die Stufe für Claudes Antwort auf diesen Turn fest. Ein user-Turn, der nur Tool-Ergebnisse enthält, zählt nicht als neuer Input: Die Änderung wartet auf den nächsten user-Turn mit neuem Input. Die Stufe gilt dann, bis eine andere role: "system"-Nachricht sie ä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 Systemnachrichten mitten in der Konversation ändern: Um Anweisungen oder Tools während 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 inline-tools-2026-09-15 in der Claude API). Ein tool_addition-Block kann ein Tool benennen, das zu Sitzungsbeginn in tools deklariert wurde, oder die vollständige Definition des Tools enthalten, sodass ein Tool, das zu Sitzungsbeginn unbekannt ist, nicht in tools stehen muss. Dies bewahrt Prompt-Cache-Treffer bei früheren Turns und hält den Konversationsverlauf append-only. Der ältere Header mid-conversation-tool-changes-2026-07-01 funktioniert weiterhin für Änderungen, die ein Tool per Referenz benennen, in der Claude API, Amazon Bedrock und Google Cloud. Dieselbe Nachricht ersetzt erzwungenes tool_choice, wenn ein bestimmtes Tool im aktuellen Turn ausgeführt werden muss (siehe Breaking Changes). Für eine Erinnerung, die nur für einen Turn gilt, sende sie als separate reine Text-role: "system"-Nachricht mit clear_at: "next_user_message" (turn-bezogene Systemnachrichten, Beta-Header mid-conversation-system-clear-at-2026-08-21) und belasse sie im Verlauf: Sie wird nach der nächsten Benutzernachricht 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 turn-bezogen 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. Der Parameter fallbacks ist auf Amazon Bedrock, Google Cloud oder Microsoft Foundry nicht verfügbar. Verwende auf diesen Plattformen stattdessen clientseitigen Fallback. Wenn du den Retry selbst baust, gilt die Fallback-Gutschrift zu denselben Bedingungen wie bei Claude Fable 5. Siehe Ablehnungen und Fallback.

  4. Beginne mit high Effort und teste systematisch: 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 Aufgaben und medium als Kostenkontrolle, die einen Test wert ist. Die Verbesserungen 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 Nachdenkzeit und die Zeit bis zur ersten Antwort, also setze sie für die anspruchsvollsten Aufgaben ein und dort, wo deine Evals den Gewinn zeigen. Führe einen neuen Durchlauf mit deinen eigenen Evals durch, statt eine für Claude Fable 5 abgestimmte Einstellung zu übernehmen. Siehe Empfohlene Effort-Level für Claude Fable 5.1.

  5. Kürze den Kontext auf dem Server oder komprimiere in einer Form, die kein veraltetes Nachdenken mitführt: Wenn dein Code ältere Turns auf dem Client kürzt 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 aktuelle Turns wörtlich hinter der Zusammenfassung behältst oder im Hintergrund zusammenfasst, während die Konversation weiterläuft, verwende On-Demand-Compaction (Beta-Header compact-2026-09-04) statt einer vom Client geschriebenen Zusammenfassung. Die API schreibt einen signierten Zusammenfassungsblock, den du anstelle der zusammengefassten Nachrichten einsetzt. Die Thinking-Blöcke in den Turns, die du behältst, können gültig bleiben, unter den Bedingungen in Komprimierung und beibehaltenes Nachdenken. 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 Benutzer-Turn und spiele nichts anderes erneut ein. 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 bei den meisten Workloads vergleichbar mit aufwendigeren Schemata ab.
    • Keep-Tail-Compaction: Wenn du die neuesten Turns wörtlich hinter einer Zusammenfassung behältst, entferne die thinking- und redacted_thinking-Blöcke aus diesen Turns (Text und Tool-Aufrufe können bleiben), oder setze prefix_mismatch_behavior: "drop_block". Ihr Nachdenken wurde gegen den vollständigen Verlauf erzeugt und schlägt hinter der Zusammenfassung andernfalls fehl.
    • Hintergrund-Compaction: Wenn du die Zusammenfassung abseits des kritischen Pfads erstellst und später einsetzt, enthält jeder in der Zwischenzeit erzeugte Turn Nachdenken, das vor dem Austausch entstanden ist. Sende "drop_block" bei jeder Anfrage, die noch vor dem Austausch erzeugte Thinking-Blöcke enthält (oder entferne diese Blöcke selbst; input_transformations in der ersten Antwort nach dem Austausch listet genau auf, welche), oder komprimiere synchron.

    Schneide keine einzelnen Turns aus der Mitte des Transkripts heraus: Das macht jeden späteren Thinking-Block ungültig, und keine clientseitige Form vermeidet das. Verwende eine Systemnachricht mitten in der Konversation für die Anweisungsänderung, die du vornehmen wolltest, oder serverseitige Kontextbearbeitung für selektives Entfernen. Siehe Komprimierungsblö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 in der Konversation, 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 eine Konversation von Claude Fable 5.1 zu einem anderen Modell als Claude Mythos 5.1 wechselt, werden ihre Blöcke verworfen.
  • 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 jedes prefix_binding_mismatch. model_binding_mismatch-Einträge nach einem Modellwechsel sind zu erwarten.
  • Halte den Konversationsverlauf nur anhängend: Friere system und tools zu Sitzungsbeginn ein und verlagere Änderungen während der Sitzung in role: "system"-Nachrichten und tool_addition- / tool_removal-Blöcke, sende Erinnerungen pro Turn als turn-bezogene System-Nachrichten, die du nie entfernst, kürze den Kontext serverseitig oder entferne Thinking-Blöcke aus allen Turns, die du über eine clientseitige Zusammenfassung hinweg mitführst, und verweise auf 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: Für neue Konten wird die Prüfung standardmäßig durchgesetzt, auch wenn das für deines nicht gilt.
  • Überprüfe Agent-Loops auf das Verhalten mit einem Tool-Aufruf pro Turn und füge die Batching-Anweisung hinzu.
  • Wenn deine Oberfläche Fortschrittstext zwischen Tool-Aufrufen darstellt, setze thinking.display auf "updates" (Beta) oder "summarized" und fordere Updates im Prompt an.
  • Wenn du den Effort zwischen Anfragen änderst, verlagere die Änderung in eine role: "system"-Nachricht für Effort pro Nachricht (Beta), um Cache-Treffer zu behalten.
  • Behandle stop_reason: "refusal" und lies stop_details.category. Ziehe fallbacks: "default" (Beta) in Betracht.
  • Bewerte effort mit einem neuen Sweep neu, beginnend bei high, und ermittle Kosten und Latenz für deine eigenen Workloads neu. Der Tokenizer ist 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 Claude Mythos 5.1, das verifizierten Organisationen dieselben Fähigkeiten bietet:
model = "claude-mythos-5-1"  # After

Was sich geändert hat

  1. Nachdenken kann nicht mehr deaktiviert werden: Claude Opus 5 akzeptiert thinking: {type: "disabled"} bei einem Effort-Level von high oder niedriger. Bei claude-fable-5-1 und claude-mythos-5-1 ist adaptives Nachdenken immer aktiviert, 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 Nachdenken 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. Bewahrtes Nachdenken über Modelle hinweg: Claude Fable 5.1 liest die Thinking-Blöcke von Claude Opus 5: Konversationen, 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 werden außerdem ungültig, wenn sich frühere Turns ändern: Wenn dein Code zwischen Anfragen frühere Nachrichten bearbeitet, system oder tools neu aufbaut oder auf dem Client komprimiert, hatte Claude Opus 5 nichts dagegen, 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 Traffic umstellst. Siehe Breaking Changes.

  4. Text zwischen Tool-Aufrufen wird in Thinking-Blöcken zurückgegeben: Bei Claude Opus 5 wird Text, den das Modell zwischen Tool-Aufrufen schreibt, als text-Blöcke zurückgegeben. Bei claude-fable-5-1 wird diese Erzählung, wie bei Claude Fable 5, als Fortschritts-thinking-Blöcke zurückgegeben, einer vor jedem Tool-Aufruf. Mit dem Standardwert "omitted" für thinking.display enthalten sie keinen lesbaren Text. Wenn deine Oberfläche diese Erzählung darstellt, setze display: "updates" (Beta), um Fortschrittsmeldungen als Text zu erhalten, während das Reasoning verborgen bleibt, oder "summarized", um beides zu erhalten. Stelle dann die nicht leeren thinking-Blöcke zwischen tool_use-Blöcken dar. Siehe Fortschrittsmeldungen 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 Klassifikatoren von Claude Opus 5. Rechne mit zusätzlichen stop_details.category-Werten, etwa "bio"; die vollständige Menge findest du in der Tabelle der Ablehnungskategorien. 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 Tarifs von Claude Opus 5. Siehe Claude-Preise.

  7. Datenaufbewahrung: Claude Fable 5.1 und Claude Mythos 5.1 erfordern eine 30-tägige Datenaufbewahrung, sind unter Vereinbarungen zur Null-Datenaufbewahrung (ZDR) nicht verfügbar, sofern dies nicht ausdrücklich von Anthropic genehmigt wurde, 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 Vereinbarung zu „zero data retention" (Null-Datenaufbewahrung), oder ZDR, hat, bestätige zuerst die Berechtigung: Diese Modelle sind unter ZDR nicht verfügbar, sofern Anthropic dies nicht ausdrücklich genehmigt hat. Siehe Modellspezifische Anforderungen an die Datenaufbewahrung.
  • Aktualisiere den Modellnamen von claude-opus-5 auf claude-fable-5-1 (oder claude-mythos-5-1).
  • Entferne jede thinking: {type: "disabled"}-Konfiguration: Sie gibt bei claude-fable-5-1 einen 400-Fehler zurück. Steuere den Token-Verbrauch mit niedrigeren effort-Stufen und überprüfe max_tokens.
  • Ersetze erzwungenes tool_choice (any oder tool) durch auto plus eine explizite Anweisung (user-Turn oder System-Nachricht mitten in der Konversation) 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 „preserved thinking" (erhaltenes Nachdenken), Verlaufsbearbeitung, Verhalten, Effort und Fallback aus der Claude Fable 5-Checkliste an.
  • Ermittle die Kosten für deine eigenen Workloads neu. Der Tokenizer ist unverändert. Die Preise pro Token unterscheiden sich.

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

Arbeite die folgende Checkliste durch. Wenn du Claude Opus 4.7 oder früher verwendest, beginne mit dem entsprechenden Abschnitt im Migrationsleitfaden für Claude Opus 5.5.

Aktualisiere deinen Modellnamen

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

# Oder für Claude Mythos 5.1, das verifizierten Organisationen dieselben Fähigkeiten bietet:
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 Nachdenken.
  • Aktualisiere das Parsen von Antworten, das Inhalte nach Position liest, etwa content[0].text: Eine Antwort kann jetzt mit thinking-Blöcken beginnen, wähle Inhaltsblöcke daher stattdessen nach type aus.
  • 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 mit high), überprüfe Prompts nahe dem Caching-Minimum von 512 Token (1.024 Token bei Claude Opus 4.8) und ermittle Kosten und Latenz neu. Die Preise pro Token unterscheiden sich, und Thinking-Token werden als Output-Token abgerechnet, sodass Workloads, die auf Claude Opus 4.8 ohne Nachdenken liefen, mehr Output-Token pro Anfrage erzeugen können.

Migration zu Claude Mythos 5.1 von Claude Mythos 5

Claude Mythos 5.1 ist das Gegenstück zu Claude Fable 5.1 für Organisationen, die über die Verifizierungsprogramme von Anthropic verifiziert wurden, wie etwa das Cyber Verification Program. Bestätige, dass deine Organisation Zugriff auf Claude Mythos 5.1 hat, bevor du die Modell-IDs wechselst.

Die Unterschiede auf API-Ebene entsprechen Migration von Claude Fable 5 zu Claude Fable 5.1: Erzwungene Tool-Auswahl gibt einen 400-Fehler zurück, und nur Claude Mythos 5.1 und Claude Fable 5.1 lesen die Thinking-Blöcke von Claude Mythos 5.1 (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 Konversationsprüfung nicht durch, sodass das Bearbeiten früherer Turns Thinking-Blöcke nicht ungültig macht, den Prompt-Cache aber 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?