What each limit actually does
Why requests/minute is approximate
The gateway throttles per second, not per minute, and it is a token bucket. A 500/minute plan is configured as a refill of ≈8.33 requests/second with a burst capacity of 100. The consequence is arithmetic, not a defect: a client that has been idle arrives with a full bucket, so it can land 100 requests immediately and then draw the sustained rate on top. Inside one rolling minute it can therefore complete meaningfully more than 500 requests. Conversely, a client that sends its whole minute’s allowance in the first two seconds will be throttled even though it is under its per-minute number. Read your per-minute figure as a sustained rate you can plan capacity against, not as a ceiling that will reject the 501st request.Why requests/day is approximate
The gateway’s quota periods areDAY, WEEK and MONTH; there is no finer
period, which is also why requests/minute cannot be expressed as a quota at all.
Quota accounting is distributed and eventually consistent, so the count that
trips is close to your usage rather than identical to it.
Why tokens/minute is “exact accounting, approximate admission”
The token count is computed exactly from your request body, before any engine work. What is approximate is when that count starts refusing traffic: enforcement is subject to the same short bounded window as every other claim on your key, so there is a period in which you can exceed the rate before admission catches up.Your hard admission controls are the request rate, the daily quota and the
per-request ceiling. Read the tokens/minute figure as the sustained token rate
your plan is sized for.
The one limit that is exact
The per-request ceiling is checked at the top of the handler, before the engine runs and before anything is billable. It is stateless: there is no cache, no window, no eventual consistency. If your request is over it, you get a413
with the exact numbers, every time.
That is deliberate, and it is the control that actually matters against runaway
cost: it bounds what any single request can consume, which is the failure mode
a rate limit cannot bound at all.
The offerings
There are two: Pay as you go, which is what self-serve signup lands on, and Enterprise.
Burst is 20% of the per-minute allowance on both offerings.
There is no self-serve path onto Enterprise. Email
hello@nextmoca.com.
On Enterprise the per-minute rate is the binding constraint:
2,000/min sustained for a full day is 2,880,000 requests, so the daily quota
cannot be reached. Plan against the rate, not the quota.
Per-request ceilings
These apply to every single request, independently of your plan’s rate.
A
413 from the token or record ceiling tells you exactly what to do about it:
observed/limit pair is there so you can resize precisely
instead of halving and retrying.
What counts toward the 100,000
The same quantity the meter uses: every customer-supplied text field the engine processes:keywords, tags and attributes are not counted: they are structurally
small, and metering them would complicate a number you have to be able to
reproduce for no additional protection.
These three fields are bounded only by the 6 MB body limit. Do not read “not
metered” as “free to fill”: a payload that depends on them being unbounded is
relying on the absence of a limit rather than on a guarantee, and that is not a
safe thing to build on.
The ceiling is denominated in the heuristic token count that this formula
produces. That count is an approximation of the request’s token count, not a
model tokenizer’s measurement of the same text, so the two will not agree. The
count a request is actually metered and billed on is returned in the response as
usage.input_tokens; treat that returned number as the authoritative one rather
than pre-computing a count with a tokenizer.How to recompute your own bill has the
reference implementation of estimate_tokens, so you can check a payload
against the ceiling before you send it.The autochunk candidate ceiling
budget.autochunk splits each record into candidate passages before selection,
so one document can be selected within rather than only kept or dropped whole.
That means the number of things the engine ranks is no longer the number of
records you sent, and records cannot bound it: a one-record request can
produce hundreds of candidates.
So the post-split count has its own ceiling of 384, checked before selection
runs:
observed and limit
tell you how far over you are, so you can split precisely.
budget.autochunk is not supported on every operating point. On a label
that does not accept it, the request is refused with 400 and reason: "autochunk_unsupported_operating_point" rather than being served with the flag
silently ignored, so a call that returns 200 with autochunk set is a call
where autochunk ran. Requests that set it also carry records_expanded in the
response: how many extra candidates the split produced.The text normalization ceiling, and why it differs by operating point
The text shape splits
your paragraph on blank lines into records for you. That split has its own
ceiling, separate from the 1,000-record ceiling above, and the three
published labels do three different things when a text request crosses it.
This was verified live, on the same oversized request (roughly 1,100 short
paragraphs) sent unchanged except for budget.operating_point:
np-2026-08-r4 tells you outright that your text was too large to
normalize; np-2026-07-r2 and np-2026-08-r3 both truncate silently, and
np-2026-08-r3 can charge you for the privilege. If you send long text
payloads, check records_available against how many paragraphs you sent
regardless of which label you pin, and prefer np-2026-08-r4’s explicit 400
to a silent truncation if you have a choice. Split the source text yourself
before sending it, the same way you would split any other oversized request.
Key caps
How the cap is counted depends on the kind of workspace you are in.
On a team workspace there is a second, organisation-wide backstop of 32 live
keys, independent of any one member’s own count. A member can be well under
their own cap and still be refused because the workspace as a whole has reached
32. When that happens, ask another member to revoke a key, or email
hello@nextmoca.com.
A revoked key does not count against either cap; a key still activating does.
The caps exist for a specific mechanical reason rather than as a licensing
lever: a suspension or plan change has to rewrite the organisation record and
every key in one all-or-nothing transaction, and that transaction has a hard
size limit. Capping keys is what keeps a plan change atomic, and it is why the
organisation-wide backstop exists on top of the per-member cap.
Remember that rotation is create-then-revoke, so you need one spare slot to
rotate without an outage.
Minting and revoking keys are self-serve, from the dashboard’s Keys page.
Rotation is create-then-revoke, in that order; see
Authentication.
Provisioning a key is not instantaneous either way; associating it with your
plan takes a minute or two.
Handling a 429
A rate limit and a daily quota both surface as429, with different bodies:
Retrying a daily-quota
429 in a tight loop turns one exhausted quota into a
self-inflicted outage plus a support ticket. Branch on the body.
Because the plan limits are approximate in both directions, a 429 is a
normal operating condition rather than an incident. Build the backoff in from
the start; do not treat the first one you see as a bug.
Requesting more
Rate, quota and per-request ceilings are plan attributes, so the usual answer is a plan change. Two cases are worth raising with us directly instead:- A workload that is legitimately over the per-request ceiling: a single document that genuinely does not fit. Splitting is usually the right answer, but not always, and we would rather hear about the case than have you work around it silently.
- A burst shape the token bucket handles badly: for example a batch job that wakes hourly and wants its whole hour’s traffic in ten seconds. That is a configuration conversation, not a plan upgrade.
Errors
Every status code, what causes it, and whether to retry.