Cheap AI tokens are running out

Estimated reading time: 8 minutes

Key takeaways:

• Your per-seat AI plan is a subsidy that may end. Per-token rates cost roughly ten times more.
• Make token usage visible before a bill forces the conversation and never rank engineers by tokens.
• Match the model and effort level to the task. Teams that do will adapt faster to metered pricing.

---

Cheap AI tokens won’t last forever, so track consumption and match models to tasks before your first metered bill arrives.

We are emerging victorious from the phase of cajoling everyone to use AI and entering the phase of realizing there’s serious work to do to keep costs under control.

Now that our engineers are seeing just how much faster they can build, and also what is expected of them in this new world, we and our organizations need to be able to stump up the cash to keep the tokens coming.

A learning from my network is that, as companies implement various guardrails and limits to stop spend going bananas, many engineers secretly get frustrated and go back to using their personal plans, which have generous usage limits.

Typically, their (large) employer is paying per token on an enterprise plan, whereas the personal plan is a flat rate that the lab subsidizes, so on it they don’t have to worry about token costs. It’s understandable, but it means company code and data go through accounts the company doesn’t control, and the real demand never shows up where anyone can plan for it.

Fortunately, for us at Nordhealth, we’re still small enough to be on a Claude Team plan, which with each Premium seat gives us more than enough tokens per engineer. So AI (at the moment, at least) is a predictable expense in my budget.

However, we know that if we were on a metered enterprise plan like many of you reading this, the same usage would cost roughly ten times as much at today’s prices. Back in May, Simon Willison worked out that one month of his Claude Code and Codex usage would have cost $2,180 at per-token rates, against the $200 he actually paid in subscriptions.

In the last year, the frontier labs have been actively moving their bigger customers across to plans where you pay per token. Anthropic switched its Enterprise plan to a $20 seat fee plus metered usage in November 2025, and OpenAI moved Codex on ChatGPT Enterprise to token pricing in April 2026.

For those of us still on a heavily subsidized per-seat plan, the hope is that we don’t grow too much (typically enterprise billing starts after a certain number of seats are needed) and that the frontier labs don’t stop offering these plans altogether. It’s a big item on my worry list for next year.

Token prices keep falling, and Ramp’s AI Index has the effective price per million tokens down 41% since March. However, with both Anthropic and OpenAI reportedly preparing to go public, I worry that the age of cheap, easy-to-administer frontier AI may soon be behind us.

Many larger companies are already beyond this point, and Gergely Orosz’s write up shows how companies like Stripe and Uber have managed it.

For those like us still getting a great deal, it’s time to start preparing for what we do if we have to change.

Create a culture of understanding consumption

Firstly, you need to create a habit of having your engineers understand their consumption. It should be expected that all engineers:

• Understand how to view their consumption (in Claude Code, that’s /usage), and what the limits are.
• Are aware of the different models available to them and which suits which kind of task (more on that below).
• Are able to find examples of best practice on the above, tailored for your company’s codebase and workflows.
• Exercise creativity in getting the most out of each token by improving their skills on how to work with AI effectively.

Creating and steering the discussion in a specific Slack channel can get most of this done, and you can encourage those who are best at this to post frequently.

It helps to give managers detail on token consumption across their teams. Pulling usage data from the admin dashboard can let you do two things:

1. Compute the broad trends for your whole department (e.g. highest, lowest, median token usage, and if and when limits are being hit).
2. Give managers the usage for their team, so they can see where their staff land in the broad trends.

One thing to avoid is ranking people by tokens, because you get tokenmaxxing, usage chased for its own sake, which is the opposite of what you want.

I also experimented with analyzing codebase contributions alongside token consumption. This comes with the now-obvious caveats about measuring engineering output, but it can open interesting conversations with folks who could improve their token efficiency, or who could use AI more.

I’ve found that engineers respond well to anonymized usage data for the whole department, which shows them where they fit, with names only visible to their managers. If you wait until there’s a bill, the first time anyone looks at these numbers is in a conversation about cost, and it feels like an audit. Doing it now makes it normal.

Use the right model for the job

Once you’ve established that culture, the next step is helping everyone understand how to use the right model, and effort, for the job. Last year, I wrote in How do I get everyone to use AI? that every engineer should have a generous budget and optimize within it to get the most out of it that they can.

An important assumption to break is that whenever a new, best-in-class frontier model is released, it’s the only one worth using. Your application, programming language, and codebase likely haven’t become exponentially more complex in the last six months, so Opus 5, or an older, smaller model, is probably good enough for most tasks without needing Opus 5.5.

A good rule of thumb is that the most expensive frontier models should be used for large exploratory tasks which generate plans that smaller models can implement, or turned to when the smaller models can’t solve that particularly tricky bug.

Less obviously, model choice always has two dimensions: the size of the model and how much reasoning effort you give it. On Artificial Analysis’s October 2026 figures, GPT-6 Luna at max effort scores 38 on their Intelligence Index for about $0.07 a task, while Claude Opus 5.5 at low effort scores 42 for $0.55. That’s roughly 690% more expensive. It’s worth sharing benchmark websites like this with your organization, as the impact of effort on cost is not obvious.

The same is true within a single lab’s models: Opus 5.5 at low effort and Sonnet 5.5 at medium land within a point of each other at almost the same cost per task. Smaller models don’t necessarily mean cheaper, nor do bigger models necessarily mean more expensive.

Uber defaulted its reasoning effort to medium because for many tasks it “hits a good balance between cost vs quality.” Your mileage may vary here, and it’s worth asking your team to run experiments with effort levels to find the sweet spot for you and your codebase.

Understanding these levers also makes it easier to accept that generous per-seat plans may not be around forever and to get into the habit now of navigating these tradeoffs, which will matter even more if the company ever has to pay for every token.

That doesn’t mean using less AI; it just means using the right model for the job.

When cheap AI tokens go away

If our company grows much larger, or if the frontier labs decide that everyone will pay per token in the future, we, like many other companies, will need to get creative. If we want to continue consuming the same number of tokens, we can’t easily afford to pay 10x for them.

We may have to switch to routers such as OpenRouter or Ramp’s Router. Open-weight models have also become genuinely capable over the last six months, often for a fraction of the cost.

The work then is choosing the right models for particular tasks and deciding whether to build the routing logic ourselves. AT&T, as covered in Orosz’s article, kept frontier models for the most complex code problems and moved lighter work to open models through a router, which cut the cost of some advanced tasks, including coding, by up to 56% for only a 2% drop in measured quality. That figure also assumes you have an internal measure of quality to benchmark against, which is more engineering work you’ll have to do yourself.

Let’s not forget the harness. Claude Code, Codex, and others wrap their models in an agent loop, tools, context management, caching, and prompts tuned to that model. Once you step out into the router world, much of that becomes your problem. Earlier this year, Can Bölük showed the impact of spending time improving agent harnesses, which is yet another thing you may have to think about.

Once every token is billed, you’ll also need to stop spend spiraling out of control. Many of us had nasty billing surprises from AWS a decade ago, and Simon Willison has recently argued that because agents make it so easy to spin up things that cost money, pay-per-use services need hard spend caps by default, e.g. ones that cut usage off immediately rather than just sending a warning now and a bill later.

This is where the habits pay off: a team that already picks models deliberately and knows its consumption can much more easily move to a router-based world, as they’ll have the culture and skills needed to be more judicious with token usage.

Building the habits regardless

Although your engineers may only need to think about whether they’re hitting their session limit, there’s a lot you can help your team do ahead of time to better experiment with, understand, and optimize their usage. If you’re already metered, these habits are great to get more out of your money.

None of us knows whether we’ll be paying per token tomorrow, next year, or next decade. However, getting consumption out into the open, helping your engineers understand cost benchmarks for model size and effort, and building a culture of getting the most out of your allowances will set you up well for whatever comes down the line.

If the machine does start asking for coins, your team will already know what it’s spending and why.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.