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
Request budgets
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.
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. 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
- Read Retry-After or the response’s retry timing.
- Wait for that duration and add a small random delay when several clients retry together.
- Use bounded exponential backoff instead of a tight retry loop.
- Reuse the operation’s supported idempotency or delivery identity, especially for writes and webhook deliveries.
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
Credits and usage
Understand metered costs and funding controls.
Subscription management
Manage plans, trial dates, payment methods and cancellation.