Skip to main content
A usage limit caps what one workspace can spend. Set one on a staging workspace and a runaway loop stops itself instead of burning the month’s budget. Set one on a team’s workspace and its spend becomes predictable. You will find them under Platform > Usage, behind the Usage limits button. Limits are off by default. A workspace with no limits set behaves exactly as it always has, so turning this feature on for one workspace changes nothing anywhere else.

​
Two limits, because they catch different things

Each workspace can carry two limits, and either one works on its own. A monthly budget is the one to set if you want spend to match a number you have agreed with finance. It will not stop a loop, though: by the time a monthly cap trips, the money is already gone. That is what the daily ceiling is for. Setting both is the usual answer. The monthly window follows your billing period rather than the calendar month, so the figure you see here reconciles with the invoice. If your billing period starts on the 14th, so does the monthly window. The daily window is always midnight UTC, whatever timezone you work in. The two are independent. A daily ceiling resetting does not touch the monthly budget, and the reverse.

​
Setting a limit

Open Usage limits, pick a workspace, and fill in either field. Both are in euros. Leave a field empty for no limit on that window. You also choose what should happen when a limit is reached:
  • Notify and keep serving. We email your billing managers once and the workspace keeps running. This is the right choice for production, where going quiet unexpectedly is worse than an unexpected invoice.
  • Block new requests. The workspace refuses new requests until the window resets. This is the right choice for staging and for experiments.
Setting a limit needs the billing permission, so owners and admins can change one and other members cannot. Everyone who can see the Usage page can see the limits and how much of them is used.

​
What counts toward a limit

Everything a request spends counts: inference, embeddings, retrieval, guard checks, the PII firewall, ingestion, memory extraction and traces. If a request cost you credits, it moves the number. Charges for stored data do not count. Keeping documents and memory in your knowledge graph carries a monthly charge, and that charge is left out of the limit on purpose. It is a charge for data already at rest rather than for anything anyone did, so counting it would let a completely idle workspace breach its limit, and blocking requests would not bring the charge down. Your plan allowance is the instrument that bounds stored data. This is why the page calls the number usage and not spend: it is what the workspace’s activity cost, not your whole invoice. Expect it to read lower than your bill.

​
When a blocking limit is reached

Requests from that workspace are refused with HTTP 402 until the window resets. The error names which limit it was and when it lifts, so it is not a bare “payment required”:
type is always usage_cap_exceeded. code is daily_usage_cap or monthly_usage_cap, so a client can tell the two apart without reading the message. This applies to every request that spends, not only chat completions: embeddings, document ingestion, remembering a fact, and the MCP tools are all refused the same way. A document upload that was accepted before the limit was reached and processed after it shows as failed with the reason on it, rather than disappearing.

​
Getting out of a block

A limit you set too low is not a trap. Raise or clear the limit and it takes effect immediately. There is nothing to wait for and no cache to clear. The next request is served. A block never applies to your last remaining workspace. If your organization has only one workspace, choosing “Block new requests” on it will not take you offline: we email you instead. The dialog says so when this applies to you. Once you have a second workspace, blocking works normally on both.

​
Alerts

When a limit is reached we email your organization’s owners and admins once for that window, whether the workspace blocks or keeps serving. Crossing the same limit again later the same day does not send another email. When the window resets, the alert arms again. A workspace that keeps serving still sends the email, so a workspace running over its budget is never doing so quietly.

​
Seeing what happened

If a limit was reached during the period you are looking at, a banner appears at the top of the Usage page naming the workspace and the limit. That turns “why did our requests stop” into something you can answer yourself. Every limit reached and every request refused is also written to the audit log, along with every change anyone makes to a limit, including who made it and the old and new values. Look for the Workspace component in Platform > Audit logs.

​
Good to know

A limit can be exceeded slightly. The check runs before a request is served, so the request that crosses the line still completes. The window total can end up over the limit by the cost of that one request. The alternative would be to charge you and then refuse, which is the thing this feature exists to prevent. Limits are per workspace, and usage is attributed per workspace. Usage in one workspace never counts toward another’s limit. Your credit balance stays pooled across the whole organization: a limit governs attribution, not your balance. A limit of zero is allowed. Set one on a workspace you want frozen and every metered request is refused, subject to the last-workspace rule above. Limits do not replace low-balance alerts. A limit bounds one workspace’s activity. Low-balance alerts tell you the organization is running out of credits altogether. They are worth having both.