Laveur
arrow_backAll posts
July 26, 2026TJ Magno7 min read
aiengineeringai strategytechnology

The End of Tokenmaxxing

Meta, Uber, and Shopify all tried unlimited flagship-model access. All three got the same expensive lesson: more tokens isn't more value.

The End of Tokenmaxxing

For the last two years, the operating assumption inside many engineering orgs was simple: hand developers the flagship model, tell them not to worry about the bill, and see what happens. Not because leadership wanted to waste money, but in the time of a "land grab" or "gold rush," speed felt like the only thing that mattered. The fastest way to look fast was to burn through as many tokens on the biggest, most expensive model available and hope value showed up somewhere in the wreckage.

Worldwide AI spending backs up how far that ran. Gartner forecasts total AI spend in 2026 will hit $2.59 trillion, up 47% from last year. Enterprises are set to more than double what they spend, specifically on generative AI models and agents. And yet MIT's Media Lab found that despite over $30 billion in enterprise AI investment, 95% of pilots showed zero measurable financial return. Spend was up nearly 50%, but 19 out of 20 pilots couldn't even pay for themselves.

That's the reckoning… the end of "tokenmaxxing." 2026 is the year many companies are finally sitting down, reassessing their AI strategies and budgets, and charting their respective courses toward some calculable and justifiable ROI.

Claudeonomics

Meta is a perfect poster child for this reckoning. Earlier this year, an engineer built an internal leaderboard called "Claudeonomics," tracking AI token usage across more than 85,000 employees. It handed out badges and titles: Token Legend, Session Immortal, Cache Wizard. In one 30-day stretch, employees burned through more than 60 trillion tokens. The top individual user averaged 281 billion tokens a month, a figure that would cost real money no matter which model was doing the burning.

Still from Anchorman of Brian Fantana (Paul Rudd) confidently gesturing next to the line "60% of the time, it works every time," used to illustrate unreliable AI output despite heavy spendStill from Anchorman of Brian Fantana (Paul Rudd) confidently gesturing next to the line "60% of the time, it works every time," used to illustrate unreliable AI output despite heavy spend

Meta's own CTO, Andrew Bosworth, set the tone back in February, saying that a top engineer spending an amount equal to their salary on tokens saw a 10x productivity increase, and calling it "a no-brainer" with "no upper limit." That was the mindset the whole leaderboard ran on: more tokens, more status, more proof you were "AI-native." And, apparently, more value creation.

Except engineers who actually looked at what was happening under the hood found something less flattering. People were running agents idly for hours just to climb the rankings. ROI wasn't the point, tokens used was the point. Meta quietly killed the leaderboard within days of it becoming public, and has since moved to cap and centrally monitor internal AI spend.

Uber ran the same experiment and got the same answer faster. The company blew through its entire 2026 AI coding budget in four months, most of it on flagship coding models, and had to cap employee spend at $1,500 per month per tool. Uber's own COO admitted that despite roughly 95% of engineers using AI tools monthly and a majority of new code being AI-assisted, the link between all that token spending and any measurable output "is not there yet."

In April, Shopify's VP and Head of Engineering lauded their own internal token usage leaderboard, stating they "actively celebrate the people who use the most tokens" to make sure great work with AI gets recognized. In June, they shut it down. They realized it created the same perverse incentive. Employees ripped through tokens just to climb the rankings, more concerned with looking like they were doing a lot of work than actually building or showcasing anything of value.

Three different, "tech-forward" companies learned the same lesson the same, expensive way: unlimited access to the smartest model on the market doesn't automatically produce more value. All you can count on is consuming more tokens. Those aren't the same thing, and 2026 is the year that distinction started actually costing people their budgets.

The Miscalculation Was Sameness, Not Spending

It's easy to read Meta's and Uber's stories and conclude the fix is "spend less on AI." That's not it. Both companies are still spending more on AI this year than last. What's actually broken is the assumption that one model, the biggest, flashiest, flagship model, should be handling every task a company throws at it. There's simply now a more concerted effort to extract more value from less consumption.

That was always going to be a miscalculation. A model capable of complex, multi-step reasoning is the right tool for the handful of tasks that actually need that kind of reasoning. It's overkill, and expensive overkill, for the drafting, summarizing, and routine code generation that comprises most of what actually happens throughout a given day.

It's worth noting who benefits from the mindset that got Meta and Uber into this mess in the first place. Nvidia CEO Jensen Huang said he'd be "alarmed" if a $500,000 engineer wasn't burning through $250,000 worth of tokens. That's a strange thing to be alarmed about, unless your business is selling the chips those tokens run on. Huang isn't wrong that AI-assisted engineers should be productive, and it's reasonable to expect software engineers to be more experimental in pursuit of that productivity given the new tools at their disposal. But "no upper limit on token spend" is precisely the incentive of a company selling shovels during a gold rush, not necessarily good advice for the company holding the shovel.

What the Fix Actually Looks Like

The fix has to be twofold: assigning each task to the model built for it, and deciding whether piping a task through your LLM of choice is even the right move in the first place. Going forward, engineering orgs might be best suited directing employees to follow stringent model-flow procedures. Use a smaller, cheaper model for the routine work. Reserve the expensive, powerful model for problems that are actually hard enough to deserve it. And if there's some small tweak you could reasonably and quickly make yourself, just do it yourself.

Still from Moneyball of Billy Beane (played by Brad Pitt) leading a room of scouts, used to illustrate assigning the right resource to the right job instead of defaulting to the most expensive optionStill from Moneyball of Billy Beane (played by Brad Pitt) leading a room of scouts, used to illustrate assigning the right resource to the right job instead of defaulting to the most expensive option

The correction is happening right now, both inside companies that got burned and companies just figuring out how to make use of these widely available tools. This isn't a retreat from AI. It's the introduction of a plan that should have existed from day one: a system that looks at an incoming task and assigns it to the right model instead of simply the biggest one.

Routine, well-defined work goes to a fast, inexpensive model. Complex reasoning, architecture decisions, or anything genuinely hard goes to the model built to handle it. That's not austerity or a sign of poor business performance. It's the same discipline that's always separated scalable, sustainable companies from those that just know how to burn cash.

One thing worth being clear about: figuring out which model belongs on which task, and building the system that actually routes work that way, is a specialized job. Where it lives depends on the shape of the business. At an enterprise, it's the Head of Engineering's call to own. At a startup, it might be whoever's closest to the codebase, with the founder setting the spend ceiling. If you're working with an agency or a build partner, it's on them to have already solved this before your project starts, not something you should have to specify in a scope of work.

What doesn't change across any of those setups: you shouldn't have to become the one routing tasks between models any more than you should have to learn to write the production code yourself. That's exactly why our own build pipeline runs multiple models in tandem instead of pointing one expensive model at everything. A manager model plans the work, then different contributor models handle the pieces they're actually suited for, with expensive reasoning reserved for the steps that need it. It's the same lesson Meta, Uber, and Shopify already learned, just applied at the outset instead of after the invoice arrived.

If you're not sure whether your business is quietly tokenmaxxing, or you just want a system built the right way from the start, that's what we're here for.

Let's Talk.

Know someone who could use our help?

Refer a friend for 20% commission, for as long as they're a client.

Refer a Friend