OpenRouter incident intake
OpenRouter 402 Brownout Runbook
A focused handoff for OpenRouter-backed apps that hit 402 Payment Required, insufficient credits, stale balance snapshots, impossible max_tokens settings, or retry storms. The goal is to stop unsafe dispatch first, then choose the smallest paid review scope that can prove the fix.
Brownout states to separate
Treat balance and dispatch as separate decisions. A user-facing "waiting credits" state can be useful, but the backend still needs a hard admission-control rule that decides whether the next model call is affordable, stale, unauthorized, or blocked.
Payment Required blocks dispatch and records the active workflow statemax_tokens is calculated before the call, not after provider rejectionWhat the review checks
The paid review is scoped around one OpenRouter cost boundary: the point where your app decides whether an agent step, chat response, background job, or tool loop is allowed to spend more money.
max_tokens ceiling from balance, model price, prompt tokens, cache-read share, and safety margin.total_cost or usage.cost reconciles reservation, display, and budget ledger.Scope routing
Choose the smallest useful paid path
If the app is not burning money yet, the $99 path is enough for one brownout state or one launch guardrail. If a live workflow can repeatedly hit 402, retry, or degrade user output, use the $299 focused review. If the bill is already moving, use the $1,000 emergency sprint.
max_tokens cap, one stale balance rule, or one launch-pricing sanity check.Packet builder
Generate a sanitized 402 handoff
Capture only the failure shape: state, token cap, retry count, stale snapshot age, rough daily burn, and the dispatch decision needed. The generated packet routes bounded incidents to the dedicated OpenRouter 402 intake and live burn-rate incidents to emergency scope.
Sanitized evidence packet
Public intake can stay small. The useful packet is a redacted state transition, not a dump of production data.