Quickstart Pricing

Home → Help

A model that worked yesterday now fails for everyone on the same key group

Gateways route by group: a key belongs to one group, a group points at one or more upstream accounts. If the group has a single account and that account stops serving the model — expired credit, revoked key, a model list that no longer matches — every key in the group loses the model at once.

What you are seeing

Why it happens

The error wording points at the model, which sends people to check spelling and availability. The actual condition being reported is “no account in your group can serve this”, and the fix is on the account side.

Single-account groups have no redundancy by construction. With two or more accounts the router fails over and nobody notices; with one, a single upstream problem is a full outage for that group.

A subtler version: an account advertises a model it cannot actually deliver. Every request routed to it fails, and depending on the router's health logic the repeated failures can pull the whole group out of rotation — so models that were fine start failing too. We have seen exactly this: one mis-declared model name in an account's list took down an entire group's traffic.

Confirm it is this

Ask the gateway what your key can actually reach, rather than assuming:

curl -s 'YOUR_BASE_URL/models' \
  -H 'Authorization: Bearer YOUR_KEY' \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); print(len(d["data"]), "models"); [print(" ", m["id"]) for m in d["data"]]'

If the model is missing from this list, the key's group cannot serve it — no amount of fixing the request will help. If it is present but calls still fail, the upstream account behind the group is the thing that is broken.

How to fix it

  1. Check /models with the failing key firstIt answers in one request whether this is a routing problem or a request problem, and it costs nothing.
  2. Ask the provider which group the key belongs toTwo keys that look identical can sit in different groups with different upstream accounts. Knowing the group turns “sometimes it works” into a reproducible rule.
  3. Keep a second key in a different group for anything importantIt is the cheapest redundancy available: when one group has an upstream problem, switching keys is a one-line change rather than an outage.
  4. Do not rely on a model appearing in a public listA model listed on a pricing page may still be unavailable to your particular group. The authoritative answer is what /models returns for your key.
On APICLAN each key belongs to exactly one group, and /models always reflects what that key can really call. Which models each group carries is listed on the pricing page.

Related

Unexpected token '<' when calling an OpenAI-compatible API401 invalid API key — when the key looks right but still fails

Last checked 2026-10-01. Written from problems diagnosed on a live OpenAI-compatible gateway, not collected from other sites.