Every team that rolls out AI on metered models eventually has the same meeting. Usage grew, a workflow looped, an enthusiastic user discovered long documents — and the bill arrived weeks after the spend it describes. The alerts fired, but alerts describe the past. By the time anyone read them, the money was gone.
We think that failure is structural, not behavioral. You cannot fix it with better dashboards, tighter alert thresholds, or a monthly review. The only place to stop an overrun is before the model call — and that is where xMatix put the control.
Why post-hoc billing alerts fail
The standard pattern for AI cost control is: consume first, measure later, alert eventually. It fails for predictable reasons:
- Alerts lag consumption. Usage aggregation runs on a delay. A runaway loop or a burst of heavy queries can spend a month's budget in the gap between the event and the notification.
- Alerts don't stop anything. An alert is an email. Unless a human reads it and intervenes, consumption continues at full speed. The system has no mechanism to say no.
- Attribution arrives too late to matter. When the invoice is one number for the whole tenant, finding which team, user, or agent drove it is forensic work. You can assign blame; you cannot assign budgets.
- Nobody can plan. If the finance team cannot cap AI spend in advance, every rollout is an open-ended commitment. The rational response is to restrict access — which kills the value of having an assistant at all.
Governed consumption inverts the model: define what may be spent, by whom, at what rate, and enforce it at the moment of the request.
Seats first: who may use it
xMatix Sense is a licensed product, managed through the same licensing machinery as every other xMatix feature. A tenant holds a Sense license allocation; administrators assign user-license seats to the people who should have the assistant. The chat surface itself is gated on the seat — no seat, no assistant button, no chat window, no consumption. Access is a deliberate allocation decision, not a default.
Credits: a currency you can budget
On top of seats sit AI credit allocations. Credits are the tenant's spending currency for AI, allocated per calendar-month period. Token credits meter language-model usage; model credits meter machine-learning inference and training requests. An administrator sets the tenant's periodic quota — and, where needed, per-user caps within it — on a dedicated credits page in setup.
Credits matter because raw tokens are unmanageable as a budgeting unit. Different models cost different amounts, and finance teams do not think in tokens. Credits give every model a common denominator, which is what makes the next piece work.
Per-model rate cards
Every model available to a tenant carries a rate card defining how it converts usage into credits, in one of two modes:
- Per token — input and output credits per thousand tokens, for chat and inference models. A premium model carries a higher rate than an economical one, so the cost difference is visible in the same currency.
- Per request — a flat credit price per call, split by request kind: inference versus training, for machine-learning models where token counts are meaningless.
Rates for platform-provided models are defined centrally and are read-only to tenants — a tenant cannot quietly discount its own consumption. When a complex question escalates to a stronger model, the turn is metered at the escalated model's rate automatically; the routing decision and the billing decision cannot drift apart, because they resolve from the same model record.
Enforcement before the call — the design choice
Here is the part that makes the rest more than reporting. When a Sense turn is about to invoke a model, the platform runs a pre-flight quota check: is there an allocation for this tenant and feature, and does it have credits remaining for the current period? If the answer is no, the call never leaves the building. The user gets a clear exhaustion message instead of an answer, and the model provider never sees the request.
The check sits ahead of the model call in the execution pipeline, alongside daily token and cost budget guardrails that act as a second, coarser brake. Long-running agent workflows carry their own cost guardrails too — step caps, timeouts, and concurrency gates — so a queued background job cannot loop its way through a month's allocation. The admin copilot draws from its own separate credit pool, so an intensive build session cannot starve the assistant your field team depends on.
The consequence for planning is simple: the worst case is the number you configured. Not the number plus whatever happened before the alert was read. When a CFO asks what the AI can cost this month, there is an exact answer, and the platform enforces it.
Append-only ledgers: the audit half
Every deduction lands in an append-only credit ledger. The platform resolves which model served the request, computes the credit cost from that model's rate card, appends a ledger entry, and updates the tenant and per-user consumption counters. Nothing is overwritten; the ledger is a permanent record of who consumed what, through which agent, against which model, at what rate.
This is what turns metering into governance. Usage rollups per tenant, per user, and per agent come straight off the ledger and surface on the usage and credits admin page. Disputes resolve by reading the record rather than reconstructing it. And because the ledger is denominated in credits, a tenant reselling xMatix capability downstream can budget and allocate AI to its own users with real numbers — AI you can budget is also AI you can resell.
Bring your own key
Some organizations already have negotiated model contracts, committed spend, or data-routing requirements that dictate which endpoints their AI may touch. xMatix supports bring-your-own-key: in AI Studio, a tenant admin connects custom model endpoints under the tenant's own credentials, stored encrypted, with connectivity validated at setup. Custom models carry their own rate cards, mix into failover chains alongside platform models, and can be pinned per agent.
Governance still applies — BYO models flow through the same pre-flight checks and the same ledger. You change whose contract the tokens bill to, not whether the spending is controlled.
The shape of the whole system
Put together, the layers read like a budget hierarchy rather than a monitoring stack:
- Seats decide who can use Sense at all.
- Credit allocations cap what a tenant — and optionally each user — can spend per period.
- Rate cards price every model in the same currency, set centrally for platform models.
- Pre-call enforcement makes the cap a hard stop, not a suggestion.
- Append-only ledgers make every deduction attributable and auditable.
- BYO-key lets you choose the contract without escaping the controls.
None of this limits what Sense can do for a licensed user with budget remaining — answers, drafts, and actions work exactly as designed. It limits the one thing that should be limited: the ability of an AI system to spend money nobody agreed to spend. Alerts tell you that happened. Enforcement makes it not happen. We built the second one.