Tokenmaxxing Is a Trap. ValueMaxxing Is the Way Out.

Tokenmaxxing gave way to token budgeting, but neither fixes the economics.

What's the difference between tokenmaxxing and valuemaxxing?

Tokenmaxxing is the reflex that defined early 2026: consume as many tokens as you can. Companies like Meta and Salesforce pushed employees to burn tokens, and some even ran internal usage leaderboards all based on the theory that more consumption meant more productivity. Reach for the biggest model, the longest context, the most calls, and don't count. It treats token consumption itself as a proxy for value.

ValueMaxxing optimizes a different ratio:

ValueMaxxing = value delivered ÷ infrastructure cost

The distinction matters because the two numbers move in opposite directions. Per-token prices have collapsed — by some estimates more than 200× over two years — while total enterprise AI spend has risen sharply over the same period. The thing that actually drives your bill isn't the unit price; it's how many tokens your product consumes to deliver one unit of value. As many have learned: with no guardrails in place, agents are voracious.

A simple chatbot answers a question in one call. An agent plans, calls tools, reads results, re-plans, and loops. Gartner's March 2026 analysis puts agentic workloads at 5–30× the tokens per task of a standard chatbot, and other production data puts coding agents closer to 50×. The most-quoted real-world example: Uber burned through its entire 2026 AI budget in about four months on tools like Claude Code and Codex, then capped employees at $1,500 a month. (SemiAnalysis argues cases like Uber's are partly self-inflicted via leaderboards that rewarded consumption, so we should view this case as a cautionary tale, not the median.) The unit price wasn't the problem. The unit count was.

But the story didn't stop at overspending. Through 2026 the industry swung to the opposite reflex: token budgeting. Once the bills landed, enterprises started rationing, and SemiAnalysis's mid-2026 survey of 50+ enterprises found per-employee AI budgets becoming the norm, anywhere from $250 to tens of thousands a month. But a cap is a blunt instrument: it throttles the very usage that was supposed to create value and so in some cases it’s most likely to also throttle productivity. ValueMaxxing is a third way: to not burn freely, not to ration, but to make each dollar of infrastructure deliver more, so you don't have to choose.

This is Jevons' paradox in a data center: make a resource cheaper to use and total consumption rises faster than the price falls. Tokenmaxxing accelerates the treadmill. ValueMaxxing steps off it.

If token burn is so bad, why isn't everyone screaming about it?

The budgeting wave (and rash of “blame the platform”-style news commentary) shows enterprises finally feeling the bill. But in our own customer interviews, plenty of teams still aren't describing token burn as acute pain, and not because the problem is small. For many right now, it's being masked so it will ultimately surface late and all at once.

The masking mechanism is subsidy. The major cloud and model providers hand out credits and token grants at a scale that makes inference feel free for the first year or two of a company's life. AWS Activate credits have been redeemable against third-party foundation models on Bedrock — Claude, Llama, Mistral and others — since 2024, with accelerator cohorts receiving anywhere from six figures up to seven. Google Cloud advertises up to $350K for startups; Azure offers its own tier. For a young AI company, 60–70% of infrastructure spend is compute and inference, and credits can wipe out both for one to three years.

It's not only startups. Larger enterprises get a different anesthetic: AI vendors funded to sell tokens below cost, and internal budgets nobody scrutinizes until they blow up, which is exactly how a company Uber's size burned a year's budget in a quarter. Same masking, different balance sheet.

It is therefore reasonable to assume that subsidies will go long enough to mask the cost curve entirely until suddenly they don’t. For example, some credits expire on a 12–24 month clock, and some providers have already tightened enforcement in 2026. The pattern we keep hearing in interviews is the same: cost only becomes a board-level conversation when the credits run out or once someone on the board or in the org has flagged the risk. Teams running on grant-funded inference don't reason carefully about per-token economics, because they don't have to yet.

Here's the strategic point. A subsidy is not a solution. Token grants keep inference cost off the customer's income statement, but they don't make a single workload more efficient. The tokens still get burned; someone is just absorbing the bill temporarily to win the account. The underlying inefficiency (e.g. GPUs idling between requests, KV cache recomputed on every turn, frontier models answering questions a small model could handle) is untouched. When the subsidy ends, the customer inherits the full, unoptimized cost structure and a switching decision they were insulated from making.

The only durable position is to actually make the workload cheaper to run. That's a technological fix, and it's the one we're betting on.

Where does inference cost actually come from?

You can't optimize what you don't decompose. Inference has two phases with completely different cost profiles:

• Prefill processes your prompt. It's compute-bound and parallel — the GPU is busy.
• Decode generates the response one token at a time. It's memory-bandwidth-bound, which is why providers typically price output tokens at roughly 2–6× input tokens. Every generated token re-reads the model's key/value cache from memory; the GPU spends much of decode waiting on memory, not computing.

This is why "just buy cheaper tokens" misunderstands the machine. The cost isn't a fixed property of a token, it's a function of how well you keep the GPU fed and how much redundant work you avoid. That's the surface ValueMaxxing operates on.

What does the optimization toolkit actually look like?

The good news for anyone willing to treat this as an engineering problem: the techniques are real, open-source, and individually well-documented. The table below is the toolkit we're building against. Each gain is real but workload-dependent — treat them as proof the lever works, not as the number you'll hit.

Table: Inference optimization techniques, what they reduce, and representative published gains.

A few of these deserve emphasis because they directly attack the agentic cost driver:

Routing is the highest-leverage and most underused. RouteLLM's published result cut cost (~85% on a standard benchmark while preserving 95% of GPT-4-class quality) by sending only ~14% of queries to the expensive model. Most agent loops call a frontier model for every step, including the trivial ones. Routing the easy steps to a small model is found money. (The exact percentage is benchmark-specific; the principle is not.)

KV-cache reuse is the one agents need most and get least. An agent re-reads the same growing context on every turn, re-paying prefill it already paid. Caching and reusing that state and increasingly treating the KV cache itself as a form of agent memory removes redundant compute that scales linearly with conversation length. And this isn't only about cost: as an agent's context fills, its accuracy degrades, so loading only what each step needs improves reliability as much as it cuts the bill.

Speculative decoding and FP4 quantization attack the memory-bound decode phase head-on. EAGLE-3 reports 3–4× more tokens per dollar on current hardware with no quality tradeoff; NVIDIA's NVFP4 reports near-baseline accuracy at a fraction of the memory and compute of FP8. These compound with everything above.

The point of the above table isn't any single row. It's that these things stack. A team that batches and caches and routes and quantizes isn't shaving 10% — it's operating on a structurally different cost curve than a team buying raw tokens at list price.

There's a lever underneath all of these that never shows up on a pricing page: utilization. The figure we keep hearing from infra builders is that average GPU utilization sits near 40%; disciplined placement of models across the right hardware pushes it to 80–85%. That alone can cut costs by 40–50% on a stack that's already running open-source models because you're just paying for fewer idle GPUs. It's also the lever an owner-operator of the data center is best positioned to pull.

So what is Aurora building?

We think the right frame is inference as a control problem, not a procurement one. If you've reserved a fixed slice of GPU, which is how serious capacity gets bought, then your objective isn't "cheapest token." It's maximum value extracted per dollar of that reservation. That reframes the whole stack as a control loop you tune, and it's where Aurora's position as an owner-operator of the underlying data centers and reservable GPU capacity becomes an advantage rather than a cost line.

The design areas we're exploring, informed directly by the production teams we're interviewing:

• Optimizing against a fixed reservation — making value-per-dollar the explicit objective function, not an afterthought.
• KV cache as agent memory — letting agents recall state without re-paying prefill on every turn.
• A multi-tenant control plane — sharing adapters and cache safely across workloads to harvest utilization that single-tenant setups leave on the floor.
• Idle-capacity harvesting — interactive traffic at peak, batch jobs off-peak, against the same owned hardware.
• Proof as product — the aim is to prove savings on your real workload, not a benchmark. The teams furthest along here replay the shape of a trace rather than its contents, so customers never hand over sensitive data. That's the bar we want to hold ourselves to.

The optimization claims in this space are easy to make and hard to verify, which is exactly why inflated savings pitches thrive. We'd rather show you the savings on your own traffic than ask you to trust a benchmark.

What this means if you're putting agents into production

If you're early and running on credits, the honest advice is to model your steady-state, un-subsidized cost now while you still have runway, because the grant clock is shorter than the time it takes to re-architect. The teams that get surprised are the ones who let the subsidy stand in for a cost strategy.

There's a second lever that doesn't show up on a token invoice at all: where the work runs. Owning the data center and the energy behind it changes the cost floor, and for many teams it also answers a data-residency and sovereignty requirement they'd otherwise pay a premium to satisfy. Value-per-dollar is a function of the whole stack, not just the model.

And when you do confront the real number, remember that the lever isn't the price tag on a token. It's how much value you extract from each dollar of infrastructure you've already committed to. Gartner expects the provider's cost of inference to fall more than 90% by 2030 through exactly these efficiency gains — the question is whether that efficiency shows up in your margins or only in someone else's.

Tokenmaxxing waits for the next price cut. ValueMaxxing builds the thing that makes the price cut yours.

Aurora owns and operates the data centers and GPU capacity its customers run on, which is why we care about value-per-dollar of infrastructure rather than headline token prices. We're currently interviewing teams running agentic workloads in production to inform what we build next — if that's you, we’d love for you to get involved; just book a meeting with our CPO Tim, using his meeting link below: