> ## Documentation Index > Fetch the complete documentation index at: https://docs.erstan.com/llms.txt > Use this file to discover all available pages before exploring further. # Rate limits > Compare plan capacity, understand durable Agent queues and recover from request throttling. Rate limits protect service capacity. They are separate from your [Credits](/billing/credits): having enough Credits does not make every run start immediately, and a request limit does not mean your monthly allowance has been used. ## Limits by plan These standard limits apply in QA and production. Open **Settings → Billing** or **Usage** to see your account's effective limits and current active and queued work. Agreed Admin overrides take precedence. **Agent runs** | Plan | Active runs | Queued runs | | - | -: | -: | | Personal | 8 | 100 | | Pro | 8 | 500 | | Team | 25 | 2,000 | | Enterprise | By agreement | By agreement | **Request budgets** | Plan | API / min | MCP tools / min | | - | -: | -: | | Personal | 300 | 60 | | Pro | 600 | 120 | | Team | 1,200 | 300 | | Enterprise | By agreement | By agreement | Limits are shared by the **billing account**, across its people, workspaces, API keys and service replicas. Creating another workspace or key does not multiply them. Enterprise uses Team's standard limits until agreed overrides are configured; it does not receive a separate reserved fleet automatically. | Additional protection | Standard limit | Scope | | - | - | - | | General hosted MCP requests | Same numerical budget as the plan's API requests / minute | Separate shared account MCP request bucket | | Generic Agent webhook attempts | 100 / minute | Each known published trigger, including rejected authentication attempts | | MCP anti-flood protection | 3,000 / minute | Client IP, per API process | | Anonymous ordinary API requests | 300 / minute | Client IP, per API process | | Email sign-in link requests | 5 / minute | Client IP | Provider callbacks such as Stripe and Slack retain their own handling. The generic Agent webhook limit does not replace those callback protections. ## What counts as active An execution uses one active slot while processing model or tool work, including an active request to a connected service. This applies to runs started through chat, Slack, Microsoft Teams, the API, schedules and triggers. Steps inside one execution do not each take another slot; separately started child executions need their own slots. Queued work, idle conversations and completed runs do not occupy active execution slots. Durable waits for user input, approval, funding or a provider retry release capacity when the active phase stops. Resumed work reacquires capacity before continuing. Your plan sets a ceiling, rather than reserving that many workers at all times. Shared fleet capacity, worker readiness and connected services affect when work can start. Erstan scales its worker fleet as demand grows; newly added workers still need time to become ready. An upgrade makes the higher entitlement available to admission. A downgrade lets already admitted work finish and holds new work until it fits the new limit. It does not terminate progressing runs to force the lower limit immediately. ## Queued work and deadlines **Queued** means Erstan accepted the run and saved it durably. When all account slots or available workers are busy, it waits until capacity is available. Accounts take turns so one large backlog cannot prevent another eligible account from starting. Older background work gains priority over time. The run card and run details explain whether work is waiting for account capacity, an optional member ceiling, worker capacity or an external service. They show the queue start deadline where one applies. Keep the accepted execution ID and track that run; do not submit it again simply because it is queued. See [Run Agents through the API](/developers/run-agents). New queued execution phases have a **24-hour deadline to start**, measured from when they become eligible to run. If a phase never starts before that deadline, the run records a queue expiry reason and its owner receives an in-app notification. Review the run and retry when capacity is available. A provider retry after work has already started retains its own durable recovery lifecycle. The queue deadline is not a maximum running time. It does not cancel a progressing model/tool call, or expire an existing user approval wait after 24 hours. Waiting in an execution queue does **not** consume execution Credits. An intentionally retained, separately metered resource, such as a running computer session, follows its own lifecycle and published charges. Use the existing **Cancel** control to cancel accepted work. Cancellation and recovery preserve the run identity; queue waiting is not a reason to create a duplicate write. ## When the pending queue is full The pending ceiling is separate from the active ceiling. When a new submission would exceed it, Erstan rejects that new admission with HTTP **429**, `queue_full` and retry timing. It does not silently discard an accepted run. A supported idempotent replay returns the existing accepted identity rather than adding another pending item. Honor the retry delay, reduce batch size and track already accepted work. A queue that is full is different from a requests-per-minute limit: making fewer HTTP calls does not instantly free pending execution capacity. ## Requests per minute and bursts Request budgets count requests, not model tokens or completed business tasks. Starting a run, polling status and reading lists can each contribute. Known streaming routes and provider callbacks use their own handling. The authenticated account's shared token buckets allow an initial burst up to the listed minute budget and refill continuously at that rate. For example, Personal's ordinary API bucket holds up to 300 requests and refills at five requests per second. This is a sustained rate with a finite burst, rather than a promise that every rolling 60-second interval contains exactly 300 requests. Restarting a process or switching keys does not reset the account's shared budget. A hosted MCP tool call consumes both the account's general MCP request budget and its separate MCP tool-call budget. Ordinary API and general MCP requests use distinct account buckets. Existing IP and authentication safeguards still apply, so an account entitlement does not remove sign-in or anti-flood protections. ## HTTP 429 and retry timing 1. Read **Retry-After** or the response's retry timing. 2. Wait for that duration and add a small random delay when several clients retry together. 3. Use bounded exponential backoff instead of a tight retry loop. 4. Reuse the operation's supported idempotency or delivery identity, especially for writes and webhook deliveries. Shared account API throttling returns `account_rate_limited`. Hosted MCP includes retry timing in its JSON-RPC error data as well as the HTTP header. Generic Agent webhook throttling returns `trigger_rate_limited`; a full Agent backlog returns `queue_full`. Some existing IP safeguards use their own response format, so check the HTTP status and headers first. If shared rate admission is temporarily unavailable, Erstan returns a retryable service error instead of pretending the account has spare capacity. If a request already returned an accepted execution ID, track that execution. After a network timeout, inspect durable status before submitting a replacement write. ## Member ceilings and connected services Team and Enterprise can have an additional per-user active ceiling configured by an authorized Erstan Admin. It is off by default and does not increase account capacity. Scheduled and event-driven work shares a separate system principal with the same optional ceiling; it also shares the account's total active limit. Microsoft, Google, NetSuite, model providers and other connected services enforce their own request and concurrency limits. A provider throttle can delay work even when Erstan capacity is available. Provider retry handling is separate from plan access, account throttling and Credit exhaustion. Stagger large batches, avoid excessive status polling and use focused Agents. For repeated capacity problems, give support the run ID, approximate time and error code. Never send API keys. ## Choosing the right recovery | Message | Appropriate action | | - | - | | Queued or provider busy | Track the existing run and wait for capacity. | | Queue deadline reached | Review the saved run and retry when capacity is available. | | `queue_full` | Honor retry timing, reduce new submissions and let accepted work drain. | | HTTP 429 or account/trigger rate limit | Honor retry timing and reduce request frequency. | | Credit balance exhausted or budget paused | Review Usage and add funding or adjust authorized budget controls. | | Subscription payment problem | Open Billing or the Stripe recovery link. | | Upgrade required | Review the plan that includes the feature. | | Admin access required | Ask an authorized owner or Admin; an upgrade does not grant permissions. | Understand metered costs and funding controls. Manage plans, trial dates, payment methods and cancellation. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.