Every enterprise-grade LLM gateway ships two modes for budget checks: monitor (warn, do not block) and enforce (hard-block on threshold). Which mode you pick per workspace is the single most consequential policy decision in cost governance. Get it wrong in one direction and your budgets are theater; get it wrong in the other direction and you break user-facing traffic.
The two modes, precisely
Monitor mode: the gateway evaluates the budget check but always lets the call proceed. If the budget is over threshold, a warning event fires (email, Slack, dashboard alert). The next call still proceeds. And the next. And the next.
Enforce mode: the gateway evaluates the budget check and rejects the call with HTTP 402 the moment the threshold is crossed. The caller receives a typed error. The traffic stops.
The philosophy: fail-closed for spend, fail-neutral for quota
The ThinkNEO stance — and it is a stance, not a technical necessity — is that cost enforcement should default to fail-CLOSED, and quota enforcement should default to fail-NEUTRAL.
- Cost fail-CLOSED means: if the budget check itself hiccups (Redis unavailable, Postgres slow, control plane restart), the call is blocked. The reasoning: the alternative is to let money burn during your outage. Blocking a call is recoverable; overspending is not.
- Quota fail-NEUTRAL means: if the quota check hiccups, the call proceeds under monitor semantics. The reasoning: the alternative is to break live user traffic during a control-plane hiccup, which is a worse outcome than letting a few extra requests through.
You can invert either default with a documented rule. But the default is not a coin toss — it is a considered decision about which failure mode you can tolerate.
When monitor is the right choice
- Trial workspaces during the trial period. The user has not paid anything; blocking their fifth exploratory call is user-hostile. Monitor lets them explore, then enforce kicks in at trial end.
- Internal-only workloads with a known team owner. If a runaway spend is caught within hours by the team lead, the risk of "block by mistake" outweighs the risk of "let a bit extra through."
- New rules under evaluation. Ship a new rule in monitor mode for a period; observe how often it would fire; flip to enforce when confident.
When enforce is the right choice
- All paid production workspaces. The tenant signed up for a plan with a bounded cost commitment. Enforce is what makes that commitment real.
- Any workload where a cost anomaly would harm the business. If the ceiling matters, it is a hard ceiling, not a suggestion.
- Regulated environments. Auditors want to see that controls are effective, not that alerts existed.
Warnings before the block
Enforce mode without progressive warnings is customer-hostile. The pattern that works:
- 50% of budget: informational notice in the dashboard.
- 75%: email/Slack warning to the workspace owner.
- 90%: escalated warning; recommend action (upgrade, throttle, reduce scope).
- 100%: hard-block. HTTP 402 with clear error message and a link to remediate.
The 90% warning is doing the work — if the owner acts, the block never fires. If they don't, the block fires with plenty of prior notice.
Trial-to-paid transition
The specific case that recurs: a new workspace starts on a 7-day free trial (monitor mode for cost). At day 7, the workspace has two possible transitions:
- Trial → paid: enforce mode kicks in with the paid plan's cap.
- Trial → downgrade (still on free): enforce mode kicks in with the free-tier cap ($0 or a very small ceiling).
The trial warnings should fire at D5, D6, D7 with escalating urgency, so day 8 is never a surprise. If the tenant is caught off guard by day-8 enforcement, the warning cadence is wrong — not the enforcement itself.
The bug-bounty comp exception
Some organizations (bug-bounty programs, community grants, partner MOUs) issue permanent enforce-mode accounts as comp. These are not trial extensions — they are lifetime START-tier grants with the enforce policy explicitly encoded. The design guarantee: someone with a comp account cannot accidentally overspend, because their tier is capped and enforce is on from day one. The comp accounts are pointed to a specific comp plan code, not a magic-number rule — that way an internal audit can list every comp account and every account is enforceable.
When to break your own rules
The pattern to avoid: a technical failure in the enforcement plane cascades into blocking a whole class of traffic that had nothing to do with the failure. The mitigation is a break-glass procedure — a documented, audited, single-command flip from enforce back to monitor for a workspace or all workspaces, with a required note explaining why. Every break-glass firing is itself an audit row.
Bottom line
Hard-block vs monitor is not a technical choice. It is a policy choice about which failure mode you can afford. Default cost to enforce, default quota to monitor-on-failure, warn early and often, and give your operators a break-glass they can invoke without waking up a manager. The details are less important than the discipline of picking a default and defending it.
Related reading: What is LLM cost control? · Cost control vs FinOps · BYOK cost accounting