How to price AI tokens for clients: four failed attempts

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

If your agency has started using AI on your work, you are already paying for it. You just cannot see it. It sits inside a fixed monthly retainer somewhere, or it is quietly funded out of a margin the agency will not admit is shrinking. Either way, the productivity gain the tools were supposed to bring you is not showing up on your invoice as something you can question, compare, or negotiate.

I took the opposite path at The WP Clan. AI usage goes on the invoice as its own line, alongside human hours, at the provider’s own billing unit. It sounds simple until you sit down to work out what the billing unit should actually be. It cost me four failed attempts to get there, and every attempt is instructive because it fails for a reason a buyer should recognise the next time an agency quotes an “AI charge” that does not add up.

This is part 2 of a short series on the arithmetic. Part 1 argued why the line has to exist at all. This one is about how to price it honestly, and the four ways a well-meaning agency will price it wrong first.

Why the base your agency picks ends up on your bill

The base is the answer to one question: a unit of AI work costs this many currency units, calculated like so. Change the base and the invoice changes, sometimes by an order of magnitude, for exactly the same delivered work. The four attempts below all measured something real. Only the fourth measured the thing you were actually paying for.

The source material is our own internal record, dated 11-12 September, kept as the working notes for the billing model we now run against a real client on a real project management stack. The list prices I reference are the current published rates on claude.com/pricing, verified today.

Attempt one: the API list price inflates cache reads into work you never bought

The obvious base is the one every provider will give you: their published per-token API list price, multiplied by the tokens your session consumed. It has the appeal of being auditable — you can pull the transcript and reproduce the number to the penny.

The first three sessions we metered against list price came out at $161 in total. My reaction, cleaned up, was blunt: two short pieces of writing had come out of those sessions, and a bill for one hundred and sixty dollars did not match what was on the page. Something was inflating the meter.

The something was cache reads. One of those three sessions logged 110 million tokens on its own. A long conversation re-reads the same context over and over — the earlier turns, the accumulated instructions, the working documents — and the API list price bills every one of those reads. That is not, in any honest sense, work delivered to you. It is a side effect of the session being long. If your agency charges you for those reads at list price, you are paying for the fact that your project happens to require a longer conversation, which is a property of the agency’s process rather than of your work.

Attempt two: splitting a subscription makes your bill depend on other clients’ months

The second attempt tried to move away from list price by using the flat rate the agency actually pays. Our AI subscription runs at $120 a month. Divide that across the clients we ran work for in a given month and, on the month I did the sums, the share attributable to one client’s project came out at $8.

Eight dollars looked much more comfortable than one hundred and sixty. It was also unusable. What that $8 figure meant, in practice, was: your AI charge this month depends on how much AI work I happened to do for other clients. A busy month for other projects reduces your share; a quiet month raises it. That is not a billing base, that is a lottery, and no procurement team should sign an invoice built that way.

The failure here is structural. A shared cost, allocated by division, does not become a per-client price by getting divided. It stays a shared cost dressed up as one.

Attempt three: a monthly average does not survive contact with a single session

The third attempt looked more sophisticated. Take thirty days of session data, work out a blended rate — this many tokens costs that much on average — and apply that rate to each individual session as it happens. Something like the way an electricity supplier averages a tariff.

Applied to two specific sessions we had already spot-checked, the blended rate roughly doubled the cost we already knew was true. The reason is a ratio that varies enormously between sessions: how many cache reads pile up per token of actual output. Across the month the ratio averaged 370 to 1. On those two sessions it was 197 to 1. A blended average masks the variance; the moment you apply it to a session whose real ratio sits far from the mean, you are pricing a fiction.

The lesson here has nothing to do with AI, really. It is the same lesson that catches out any allocation model. An average is a good description of a set; it is a poor price for a single instance.

Attempt four: half of what looked like usage was the same message counted twice

The fourth attempt was the one that scared me, because it revealed that every previous attempt was working from a broken measurement.

The raw transcripts for a given period contained 19,181 lines that carried a usage block — that is, lines that reported having consumed tokens. When I grouped them by message.id, 8,355 of those lines were duplicate records of the same message. The client-side log kept re-appending the same usage block as the session evolved. Anything I had calculated without first de-duplicating by message.id was roughly twice the real figure.

Had that not surfaced, none of the other three problems would have been visible in the first place. The instructive part is not the duplicate itself. It is that the entire quality of the accounting hinged on a two-line change in the measurement script that nobody had thought to write. If your agency is billing you for AI without having done that de-duplication — and most have not — the number you are being handed is not the number they think it is.

The base that held: the delivered artefact, not the session

Once the measurement was clean, the answer to the base question stopped being complicated. The unit that survived all four objections is the token cost of the delivered artefact. Not the whole session, not a share of a subscription, not a blended tariff, and not the raw transcript. The output that was actually handed to the client, plus the input that went into producing it.

Two 1,500-word articles, priced this way at the current list, come out to around $0.15 on Opus 5 or $0.06 on Sonnet 5. Not $161. Not $8. Everything else — the research, the retries, the backtracking, the long context re-reads — sits on our side of the line as our overhead, because those are properties of how we work rather than of the piece you asked for. If our process is inefficient, that is ours to fix, not yours to fund.

The arithmetic collapses nicely once you notice a small regularity in the published prices. On every current model tier — Opus 5, Sonnet 5, Haiku 4.5 — output tokens are billed at exactly five times the input rate. That means input and output can be combined into a single weighted number:

weighted tokens = input + (5 × output)
1 unit          = 100,000 weighted tokens

The 1,500-word article works out at roughly 5,000 input tokens plus 2,000 output — 15,000 weighted tokens, or 0.15 units. At current list, one unit costs around 50¢ on Opus, 20¢ on Sonnet, or 10¢ on Haiku, before margin. We apply a fixed ×2 to arrive at the sale price. Nothing hidden, nothing rebalanced silently when prices move. When the provider changes their list, the unit cost changes with it, and the multiplier stays where it is.

What this looks like on a real invoice

The invoice you receive from us carries human hours as human hours, and AI usage as three separate lines — one per model tier — each measured in units of 100,000 weighted tokens. External API costs from other providers (image generation, transcription, translation) sit on their own lines, each priced in the provider’s own billing unit, each at ×2. Nothing is bundled into “AI charge” as an opaque single figure. Every line has a unit you can compare against the provider’s public rate card.

The build to make this work is not glamorous. It is a measurement job that reads session transcripts, groups by message.id to strip duplicates, filters to the delivered outputs, computes weighted tokens per model tier, and writes the result into the project management tool as time records against a set of dedicated “Token Usage” job types. There is a catch-all line — “External API Cost”, priced at ×2 against the provider’s own euro figure — so a new service does not require the catalogue to be rebuilt. When a client asks what a unit of AI work meant on their project last month, we can point to specific delivered outputs and the transcripts they came from.

A rough human equivalence, useful for reading the invoice: one unit of AI work is around 10 to 15 minutes of the assistant actively working. Around four units to an hour, then. The comparison to make in your head is not “AI cost versus zero”; it is “AI cost versus what an hour of the equivalent human work costs on the same project.”

What to ask your agency this month

If AI is now on the critical path of the work someone is doing for you, three questions are worth putting in writing. First, are you charging me for the AI you use on my work, and if not, where is the cost sitting. Second, if you are charging me, what is the base — list price, subscription share, blended rate, or delivered output — and can I see how the number on my invoice was calculated from the raw usage. Third, what is your margin on that line, stated as a multiplier.

The honest answers to those three questions tell you a great deal about how the agency runs, quite apart from what they say about AI. An agency that has thought this through has an itemised bill you can read. An agency that has not will hedge, or produce a single “AI charge” line whose derivation nobody in the room can quite explain. That is a signal worth paying attention to — because if AI cost is being handled this loosely on your bill, it is probably being handled this loosely inside the work as well.

Part 3 of this series moves from the base to the catalogue: what the invoice looks like line by line, how a project management tool actually carries it, and the traps we hit getting the numbers to survive contact with a live client project.