There is a new pitch making the rounds in boardrooms: stop thinking about headcount and start thinking about token volume.
One developer equals some number of tokens per month. Replace the developer, buy the tokens, and let the spreadsheet declare victory.
The math looks clean because it leaves out the work.
A developer is not a token consumer
Tokens are what a model consumes when someone asks it to do something. A developer is the person who decides what to ask, whether the answer makes sense, and what should happen next.
That distinction disappears when executives turn model usage into a staffing unit. Software work is not interchangeable. A frontend engineer tuning rendering performance does not use AI in the same way as a backend engineer designing a distributed system. A DevOps engineer automating deployments has different needs from someone building a data pipeline. Token volume cannot tell you which of those jobs was done well.
It also cannot tell you which work should not have been done. That is part of the job too.
The number moves constantly
My own usage changes sharply from week to week. During a large rewrite or rearchitecture, I might use agents to inspect years of data, work across several repositories, and test a new interface. The token count climbs.
The following week may involve review, testing, and cleanup. I still use the same tools, but most of the work can run on smaller models with shorter context. The count drops.
Neither week tells you how productive I was. A large token bill can mean useful progress. It can also mean a looping agent, a poorly scoped prompt, or a developer who let a model generate ten versions of a solution instead of making a decision.
Token spend is not a quality metric for a programmer. Treating it as one encourages the wrong behavior: more prompts, longer context, and expensive models selected for the appearance of effort.
The price is not stable either
Even if you accept the comparison, the cost model changes underneath it. A prompt sent to a small model costs a fraction of what the same prompt costs on a frontier model. Providers change prices, models change token efficiency, and tools hide which model handled the request.
A $200 subscription can make the service feel cheap while venture funding absorbs the difference between the price and the actual cost of inference. If the subsidy changes, the budget changes with it.
The provider matters too. A team that uses one vendor builds its expectations around that vendor's prices, limits, and model behavior. Move the same workload elsewhere and the token count can change substantially. The cost model was never a fact about the work. It was a fact about the tool the team happened to choose.
What disappears when people leave
The dangerous part is not a bad spreadsheet. It is what happens after the spreadsheet wins.
A company cuts the people who understand the system, its old failures, and the reasons behind its awkward decisions. Later, the token bill arrives higher than expected. The model can generate code, but nobody left knows which parts of the system are safe to touch or which apparently simple change will wake up an old incident.
You can cancel a model subscription. You cannot simply rehire the institutional knowledge that walked out during the reorganization.
If someone tells you to convert developers into token volume, ask which model they used for the calculation. Ask whether the price includes the real cost of inference. Ask what happens when the subsidy ends. Most importantly, ask who will know what to ask the model after the people who understood the system are gone.
In the Slop Codex, the Warlock of Staff Reduction uses token math to justify a reorganization already decided. The Solo Sovereign treats the same math as proof that one person can own everything. Both have confused a model's output with a human being's judgment.
Tokens are a useful operating measure. They are not employees, expertise, or accountability. If the spreadsheet cannot tell you who knows the system when it breaks, it is not a staffing plan. It is a way to hide the risk.