Multi tenant architecture rests on an assumption that held for twenty years: the marginal cost of serving one more customer is close to zero. Storage is cheap, compute is shared, and a heavy user costs you slightly more database time than a light one.
Inference breaks that. A tenant running agents against their data generates real, measurable cost per action, and the variation between tenants is enormous rather than marginal. One account can genuinely consume more than the rest of your customer base combined, and under a flat subscription you absorb all of it.
The noisy neighbour problem grew teeth
Multi tenant systems always had noisy neighbours. One tenant running heavy reports slowed things for everyone, and the answer was rate limiting and query optimisation.
The version that arrives with inference is different in two ways. It affects your cost directly rather than only your performance, and it scales with how much value the tenant is getting rather than with anything you can call abuse.
That second point matters. A tenant hammering your database with inefficient queries is doing something wrong and you can ask them to stop. A tenant using your agent features heavily is doing exactly what you built, successfully, and costing you money for it. There is no version of that conversation where they are at fault.
So this is a pricing and architecture problem rather than an abuse problem, and treating it as abuse produces a bad customer conversation and no solution.
Meter per tenant before you need to
The first requirement is knowing what each tenant costs, and most platforms cannot answer that today.
You need inference spend attributed to a tenant, ideally to a feature within that tenant. Without it you have one monthly bill and no way to tell whether it is broad growth or three accounts, which are completely different problems with completely different responses.
Build this before you need it, because retrofitting attribution across a codebase where calls happen in a dozen places is considerably harder than adding it at the boundary. If your model calls already go through a single interface, this is a small change. If they do not, that is the actual finding.
Then look at the distribution rather than the average. Averages hide exactly the case that will hurt you, and the useful chart is cost per tenant sorted descending, where the shape is usually a steep curve rather than anything resembling a normal distribution.
The first thing we look for is whether model calls already pass through one interface. When they do this is an afternoon; when they are scattered through the codebase, consolidating them is the real project and the metering is the easy part.
Caps are a product feature, not a punishment
Once you can see it, you need limits, and how you present them determines whether customers accept them.
A cap framed as a restriction feels like a downgrade. The same cap framed as spend protection is something finance teams actively want, because their fear is an unpredictable bill, and a limit is the answer to that fear rather than an obstacle.
Make it visible. Usage against allowance, in the product, before anyone hits it. Customers discovering a limit at the moment they hit it experience an outage; customers watching a number rise make decisions.
And decide what happens at the ceiling. Hard stop, degrade to a cheaper model, queue, or notify and continue with overage. Each is defensible and each needs to be chosen deliberately, because the default is usually whichever one falls out of the implementation.
The same reasoning applies from the other side of the table, which we covered in what outcome billing costs the buyer.
Not every step needs the expensive model
The architectural lever with the largest effect is routing, and it is frequently the last one teams reach for.
Most workflows contain a mix of steps. Classification, extraction and formatting are handled well by smaller and much cheaper models. Genuine reasoning across ambiguous context is where the expensive one earns its price. Sending everything to the largest available model is simple and is usually paying several times over for the majority of calls.
Caching matters more than most teams assume, because tenant workloads repeat far more than they expect. The same document summarised twice, the same question asked by two people in one company, the same enrichment run nightly on records that have not changed.
Both of these reduce cost without touching what the customer receives, which makes them the work to do before any pricing change.
Routing is the lever we reach for first and teams reach for last, usually because the pipeline was built when only one model was worth using. Revisiting that assumption is frequently worth more than any pricing change.
Tenant isolation now includes cost
Isolation used to mean data and performance. Add cost to the list.
Practically that means per tenant budgets enforced in code rather than in a spreadsheet, alerting when a tenant's spend changes shape rather than only when it exceeds a threshold, and the ability to throttle one tenant without affecting anyone else.
That last capability is worth building before you need it. The alternative during an incident is a choice between absorbing the cost and degrading service for everybody, and neither is a decision you want to be making at speed.
This is the cost side of the same shift that repriced the sector, which we looked at in what agents did to software valuations.
If you are adding agent features to an existing multi tenant platform, our SaaS development team treats metering and caps as part of the feature rather than as a later addition, because retrofitting them is where the cost actually lands.
Frequently Asked Questions
How do we attribute inference cost to a tenant?
Tag every model call with the tenant and the feature at the point it is made, and aggregate from there. If your calls go through one interface this is a small change. If they are scattered through the codebase, consolidating them is the first task and worth doing regardless.
What if a few tenants are unprofitable?
That is common and usually fine, provided you know which ones and by how much. The problem is not having unprofitable accounts, it is not knowing you have them. Once visible, the options are pricing, caps, or a conversation, and all three require the data first.
Will customers accept usage limits?
Generally yes, when they are visible and generous enough not to bite in normal use. Finance teams often prefer a capped bill to an open ended one. What customers reject is discovering an invisible limit at the moment it stops their work.
Should we build a separate tier for heavy users?
Often the cleanest answer. It gives heavy users a legitimate path rather than making them feel like a problem, and it lets you price the cost you actually incur. It also stops the base tier being priced defensively against a minority of accounts.
How much can routing to smaller models actually save?
Frequently the majority of inference spend, because most steps in most workflows are not the hard ones. It requires evaluating each step honestly rather than assuming the whole pipeline needs the largest model, which is the default nobody revisits.
Is per tenant infrastructure the answer?
Rarely. Dedicated infrastructure solves isolation and multiplies operational cost and complexity. Metering and caps within a shared architecture solve the same problem for far less, unless you have a compliance requirement that genuinely demands separation.
How do we forecast this cost as we grow?
Model it per tenant rather than in aggregate, using the distribution rather than the mean. Growth in tenant count and growth in per tenant usage are separate variables that behave differently, and a forecast built on an average will be wrong in whichever direction hurts most.
Talk to our team if you are adding agent features to a multi tenant platform and cannot yet see cost per tenant.