Skip to main content

Rate limits and spend caps

Two kinds of limit apply to a key. The rate ceiling bounds how fast it may go and is the operator's to change. Spend caps bound what a day, a week or a month may cost and are yours. Both live on the platform; jevlin limits reads the spend side from a shell.

The rate ceiling​

Every project has three figures: requests a minute, requests an hour, and how many may run at once. They come with the project, not the tier, and every key in the project shares them.

unclaimed agentproject, and a claimed agent
requests a minute10120
requests an hour1203,000
at once216

These are the defaults since 19 October 2026. A project created before then kept its earlier figures, 10 a minute, 60 an hour and 2 at once, until an operator raises them, which is why an older project's Limits page may still show those. Everything on the search API counts against the rate: searches, feedback, and the free reads such as jevlin limits and the traces the platform shows. A turn end does not; it has its own, looser allowance.

The ceiling is enforced by the router, not the client. Nothing in the config or the skill changes it.

Seeing it, and asking for more​

Sign in at platform.jevlin.ai, pick the project, and open Limits. The three figures in force are shown under Now. Above the request form is a cap of your own: a number at or below the ceiling, blank or 0 for none. Set it to hold a project under its ceiling, and Save rate limit. It never raises anything.

Request higher limits asks for the three figures you want and an optional reason; the placeholder says what helps, such as moving from testing to a production workload. Request increase sends it to the operator.

  • A person decides it, from the operator's side of the platform. There is no automatic grant.
  • Until it is approved the current ceiling stands. The page shows the new figures once it is.
  • Nothing to install or restart; the router applies the new ceiling to the project's next request.

Requesting a ceiling from the command line is not built.

The free allowance​

Separate from both: a search that carries its trajectory is served free, up to a daily count per tier and $2 of engine cost a day per account, and draws nothing from credit or from the caps below. See Pricing and the free tier for the bands and the numbers; 402 credits_exhausted and 402 spend_ceiling do not apply to a free search.

Spend caps​

A claimed account has no fixed daily allowance. Its ceiling is its credit: today's spend plus the project's share of what the organization has left, recomputed about once a minute. An unclaimed agent has a fixed one, $0.10 a day, about six fast searches.

Below that, you can set caps of your own for the day, the week and the month, from the platform (the project's Spend limits) or with a key over the API. Windows are calendar UTC: the day from midnight, the week from Monday, the month from the 1st. A new cap binds within a minute. Reading or setting caps spends nothing and works when the account is at its ceiling or out of credit, which is when you need it.

A search is charged after it runs, at its real cost, so the request that crosses a cap completes and the next one is refused.

From a shell​

jevlin limits # the caps and today's spend, read from the router
jevlin limits -json # the same as one envelope

It prints the three caps, none where no cap is set and not reported where the router sent nothing, then today's spend against the effective ceiling, the lowest of the credit balance and the caps, and what remains. Setting a cap from the command line is not built.

Since 21 October 2026 the router also reports the week's and the month's spend on the same read; the client does not print them yet, and -json carries only what it printed.

When a request is refused​

A request over a limit is refused, not queued. Branch on the envelope's code, action and retryable, never on the message; see The envelope.

what ran outthe router answerswhat to do
the minute's or the hour's requests429 rate_limited, with how long to waitwait, then retry; raise the ceiling if it keeps happening
requests at once429 concurrencylet one finish; the next request runs
a spend cap, or the unclaimed daily ceiling402 spend_ceilingwait for the window, raise the cap, or claim the agent
the organization's credit402 credits_exhaustedtop up on the platform

A self-set cap refuses the same way as the ceiling, with the same code. If searches are being refused and the Limits page looks wrong for the work, clear your own cap first; if the ceiling itself is the bound, request an increase.