Tokens Are Not Currency. They're Lines of Code With a Price Tag.

Nisha Talagala has published a primer in Forbes arguing that tokens — the unit of cost and measurement for LLM consumption — are becoming a foundational business currency. She introduces the term tokenmaxxing, points at companies already publicly assessing employees by token use, and lays out a calm framework for budgets, tracking and tradeoffs. As primer, it's fine. As a roadmap for any engineering organisation that actually has to ship under a budget, it's the most polite version of a very dangerous idea.

The dangerous idea: that token usage is a measurement of work. It isn't. It's a measurement of bill. From the seat of someone who has had to defend an AI cost line in front of a CFO and an SRE rotation in the same week, the framing matters more than the numbers — and Forbes gets the framing half right.

What Forbes gets right

Three things in the article are correct and should already be on every CTO's roadmap:

1. Token spend is real and growing. The article cites the case of a single email revision consuming around 100 tokens at a cost of roughly 0.25 US cents per task. Multiply that by every employee, every workflow, every retry, every chained agent — and the line item climbs from "rounding error" to "negotiate with the CFO" within a single quarter. Companies that started by giving employees unlimited token budgets are now, predictably, rationing.
2. Tokens are non-uniform. Forbes is right that not all tokens are equal — across vendors, across models, across tasks, and across time. A token to a frontier reasoning model is not commercially comparable to a token to a small open-weights model, even if accounting wants to add them up.
3. You need tooling. Token tracking will produce the same vendor wave that cloud cost did a decade ago: a market for FinOps-for-tokens. That market is already forming.

Those three observations are enough to justify the article on their own. The problem is the fourth idea bolted onto them.

Where Forbes goes wrong: tokens as a productivity proxy

The article describes — without enough criticism — a trend in which companies treat tokens per employee per unit of time as a productivity metric. It even draws the analogy to a sales associate's travel budget: an employee who underspends their token budget is, in the article's framing, equivalent to a sales rep who doesn't book customer visits. Underspending becomes a negative signal.

This is Goodhart's Law in a new costume. When a measure becomes a target, it ceases to be a good measure. Once you tell engineers their token usage is being assessed — formally, by management, with implications for performance reviews — you have not measured anything about productivity. You have created a new market for noise.

Forbes acknowledges the abuse vector ("tokens are trivial to abuse"), but treats it as a manageable hygiene issue. It isn't. The history of engineering metrics is the history of exactly this failure mode:

• Lines of code per developer. Measured for two decades. Optimised by writing more lines of code. The reward was Fortran 77 codebases that no human could maintain. The thing being measured — value created — was uncorrelated with the metric and eventually anti-correlated. I've argued this exact case for productivity metrics and the underlying mechanic is identical.
• Tickets closed per sprint. Optimised by splitting tickets. Or closing trivial ones first. Or padding sprints. The teams that gamed it best had the worst delivery outcomes.
• Test coverage percentage. Optimised by writing tests that exercise lines without asserting behaviour. Coverage went up, defects went up, engineers were promoted.

"Tokens consumed per employee per month" sits in this lineage. It's worse, though, because every gamed token costs real money to a real vendor. The classic vanity metrics were free to game. Tokenmaxxing is paid gaming, with the invoice routed through finance.

The honest measurement is harder, and it isn't tokens

What you actually want to know about an engineer using AI tooling is approximately:

• Did the change ship?
• Did it ship correctly?
• Did it ship faster than it would have without the tooling?
• Did the engineer learn something reusable, or did they outsource the thinking?
• Is the resulting code reviewable, maintainable and owned?

None of those five are measurable in tokens. The first four are measurable through DORA-style outcome metrics — deployment frequency, lead time, change failure rate, mean time to recovery — applied honestly. The fifth is measurable only through code review and time. There is no shortcut, and tokens are not the shortcut in disguise.

The Forbes piece nods at this with the phrase "infuse the AI force multiplier" — meaning, in plain language, that the human's domain expertise is what makes a token valuable. Agreed. But that admission undermines the entire token-budget-as-productivity-metric framing it sits next to. If the multiplier is the human, the meaningful unit is outcome per engineer, not tokens per engineer. The token spend is an input cost, like cloud, electricity or office space — and you don't promote people for spending more on electricity.

What tokens actually are: a cloud cost line, with worse defaults

If you strip out the productivity-metric mistake, what's left is correct and worth managing properly. Tokens belong on the same maturity curve as cloud spend, and the playbook from the FinOps decade applies almost unchanged:

1. Allocate spend to outcomes, not to people. A token consumed by a CI agent that catches a regression in production is not commensurable with a token consumed by an engineer asking an LLM to rephrase a Slack message. Tag tokens by workflow, not by employee — the same way you tagged EC2 instances by service, not by the engineer who launched them.
2. Set per-route quotas, not per-person budgets. The interesting cost overrun in an AI-augmented org is rarely a chatty employee. It's a runaway agent in an automated pipeline calling a frontier model in a loop with retry-with-backoff. Per-employee budgets won't catch that. Per-tool and per-workflow budgets will, the same way per-service cloud budgets caught the lambda that span up Aurora reads at 3am.
3. Price-arbitrage between models. Forbes is right that vendors and prices fluctuate; the correct response is a routing layer that sends each task to the cheapest model that meets the quality bar for that task — not a fixed contract with one frontier vendor at list price. Foundation-model economics rewards careful build-vs-buy decisions per workload, not standardisation on the most expensive option.
4. Build observability before incentives. Most organisations are about to make policy decisions about tokens before they have reliable per-task attribution. The order is wrong. Get the attribution right first — by service, by workflow, by retry, by user-facing outcome — and then talk about budgets. Otherwise you'll set quotas based on noise.

This is FinOps with a different unit. It is not, and should not be, performance management.

What "tokenmaxxing" actually signals about an organisation

If an engineering organisation finds itself rewarding token consumption — or worse, finds its engineers gaming token consumption to look productive — the problem isn't with the engineers. It's with the leadership that picked the metric. Tokenmaxxing is a symptom, and the underlying disease is the same one I see at every client that hasn't built a real measurement culture: management wants a single number, finance wants a single number, and the LLM bill is conveniently a single number that goes up.

A real engineering org resists that compression. It runs at least two streams in parallel:

• A cost stream. What did we spend on AI tooling, broken down by workflow, by team, by model, by retry mode? Where is the waste? Is the routing layer doing its job? Are agents looping?
• An outcome stream. What shipped? What didn't? What was the change failure rate? Did the AI-assisted PRs have a different defect profile than the non-assisted ones? Did the AI catch more incidents than it caused?

If you only run the cost stream, you'll end up optimising for token consumption — and Forbes is correctly describing the kind of company you'll become. If you only run the outcome stream, you won't catch the runaway agent that lit your AWS bill on fire. You need both, and they need to live on different dashboards reviewed by different people.

What I'd put in front of a CTO this quarter

1. Per-workflow attribution before per-employee budgets. Until you can name the top five token-spending workflows in your stack, you do not have a token problem you can solve.
2. A kill-switch per agent, the same kind I've argued is non-negotiable for any agentic production system. An infinite loop in an agent is now a finance incident as much as an SRE one.
3. A model-routing layer, even a rudimentary one. If every team is calling the same frontier model directly with no fallback to cheaper tiers for trivial tasks, your token bill is paying for laziness in your platform, not productivity in your engineers.
4. A measurement policy that explicitly excludes tokens from individual performance. Make it written. Make it loud. The first time a manager praises an engineer for "consuming more tokens this quarter", the metric is dead and your culture is downstream.
5. A line in the budget for waste. Some fraction of token spend will be exploratory, dead-end and irreducibly experimental. That's fine. Name it, budget for it, and stop trying to optimise it to zero. The waste line is also where most of the learning happens.

The line I'm drawing

Forbes is right that tokens are now a real line item that companies need to plan, track and govern. Forbes is wrong — or at least dangerously casual — about extending that line item into a productivity metric for individuals. The first is FinOps. The second is the lines-of-code mistake re-issued with a vendor invoice attached.

The companies that will navigate the next two years well will be the ones that treat tokens with the same boring discipline they (eventually) learned to apply to cloud: allocate spend to outcomes, route work to the cheapest sufficient model, observe before you incentivise, and never — never — promote an engineer for consuming more of the input.

Tokens are a cost. The engineer is the multiplier. If your metrics confuse those two, you don't have an AI strategy. You have an AI bill.

---

Sources:

• Nisha Talagala, Are Tokens The New Currency? A Primer For Business, Forbes, May 2026. forbes.com
• The Pragmatic Engineer, The Pulse: Tokenmaxxing as a weird new trend. blog.pragmaticengineer.com
• Wall Street Journal, Why Some Companies Say AI Tokenmaxxing Is Key To Survival. wsj.com

Trying to put an AI-augmented engineering team under a real budget and not sure how to measure it without breaking the team? Talk to a CTO — we'll help you separate the invoice from the work.