There are two kinds of limit in Revoye and they behave differently: ours protect the service, and yours protect your provider accounts. Confusing them is the commonest source of "why is my integration slow" tickets.

Revoye's ingress limits

Requests per minute, per API key and per IP. Exceeding them returns 429 RATE_LIMITED with a Retry-After header. Honour the header.

This limit is about request rate, not work volume. It is difficult to hit accidentally with real prompts — a prompt takes tens of seconds to run — and easy to hit by polling GET /v1/status in a loop. If you are seeing 429, look at your polling before you look at your prompts.

Your own hourly limits

Set in the dashboard, at three levels:

Level	Protects
Per agent	One browser tab, one provider account, from being hammered
Per provider	Everything on that provider together
Global	All your providers at once

When one is reached, the router stops dispatching to whatever it covers. The job does not fail — it waits, or goes to another eligible agent. 503 PROVIDER_RATE_LIMITED surfaces only when you asked not to wait, so a caller who wanted an immediate answer gets an explanation rather than a hang.

GET /v1/status reports rate_limit_per_hour and used_this_hour for each provider, so your own code can see how close it is.

Setting them sensibly

These caps exist because a browser session that suddenly makes hundreds of requests an hour does not look like a person using a chat product. Set them below whatever the provider would consider unusual for your account, and leave headroom. Revoye cannot tell you what that number is — no provider publishes one for its web interface — which is exactly why the control is yours and the default is conservative.

Sizing your fleet

Throughput is agents, not bandwidth.

prompts per hour  ≈  agents × (3600 / average seconds per prompt)

At 45 seconds per prompt, one agent is roughly 80 prompts an hour. Three agents, roughly 240 — if your own hourly caps allow it, and if the machine can keep three tabs generating at once.

The constraints, in the order they usually bind:

Your hourly caps.
The number of agents you have created.
The machine's memory — every agent is a browser tab running a heavy web application.
What each provider account tolerates.

Diagnosing a slow integration

Symptom	Cause	Fix
`queue.depth` climbing, `agents.idle` at zero	Saturated	More agents, or fewer prompts
`queue.oldest_queued_at` far in the past, `devices.online: 0`	The machine is asleep	Turn it on; or use webhooks so it does not matter
Frequent `PROVIDER_RATE_LIMITED`	Your own cap is the constraint	Raise it deliberately, or spread across more providers
Frequent `429 RATE_LIMITED`	You are polling	Poll less; use webhooks
`attempts > 1` on most jobs	Agents are timing out	Check the extension; raise `timeout_ms` for long prompts

Other limits


Prompt	100 000 characters
Request body	1 MiB
Queued jobs per account	1 000
Per-attempt timeout	5 000–600 000 ms (default 180 000)
Whole-job deadline	10 000–3 600 000 ms (default 900 000)
`metadata`	4 KiB
List pagination	`?limit=` default 25, max 100, with `?cursor=`

Lists are cursor-paginated, returning { "data": [...], "next_cursor": null }. Offset pagination is not offered — it skips and duplicates rows on a table that is being written to.

Rate limits and capacity