Evidence correction, 14 October 2026: earlier versions of this post included figures we could not source: an AT&T Copilot result, Uber per-engineer costs of $3,000 to $5,000, a Stanford and Microsoft study of 1,200 users, a FinOps visibility gap, and routing savings from internal modeling. They also said Meta imposed hard limits, which it had not. A follow-up correction the same day fixed the Uber per-engineer figures and adoption numbers, which had mixed two different metrics. Those claims are removed or replaced with the published figures below.
The week tokenmaxxing became a liability.
For the past year, every enterprise AI narrative ran in one direction: adoption metrics, tokens consumed, frontier models deployed everywhere. The measure of seriousness was how much you spent.
That flipped in June 2026.
TechCrunch reported on June 24 that companies are scrambling to stop employees from maxing out AI budgets with small tasks. Accenture, which had earlier warned staff they could miss out on promotions if they did not use AI, was now trying to stop them from spending its token reserves on basic jobs like converting PDFs into slides. The same month, Uber capped AI coding spend at $1,500 per engineer per month for each tool after using up its full-year 2026 budget by April, and Walmart moved to a fixed token allocation per employee for its internal agent.
The industry coined a term for it: tokenminimizing. The opposite of tokenmaxxing. Less prompting, not better prompting.
The instinct is understandable. The math is wrong.
What the numbers actually looked like.
The reporting around it gives a few numbers:
- Uber opened Claude Code to its engineers in December 2025. By March, 84% of its developers were agentic coding users, API costs averaged about $150 to $250 per engineer per month with heavy users at $500 to $2,000, and the full-year AI coding budget was gone by April. The cap that followed is $1,500 per engineer per month for each agentic coding tool.
- Meta: an employee built Claudeonomics, a leaderboard that ranked token use across more than 85,000 staff. It rewarded consumption, not results, and Meta shut it down in April.
- Walmart now gives each employee a fixed number of tokens for Code Puppy, its internal agent for work like spreadsheet analysis and presentations. Staff keep access to Claude and ChatGPT.
- Accenture moved from pushing employees to use AI to stopping them from using it on basic tasks.
These are spending responses, not efficiency responses. They reduce volume. They do not change unit economics.
Why agentic workloads broke the spreadsheet.
The underlying cause is not that engineers are profligate. It is that the cost structure of agentic workflows is categorically different from chat.
A 2026 study of eight frontier models on SWE-bench Verified (Bai et al., arXiv:2604.22750, with Stanford's Erik Brynjolfsson among the authors) found that agentic coding tasks consume about 1,000x more tokens than code reasoning and code chat, and that runs on the same task can differ by up to 30x in total tokens. The agent reads files, writes diffs, runs checks, reads error output, and revises. Each step burns tokens, often at frontier model rates.
GitHub Copilot Business costs $19 per user per month on the subscription plan. Uber's engineers averaged about $150 to $250 each per month in API costs, and heavy users ran $500 to $2,000.
The subscription model was priced for chat. Enterprises adopted agents. The pricing model did not update fast enough. Finance noticed.
What a hard cap actually does.
A hard cap is a quantity lever. It limits the number of queries. It does not change the cost of each query.
If an engineer hits the cap halfway through the month, they stop. Projects slow. The cap redistributes the cost into lost productivity rather than eliminating it. The total economic impact (API spend plus productivity loss) is often worse than uncapped spending with better routing.
The FinOps Foundation's State of FinOps 2026 report surveyed 1,192 practitioners: 98% of FinOps teams now manage AI spend, up from 31% two years earlier. Managing a bill is not the same as reading it, and a cap needs no per-request data at all.
You cannot optimize what you cannot see. And you cannot cap your way to a correct unit economics model.
The math: caps versus routing.
The table below is an illustrative model, not a measurement. It assumes a 5,000-engineer organization spending $4.5M a month with every call on a frontier model at $5 per million input tokens, and it counts input-token cost only. The routed row assumes 70% of calls go to a $1 model, 20% to a $3 model and 10% stay on the frontier model.
| Approach | What it limits | Monthly API cost |
|---|---|---|
| Every call on the frontier model | Nothing | $4.5M |
| Hard cap at $1,500 per engineer | Number of calls: heavy users stop when they hit the cap | Falls only by the work that stops |
| Routing at a 70/20/10 split | Price per call, at the same call volume | $1.62M (-64%) |
Prices: Anthropic list input prices per million tokens for Claude Haiku 4.5 ($1), Sonnet 4.6 ($3) and Opus ($5), June 2026.
A cap saves money by stopping work. Routing saves money at the same volume of work, but only on the calls a cheaper model handles well enough, and that share has to be measured on your own traffic. The cap is a blunt instrument. Routing is a unit-cost reduction.
The RouteLLM paper (UC Berkeley, Anyscale, Canva, ICLR 2025) shows how much that share varies. On MT Bench, its matrix factorization router reached 95% of GPT-4's performance while sending only 26% of queries to GPT-4 and the other 74% to a cheaper model. On MMLU, the same 95% target took 54% GPT-4 calls.
The visibility problem underneath the spend problem.
Most organizations implementing caps are doing so because they can't answer a simpler question: what are we getting for what we're spending?
That question is unanswerable without per-request observability. Which model handled this query? What did it cost? Did it succeed? Was the frontier model necessary, or would Haiku have worked?
Without that data, the only control available is quantity: set a number and cut people off when they hit it. With that data, you can route intelligently, set model-specific budgets, and see which workloads actually justify frontier model rates.
The correct sequence.
Tokenminimizing is a reaction to a real problem. The problem is real: enterprise AI spend is growing faster than enterprise AI output. But the reaction attacks the wrong variable.
The sequence that actually works:
- Add observability first. Per-request cost, model used, latency, and whether the frontier model was required. You cannot route without a signal.
- Set a quality floor, not a quantity cap. Define the minimum acceptable output for each task class. Route below the floor, not above it.
- Route based on query complexity. Send the queries a budget model handles well to the budget model and reserve the frontier model for the rest. Measure that split on your own traffic: in RouteLLM it was 26% frontier calls on MT Bench and 54% on MMLU.
- Cap by model tier if needed, not by total tokens. A cap on frontier model spend is a routing incentive. A cap on total tokens is a productivity tax.
The companies that implement caps today will implement routing next quarter, after they see that the cap cut productivity without fixing the unit economics. The companies that implement routing now skip the intermediate step.
What Nadir does here.
Nadir is OpenAI compatible. Point your existing API calls at Nadir's base URL, set model=auto, and the router classifies each prompt and sends it to the cheapest model that can handle it.
Per-request cost, model used, routing decision, and latency are visible in response metadata and the dashboard. You can see, at the prompt level, what each task type actually costs and whether it needed the frontier model.
Nadir publishes no universal savings percentage. What routing saves depends on your workload mix, so Nadir measures it per request against the benchmark model you choose.
You are not reducing the number of queries your engineers run. You are reducing what each query costs.