Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Prompt-Caches sind modellspezifisch. Wenn Claude Fable 5 eine Anfrage ablehnt und du sie auf einem anderen Modell erneut versuchst, muss das Konversationspräfix, das bereits für Claude Fable 5 gecacht war, von Grund auf in den Cache des neuen Modells geschrieben werden – und Cache-Schreibvorgänge kosten mehr als Cache-Lesevorgänge. Das „fallback credit" (Fallback-Guthaben) beseitigt diese zusätzlichen Kosten: Die Ablehnung enthält ein Guthaben-Token, du gibst das Token beim erneuten Versuch zurück, und der erneute Versuch wird so abgerechnet, als wäre die Konversation von Anfang an auf dem neuen Modell gewesen.
Du brauchst diese Seite nur, wenn du den erneuten Versuch selbst implementierst: mit dem Ruby- oder PHP-SDK, über rohes HTTP oder mit eigener Retry-Logik. Serverseitiger Fallback und die SDK-Middleware wenden das Fallback-Guthaben automatisch an. Wenn du eines von beiden verwendest, überspringe diese Seite.
Ablehnungen und Fallback behandelt das Erkennen von Ablehnungen und die Wahl eines Fallback-Ansatzes. Prompt-Caching erklärt Cache-Lesevorgänge und Cache-Schreibvorgänge, falls dir diese Begriffe neu sind.
Mit dem Beta-Header aktivieren
Sende die Anfrage, die möglicherweise abgelehnt wird, mit dem Header anthropic-beta: fallback-credit-2026-06-01. Der Header server-side-fallback-2026-06-01 stellt dieselben Felder ebenfalls bereit.
Zwei Felder aus der Ablehnung auslesen
Bei einer Ablehnung enthält stop_details das Feld fallback_credit_token, einen opaken String, der das Guthaben repräsentiert, und fallback_has_prefill_claim, einen Boolean, der dir sagt, welche Form des Retry-Bodys du verwenden sollst. Beide sind null, wenn für die Ablehnung kein Guthaben verfügbar ist.
Den erneuten Versuch erstellen
Beginne mit dem Body der abgelehnten Anfrage. Setze model auf das Fallback-Modell und füge das Token als Top-Level-Parameter fallback_credit_token hinzu. Wähle die Body-Form aus der Tabelle unten.
Den erneuten Versuch mit demselben Header senden
Sende den erneuten Versuch mit demselben Beta-Header fallback-credit-2026-06-01. Der erneute Versuch benötigt den Header, um das Token einzulösen.
Das Feld fallback_has_prefill_claim sagt dir, ob der erneute Versuch die Teilausgabe des abgelehnten Modells fortsetzen kann, anstatt von vorne zu beginnen:
fallback_has_prefill_claim | Retry-Body |
|---|---|
true | Der Body der abgelehnten Anfrage, unverändert, plus eine angehängte Assistant-Nachricht, deren content den content der abgelehnten Antwort wiedergibt. Das Retry-Modell setzt die Antwort dort fort, wo das abgelehnte Modell aufgehört hat, und abgeschlossene Server-Tool-Aufrufe werden nicht erneut ausgeführt. |
false | Der Body der abgelehnten Anfrage, unverändert. |
Das folgende Beispiel stellt eine Anfrage, die möglicherweise abgelehnt wird, löst das Guthaben-Token bei einem erneuten Versuch gegen Claude Opus 4.8 ein und stuft sich durch die Ablehnungsleiter herab, die unter Wenn ein erneuter Versuch abgelehnt wird behandelt wird.
Fallback-Guthaben ist in der Beta-Phase auf der Claude API, Claude Platform on AWS, Amazon Bedrock, Vertex AI und Microsoft Foundry verfügbar. Guthaben-Token, die in Ergebnissen von Message Batches zurückgegeben werden, können nicht eingelöst werden; die Einlösung gilt nur für direkte Messages-API-Anfragen.
Das Retry-Modell muss eines der zulässigen Fallback-Ziele des abgelehnten Modells sein. Zum Start ist das zulässige Ziel von Claude Fable 5 Claude Opus 4.8 (claude-opus-4-8).
Die Rückerstattung ist im usage des erneuten Versuchs sichtbar: cache_creation_input_tokens ist niedriger und cache_read_input_tokens ist um denselben Betrag höher, als dieselbe Anfrage ohne das Token melden würde. Eine Verschiebung von null bedeutet, dass das Token akzeptiert wurde, aber nichts neu zu bepreisen war, zum Beispiel weil der Cache des Retry-Modells bereits warm war.
Die meisten erneuten Versuche werden beim ersten Anlauf eingelöst. Wenn nicht, gibt die API einen 400-Fehler zurück, der dir sagt, was du als Nächstes versuchen sollst.
Fortsetzung abgelehnt: den unveränderten Body erneut senden
Wenn der erneute Versuch, der die Assistant-Nachricht anhängt, mit einem 400-Fehler abgelehnt wird, sende den Body der abgelehnten Anfrage unverändert erneut, weiterhin mit dem Token.
Token abgelehnt: das Token weglassen
Wenn der unveränderte Body ebenfalls mit einem 400-Fehler abgelehnt wird, dessen Nachricht fallback_credit_token nennt, versuche es ohne das Token erneut. Das Guthaben verfällt, aber der erneute Versuch selbst geht durch.
Wenn die abgelehnte Anfrage Server-Tools ausgeführt hat, führt ein erneuter Versuch ohne Token diese Tools erneut aus und berechnet sie erneut. Gib in diesem Fall den 400-Fehler an deinen Aufrufer weiter, anstatt zu einem tokenlosen erneuten Versuch durchzufallen.
Die folgenden Abschnitte behandeln Sonderfälle und die vollständigen Einlösungsregeln. Die meisten Integrationen benötigen sie nicht.
Erkenne Ablehnungen und wähle zwischen serverseitigem Fallback, der SDK-Middleware und einem manuellen erneuten Versuch.
Wie Cache-Lesevorgänge und Cache-Schreibvorgänge abgerechnet werden.
Was this page helpful?
client = Anthropic()
request = {
"max_tokens": 1024,
"messages": [{"role": "user", "content": "Hello, Claude"}],
}
def send(model, body):
return client.beta.messages.create(
model=model, betas=["fallback-credit-2026-06-01"], **body
)
response = send("claude-fable-5", request)
if (
response.stop_reason == "refusal"
and (details := response.stop_details)
and (token := details.fallback_credit_token)
):
exact_body = request | {"fallback_credit_token": token}
# Bevorzuge die Fortsetzungsform, außer die Behauptung ist False
if details.fallback_has_prefill_claim is not False:
# Gib den Inhalt der Ablehnung wieder und entferne nachgestellte Leerzeichen aus einem
# abschließenden Textblock (der Prefill-Validator lehnt sie ab; der serverseitige
# Abgleich toleriert die Änderung). Anfragen mit Tool-Nutzung lassen zudem ungepaarte
# tool_use-Blöcke weg und entfernen nach den Auslassungen erneut Leerzeichen.
echoed = [block.model_dump() for block in response.content]
match echoed:
case [*_, {"type": "text"} as final_block]:
final_block["text"] = final_block["text"].rstrip()
attempt = exact_body | {
"messages": [
*request["messages"],
{"role": "assistant", "content": echoed},
]
}
else:
attempt = exact_body
try:
response = send("claude-opus-4-8", attempt)
except BadRequestError as error:
if "redemption temporarily unavailable" in str(error):
raise # Transient: retry with the token within its five-minute window
try:
# Greife auf den unveränderten Body zurück, weiterhin mit dem Token
response = send("claude-opus-4-8", exact_body)
except BadRequestError as error:
if "redemption temporarily unavailable" in str(error):
raise # Transient: retry with the token within its five-minute window
# Das Token selbst wurde abgelehnt: gib es auf und versuche es ohne erneut.
response = send("claude-opus-4-8", request)
print(json.dumps({"stop_reason": response.stop_reason, "model": response.model}))Jeder stop_reason-Wert und wie du ihn behandelst.