LLM API Error Header Reader
Fix LLM API 429 / 402 / 403 errors: read the rate-limit headers, find out if the real cause is a plan limit of 0, and sweep which models your key can call. LLM API Error Header Reader helps when a model call keeps failing with 429, 402 or 403 and your dashboard says you have quota left.
Example input
Use the LLM API Error Header Reader on this problem (a sample I wrote).
My script calls a hosted LLM API on a free-tier key. The model `example-small-latest` always returns 429, even for a one-word prompt, though my dashboard says I used $0 of my monthly quota. Another model, `example-mini-8b`, works fine on the same key. Raw response of the failing call:
HTTP/2 429
content-type: application/json
x-ratelimit-limit-req-minute: 0
x-ratelimit-remaining-req-minute: 0
x-ratelimit-limit-tokens-minute: 0
retry-after: 60
{"object":"error","message":"Rate limit exceeded","type":"rate_limited","code":"1300"}
I already waited 10 minutes and retried: same result. The console 'Limits' page lists example-small-latest with 30 requests/minute. I use Python 3 and the requests library; the API key is in the env var EXAMPLE_API_KEY. The provider has a list-models endpoint at GET https://api.example.com/v1/models and a chat endpoint POST https://api.example.com/v1/chat/completions with OpenAI-style bodies.Example output
## Evidence
- **Provider / model:** unknown provider (placeholder `api.example.com`), model `example-small-latest`; endpoint `POST https://api.example.com/v1/chat/completions`.
- **Status / body:** `HTTP/2 429`, `{"object":"error","message":"Rate limit exceeded","type":"rate_limited","code":"1300"}`
- **Headers (verbatim):**
- `x-ratelimit-limit-req-minute: 0` (zero)
- `x-ratelimit-remaining-req-minute: 0`
- `x-ratelimit-limit-tokens-minute: 0` (zero)
- `retry-after: 60`
- **Pattern:** fails every time, even for a one-word prompt. Only this model fails; `example-mini-8b` works on the same key.
- **Account facts:** free-tier key, dashboard shows $0 of monthly quota used; the console "Limits" page lists `example-small-latest` at 30 requests/minute.
- **Already tried:** waited 10 minutes and retried, with the same result.
## Classification
1. **A. Model not included in your plan: LIKELY.** The per-minute request limit and the per-minute token limit are both `0`, so the key has no allowance for this model at all. `example-mini-8b` works on the same key, so the key itself is valid. The "Limits" page is a plan table, not proof that your key can call the model.
2. **B. True rate limit: RULED OUT (mostly).** A true rate limit shows a non-zero limit with `remaining` near 0. Here the limit is 0, a one-word prompt fails, and 10 minutes of waiting changed nothing.
3. **D. Permission or key-scope block: POSSIBLE.** The body says nothing about region, scope or terms, but a per-model scope restriction could also show limit 0. This is not confirmed.
Unmatched or ruled out: C (billing or quota exhausted) is ruled out because the status is 429 not 402, the dashboard shows $0 used, and another model works. E (outage) is ruled out because the status is not 5xx and the failure is consistent. F (request too large) is ruled out because a one-word prompt fails.
Note: I can't tell what `code: "1300"` means. Check the provider's error-code docs.
## Confirming check
- **A vs B:** `retry-after: 60` is present but the limit headers are 0. Your 10-minute retry already counts as this check. If a limit header is `0` and the call fails again at once, it is class A, and waiting is not the fix.
- **A vs D:** run the sweep below on the same key. If other models pass and only this one shows limit 0, it is class A. If the failures follow the key's scope, region or project, it is class D. In that case, check the key's project and terms-acceptance settings in the console.
## Availability sweep
…Real output from running the skill on a sample problem, shortened. The skill file itself is not published here.