Timeouts and rate limits are expected failures; their copy must be distinct from model error

What it is

The model fabricating, a tool crashing, missing permission — those are ability or correctness failures. A long queue, a spent budget, a gateway 429 — those are capacity failures. They mean entirely different next steps: the first wants a different road or a different task; the second wants waiting, a lower-capacity mode, or another hour. Writing timeout and rate-limit as “something went wrong” describes capacity in the language of correctness. People then start to distrust the model, or start rewriting the prompt — both the wrong medicine.

Expected failures need expected talk: when to try again, whether this is happening to everyone, which band is still available now.

Why it happens

Capacity failure’s causes sit in queues and quotas, not in prompt quality. A generic error shell (red bar, try again, say it differently) pushes the cause onto the user or onto the model. The repairs people then try (rephrase, switch accounts, paste a longer context) do nothing to a 429 and may add load.

Expectability should lower threat: if everyone is waiting, it is not my fault. Copy and progress that draw “the whole site is busy” as “your request failed” throw away the social-comparison information and leave a personal failure. Work on support and status pages finds that scope (just you / everyone) and time-to-recovery steady behaviour better than apology.

Studying it

The same 429/timeout, four copies: generic error, please rephrase, site-busy with a retry clock, site-busy with a low-capacity retreat. Dependent variables: whether people rephrase, whether they retry immediately (hitting the hot path), whether they take the retreat, who they blame. Independent variables: queue position or recovery clock shown, whether a manual path is usable at the same time.

Immediate retry rate is the system metric that matters. Copy that encourages an instant second press turns rate-limit into oscillation.

Where it stops holding

When a timeout is actually the model looping, capacity language misleads; that belongs with ability failure and ability degradation. A per-user quota (your daily count is gone) is not site-busy: the copy must say your allowance, with a reset time and options to upgrade or use less. Offline and permission errors are not capacity either. This entry is only the copy of expected capacity failure. Do not fold it into fluent-error talk.

Applying it

• 429, queueing, and spent budget get their own capacity panel: cause, scope (you / this region / the site), earliest retry, low-capacity acts available now. Ban “try saying it differently.”
• The client backs off on capacity failure. Do not make Try again a primary button that can be mashed. Primary should be the retreat or “notify me when.”
• Status page and in-app copy share reason codes, so the app does not say error while the public page says fine.
• Check: fill the quota on purpose. If the copy mentions rephrasing, it has failed. If people mash retry within ten seconds, backoff is not installed. Then ask “was your wording bad, or is it busy” — “my wording” means the language family was wrong.

Related

• Same group: L1.06.1 On failure, fall back to a deterministic path · L1.06.2 The degradation order must be defined in advance · L1.06.3 Silent failure is more harmful than explicit failure · L1.06.4 Empty, wrong, and partial output need different fallbacks · L1.06.5 Fluent wrong output is the most dangerous; it trips no degradation · L1.06.6 A deterministic fallback must be maintained in peacetime · L1.06.7 Degradation must keep what the user already entered
• Nearby: I2.13 Automatic retries · L1.12 Latency and streaming experience · L4.13 Agent failure reporting and escalation
• Search terms: rate limit copy · expected capacity failure · timeout versus model error