A seat does not show usage
A recurring pattern in AI-native quotes: a line for licences, and a line for consumption, both presented as pass-through cost, both fixed per month.
The consumption line at least behaves like consumption. The licence line does not behave like anything. A seat costs the same whether it is used or not, which means there is nothing to reconcile it against.
That is worth stating plainly because it has a consequence most buyers never reach. If a client pays for ten seats and the team in practice uses five, there are two entirely different situations that look identical from the outside:
- The supplier bought ten. Five sit idle. That is a real cost with no value, on the supplier's side, and they have every reason to want it corrected.
- The supplier billed ten and bought five. The difference is revenue with no matching cost, on a line that was described as pass-through.
Neither is necessarily deliberate. An estimate that is never reconciled looks exactly like the second one. But the two cannot be told apart by asking, only by reconciling, and a seat produces nothing to reconcile with.
What a key does that a seat cannot
Route the consumption through client-held API keys instead, and three things change at once.
Usage becomes visible. One key per person, separate keys for anything running server-side. Consumption per key, readable by the client. That is the whole answer to the reconciliation problem: there is now something to check.
A ceiling becomes possible. Per key, a weekly or monthly spend limit and a restriction on which models may be called. A generic router such as OpenRouter does this natively; the account carries a prepaid balance and each key is capped independently.
Model choice stays open. A generic router will call any provider's models. Box the setup into a single model vendor and only that vendor's models are available. Over a project that has to live for years, that optionality is worth something, and it is the one benefit here that cannot be obtained any other way.
The ceiling answers a question contracts cannot
Who pays when an automated run goes wrong?
As a contract clause this is close to unnegotiable. No supplier willingly writes that they carry the cost of their own agents' failed runs, and no client gets that clause through without a fight.
As a mechanism it is already solved. A hard ceiling bounds the damage regardless of who is at fault. It requires no interpretation after the event and no counterparty conceding anything. The blast radius is a number both sides agreed to in advance.
This is the same move as a credit limit rather than a liability clause, and it works for the same reason.
Two things this does not solve
Keys should not replace the supplier's seats. Subscription plans are meaningfully cheaper per token than API access, which is why suppliers use them for interactive work in the first place. A client who replaces the supplier's seats with client-held keys buys control at a higher unit price. The split that holds: seats stay the supplier's cost, since they are the supplier's working equipment; the ongoing automated consumption moves onto client-held keys with a ceiling.
Owning the accounts buys nothing else. This is worth saying because it is where the conversation usually goes first. There is no accessible history in the accounts, no accumulated effect of the kind "we have now trained it on our codebase". Visibility is the only benefit, and keys deliver visibility without anyone taking over anyone's accounts. Letting the supplier keep their own accounts also keeps the supplier responsible for their own tooling, which is a feature.
Two things to verify before proposing it
We would not accept a supplier asserting these without checking, so we should not either.
Tool licensing. Several of the agentic coding tools are licensed for interactive subscription use and are not obviously intended to run on third-party keys. Not every provider-native feature survives a router either, and caching behaviour can differ. Check it against the specific toolchain rather than assuming it generalises.
The data path. A router becomes a processor in the chain, which means a data processing agreement, multiplied by however many jurisdictions the client operates in. The roughly five percent routing premium is cheap insurance against a spike month; a new DPA across five markets is a different kind of cost. Bundle it with any other processor review already in flight.
What to call the premium
Not overhead. The five percent buys visibility on a line that was previously unmeasurable, and a ceiling on a line that previously had none. Weigh it against the peak month rather than against the list price per token, and it stops being a discussion.
Related: Quoting AI-native delivery and Governing AI cost at scale. The buyer-side series that raises the liability question this article answers begins at An even number over uneven work.