Skip to main content

​
High-level overview

A Quota is a budget attached to one subject inside a workspace: the workspace itself, one agent, one verified end user, one Gateway, one pool, or one model. The Quota names a USD limit and a window (daily or monthly). Dome prices each completed model call at per-model token rates, adds that cost to every matching subject’s spend for the window, and checks those budgets before the next call proceeds. Setting a Quota and exhausting it looks like this:
  1. An operator sets a monthly workspace Quota of $5,000.
  2. Agents keep calling models through a Gateway.
  3. Each completed call adds priced spend to the workspace counter for the current UTC month.
  4. While spend stays under $5,000, calls continue. The first call that would push the counter over the cap receives HTTP 429.
  5. The same call can also hit an agent Quota, a Gateway Quota, and a model Quota. Every matching budget must still have room.
Pick who owns the budget and how often it resets. Dome refuses or reroutes when the money is spent.

​
When a Quota change takes effect

The limit you set (subject, amount, window, enabled) is workspace config. Dome loads that config on a poll interval (default about 10 seconds), the same tick that picks up Rule and Guard config. A new or updated Quota may not shape enforcement until the next successful sync. After that sync, the new limit is live. Spend moves when priced calls complete. Edit the Quota form and the counters do not jump. Raise a limit and spend already recorded in the window stays. Disable a Quota and that budget stops being checked. Other Quotas that still apply keep their own counters.

​
Every matching Quota must pass

Subjects carve different slices of the same traffic. A single model call can touch several Quotas at once: the workspace total, the calling agent, a verified Act-As user, the Gateway in the URL, the pool that routed the call, and the model that served it. Dome allows the call only when every applicable enabled Quota still has remaining budget. An agent Quota with room left cannot override an exhausted workspace Quota. Subject types and what each rejects are on the Quotas reference.

​
Windows reset spend, not the Quota

A window is the calendar period the counter covers. daily resets at UTC midnight. monthly resets at the start of each UTC calendar month. The default on create is monthly. You can keep both a daily and a monthly Quota on the same subject. They are separate budgets. When the window rolls over, spend for that window starts at zero again. The Quota itself stays until you update or remove it. Details are on the Quotas reference.

​
Exhaustion: reject or spill inside a pool

Most Quotas reject affected calls with HTTP 429 when the budget is gone. Model Quotas inside a pool can behave differently. The resolver skips the exhausted member. If another eligible pool member remains, the caller never sees the exhaustion. If every member is unavailable or exhausted, the gateway returns HTTP 429 with subject_type: all_members. Direct calls to an exhausted model (no pool spillover path) return HTTP 429 with subject_type: model. Quota enforcement is a barrier applied before the pool’s routing strategy runs, so spillover composes with priority_weighted, round_robin, and least_loaded alike. Refer to Pools concept and model Quotas reference.

​
What counts toward a Gateway Quota

A Gateway Quota follows the gateway in the request path, not a fixed membership snapshot. Usage accrues when a call is routed through that Gateway, whichever pool or model member serves it. Membership can change during the window. Spend still lands on the same Gateway Quota. Passthrough LLM calls are still checked against Quotas, but they do not add priced spend. The opaque body carries no token usage to meter.

​
What you see in audit

Completed model calls emit llm.model_call.completed with token counts. Exhaustion emits access.denied with deny detail QUOTA_EXCEEDED. Create, update, and delete emit their own lifecycle events. Event names are on the Quotas reference.

​
Next steps

With the Quotas spend-cap model in mind, continue with:
  • Architecture concept for where Quotas sit in the request path
  • Rules concept for allow and deny before spend metering
  • Guards concept for content inspection after authorization
  • Quotas reference for subjects, windows, and event names
  • Set Usage Limits to create, update, list, and remove Quotas