How to Track and Cap LLM Spend Per Customer in Multi-Tenant Platforms

Why reporting alone does not cap spend

In a multi-tenant platform, many customers share the same models, agents and tools, and often the same provider credentials. A provider invoice shows one total. An aggregate dashboard shows trends. Neither tells you which tenant consumed which tokens, and both arrive after the spend has happened.

OWASP guidance for LLM applications points to several controls: API gateways or middleware that enforce per-user or per-IP rate limits, continuous monitoring of resource consumption, response times and costs, and hard spending limits and billing alerts in the provider's console. OWASP also frames uncontrolled consumption as both a cost and an availability threat, with recursive or resource-intensive queries and uncontrolled tool chaining as named scenarios.

Two cautions follow. Per-user or per-IP limits are not per-tenant limits, so tenant scoping has to be designed deliberately. Provider-level limits are useful as a backstop, but do not assume they can be scoped to an individual tenant. Treat spend control as an enforcement problem with an evidence trail, not as a reporting problem.

Propagate tenant identity and meter tokens accurately

Attribution is only as good as the identity attached to each request. Derive the tenant from authenticated context, such as a validated session or signed token, at the first trusted boundary. Do not accept a tenant value supplied by the client. Carry it as request context through every hop, including queues, agent steps and tool calls. If it is missing, apply a restrictive default budget or reject the request rather than attributing usage to a shared bucket. This is the same discipline OWASP describes for multi-tenant isolation, where tenant metadata travels with the data, for example alongside every retrieval chunk.

A single shared provider credential hides tenants from the provider, so attribution must happen on your side of the call. Per-tenant credentials can help where the provider supports them, but they add key management and do not replace platform-side metering.

For token accounting, estimate input tokens and reserve budget before the call, then reconcile against actual usage when the call completes. For streaming responses, count output as it arrives and cut the stream if a hard limit is crossed. Treat each retry as its own billable attempt, tied to the original request ID with an attempt number. With multi-model routing, record the model on every call and normalize usage into a common unit using a versioned price table. Count tool calls as a separate dimension, because loops can consume budget without large token counts.

Set tiered limits and choose the right action

Tiers usually follow the commercial relationship: a default tier, higher tiers for larger tenants, and tighter limits for new or unverified ones. Combine a rate limit, which bounds burst behavior, with a token budget over a longer window, which bounds cumulative use. Add per-model and per-tool limits where a model or tool carries disproportionate exposure.

Soft thresholds should change behavior without stopping the tenant: notify, slow requests, or route to a smaller model if your routing policy allows it. Hard thresholds should block. Escalation for human approval suits cases where a tenant has a legitimate reason to exceed its tier, such as a seasonal processing peak. It needs an owner, a timeout and a recorded outcome. Decide up front whether enforcement fails open or closed if the metering store is unavailable. For hard limits, failing closed is the more defensible default, though the right choice depends on the business function the request supports.

Failure modes to test before production

Retries are the most common source of silent overrun. If the client, the SDK and the platform each retry, one user action can become several billable calls. Meter at the point nearest the provider and key each attempt to the original request.

Tool-call loops and recursive queries can exhaust a budget through repetition rather than size. Limits may need to cover the number of tool calls and the depth of chaining per request, not only model tokens. This is an inference from the OWASP scenarios rather than a prescribed control, and it should be tested explicitly with recursive and resource-intensive inputs.

Shared-credential gaps appear when background jobs, internal tools or evaluation scripts call the model outside the tenant-aware path. Each of these either needs a tenant context or an explicit internal-use identity. Finally, check for streaming overrun, where a long response passes a hard limit before the count is updated, and for concurrent requests that each pass a check but together exceed the budget.

Where should enforcement sit?

Enforcement can live in application code, in provider quotas, in gateway or middleware, or in a policy layer in the execution path. Evaluate each against the same criteria: whether it covers every model, agent and tool; whether a developer can bypass it; whether limits scope to a tenant; whether it can be deployed in your own environment to meet data residency requirements; and whether retention and evidence durability are configurable.

• Application code: Flexible and close to business logic, but applied inconsistently across services and models, and easy to bypass with a new code path.
• Provider quotas and console limits: A useful backstop with hard limits and billing alerts. They act at provider level, and per-tenant scoping should not be assumed.
• Gateway or middleware: Enforces rate limits at request time for traffic routed through it. Coverage depends on every call using that route, and tool calls may fall outside it.
• Policy layer in the execution path: Evaluates each interaction and tool call against policy before it proceeds. It needs tenant identity supplied to it and a defined failure behavior.