Ablehnungen bei Claude richtig behandeln

TL;DR

Wenn die Sicherheitsklassifikatoren eine Anfrage ablehnen, bekommen Sie HTTP 200 mit stop_reason: "refusal" und leerem oder unvollständigem Inhalt — keinen Fehler. Code, der ungeprüft auf content[0] zugreift, bricht. Und die Ausweichroute auf ein anderes Modell ist nicht voreingestellt; ohne sie bleibt die Anfrage einfach stehen.

Das Fehlerbild

antwort = client.messages.create(model="claude-opus-5", max_tokens=1024,
                                 messages=[...])
print(antwort.content[0].text)     # IndexError bei einer Ablehnung

Kein Ausnahmefehler, kein Statuscode über 400. Die Antwort ist formal erfolgreich, content ist aber leer. Der richtige Ablauf prüft zuerst:

antwort = client.messages.create(model="claude-opus-5", max_tokens=1024,
                                 messages=[...])

if antwort.stop_reason == "refusal":
    kategorie = getattr(antwort.stop_details, "category", None)
    ablehnung_behandeln(kategorie)
else:
    print(next(b.text for b in antwort.content if b.type == "text"))

Verzweigen Sie über stop_reason, nie über stop_details. Letzteres ist rein informativ und kann auch bei einer Ablehnung null sein; ein explanation-Feld ist nicht garantiert vorhanden.

Zwei Zeitpunkte, zwei Abrechnungen

Die Ablehnung kann an zwei Stellen greifen, und der Unterschied zählt:

Vor jeder Ausgabe — content ist leer. Diese Anfrage wird gar nicht berechnet: keine Eingabe-Token, keine Ausgabe-Token, kein Verbrauch von Kontingenten.

Mitten im Strom — nach bereits erzeugter Teilausgabe. Das bereits Gesendete wird regulär berechnet. Behandeln Sie die Teilausgabe als unbrauchbar und verwerfen Sie sie, statt sie als vollständige Antwort zu deuten.

Für die Kostenüberwachung heißt das: Ablehnungen vor der Ausgabe tauchen in der Rechnung nicht auf, aber in der Fehlerquote — messen Sie beides getrennt.

Wen es betrifft

Die Klassifikatoren sind bei Claude Opus 5 und Claude Fable 5 erhöht und zielen auf Forschungsbiologie und den Großteil sicherheitsbezogener Inhalte. Falsch positive Treffer bei legitimer Arbeit sind möglich — Sicherheitswerkzeuge, Analysen im Umfeld der Lebenswissenschaften, Penetrationstest-Auswertungen.

Das ist der Grund, warum eine Ausweichstrategie auch für vollkommen unbedenkliche Anwendungen sinnvoll ist. Wer in diesen Feldern arbeitet, sollte sie einplanen.

Die Ausweichroute — standardmäßig einbauen

Ohne Konfiguration bleibt eine abgelehnte Anfrage einfach stehen. Der empfohlene Weg ist der serverseitige Mechanismus mit automatischer Modellwahl:

antwort = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    betas=["server-side-fallback-2026-07-01"],
    fallbacks="default",
    messages=[...],
)

"default" wählt das empfohlene Ersatzmodell nach Ablehnungskategorie aus — Ablehnungen aus dem Sicherheitsbereich werden etwa auf Claude Opus 4.8 geleitet. Das ist einem fest verdrahteten Modell vorzuziehen: Verschiedene Ersatzmodelle tragen verschiedene Klassifikatoren, und Sie sparen sich die Migration, wenn ein fest gesetztes Modell abgekündigt wird.

Achtung bei den Beta-Kennungen: Die Form mit "default" verlangt server-side-fallback-2026-07-01. Die ältere Listenform fallbacks=[{"model": "claude-opus-4-8"}] verlangt server-side-fallback-2026-06-01. Wer eine Kennung mit der jeweils anderen Form kombiniert, bekommt einen Fehler 400.

Wie Sie erkennen, wer geantwortet hat

Zwei Signale, und sie sind nicht austauschbar:

# Wechselpunkte: ein Block je Modell, das abgelehnt hat
for block in antwort.content:
    if block.type == "fallback":
        print(f"{block.from_.model} lehnte ab, {block.to.model} übernahm")

# Verlässlicheres Signal — deckt auch gemerkte Weiterleitungen ab
ausweich_gelaufen = any(
    e.type == "fallback_message" for e in antwort.usage.iterations or []
)
if ausweich_gelaufen and antwort.stop_reason != "refusal":
    print(f"Beantwortet von {antwort.model}")

Der fallback-Block markiert den Wechselpunkt. Er fehlt aber bei gemerkten Weiterleitungen: Nach einer Ablehnung werden Folgeanfragen etwa eine Stunde lang direkt an das Ersatzmodell geleitet, und diese tragen keinen Block. Verlassen Sie sich deshalb auf den Eintrag in usage.iterations.

Und prüfen Sie weiterhin stop_reason — das Ersatzmodell kann ebenfalls ablehnen. Ein stop_reason: "refusal" auf der finalen Antwort bedeutet: die ganze Kette hat abgelehnt.

Wo der Mechanismus nicht verfügbar ist

Der serverseitige Parameter steht auf der Anthropic-API zur Verfügung — nicht auf Amazon Bedrock, Google Vertex AI oder Microsoft Foundry, und er wird von der Batch-API abgelehnt.

Dort registrieren Sie stattdessen die clientseitige Zwischenschicht des SDK, die dieselbe Aufgabe übernimmt:

from anthropic import Anthropic, BetaFallbackState, BetaRefusalFallbackMiddleware

client = Anthropic(middleware=[
    BetaRefusalFallbackMiddleware([{"model": "claude-opus-4-8"}])
])

zustand = BetaFallbackState()      # EIN Zustand je Gespräch
with zustand:
    antwort = client.beta.messages.create(model="claude-fable-5",
                                          max_tokens=1024, messages=verlauf)

Ein Detail mit Wirkung: Legen Sie je Gespräch einen Zustand an. Ein gemeinsam genutzter Zustand über mehrere Gespräche hinweg verbindet unzusammenhängende Verläufe miteinander.

Für Organisationen mit Null-Datenaufbewahrung wird die Merkfunktion übrigens gar nicht geführt — jede Folgeanfrage geht wieder zuerst an das ursprüngliche Modell. Die Einordnung steht im Beitrag zur Datenaufbewahrung.

Häufig gestellte Fragen

Warum bekomme ich HTTP 200 mit leerem Inhalt?

Weil die Sicherheitsklassifikatoren die Anfrage abgelehnt haben. Das ist kein Fehlerzustand im Sinne des Protokolls: Sie erhalten eine erfolgreiche Antwort mit stop_reason: "refusal" und leerem oder unvollständigem content. Prüfen Sie stop_reason, bevor Sie auf den Inhalt zugreifen.

Wird eine abgelehnte Anfrage berechnet?

Bei Ablehnung vor jeder Ausgabe nicht — weder Eingabe- noch Ausgabe-Token, und es werden keine Kontingente verbraucht. Bei einer Ablehnung mitten im Strom wird die bereits gesendete Teilausgabe regulär berechnet; verwerfen Sie sie, statt sie als vollständige Antwort zu behandeln.

Ist die Ausweichroute auf ein anderes Modell voreingestellt?

Nein, sie ist ausdrücklich opt-in. Ohne Konfiguration bleibt eine abgelehnte Anfrage stehen. Bauen Sie den serverseitigen Parameter mit fallbacks="default" standardmäßig ein — die automatische Auswahl leitet nach Ablehnungskategorie und erspart Ihnen die Pflege einer festen Modellliste.

Warum sehe ich keinen fallback-Block, obwohl ein Ersatzmodell geantwortet hat?

Weil es sich um eine gemerkte Weiterleitung handelt. Nach einer Ablehnung werden Folgeanfragen etwa eine Stunde lang direkt an das Ersatzmodell geleitet, ohne dass ein Wechselpunkt markiert wird. Nutzen Sie deshalb den Eintrag fallback_message in usage.iterations als verlässliches Signal.

Was mache ich auf Amazon Bedrock oder Vertex AI?

Dort steht der serverseitige Parameter nicht zur Verfügung. Registrieren Sie stattdessen die clientseitige Zwischenschicht des SDK, die dieselbe Aufgabe übernimmt und Folgeanfragen an das akzeptierende Modell bindet. Wichtig: je Gespräch einen eigenen Zustand anlegen, sonst werden unzusammenhängende Verläufe aneinandergekoppelt.

Der nächste Schritt

Suchen Sie in Ihrem Code nach jedem Zugriff auf content[0] ohne vorherige Prüfung von stop_reason. Das ist eine stille Bruchstelle, die erst im Produktivbetrieb auffällt — und der Einbau der Ausweichroute kostet eine Zeile. Wir schauen gern mit drauf.