503 No available accounts
503 No available accounts means the request reached the API proxy or gateway, but no upstream account, provider, group, or route is currently available. It is usually not a simple API key typo. Treat it as an account-pool capacity, model limit, group permission, client restriction, or routing failure signal.
Snapshot
Do not rotate keys first. This error usually points to an unavailable account pool, provider, group, or model route. Test a minimal request, confirm the model and group, then decide whether to wait, reduce context, change model, or switch provider.
What This Error Means
503 Service Unavailable means the server is temporarily not ready to handle the request. In an AI API proxy workflow, No available accounts narrows that down: the gateway could not find a usable upstream account, provider, group, or model route.
This is different from a 401. A 401 means authentication failed. 503 No available accounts often means authentication passed, but the routing layer behind it has no working exit.
Common Causes
- The proxy account pool is full, and upstream accounts are cooling down, rate limited, disabled, or temporarily unavailable.
- The selected model hit a model-level limit, especially with long-context, thinking, opus, or high-input-token requests.
- The API key’s group has no usable provider attached, or upstream accounts were assigned to a different group than the key uses.
- The provider restricts certain routes to specific clients, such as Claude Code only, while CC Switch, reverse proxies, or unofficial clients are rejected.
- A self-hosted gateway or second-level proxy has a routing bug: one upstream returns no account, but sticky sessions or error handling do not fail over to another account.
How To Fix It
- Wait 30 to 120 seconds before retrying. A 503 should be treated as a temporary capacity signal, not as an invitation to retry in a tight loop.
- Send the smallest possible request with the same Base URL, API key, and model. If that also returns 503, check provider status, account pool, group, and model availability.
- Test a more ordinary model. If a high-context, thinking, opus, or special route fails while a regular model works, the bottleneck is probably model-level capacity or cooldown.
- Check the provider dashboard for API key group, provider binding, balance, daily quota, and client restrictions. Rotating the key alone usually does not fix an unavailable upstream pool.
- If you use CC Switch, a reverse proxy, or a self-hosted gateway, bypass that layer once and test the provider Base URL directly. Secondary routing, sticky sessions, and fallback failures can amplify a short upstream outage.
Checks For API Proxy Users
Separate three layers: your local tool, the proxy provider you configured, and the upstream account pool behind that provider.
If a minimal curl request works but Claude Code, Codex, or Cursor fails, inspect the tool profile, model name, context size, and client restriction. A coding-agent call can carry a large historical context even when the visible concurrency is low.
If the minimal request also fails, the problem is probably not local. Check the provider status page, announcements, support channel, and account-pool capacity instead of repeatedly editing the API key.
When To Change Provider
Changing provider makes sense when the minimal request keeps returning 503, multiple models on the same provider are unavailable, or the provider confirms the account pool is saturated.
If only one model fails, try another model or group first. If only one client fails, check client restrictions and Base URL configuration first. Treating every 503 as “the site is down” is a lazy diagnosis and can make you migrate between providers without fixing the actual configuration or context problem.