Next Month, Big Tech Starts Auditing the Token Bill
I wrote earlier about the token economy collapse — that one was the supply side: unlimited subscriptions as a capital game between the labs, who subsidizes whom, how pricing ends. This one is the demand side: the companies paying the bill, when they start auditing it, and what they'll discover they don't know.
The Window Is Closing
For the past year, the internal logic for rolling out Claude Code / Codex / Cursor has been "just get people using it." Nobody watched tokens, because next to engineering salaries the amount is a rounding error.
That window is about to close, and the reason is boring: when something goes from "a few people trying it" to "the whole team, every day," the absolute size of the bill clears finance's attention threshold. The moment someone pulls that line item into a monthly review and asks "is this money well spent," the whole org flips from ignoring token cost to auditing it.
I'm betting this starts within the next month. Not because the bill is actually unaffordable, but because most big tech orgs crossed the "everyone's on it" threshold sometime this last quarter.
The Audit Comes From Three Angles — and You Can't Answer Any of Them
Question 1: where did the money actually go?
Not "what did we spend this month," but "which project, which person, which kind of task is burning it."
That's the first wall. Anthropic's and OpenAI's dashboards give you org-level cumulative numbers and nothing that lands on a project or a person. Codex doesn't really have a dashboard at all — the data sits in rollout files under ~/.codex/sessions/. Cursor is per-session with no aggregated history.
So a manager asks "which project on my team burns the most tokens," and nobody can answer.
Question 2: how much of it was wasted?
The most overlooked chunk, and the easiest to recover. Two typical sources:
- Cache misses. Prompt caching saves a lot of repeated input, but if your usage pattern invalidates the cache constantly, you're paying full price to re-read the context every single time. A hit rate dropping from 90% to 60% can multiply input cost several times over. Almost nobody knows what their own hit rate is.
- Redoing work. A task hits the rate limit halfway through, or the result is wrong and you start over — every token in those rounds is sunk cost. If your redo rate is high, a real chunk of your bill is tuition.
Neither number appears in any vendor dashboard.
Question 3: was it worth it?
The ultimate question, and the hardest to quantify. The naive framing is to put token cost next to actual output — merged PRs, fixed bugs, completed tasks. Ten thousand tokens that produced a shippable feature and ten thousand tokens spent going in circles are not the same thing.
But to compute that you have to line "token consumption" up against "git commits" — and right now those two datasets live in two places that have never heard of each other.
This Is a Tooling-Category Window
Notice what the three questions have in common: the data needed to answer them is already sitting on your disk — Claude Code's JSONL, Codex's rollout files, Cursor's state.vscdb, git log. What's missing isn't data. It's the layer that lands it at project/person/task granularity and lines it up with output.
Vendor dashboards won't build this. Their incentive is for you not to see your unit cost clearly — once you see it, you start cutting. Third-party SaaS dashboards want you to upload usage data from internal code, which enterprise compliance won't clear. What's left is local-first cost observability.
Vibemeter, which I build, happens to sit on exactly that line: cost broken down per project and per session, cache hit rate as a first-class metric, every session linked to the commits it produced, and nothing ever leaving the machine. I originally built it to answer "can I finish this next task before my limit resets," but looking back through these three questions, the foundation turns out to be right — the first step of auditing cost is always getting the numbers down to a granularity you can act on, not staring at an org-level total.
It's still missing multi-user aggregation, forecasting, and export before it counts as an org-level cost dashboard. But the direction just got validated by an external trend.
Different Moves for Three Audiences
If you're an IC engineer: do your own accounting before anyone asks. What's your cache hit rate? Your redo rate? Which project burns the most? Someone is going to ask eventually, and knowing the answer a month early beats being caught flat.
If you're a manager: don't wait for finance to come find you. Build per-project / per-person token visibility now, even a crude version. What you want isn't the few thousand dollars in savings — it's having an answer, an attribution, and a corrective action when the question comes down from above. It's a cheap opportunity to show you actually know what your team is doing in the AI era.
If you build tools: this is a real window, but don't ship yet another upload-your-data cloud dashboard — enterprises can't clear it. Local-first, real granularity, aligned with output. That's the moat in this category.
A Counterintuitive Prediction
In this cost-audit wave, what gets exposed is worth far more than what gets saved.
Companies open the token books to save money. What they actually find: who's getting 10x output from AI, who's burning tokens into good-looking activity metrics, and which projects should never have had AI on them in the first place.
The token bill turns into a mirror — showing who creates value and who manufactures busyness. Saving money is the surface; attribution is the substance. The teams that clean that mirror first don't win the budget they saved. They win seeing their people and their work clearly.