AI budgets and rate limits

Two separate limits govern how much Sentinel-Q your organisation can use in a day, and they fail in different ways for different reasons. Knowing which one you have hit turns a confusing outage into a two-minute diagnosis, so this article names both, gives you the exact response each produces, publishes the figures for every plan, and is honest about the one thing the product tells you to do that you cannot actually do.

The per-minute request limit

This one counts whole calls to the assistant per organisation per minute, regardless of how large each one is. Like the daily spend cap and the per-request output ceiling below, it comes from your plan.

Exceeding it returns HTTP 429 with the body {"error":"rate_limited"}, and writes an audit row of type rate_limited recording how long to wait. Nothing is lost — your message has already been saved to the thread by the time the limiter is consulted, so retrying continues the same conversation.

The daily spend cap

Every model call is metered — input tokens, output tokens, and an estimated cost — and the running total for the UTC day is checked before each new call. The cap is set by your plan, and each organisation is metered and limited entirely on its own: one organisation's usage can never consume another's budget or push another over its cap. There are three states.

Normal

Below the soft threshold. Full model, full output budget. Nothing is different.

Degraded

Soft threshold crossed, by default at 75% of the cap. The turn is still served, on a cheaper model, with the output capped at 1,024 tokens and agentic tool rounds capped at four. Your burn rate roughly halves and your answers get noticeably shorter. Nothing tells you this is happening in the conversation itself — the only record is the degraded flag on the call's audit row.

Exhausted

The cap is spent. No model call is made at all for the rest of the UTC day.

The cap is per plan, and it is enforced. These are the figures in force, per organisation, per UTC day:

The output ceiling is the length limit on a single reply — roughly, how much the assistant can say in one answer before it has to stop. It is why a Complete answer can run considerably longer than a Core one on the same question. Note that Free carries a nominal figure only: Sentinel-Q is not enabled on the Free plan at all, so nothing on Free reaches the cap in the first place. See The plans, and what each one includes.

Degradation begins at the soft threshold, by default three quarters of whatever your plan's cap is.

AI_TENANT_DAILY_USD_CAP     fallback when a plan cannot be resolved (12.0)
AI_TENANT_SOFT_THRESHOLD    default 0.75  (fraction of the cap)
AI_COST_ENFORCEMENT         set to off/false/0/no to meter without enforcing
AI_DEGRADE_MODEL            the cheaper model used while degraded
AI_BYO_LOOP_GUARD_USD_CAP   default 250.0 (bring-your-own provider only)

Exhaustion returns HTTP 429 with a Retry-After header pointing at the next 00:00 UTC, and this body:

The status code is deliberate. 402 Payment Required would be wrong because nothing is unpaid, and 500 would be wrong because nothing is broken. It is a queueing signal: come back tomorrow, or move to a plan whose cap fits how you actually work.

Seeing your spend before you hit the cap

This used to be impossible — every call was metered but nothing exposed the total, so the first evidence you got of approaching the cap was your answers becoming shorter, with no explanation available anywhere. That gap is closed: go to Settings → AI spend for today's calls against the daily cap, how much of it is used, the last 30 days, and a breakdown by provider and by model.

The workaround this article used to recommend — watching for terse answers as a proxy for being near the cap — is no longer necessary, but it still works if you prefer a live signal over checking a page: past roughly 75% of the daily cap the assistant degrades before it stops.

If you bring your own AI provider

An organisation running on its own AI provider credential is not subject to the per-plan daily spend cap at all. The calls are billed by the provider directly to that organisation, so capping our estimate of money we are not spending would achieve nothing. What applies instead is a runaway guard: a much larger ceiling, set far above any plausible legitimate day and far below a plausible invoice shock. The shipped figure is $250 of estimated list-price spend per UTC day.

• The cheap-model swap is not applied to you. Routing your traffic to a cheaper model to save money you are already paying would be presumptuous, and the configured degrade model is very likely not one your account or deployment can serve at all.
• The output and tool-round tightening still applies when the soft threshold is crossed, because that is the part that actually stops a loop.
• Metering does not change. Every call is still recorded, flagged as billing to you, so a loop is visible and so invoicing can exclude those calls.

See Bringing your own AI provider for how to configure one, and which providers are supported.

The cost figure is an estimate, not an invoice

Cost is computed locally from a built-in price table of list prices per million tokens, multiplied by the tokens the provider reported. It is not read from a provider bill, it does not know about your discounts or committed-use agreements, and it will not reconcile to the cent with what you are charged.

Two behaviours in that table are worth knowing, because they both push in the direction of the cap firing early rather than late — which is the safe direction for a budget, and the annoying one for a user.

1. An unrecognised model is priced at the most expensive rate in the table. Under-counting is how a budget silently blows, so an unknown model id is charged as though it were the top-tier model. On Azure OpenAI and Microsoft Foundry this is the common case rather than the exception, because the model field there is a deployment name somebody chose and not a model id — so an EU deployment can price roughly ten times too high and hit the cap ten times too early unless the operator supplies a deployment-to-model mapping.
2. A real call is never rounded down to free. Anything that costs more than zero and less than one micro-dollar is recorded as one.

Where the budget deliberately fails open

Three paths choose availability over enforcement, and each records that it did so. None of them is a bug; all three mean the cap can be exceeded.

One thing does not fail open: the spend total is cached for fifteen seconds, and each new call's cost is folded into the cached figure rather than being dropped. A burst of calls inside one cache window therefore still trips the cap.

A correction: all three plan limits are now enforced

Diagnosing it

1. 1

   Read the status code and the error string

   429 with rate_limited is the per-minute limiter. 429 with ai_budget_exhausted and a Retry-After is the daily cap. 403 with prompt_blocked is neither — that is the prompt-injection scanner, covered in Conversations with the assistant.

2. 2

   If it is the per-minute limiter, look for automation

   Ten requests a minute is not something a person hits by typing. Something is calling the chat endpoint in a loop — a script, a retrying integration, or a browser tab left open with a client that retries on failure.

3. 3

   If answers went short before the failure, you were degraded first

   That is the ordinary sequence: normal, degraded from 75%, exhausted at 100%. It means the spend was gradual rather than a single runaway call.

4. 4

   If it failed with no degraded phase, suspect the price table

   A jump straight to exhausted suggests either one very large burst or a model id the price table does not recognise being charged at the top rate. On Azure OpenAI or Foundry, that is the first thing to check with whoever runs your deployment.

5. 5

   If the cap is genuinely too low for how you work, change plan or ask us

   Nobody in your organisation can raise it from the console, whatever the message says. Compare your daily use on Settings → AI spend against your plan's figure in the table above: if you are hitting the cap on ordinary work rather than on a runaway script, the next plan up is the self-service answer and a support request is the other one.

What to read next

1. Conversations with the assistant — the context window, the notices you may see, and what a turn records.
2. Bringing your own AI provider — running on your own credential, and what changes when you do.
3. The plans, and what each one includes — where the per-minute figure comes from.