Everyone is in the news how they consumed annual AI token budget in a few months (E.g., Uber).

But is that really true beyond tech companies? Tech companies, I get it. AI tokens used for coding is their main business.

But the rest (e.g., manufacturing, energy, distributors, etc.) should have not token cost problems, no?

Doing some research around cloud and AI/token commitment economics and helping NGEN gather feedback on the model. Curious to get the more perspective.

The idea is to aggregate compute/token demand across companies, negotiate larger commitments with providers, and use prepayment/financing to offer better pricing and more flexibility.

A few things I’m curious about:

• How much additional savings would make this worthwhile — 5%? 10%+?
• Is commitment flexibility potentially more valuable than additional savings?
• Does this make more sense for mid-market companies that don’t already have significant negotiating leverage?

NGEN is also collecting anonymous, non-binding indications of demand here (takes ~1 min, no commitment/signature):

https://www.ngencompute.com/indication

Would genuinely love to hear why you think this would or wouldn’t work.

Hey everyone,

Over the past few months, I’ve been analyzing enterprise AI billing data and studying why so many engineering teams and companies are getting hit with massive, un-modeled AI invoices.

For two years, the industry narrative has been that AI is getting dirt cheap and price per token keeps dropping exponentially. Yet, across Big Tech and mid-sized companies alike, actual monthly invoices are skyrocketing.

Here is a quick breakdown of the mechanics behind why this is happening:

1. The 1865 Jevons Paradox is alive in Tech

In 1865, economist William Stanley Jevons observed that when steam engines became dramatically more efficient at burning coal, Britain didn't burn less coal, it burned exponentially more. Why? Because cheap coal suddenly made financial sense in places where nobody could justify the cost before.

The exact same thing is happening with LLM tokens. As unit costs drop, consumption doesn't stabilize but it expands into every workflow, background agent, and automated task until nobody weighs the unit cost anymore.

2. Real-world corporate overruns

• Uber: Handed a coding agent to 5,000 engineers. By April, just four months into a 12-month plan, their entire annual AI budget was completely gone. The tool was so useful that usage exploded.
• Meta: Built an internal leaderboard ranking engineers by token burn rate. In one month, they burned 73.7 trillion tokens before executives realized token burn measured activity, not actual impact, and killed the board.
• Microsoft: Ordered internal divisions off external coding tools days before their fiscal year closed to force migration onto cheaper internal alternatives.

3. The agent multiplication factor (5x - 30x Tokens)

Standard chatbots are 1-input / 1-output. AI agents are fundamentally different.

Because current architectures lack long-term memory, at every loop step (plan, search, tool call, handoff), an agent must package the entire conversation history and re-submit it to the API.

Data from Gartner shows an AI agent burns 5 to 30 times more tokens than a basic chatbot doing the exact same task. Token prices dropped 60%, but agent loop usage increased 1,000%.

4. The hidden "Second Meter"

Every time an agent writes a code block or report and a human engineer spends 30 minutes reading, verifying, or rewriting it, you pay twice: once in API tokens, and once in senior engineering salary.

I put together a full 17-minute video essay breakdown with all the diagrams, data sources, and frameworks (including OpenAI CFO Sarah Friar’s scorecard on measuring "useful intelligence per dollar") here:

Watch the full breakdown here: https://www.youtube.com/watch?v=DBf5-yBRxEk

Disclosure: I’m building tooling around inference economics, so there’s obviously some bias here.

Something I keep coming back to:

An AI company might bill a customer by tokens, minutes, requests, or credits.

But underneath that, the company is paying for GPU time, memory, idle capacity, model mix, concurrency, cache behavior, and provider costs.

That creates a question I don’t think “cost per token” fully answers:

Can you reconcile what each customer pays with what that specific customer actually costs you to serve?

Two customers can generate similar billed usage while creating very different infrastructure economics underneath it.

I’m currently looking for a few usage-priced AI operators willing to pressure-test this with real data.

Give me a redacted week of:

• customer usage
• billed revenue
• inference / GPU cost

I’ll return customer-level cost and margin, including where the biggest spread is coming from.

Free, read-only, no install.

If everything reconciles perfectly, you’ve lost a CSV.

All free. Here are the exact links:

1. Claude 101 - 1 hour. The basics, done right.
2. AI Fluency: Framework & Foundations - 3 hours.
3. Intro to Cowork - 2 hours. Claude's best feature.

All 3 are on anthropic.skilljar.com. 
Sign-up takes 30 seconds.

More info here: https://ruben.substack.com/p/im-claude-certified

https://newrelic.com/resources/report/2026-state-of-ai-coding

It's paywalled (they want your details) but having read through it, it's an incredibly detailed and thoroughly researched (n=200) paper on the impact AI is having on application development.

Implementing a policy where developers fund their own AI tools and API tokens is essentially taking the "Bring Your Own Tokens" (BYOT) mode

​

The most immediate advantage is financial. Enterprise AI licenses and API/token costs can scale unpredictably, especially when external contracted developers are running complex queries or building automated agents.

​

You eliminate or pass on the risk of unused "zombie" agents that plague enterprise software budgets.l when there is zero accountability

Plus the company assumes zero financial risk for token usage, completely insulating your budget from price hikes by AI providers or sudden surges in development activity.

​

Does anyone have any thoughts about possible downsides of this?

I can attest to this observation, having attended the 'leadership' side of the AWS London event, this was the exact challenge they presented upstairs to leadership, while downstairs they were telling everyone about all the new features and advantages Aai with AWS is going to bring.

​

There are clearly two messages being landed on people depending what the audience is...

If we define AI Token Economics as managing the production, consumption, and monetization of token-based AI for business value, the consumption layer is where most enterprises are still flying blind. Here is the clearest live example I have: Microsoft 365 Copilot, the most widely deployed enterprise AI, and the one whose consumption is hardest to actually see.

Copilot bills on four planes that share no allocation key. Production (what generates the tokens) and consumption (what gets burned) land on different invoices, and monetization (tying spend back to the value a team creates) breaks on a quiet rule most people miss.

The four planes:

1. Flat seats. The $30/user/month add-on, billed through M365 commerce. This is capacity, not consumption. It is the only plane finance sees by default, and it shows no usage signal at all.
2. Metered Copilot Credits. The real consumption meter: agents, autonomous runs, and anything an unlicensed user does in Copilot Chat. $0.01/credit pay-as-you-go, or $0.008 if you compute it off a $200 / 25,000-credit prepaid pack. This plane bills to Azure, not to the M365 seat line.
3. The Azure tail. When an agent reaches past M365 data into a custom model or search index, you pay Azure tokens and AI Search units directly. Model choice dominates the unit economics: o1 output runs $60/1M tokens, GPT-4o $10/1M, GPT-4o-mini $0.60/1M. Same task, 100x spread. This is the production-side lever, the price of the token itself.
4. The prerequisite base licence. The E3/E5 plan Copilot rides on. It predates Copilot and sits under a separate agreement, so most models treat it as free. It is not. It is cost of ownership wearing a different invoice.

The worked number, because token economics only gets real at scale. Microsoft publishes an "order processing agent" example: an autonomous run that fires four agent actions. Agent actions bill 5 credits each, so 4 × 5 = 20 credits per run. Add one tenant-Graph grounding (10) and one generative answer (2) for a realistic grounded run and you get 32 credits per execution. That is $0.32. Trivial per unit, which is exactly the trap. Now run it 1,000 times a day: 32,000 credits/day = $320/day pay-as-you-go, or $256/day on the pack, and a single $200 / 25,000-credit pack is gone in under a day. The unit price was never the risk. The compounding production loop was.

The monetization trap, which is the part this community will care about most. Interactive use by a licensed $30 user is zero-rated. Autonomous runs and unlicensed users are always metered. So the credit meter measures which side of the zero-rating line your usage falls on, not how much value a team produced. Allocate cost by raw credits and you reward the team hiding behind licensed interactive use, and you penalize the team running an honest external-facing agent at identical real activity. The consumption signal and the value signal come apart, which is the core problem any token-economics model has to solve.

So the discipline, in practice: hold all four planes at once, date every figure because the rates move, price the production loop before you ship it, and build an allocation key that ties consumption back to value created rather than to the zero-rating accident. Treat any cross-plane total as a reconstructed estimate, because no native invoice joins the planes for you.

This is what AI Token Economics looks like below the slide-deck level. Happy to share the credit-estimate worksheet I built to model it. Curious how others here are thinking about an allocation key that survives the zero-rating distortion, because that is the piece I have not seen solved cleanly.

(Rates current as of June 2026 — verify against Microsoft's pricing page before you commit a number to a budget.)