The meter is the leak.

The invoice that ended one healthcare pilot was not large. A few hundred dollars, itemized to the thousand tokens, broken out by day. What stopped the room was not the number at the bottom. It was the column on the left — a count, growing every week, of API calls. Someone on the compliance side looked at it for a while and asked the only question that mattered: every one of these was a clinical note, and every one of them went where, exactly, to be counted?

Nobody had a clean answer. The model was good. The integration worked. And the meter that priced it had also, quietly, become the single best inventory of protected health information leaving the building — kept by the vendor, not by them.

Here is the thesis: in a regulated boundary, a per-token meter is not a pricing mechanism that happens to have a privacy footnote. The meter is the privacy decision. You cannot bill per token without the token leaving, and you cannot let the token leave without someone — the party doing the counting — holding a durable record of it. The number on the invoice is the least interesting thing the meter produces.

What a meter actually requires

Metering is not free to operate. To charge you for a thousand tokens, the billing party has to receive those tokens, tokenize them, count them, attribute them to your account, and retain enough of that to survive a billing dispute. That retention is the part nobody puts on the slide. A usage record specific enough to bill is specific enough to subpoena. In ordinary software this is a yawn. In a payer, a bank, or a hospital, it is a second copy of the most sensitive thing you have, sitting in someone else's system, with a lifecycle you do not set.

And it never stops. The defining property of per-token pricing is that the cost scales with every call, forever — and so does the record. There is no version of “we ran it ten million times” in which the meter has not seen ten million conversations. The economics and the exposure are the same line on the same graph, climbing together. People reach for the meter to make AI feel cheap to start. It is the part that is most expensive to govern.

The obvious objection

The counter is real and worth stating plainly: hosted, metered inference is how the frontier ships, and for good reason. You get the best models the day they release, no GPUs to buy, no serving stack to keep alive, and a bill that tracks usage so you never overpay for idle capacity. For most software, that trade is correct. We are not arguing it away.

We are arguing that it inverts in a regulated boundary. The thing that makes metered inference efficient — one shared model in the provider's cloud, every request flowing to it — is exactly the thing a regulated buyer is liable for. The per-call elasticity you are paying for is, structurally, a per-call egress you are answerable for. The convenience and the exposure are not two features you can separate and keep one. They are the same mechanism seen from two sides.

Serving without the meter

So we built the other way. A LeanLogix model is forked per tenant — its own adapter over a shared base, its own lineage — and served inside your boundary, on infrastructure you control, at a flat license. There is no external per-token meter in the inference path, because there is no external party in the inference path to do the counting. The fork-order API makes the per-tenant isolation explicit: one tenant, one adapter, one signed lineage, none of it routed through a billing plane that would have to see the traffic to price it.

This is not a discount on the same product. It is a different product with a different liability shape. When the inference runs in your environment and the cost is a license rather than a meter, the question that ended the pilot — where did every clinical note go to be counted — has a one-word answer. Nowhere. They did not leave, because nothing outside the boundary needed to count them. The absence of the meter is the absence of the second copy.

What this changes about the decision

The point is not that flat licensing is always cheaper — at low volume, metered usually wins on raw dollars, and we will say so. The point is that the meter-versus-license choice has been mis-filed. It is sitting in procurement's cost column when it belongs in the risk register, because the variable it really sets is not price per call. It is whether a record of every call exists, in whose hands, under whose retention policy, for how long.

A regulated team that has internalized this stops asking vendors what the per-token rate is and starts asking a sharper question: when this runs a hundred million times, who will be holding the log, and can they be made to produce it without us in the room? For a metered service the honest answer is always yes. Building so the answer is no — so there is no log to produce because there was never a meter to keep it — is not a pricing preference. It is the governance decision, made early enough that it is still cheap to make.