From cloud bills to token bills: we've seen this movie before

The same question can have a very different cost

Traditional software is relatively predictable.

A customer clicks a button. A database query runs. Some business logic executes. A result appears.

There are infrastructure costs underneath all of that, but at reasonable scale we have become pretty good at understanding them.

Now put a frontier AI model in the middle.

The user might ask a simple question requiring a small amount of context and a short answer.

Or they might provide hundreds of pages of information, trigger multiple tools, ask the model to reason through competing possibilities, search additional sources, analyse the results and produce a substantial response.

The button might look the same.

The economics underneath it aren't.

Reasoning makes this even more interesting. The better these systems become, the more work they can potentially do before they ever produce the answer we see.

You can restrict output. You can limit context. You can route tasks to smaller models. You can cache prompts and optimise token consumption.

All of those can be sensible engineering decisions.

But eventually I think you have to ask a more fundamental question.

Should a model be doing this task in the first place?

The obvious response is to use cheaper AI

There's an interesting pattern emerging.

Businesses want the capability of the frontier models because, unsurprisingly, the best models tend to be attractive for difficult work.

Then they start modelling what it will cost to run that capability across thousands of employees, customers or automated processes.

Suddenly model selection becomes an economics exercise.

OpenAI's API pricing illustrates just how wide that range can become. For standard contexts, the GPT-5.4 pricing is US$15 per million output tokens and GPT-5.4 Pro is US$180, checked 25 October 2026. Different models exist for good reason, and smaller models can be extremely capable for the right task, but there can be a substantial economic difference between asking a frontier model to think hard about something and asking a smaller model to perform a constrained task.

So businesses start routing.

Use the expensive model for this. Use the smaller model for that. Reduce the context here. Cache this. Cap that. Don't let the agent run for too long.

Again, that's not necessarily a problem. That's good architecture if the underlying use case justifies it.

What interests me is what happened before that conversation.

We decided an AI model should be sitting in the process at all.

Sometimes AI should build the automation, not be the automation

This is the bit I think gets missed in the rush to become "AI-first".

Imagine a business process with ten steps.

Maybe three of those steps genuinely require judgement. They involve unstructured information, ambiguity, language or circumstances where a model adds enormous value.

The other seven might simply be rules.

If X happens, do Y.

Look up this value.

Move this information from here to there.

Check whether these fields match.

Calculate this.

Send this notification.

Update this record.

We could put an AI agent in charge of the entire process and have it reason its way through those ten steps every single time.

Or AI could help us understand the workflow, design the system, write the code, build the integrations, create the rules and test the result.

Then conventional software can perform the seven deterministic steps.

Every time.

The same way.

Without paying a model to reconsider a decision we've already made.

And the AI can remain exactly where it earns its place.

That's still an AI-enabled solution. In fact, it may be a better one.

The browser creates a completely different economic question

This became particularly obvious to me when I started experimenting with my own workflows.

I looked at tools such as n8n, connecting different large language models through APIs, what it might cost to host models, how token consumption worked and what happened as reasoning increased.

Then I'd open ChatGPT or Claude in a browser and have access to extraordinary model capability for a relatively predictable subscription.

Those are very different commercial models.

OpenAI lists a ChatGPT Business seat at US$20 per user per month, billed annually with a minimum of two users, checked 25 October 2026. API consumption is a separate commercial model.

That doesn't mean the subscription is literally unlimited compute or that API pricing is somehow unfair. There are usage limits, guardrails and very different economics behind the products.

But from the customer's perspective, the distinction matters enormously.

A person can sit inside one of these products and use extremely capable AI to research, analyse, write, code, reason and increasingly interact with other systems.

If I build my own application around an API, I'm taking responsibility for the economics of every model interaction my users generate.

Those are not the same proposition.

Yet I'm not convinced most businesses really understand the difference.

What happens if ChatGPT becomes the operating environment?

This is where I think things get particularly interesting.

The AI products we use in the browser aren't standing still.

They're increasingly connecting to email, documents, calendars, code repositories, databases and business applications. They can search information, work across files and use tools provided by other systems.

That changes the architectural question.

Instead of putting an AI model inside every piece of software, perhaps sometimes we should bring the software and its data to the AI environment the person already uses.

That's one of the ideas behind something I built called Performance Signal.

I wanted ChatGPT to analyse my running properly. Initially that meant taking a ridiculous number of screenshots from Garmin after a run and uploading them into a conversation.

The AI capability wasn't the problem.

Getting trusted running data in front of it was.

The obvious product approach would have been to build another application, create another chat interface and pay for model inference behind it.

Instead, I built the connection.

Performance Signal makes the structured running data and the appropriate tools available to ChatGPT. ChatGPT remains the interface and provides the intelligence.

I'm not paying to recreate a conversation product that already exists.

That architecture won't make sense for every product.

But I think we're going to see a lot more businesses needing to ask whether they actually need to own the intelligence layer at all.

Expensive AI can still be incredibly cheap

None of this is an argument against using frontier models through APIs.

Sometimes the economics are exceptional.

Imagine a model consumes $20 worth of inference to help complete a piece of professional work that would otherwise require $500 of someone's time.

I don't particularly care that the AI was expensive.

It was incredibly cheap.

Now imagine another AI feature costs 40 cents every time a customer uses it. Customers don't pay anything additional for the feature, it doesn't materially improve retention or revenue, and your most active customers use it a hundred times every month.

Forty cents suddenly matters.

The important number isn't the cost of the tokens.

It's the value produced by consuming them.

That's where I think some of the AI conversation has become backwards.

Businesses are asking how to reduce the cost of their AI before they've properly established the economics of what the AI is doing.

And companies are already discovering this

This isn't theoretical anymore.

The 2026 State of FinOps report found that 98% of surveyed FinOps practitioners now manage AI spend, up from 31% two years earlier. It identified AI cost management as the number one skillset teams need to develop and highlighted visibility, allocation and determining AI value and ROI as major challenges.

That's an extraordinary shift in two years.

Uber provides an interesting example of the broader issue. Fortune’s May reporting described the company grappling with how to demonstrate sufficient business impact from significant AI expenditure, even as AI tools spread throughout engineering and other parts of the organisation. Axios’s August update describes stable spending alongside growing AI usage, which makes the example more nuanced than simply saying "AI cost too much". The real challenge is connecting growing consumption to measurable value.

That sounds remarkably similar to the early years of cloud.

The technology is useful.

Consumption grows.

The bill grows.

Then somebody asks what we're actually getting for the money.

Augmentation changes the equation again

There's another reason I don't think every AI opportunity needs to end in full automation.

I still think one of AI's greatest strengths is augmenting a capable human.

Give an accountant better access to information and the ability to analyse it.

Give a lawyer the ability to interrogate thousands of pages while remaining responsible for the conclusion.

Give an engineer a coding agent that allows them to explore and build much faster.

Give someone who understands a business process the ability to create tools that previously required an entire development project.

The objective doesn't always need to be removing the person.

Sometimes putting frontier intelligence in the hands of the person who already understands the problem produces the better outcome.

It can also produce a completely different economic model.

Instead of thousands of autonomous model calls running behind the scenes, perhaps you're giving 100 knowledgeable people extraordinarily capable tools and letting them decide when that intelligence is valuable.

That's harder to put into an automation diagram.

It might also be where some of the biggest gains are hiding.

AI-first shouldn't mean AI everywhere

I don't think the lesson from any of this is to avoid AI APIs.

They're going to underpin extraordinary products.

Nor is it that smaller models are somehow inferior because they cost less. Choosing the right model for the right task is exactly what good engineering should look like.

The lesson is that we should probably stop treating "AI-first" as shorthand for putting an LLM into every step of a workflow.

Use deterministic software when the answer should always be deterministic.

Use smaller models when the task genuinely suits them.

Use frontier models when the value of better reasoning justifies the cost.

Use APIs when automation, scale and integration make the economics work.

And don't ignore the increasingly capable AI environment your people may already be sitting inside.

We've spent the last decade learning that the ease with which technology can be consumed doesn't remove the need to understand its economics.

AI hasn't changed that.

It's just introduced a new unit of consumption.

Before asking which model should perform a task, there's probably a more important question to answer first.

Should a model be performing that task at all?