Troubleshooting

Claude Fable 5 error reference

Five failure modes cover almost every broken Fable 5 integration. Find yours by status code, then follow the fix order.

The 30-second version

A 529 is Anthropic's capacity problem and you retry it. A 429 is your throughput against Fable 5's own rate limit pool, which is smaller than the Opus and Sonnet pools. A 400 is your payload or your organization's data retention setting. A refusal is not an error at all: it arrives as HTTP 200 with stop_reason set to refusal, so no exception is raised. A 404 means the model ID is wrong or your account cannot reach claude-fable-5.

Why Fable 5 breaks differently

Four structural differences explain most of the surprises when you move an integration from Opus 4.8 or Opus 5.

  • Refusals are successful responses

    Fable 5 runs safety classifiers that can decline a request. A decline returns HTTP 200 with stop_reason set to refusal and a stop_details object. Error-rate dashboards and try/except blocks never see it, so a refusal usually shows up as an empty response in production rather than an alert.

  • The accepted parameter surface is narrower

    Non-default temperature, top_p, and top_k return 400. Assistant prefill returns 400. Both thinking.type disabled and a manual budget_tokens value return 400. The SDK request types still define these fields for backward compatibility, so the code type-checks and the API rejects it at runtime.

  • Fable 5 has its own rate limit pool

    Rate limits are applied separately per model, and Fable 5's pool is much smaller than Opus 5's. On the Start tier, Fable 5 allows 500,000 input tokens per minute and 100,000 output tokens per minute, against 2,000,000 and 400,000 for Opus 5. Traffic that never hit a 429 on Opus can hit one immediately on Fable 5.

  • Some 400s and 404s are organization-level, not request-level

    Fable 5 requires 30-day data retention and is not offered under zero data retention. An organization whose retention configuration does not meet that requirement gets a 400 on every request, no matter what the payload contains. An admin model allowlist produces the same all-or-nothing pattern.

Fix in this order

Classify the failure before you write retry logic. Retrying the wrong class either wastes money or hides a config bug.

  • 1. Read the status code and the error type

    Every API error body carries an error.type and a request_id. 429 is rate_limit_error, 529 is overloaded_error, 400 is invalid_request_error, 404 is not_found_error. Log the request_id: it is the only thing Anthropic support can act on.

  • 3. Honor retry-after and back off exponentially

    Retry 429, 500, 504 and 529 with exponential backoff, and wait at least the number of seconds in the retry-after header. Retrying earlier than that fails by definition. Do not retry 400, 401, 403 or 404: the same request will fail identically.

  • 2. Branch on stop_reason on every 200

    Check stop_reason equal to refusal before you read content. Do not branch on the content array being empty and do not parse stop_details.explanation, whose wording is not stable. Both category and explanation can be null on a valid refusal.

  • 4. Wire a fallback model, then verify it fires

    The server-side fallbacks parameter only triggers on a safety classifier decline. A 429, a 529 or a 500 on Fable 5 is returned to you unchanged, so capacity fallback is code you have to write yourself.

Fix the failure you actually have

Start with the status code. Each page gives you the cause, the fix order and the questions developers ask most about that specific failure.

Frequently asked questions