# Atlas error: Quota exceeded. Check your plan and billing details. > Atlas marks insufficient_quota as non-retryable, so open the provider billing dashboard and confirm the balance or quota for the key you configured. Atlas stops the run with "Quota exceeded. Check your plan and billing details." and does not retry, because parseStreamError maps the provider error code insufficient_quota to a non-retryable api_error carrying that exact message. Fix it by opening the provider billing dashboard and confirming the balance or quota for the key you configured, checking whether you are hitting an org-level spend cap rather than a personal one, and switching to another configured provider with `atlas models` while you sort out billing. ## Symptom The run stops with: "Quota exceeded. Check your plan and billing details." and Atlas does not retry. The failure is immediate rather than arriving after a series of backoff attempts. ## Cause parseStreamError maps the provider error code insufficient_quota to a non-retryable api_error with that exact message, so Atlas fails fast instead of burning retries against a request that cannot succeed until billing changes. ## Fix 1. Open the provider billing dashboard and confirm the balance or quota for the key you configured. 2. Check whether you are hitting an org-level spend cap rather than a personal one. 3. Switch to another configured provider with `atlas models` while you sort out billing. 4. Note that isRetryable is false here, so Atlas will not auto-retry. You must resolve the quota. ## Why does Atlas say Quota exceeded. Check your plan and billing details. Atlas says "Quota exceeded. Check your plan and billing details." because the provider returned the error code insufficient_quota. parseStreamError maps insufficient_quota to exactly 1 non-retryable api_error carrying that exact message, so the run stops at once rather than cycling through retries. The message text is not Atlas paraphrasing a provider failure. parseStreamError recognizes the insufficient_quota code specifically and attaches the message verbatim, which is why the sentence reads the same every time you hit it. The important design decision behind that mapping is the retry flag. A quota failure cannot resolve itself, so Atlas fails fast instead of burning retries against a request that is guaranteed to be refused again. Seeing the run stop immediately rather than backing off is the expected behavior for insufficient_quota, not a sign that something else went wrong. ## Does Atlas retry a quota exceeded error Atlas does not retry a quota exceeded error, and it makes 0 attempts to do so. isRetryable is false for the insufficient_quota mapping, so the run stops the moment the provider reports insufficient_quota rather than backing off and trying again. You must resolve the quota yourself. The non-retryable classification is deliberate and worth understanding, because it changes what you should do next. Retryable errors in Atlas are things a wait can cure, such as a transient server problem. A quota failure is not one of them. No amount of waiting inside a single run will restore a balance that has run out or lift a cap that has been reached. Atlas marks isRetryable false and hands the problem back to you immediately. Restarting the same request without changing anything on the billing side produces the same insufficient_quota result. ## How to check the provider billing dashboard for the key Atlas uses Step 1 of the documented fix is to open the provider billing dashboard and confirm the balance or quota for the key you configured in Atlas. Checking that specific key matters, because an account can hold several keys and a quota exhausted on 1 of them produces insufficient_quota only for requests using that key. Match the key first, then read the balance. Look at the plan, the remaining quota, and any usage limit attached to the exact credential Atlas is sending. A dashboard showing healthy credit on the account as a whole is not evidence that the key Atlas uses has quota left. If the balance is genuinely exhausted, adding funds or upgrading the plan is the only thing that clears the error, since Atlas marked the api_error non-retryable and will keep failing fast until the provider stops returning insufficient_quota. ## Is an org-level spend cap causing quota exceeded in Atlas Step 2 of the documented fix is to check whether you are hitting an org-level spend cap rather than a personal one. An org spend cap produces the same insufficient_quota code and the same Atlas message, "Quota exceeded. Check your plan and billing details.", even when your personal balance looks healthy. The org-level cap is the case people chase for the longest, because everything visible on a personal account looks fine. The organization behind the key has reached a spending limit set by an administrator, the provider refuses further requests, and parseStreamError maps the resulting insufficient_quota code to a non-retryable api_error exactly as it would for an empty personal balance. If your own balance checks out but the error persists, ask whoever administers the org whether a spend cap has been reached. Only an administrator can raise it. ## How to keep working while you fix an Atlas quota problem Step 3 of the documented fix is to switch to another configured provider with `atlas models` while you sort out billing. Atlas lets you switch the active model and provider on the fly with favorites and recents, so a quota exhausted on 1 provider does not have to stop the session. Billing fixes take time. Adding funds, upgrading a plan, or getting an administrator to raise an org spend cap are all slower than the work in front of you. `atlas models` lets you move the active session to a second configured provider immediately, and the session continues from where it was. Be honest about what the switch is: a workaround, not a fix. The provider that returned insufficient_quota will keep returning it until the quota itself is resolved, and Atlas will keep failing fast on that provider because isRetryable is false. ## How to verify the quota exceeded fix worked Verify the quota fix by re-running 1 request against the original provider and confirming that "Quota exceeded. Check your plan and billing details." does not return. A completed reply means the provider no longer returns insufficient_quota, so parseStreamError has nothing to map to a non-retryable api_error. The test is reliable because the mapping is deterministic. If the provider still reports insufficient_quota, Atlas will stop the run with the same message immediately and without retrying, so a run that proceeds is real proof the quota was restored. Do not judge the fix by a request sent to a different provider you switched to with `atlas models`, since that only proves the second provider has quota. Point the session back at the original provider and send a real request to confirm the billing change actually took effect. ## FAQ ### how to fix Quota exceeded. Check your plan and billing details. in atlas Open the provider billing dashboard and confirm the balance or quota for the key you configured, check whether you are hitting an org-level spend cap rather than a personal one, and switch to another configured provider with `atlas models` while you sort out billing. ### why doesn't atlas retry when quota is exceeded parseStreamError maps the provider error code insufficient_quota to a non-retryable api_error, and isRetryable is false. Atlas fails fast instead of burning retries, because a quota failure cannot resolve itself without a billing change. ### what is insufficient_quota in atlas insufficient_quota is the provider error code that Atlas maps to the message "Quota exceeded. Check your plan and billing details." It is classified as a non-retryable api_error, so the run stops immediately. ### atlas quota exceeded but my balance looks fine Check whether you are hitting an org-level spend cap rather than a personal one. An org cap returns the same insufficient_quota code and the same Atlas message even when your personal balance and plan look healthy. ### can I keep using atlas while my quota is exhausted Yes. Switch to another configured provider with `atlas models` while you sort out billing. Atlas lets you switch the active model and provider on the fly, so the session continues on a provider that still has quota. ### does waiting fix quota exceeded in atlas Waiting does not fix it. Atlas marks the insufficient_quota mapping non-retryable with isRetryable false, so the same request will fail the same way until the quota or spend cap is actually resolved on the provider side. ### how do I confirm my atlas quota problem is resolved Point the session back at the original provider and send a real request. A completed reply means the provider no longer returns insufficient_quota. Testing against a provider you switched to with `atlas models` proves nothing about the original one. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/provider-quota-exceeded Source of truth: aeo_pages row `/resources/troubleshooting/provider-quota-exceeded` (segment: Troubleshooting) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.