Twenty dollars buys you a meter

Between 14 May and 14 August I put 11.2 billion tokens through Claude Code. Across 42 active days. Priced at Anthropic's published API rates, that usage would have cost £9,140.

I paid none of it. I was on a subscription, so the marginal cost of every run was hidden from me.

Worth being clear about that number before anyone panics. Claude Code runs long autonomous sessions against a large repository, so it is an unusually token-hungry workload and nothing like a lawyer reviewing documents. It is also 42 active days out of roughly ninety, at my intensity, which is why I am quoting the period rather than annualising it. Take it as one heavy user's real consumption over one summer. It does make me, on paper, the worst customer a seat-priced vendor could possibly acquire.

Nobody approved any of it. I did not request a budget, no one reviewed my consumption, and there was no threshold I crossed that started a conversation. The flat fee was working as designed. It removed the marginal price signal, so there was nothing for anyone to review.

Under a bundled seat licence, the next run by somebody who already has a licence has no separately visible price. An extra user still costs you a seat, so the licences were never free. But once someone is licensed, their consumption carries no attributable cost, so the rational move is to hand out licences widely and then worry about whether people use them.

That is broadly how legal AI rollouts have been run. Adoption becomes a training problem. It gets owned by a champion, usually in innovation or knowledge, and their job is to get more people using the thing more often.

Put a meter on it and every run carries a price and an owner. The cost was always there. Seats, implementation, training and support have never been free. What changes is that consumption becomes visible and attributable, down to a person, a team or a matter.

That information lands with whoever owns the budget line, and it is rarely the champion. This is where the conversation usually goes wrong, because the champion gets cast as the hero and the budget holder as the villain. A competent budget holder wants to spend more where the return is good. Their problem is that they are being handed a consumption number and asked to judge it, with nothing that tells them what it bought.

Anthropic's Enterprise plan is now $20 per user per month, billed annually, and the seat fee covers access only. Anthropic's own documentation is blunt about it: the seat fee “only covers access to the platform and doesn't include any usage”, and every token the team uses, in chat, Claude Code or Cowork, “is billed at standard API rates on top of your seat cost”. Older Enterprise contracts with Standard and Premium seats, which ran up to around $200 a user and carried discounted token allowances, cannot continue past their next renewal. The discounted API rates that came with the higher seat prices went with them.

So access got cheaper and consumption moved onto its own line. The seat has stopped being a purchase and become a permission.

The part that gets less attention is what shipped alongside it. Administrators can set spend limits at organisation level and at individual user level, and Anthropic's documentation is explicit about what happens next: “if a user hits their individual limit or the organization limit, their usage will stop.”

The control is built, documented and waiting for somebody to configure it.

That is worth reading twice if you are the person who will end up owning this. Somebody in your organisation is going to decide what an individual user's ceiling is, and whether that ceiling is the same for a partner running a diligence exercise, an associate drafting, and a trainee learning the tool for the first time.

Most legal AI platforms buy at least part of their inference on usage-based terms from someone. That makes some form of downstream metering, allowance or tiering more likely as agentic products get more expensive to serve. It is a market inference rather than a fact, and Anthropic's move on its own does not establish it.

Consumption in a real deployment is uneven, and a small number of people account for most of it. The tempting reading is that those are your best users, the ones who worked out what the tool is actually for and started giving it work rather than asking it questions.

I cannot prove that, and neither can you. A large number tells you there was a large number. It is equally consistent with a badly designed workflow, a model failing and retrying, or somebody running an expensive route for a cheap job. Consumption data cannot separate those.

Which is the real trouble with the spend dashboard. It shows where the money went and nothing about what it bought, so the only question it can support is why one person's number is higher than everyone else's.

Most organisations will have that number before they have agreed how to measure value. The adoption dashboard counts frequency and breadth. The spend dashboard counts cost and variance. Neither counts completed work, quality, or risk taken out. Deploy the first two without the third and you have built the instrument this piece is complaining about: an input measure standing in for success.

And it runs as a loop. You run an enablement programme. It works. People get more fluent, fluency looks like handing over bigger jobs, so fluent people consume more. Consumption becomes visible, visible consumption gets questioned, and the successful programme generates the bill later used to cut it.

If you are about to spend real money teaching people to use this properly, draw that loop on a whiteboard before you sign anything.

Cloud teams hit a version of this and built a discipline around it. It is called FinOps, and the FinOps Foundation publishes the whole capability model for free: tagging and allocation so spend attaches to a team or a project, budgets and alerts, showback and chargeback so a team can see its own number or carry it, committed spend traded against variable use. And people whose actual job is the number, sitting between engineering and finance and fluent in both.

Legal is arriving at the same problem with the discipline already invented, which is the good news. The bad news is that I have yet to meet an in-house team or a firm with a named owner for the AI number the way a platform team owns the cloud number. The tooling is turning up from the vendors: dashboards, thresholds, per-matter attribution. Buying the instrument does not create the person who reads it.

This probably does not need a new job title. It needs a named owner and a working link between legal operations, the AI champion, finance, and whatever FinOps capability the organisation already runs. In a business with a mature cloud practice, half of that link already exists and nobody has thought to connect legal to it.

Metering does not force you to ration. You can raise the budget, run showback without chargeback, negotiate committed spend, cap only the exceptional workloads, or decide that some people should have an effectively unmetered relationship with the tool because the return supports it.

What metering forces is a decision about controls, and doing nothing is still a decision.

The default is that nobody configures anything, so individual managers adjudicate after the invoice arrives. That stays invisible until it happens, it lands on whoever is most visible rather than whoever is least valuable, and it teaches everyone watching that the safe move is to use the thing less. You end up punishing the behaviour you paid to encourage.

The deliberate version is duller. An allowance most people never reach. A budget per team or per matter that somebody owns and reviews. A stated view on which jobs are worth running agentically and which are not. An exception route that works in hours rather than weeks. Say it out loud, in advance, so that spending your allowance is normal rather than conspicuous.

The pricing conversation most legal teams are about to have will be run by procurement, framed as commercial, and judged on the number at the bottom of the page. What gets settled alongside it is which of your people get to use this, how hard, and who decides when that changes.

A target price is worth having in that room. So is a position on the usage rates, committed-spend discounts, what telemetry and attribution you get, who holds the admin controls, and how an exception gets approved and how fast. And a view on which of your people should have an effectively unmetered relationship with this technology, and what you are prepared to spend to protect it.

Work out how you are going to measure what the money bought before the first invoice lands. After that, the number does the arguing for you.