Selected model is at capacity: developer fixes

If you see the error message selected model is at capacity, detect it by checking for HTTP 429 or an error.message containing that phrase, then retry with exponential backoff and jitter, route requests to a fallback model or regional endpoint, and open a circuit-breaker after repeated failures so automations keep running without blocking users.

Why you see selected model is at capacity

OpenAI limits concurrent capacity for popular ChatGPT models to keep the system stable. Heavy global demand can make a particular model temporarily unavailable, producing the selected model is at capacity openai message. That is different from API keys being invalid. The server typically returns a 429 rate limit or a 503/5xx when capacity is exhausted, and the response body often contains a human readable error like "Selected model is at capacity. Please try a different model." See recent reports on the OpenAI developer forum with similar symptoms for confirmation.

Step by step fix, developer workflow

1. Detect the error programmatically. Treat HTTP 429 and 503 responses as transient. Also parse JSON error text for phrases like "selected model is at capacity" or "model at capacity" so you can classify the failure.
2. Implement exponential backoff with jitter. Start with a small base delay, double on each retry, add random jitter, and cap retries. A typical pattern: 500ms, 1s, 2s, 4s with +/- 20 percent jitter, then stop after 4 attempts.
3. Route to fallback models or regional endpoints. If the primary model is overloaded, retry the same request against a fallback model such as a smaller GPT variant you have tested, or a different regional endpoint if your plan supports it.
4. Read standard rate limit headers where available, and respect the Retry-After header. If the server returns Retry-After, use that value instead of your backoff calculation.
5. Use a circuit-breaker. Track recent failures, and when failures exceed a threshold within a window, open the circuit for a minute or more, return a graceful response, and poll the API to close the circuit when healthy.
6. Add UX fallbacks. For synchronous flows, show a friendly message like "We are experiencing temporary capacity limits. Please try again in a minute" and allow queuing. For background tasks, enqueue the job and process with exponential backoff until success or maximum retries.

Code: exponential backoff with jitter (JavaScript)

Use this in server code, n8n Code node, or any JS-enabled step to retry OpenAI calls.

async function retryWithBackoff(fn, maxAttempts = 4, baseMs = 500) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const isTransient = err.status === 429 || err.status === 503 || /selected model is at capacity/i.test(err.message || "");
      if (!isTransient || attempt === maxAttempts) throw err;
      const backoff = Math.min(baseMs * 2 ** (attempt - 1), 8000);
      const jitter = Math.random() * (backoff * 0.4) - backoff * 0.2; // +/-20%
      const wait = Math.round(backoff + jitter);
      await new Promise(r => setTimeout(r, wait));
    }
  }
}

Tool-specific notes: n8n, Make.com and Zapier

n8n

• Use the HTTP Request node to call OpenAI if you need custom control. Set Method to POST, add your Authorization: Bearer YOUR_KEY header, and set Body Parameters with model and messages.
• Put retry logic inside a Code node. Call the HTTP Request node using an Execute Workflow or use Code node + fetch and implement the JavaScript retryWithBackoff function shown above. Keep retries limited to avoid long-running workflow executions.
• For alerting, combine with the n8n node that sends emails or Slack messages on repeated failures, see our guide on getting alerted when workflows fail.

Make.com

• In a scenario use the HTTP module to call OpenAI. After the call, inspect the HTTP status. If it is 429 or the response body contains the capacity text, use a Router to route to a flow that sleeps and retries.
• Use the Sleep module to implement backoff. Increase the Sleep duration on each retry using variables stored in Data Store or an iterator count.
• For fallbacks, create a parallel path to call the API with a smaller model name or to enqueue the request into a queue (Google Sheets, Airtable) to retry later.

Zapier

• Use Webhooks by Zapier or the OpenAI app step. Wrap the call with a Zap that uses Paths or Storage to count retries.
• On 429 or error text containing capacity, branch to a Delay by Zapier step, then a second attempt. Keep attempts small because Zap runs have limits.
• For UX, use a follow-up email step to tell users their request is queued and will be processed shortly.

How to stop it happening again

• Spread load: avoid bursty traffic. Throttle user-facing requests client-side, aggregate prompts server-side, and batch where possible.
• Use fallback models: keep a tested secondary model in your config and switch automatically when you detect capacity problems.
• Implement caching for identical prompts to reduce repeated calls.
• Monitor usage: add logging and metrics for 429 rates and error messages so you can spot trends early and contact OpenAI support for upticks tied to your key.
• Consider rate limits: design UIs that do not encourage repeated immediate retries by users. Show progress states and queue items.

When to get help

If retries and fallback models do not recover the situation after several minutes, and many users are affected, open a support ticket with OpenAI and include timestamps, request ids if present, and sample error responses. Also check the OpenAI developer forum threads where others report the same issue, for example this thread about Selected model is at capacity and a related thread describing wide outages. If the problem is specific to your account, OpenAI support can investigate. If it is global, use fallbacks and circuit-breakers to keep your product usable while the provider resolves capacity.

Example circuit-breaker rules

Simple rule to protect your automation: if you see 5 capacity errors within 60 seconds for a given endpoint or model, open the circuit for 60 seconds. While open, return a cached result or a queued-acknowledgement to the user and poll the API every 15 seconds for a successful response to close the circuit. Implement counters in Redis, in-memory store for small setups, or your platform storage.

For debugging tips, capture the full response body and headers when you get 429 or capacity errors, so you can see if a Retry-After header is supplied. For more on developers reporting the same message, see the OpenAI community thread about selected model is at capacity and another thread about model-wide capacity issues.

Keep retries conservative, prefer graceful degradation for users, and route to tested fallback models or background queues. If you use n8n workflows, combine the Code node backoff with the HTTP Request node to avoid workflow timeouts and add alerts so you know when the circuit opens. See our post on n8n alerts for workflow failures for implementation ideas.

Learn to build automations like this with Automate Naija.

Frequently asked questions

What exactly triggers selected model is at capacity?

This error appears when OpenAI has temporarily exhausted capacity for a specific model. The API often returns HTTP 429 or a transient 5xx with an error message containing that phrase. It is usually transient and not caused by an invalid key. Detect both status and the error text to classify it properly.

How many retries should I perform after a model at capacity error?

Keep retries small, typically 3 to 5 attempts. Use exponential backoff with jitter, for example 500ms, 1s, 2s, 4s with +/-20 percent jitter. Stop retries when you hit the max attempts or if the server returns a non-transient error.

Can I automatically switch models when the primary is at capacity?

Yes, maintain a tested fallback model in your configuration. On detecting capacity errors, route the request to the fallback and mark the original model as degraded in a short-term cache. Ensure the fallback produces acceptable results for your use case before switching automatically.

How do I implement a circuit-breaker for my automations?

Track recent transient failures per model or endpoint. If failures exceed a threshold, open the circuit for a set window, return a graceful UX response or queue the job, and poll the API periodically. Use Redis or platform storage to maintain counters across processes, and close the circuit only after a successful health check.

Build it with us. The community is free and the build track teaches this kind of automation week by week: see pricing or join the community.