Rate limits
Banana Peel primarily limits concurrency and synchronous request duration rather than imposing a fixed RPM quota. Run-level time budgets are mode-dependent and caller-controlled — see time_budget_ms on Create a response. This page lists each limit, the exact number, and the error you get when you exceed it.
All enforced limits at a glance
| Limit | Scope | Value | When exceeded |
|---|---|---|---|
| Synchronous request duration | Per HTTP request | 420 s socket ceiling on POST /api/v1/responses and wrapper creates | Not an error — longer work returns 202 with status: "in_progress"; poll or use background: true |
| Learning-family concurrency | Per account | 3 in-flight runs (learning and learning-all share the cap) | 429 rate_limited + Retry-After: 120 — nothing created, nothing billed |
| Learning execution capacity | Per instance | 6 probes executing + 12 queued | 429 learning_capacity + Retry-After (wave-based, ≤ 600 s) — nothing created, nothing billed |
| Request body size | Per request | 1 MB JSON body on create endpoints | 413 payload_too_large — nothing created, nothing billed |
| Webhook endpoints | Per account | 25 registered endpoints | 400 webhook_limit — delete unused endpoints first |
| List page size | Per request | limit is clamped to 1–100 (runs default 50; long tasks default 20) | No error — out-of-range values are clamped; paginate with starting_after |
| Long-task manifest size | Per long task | 1,000 entities per enumerated manifest | Larger enumerations fail manifest verification and are retried, not silently truncated |
| Run spend ceiling | Per run | max_cost_usd (any mode; Learning-family defaults to $20) | Run ends with error code budget_exhausted and partial results — in-flight attempts finish and bill |
Backpressure semantics are uniform: every 429 carries a Retry-After header in seconds, the refused create makes no run and no charge, and backpressure never cancels work already in flight. Per-instance limits are about one Cloud Run instance — a retry after Retry-After may land on an instance with capacity.
Quotas per plan
There are no per-plan request quotas: Trial, Pay-as-you-go, and Enterprise share the same concurrency limits above, and there is no RPM or monthly request cap on any plan today. What actually bounds throughput is billing:
- A create is rejected with
402 insufficient_creditsbefore any browser starts when the balance cannot cover it — top up in Console → Billing. - Agent-created (unclaimed) accounts freeze with
403 account_unclaimedonce their welcome credits are exhausted or the claim window lapses — claiming the account unfreezes it. See Agent-native signup. - Every run is bounded by
max_cost_usd— see Spend ceiling.
Browser Agent API
Every 429 from the Browser Agent API — including creates sent through the Anthropic adapter (POST /api/v1/messages) and stream: true creates — carries a machine-readable error code and a Retry-After header (seconds). Honor the header, back off, and retry; nothing was created and nothing was billed.
POST /api/v1/responsesand wrapper creates can hold the connection for up to 420 seconds — an HTTP/socket duration limit on the synchronous request, not a run-time ceiling. Longer work may returnstatus: "in_progress"with HTTP 202 — pollGET /api/v1/responses/:id. Preferbackground: trueso your create returns immediately.- Learning-family creates —
routing: "learning"androuting: "learning-all", which share one cap — exist to teach the router the best path (paid calibration, not production). They are limited to 3 concurrent Learning-family runs per account (both modes fan out to the runner pool; learning-all is the most expensive mode, not an exemption). Creates beyond the cap are refused with429, error coderate_limited, andRetry-After: 120— nothing is created or billed:
429 Too Many Requests
Retry-After: 120
{
"error": {
"message": "Too many concurrent Learning runs: this account already has 3 in flight (limit 3). ...",
"type": "rate_limit_error",
"code": "rate_limited",
"remediation": "Honor Retry-After and back off. ..."
}
}- Back-off guidance: wait the
Retry-Afterseconds (~half a probe wall time), or pollGET /api/v1/responses/:iduntil an in-flight Learning run finishes (or cancel one viaPOST /api/v1/responses/:id/cancel), then retry. Submitting a batch of Learning-family tasks? Send 3, then submit the next as each finishes. - Learning-family creates also have a per-instance execution ceiling: 6 probes executing with up to 12 waiting per instance. When the ceiling and its queue are both full, the create is refused with
429, error codelearning_capacity, and aRetry-Afterheader sized to the queue (capped at 600 s) — nothing is created or billed. See Learning mode. Other routing modes never hit this limit. - Create bodies are capped at 1 MB of JSON — larger payloads are refused with
413 payload_too_largebefore anything is created or billed. - Every run also has a spend ceiling: request
max_cost_usd(any mode; Learning defaults to $20). At the ceiling, no new attempts are dispatched and the run ends with error codebudget_exhaustedand partial results — see Spend ceiling. - Outside of Learning back-pressure, there is no generic overload error code on
/api/v1/*. If an instance is overloaded you see gateway timeouts or 5xx responses — retry with backoff. Billing refusals (402 insufficient_credits,403 account_unclaimed) are covered under Quotas per plan above.
Browserbase-compatible sessions
/api/v1/sessionsis proxied to real Browserbase, so Browserbase's own account limits apply to your sessions. Banana Peel caches API-key validation briefly, so the proxy adds no validation round-trip on every request.