Partner usage and quota refusals
Organization-paid partner teams have no subscription token or turns-per-minute ceiling. The organization can set a monthly USD spending budget; zero means no limit. The budget covers all of its teams and priced usage, including retained rollups, during the UTC calendar month. Organization Overview shows that spend.
HTTP 429 with code: QUOTA_EXCEEDED and details.scope: org_spend means the organization's monthly budget has been reached. details.limit and details.used are decimal strings in USD pico (unit: usd_pico, one dollar = 10^12 pico). periodEndsAt names the next UTC month boundary. Ask the organization administrator to raise/remove the budget or wait for that boundary; a one-minute retry is not a remedy. Budget changes become effective after the roughly ten-second quota cache. Concurrent work and delayed metering can overshoot; this is not a prepaid balance.
Platform subscription teams and explicitly team-paid teams still receive team_spend or team_rate. Agent concurrency, visitor/channel protection, global request throttling and organization policy still apply to partner teams. Those refusals must not all be translated as “try again in a minute”.
Maximum steps per agent turn
A direct team owner/admin can set maxTurnIterations with PATCH /v1/agents/:id, for example {"maxTurnIterations":40}. It is returned on the agent and described in OpenAPI/generated clients. Null/absent stored values mean 8. The deployment variable AGENT_MAX_TURN_ITERATIONS defaults to 50 and bounds both writes and execution; invalid writes return 400. This setting is not accepted as a per-request override by partner chat or run routes. A partner service credential does not acquire access to the direct management route. Existing partner execution authority, model/tool grants, revocation, organization spending and team quotas continue to apply to every turn.
Organization policy has no separate step-count field. Raising this setting changes the number of permitted iterations, not any grant or spending ceiling. Heartbeat remains capped at 8 and automatic completion at 1. The limit notice includes the actual step count, SSE done.stopReason is max_iterations, and the turn lifecycle reports limited. A larger step budget does not extend the turn's time or worker-session deadlines. For long MCP workflows the per-call ceiling decreases to 60 seconds at 40 steps (48 at 50); a server configured with a smaller timeout keeps that smaller limit.
The default browser worker execution budget is 900 seconds (15 minutes), or 3600 seconds when the existing longRunning grant is enabled. Forty steps in one default worker session therefore need to average less than 22.5 seconds including model time and tool work; 40 slow 60-second browser operations will not fit. A reconnect/reprovision may be needed independently of the remaining step allowance. The turn-lock renewal ceiling remains 60 minutes. These are code-level bounds, not measured completion-time promises.
Request rate
All valid organization service credentials share one request allowance per organization, across HTTP routes and API replicas. They do not share a bucket with other organizations on the same IP. Rotating/adding a key does not reset or multiply capacity. Anonymous and user routes retain IP-and-route protection; explicit auth limits stay at 5 or 20 requests per minute, depending on the route.
| Window | Default | Deployment variable |
|---|---|---|
| 60 seconds | 300 requests | REQUEST_RATE_ORG_MINUTE |
| 3600 seconds | 18,000 requests | REQUEST_RATE_ORG_HOUR |
| 86400 seconds | 432,000 requests | REQUEST_RATE_ORG_DAY |
Each fixed window starts on its first admitted request. A rejected request does not extend it. When multiple windows are exhausted the response names the one with the longest wait. Requests that pass the rate guard consume capacity even if later validation/authorization refuses them. Failed credentials use IP limits.
{"success":false,"code":"TOO_MANY_REQUESTS","message":"Too many requests. Wait a moment and try again.","details":{"scope":"organization","limit":300,"windowSeconds":60,"retryAfterSeconds":23}}The response is HTTP 429 with Retry-After: 23. Wait at least that many seconds, then retry with jitter; preserve the operation's idempotency key. A concurrency refusal keeps AGENT_CONCURRENCY_LIMIT: wait for an active turn to finish, with Retry-After: 1 as a minimum polling delay, not a promised completion time. Monthly QUOTA_EXCEEDED uses periodEndsAt as described above and has no short Retry-After. See the complete 429 inventory.
For more capacity, ask a platform administrator to open Organizations → your organization → Settings & approval → Request rate. Each window is editable; empty means the deployment default. The change is audited and applies on the next request without resetting counters. The API is PATCH /v1/admin/orgs/{orgId}/request-rate with requestRateMinute, requestRateHour, requestRateDay (positive integers or null to restore defaults). Organization members and service credentials cannot change these limits.