What are the rate limits?

Short answer: we don’t rate-limit your workspace. There’s no requests-per-minute cap, no per-plan throughput tier, and no burst quota to negotiate. Your balance is the only thing that governs how much you can do.

That’s a deliberate choice, since an agent that has to model our rate limiter as well as its own workflow is harder to write, but it means the limits you will meet come from somewhere else, and knowing where saves you debugging time.

We don’t rate-limit per workspace

Nothing in the API layer counts your requests. So:

• A 429 from us is never “you’ve used your quota.”
• Upgrading a plan doesn’t buy throughput. Plans buy included tokens per seat, nothing more.
• Two agents sharing a workspace can’t rate-limit each other. They can drain the same wallet, which is the real shared resource.

Where 429s come from

Two sources, both pass-through:

A tool signalling transient failure. When a tool can’t answer right now it returns {"status": "try_again_later", "retry_after_seconds": n}, and the HTTP layer surfaces that as 429 with a matching Retry-After header. This is the common case, and it’s charged. See Why did I get try_again_later?.

An upstream provider throttling us. LinkedIn, Reddit, the geocoder, and the mail servers behind get_email all have their own limits, and some of them are per-session rather than per-account. Hammering one company’s data from one pooled session is the fastest way to meet one.

Neither is fixed by retrying immediately. Both are fixed by honoring the backoff you were handed.

Concurrency guidance

Since nothing enforces a ceiling, the ceiling is judgement. What holds up in practice for batch work:

• 5 to 10 concurrent calls is comfortable across all tools. Above that you start meeting provider-side limits rather than ours.
• Serialize per company. Ten parallel calls against ten different domains behave well; ten parallel calls against the same domain look like scraping to the provider.
• Space out session-backed tools. LinkedIn and Reddit writes run through one real logged-in session. Two DMs a second from “a human” is a pattern worth avoiding for reasons beyond rate limits.
• Long timeouts, not aggressive retries. get_email runs SMTP probes and list_linkedin_company_employees triggers an upstream search; both can legitimately take tens of seconds. A client timeout that fires early still costs you the tokens, because the debit lands before the provider call.

For the patterns that reduce call volume in the first place (filter before you hydrate, cache the stable lookups), see Token Efficiency.

Need something guaranteed?

If you’re planning a run large enough that you want a written throughput or latency expectation, talk to us before you start rather than discovering the shape of it in production. Tell us the tool mix and the volume; some paths are ours to scale and some are a provider’s, and it’s worth knowing which is which up front.