Rate limits and fair use
Permaura never charges per agent or per call. A hosted gateway is the one part of Permaura that costs us something every time it does work, so hosted gateways carry rate limits and a monthly fair-use ceiling. Reaching either slows a gateway down for a while. It never produces a bill, a cutoff or lost data.
The numbers on this page are the ones currently in force. They may change, and we will give notice on this page before a change takes effect.
What is never limited
No plan caps how many agents you connect, on a hosted gateway or a local one, and no plan caps how many connections you add. There are no per-agent or per-call charges on any plan. What a plan does set is the count of things listed on Plans, such as workspaces, members and hosted gateways.
A gateway you run yourself, on your own machine or on a server you control, carries none of the hosted limits below except a per-session rate, which there is 120 calls a minute with a burst of 30, so one runaway agent can't swamp the gateway for every other agent. A gateway you run has no gateway-wide rate limit and no monthly ceiling, and because it runs on your hardware you can change the per-session numbers with the PERMAURA_LIMIT_RATE_PER_MIN and PERMAURA_LIMIT_RATE_BURST environment variables.
What is limited on hosted gateways
Three limits apply to a gateway that Permaura hosts for you. The first two are rates, which keep a sudden flood of calls from overwhelming the gateway; the third is a ceiling on total use across a month.
| Limit | Counts | Currently |
|---|---|---|
| Per session | calls from one agent session | 30 a minute, with a burst of 10 |
| Per gateway | calls from all sessions on the gateway together | 30 a minute, with a burst of 10 |
| Monthly fair use | mutating calls in a calendar month (UTC) | an email at 250,000, slowed at 500,000 |
The burst is how many calls can arrive in quick succession after a quiet spell before the per-minute rate takes over. A hosted gateway saves its whole store after every call, and the storage behind it takes about one save a second, so the per-gateway rate sits at what that storage can keep up with: above it, calls would wait on storage instead of running. Every request an agent sends to the gateway counts, including the few it makes when it first connects, and the burst covers those.
What counts as a mutating call
The monthly ceiling counts mutating calls, meaning requests that change something stored on the gateway, and a request counts once however much it changes. A tool call that reaches a policy decision counts, because the decision is written to the audit log, and so do changes made in the console, such as editing a policy or approving an agent. A call refused before any policy looks at it (over a rate limit, too large, or naming a capability the gateway does not have) writes no audit record and does not count. Reading changes nothing, with one exception: the gateway notes when an agent connected with a setup code last used its session, at most once a minute per session, and the request that notes it counts whatever it was, a tool listing included. So an agent that only lists its tools or polls an approval adds at most one call a minute; an agent that signed in with your Permaura account, and you looking around the console, add nothing while only reading.
For scale, 500,000 mutating calls in a month is about 12 calls a minute around the clock, every day of the month.
What happens at each threshold
At 250,000 mutating calls in a month, the owner of the organization gets an email saying the gateway has passed that point, and the console shows a Fair use badge on the hosted gateway. Nothing else changes, and the gateway keeps running at its normal limits.
At 500,000, the owner gets a second email and the gateway is limited to 10 calls a minute for the rest of the month. It keeps running and keeps serving your agents, only more slowly, and the badge says so. On the first of the next month (UTC) the counter resets and the limit lifts on its own, with nothing for you to do.
What never happens
Reaching a limit never produces a per-call charge or an overage bill, never cuts the gateway off, and never deletes anything. Your connections, policies, grants and audit log stay exactly as they were.
An agent that goes over a limit gets an HTTP 429 response with a Retry-After header giving the number of seconds to wait, and can retry once that has passed. For developers, the body looks like this:
{
"error": "rate_limited",
"scope": "worker",
"docs": "https://docs.permaura.com/billing/rate-limits",
"message": "this hosted gateway is at its call rate limit across all callers; it is slowed, never cut off or billed",
"reason": "rate",
"retry_after": 2
}
scope says which limit the call ran into: worker for the gateway as a whole (including while it is slowed at the monthly ceiling), or session for a single agent session.
How large one call can be
Every gateway, hosted or one you run yourself, also limits the size of a single agent call. These limits are about memory rather than use, so they do not lift with time, and sending the same call again is refused the same way.
A request an agent sends to the gateway to call a tool (POST /v1/invoke, or a request to /mcp) can be at most 2 MiB. A larger request is refused with a 413.
From gateway 1.3.53 a call also has a ceiling on its unpacked size: 128 MiB on a hosted gateway, and 448 MiB on a gateway you run yourself with its default settings. The unpacked size is the gateway's estimate of how much memory the call's parameters take once it reads them, which can be many times the bytes sent: 2 MiB of points such as {"x":1,"y":2} unpacks to about 113 MiB and is within the hosted ceiling, while 2 MiB of one-field objects such as {"a":1} unpacks to about 180 MiB and is not.
The gateway checks the ceiling before it parses the call's parameters and again before any policy decides whether the call needs approval, so a call over it is refused whether or not it would have been held for approval, and nothing is run or held. Over REST the refusal is a 413; on /mcp it is a JSON-RPC error (code -32000) carrying the request's id. Both give the call's size and the limit and tell the agent to split the call. Over REST the body looks like this:
{
"error": "too large: this call's parameters would take about 188743680 bytes (180.0 MiB) once unpacked, over this gateway's limit of 134217728 bytes (128.0 MiB) for one call; split it into smaller calls"
}
On a gateway you run yourself, the ceiling moves only with the gateway's memory budget for calls, PERMAURA_LIMIT_JSON_POOL_BYTES, set in bytes between 16 MiB and 8 GiB (512 MiB by default): the ceiling is that budget less 64 MiB, or half of it when the budget is under 128 MiB. Raising the 2 MiB request limit with PERMAURA_LIMIT_BODY_EXEC_BYTES does not move the ceiling, and a larger request can then be refused for want of memory even when it is under it. Each refusal writes one line to the gateway's log with the call's size, the limit and the route, and none of the parameters.
If your agents need larger calls than this, talk to us about a higher tier, or run the gateway yourself and give it a larger budget.
Enterprise
On Enterprise, a hosted gateway is a dedicated instance that stays on rather than scaling to zero, and it has no monthly fair-use ceiling. It still has a gateway-wide rate limit, which is set per contract to fit what you run through it. Talk to us if that is the shape you need.
Asking for more
If your agents need more than these limits allow, email support@permaura.com with the workspace name and a rough idea of what the agents are doing. We would much rather hear about it before a gateway is slowed than after. If you expect to run above the monthly ceiling month after month, that is what Enterprise is for.