From the AI ROI Series, recorded 14 July 2026. IBM lost about $55 billion in market value in a single session, the stock fell more than 20%, and it was the company’s worst day since 1987. Preliminary second-quarter revenue came in at $17.2 billion against a consensus near $17.86 billion.
The reason came straight from CEO Arvind Krishna. In the final weeks of June, clients redirected their capital expenditure toward servers, storage, and memory, racing to lock in supply-constrained infrastructure before prices climbed. In his words, IBM “did not anticipate the magnitude of the capex reprioritization.” And then, rather more bluntly, “this quarter we faltered.”
Almost everyone covered this as a company having a bad quarter, which it plainly was. Infrastructure fell 7%, large software deals that were supposed to close did not, and consulting was roughly flat. I look at it from my seat, which is spent inside enterprise AI budgets, and from there the interesting part is where the money went rather than which line it came out of.
The tell is what happened to everyone else
Accenture, Cognizant, ServiceNow, Adobe, and Workday all sold off on somebody else’s earnings, which is the market pricing a pattern rather than a company. Enterprise AI spending is still climbing, and the thing worth understanding is that it is now climbing at the expense of the budget lines next to it. Every dollar going into compute, memory, and tokens is a dollar that did not go into software licenses, consulting engagements, and the rest of what an enterprise buys.
Which means every line item in your budget now has to justify itself against the AI line item, and that includes the AI line item itself. When AI is the thing crowding out everything else, AI had better be able to show what it returned. So let us look at where that money actually goes, because I promised those numbers and, honestly, they surprised me.
Where the token money actually goes
| What | Share | Why it matters |
|---|---|---|
| Input tokens, reading your codebase | ~90% of token usage | You pay mostly to read, not to write |
| Input tokens as a share of cost | ~70% | The cost lives on the input side |
| Output tokens, once caching is counted | 0.6% of usage | Writing the code is a rounding error |
| Cost without caching | ~10x higher | Caching is the biggest hidden lever in the bill |
That table upends how most people picture their coding bill. The money goes on having the model read your codebase and your documentation, over and over, on every turn. Output is very nearly a rounding error at 0.6% of usage once cache reads are counted, and Cursor’s own data says that without smart caching the cost would be roughly ten times higher. Caching sits somewhere between a tuning detail and the single largest variable in the invoice, and most organisations I talk to have never looked at it.
The correction I owe you
Here is a number that complicates something I have been saying for months, so let me be straight about it rather than quietly move on.
| Model | Cost per agent request | Cost per accepted line |
|---|---|---|
| Opus 4.7 | ~$1.57 | roughly equal to GPT-5.5 |
| GPT-5.5 | ~$0.81 | roughly equal to Opus |
| Composer 2.5 | ~$0.18 | cheapest per request |
Opus costs about twice as much per agent request as GPT-5.5, and on that number alone it looks like an easy cut. Measure cost per line of code that actually survives review, though, and the two land in roughly the same place, because more of the expensive model’s output gets accepted. So the simple version of the routing argument, which is to send everything to the cheaper model, turns out to be too simple. Routing is still right, and it is still the highest-leverage lever available, but the unit you route on has to be cost per accepted output. Optimise the wrong unit and you will cut the bill while quietly destroying the value underneath it, which is the same trap as measuring acceptance rate on its own.
The governance number in the same dataset
One more figure, and it is the one that should make a CTO put down their coffee. In the span of a single month, the share of developers letting AI agents commit code with no manual review went from about 10% to around 40%. Four in ten developers are no longer personally checking the output. So you are paying for tokens, on input you are not measuring, producing code that increasingly nobody reads, inside a stack where you cannot see what any of it returned. The cost problem and the governance problem are arriving in the same quarter, which is inconvenient, because most organisations have separate teams and separate timelines for the two.
What the AI natives are doing about it
Perplexity is quietly building its own internal coding tool, codenamed Teammate, to run software projects end to end. Two things about that are worth your attention. The first is the economics: if you are an AI company paying a model vendor for tokens, you are funding a competitor, so you build. The second is that Teammate is deliberately model-agnostic. They are designing routing in from day one, because they understand that locking yourself to a single model is a cost trap and a capability trap at once. The companies closest to the tokens are the ones being most disciplined about them, and that is worth sitting up for.
Their CTO reportedly told engineers they should be able to “stop looking at code” by the end of the year. Put that next to the 40% who already are not, and the direction is not especially subtle.
The uncomfortable question for consulting
Now the part that will be uncomfortable for a lot of people reading this. If AI agents do work that used to be billable hours, what is an hour worth? IBM’s consulting line was flat while clients poured money into compute, and Accenture and Cognizant sold off on IBM’s numbers, so the advisory world is standing directly in the crossfire of the capex shift.
I do not think consulting is finished, and the change contains a genuine opportunity, because consultancies are exactly who enterprises turn to and ask to prove the AI is working. That is the highest-value question in the market right now, and it is not one you can answer by the hour: a quarterly slide deck is a photograph, and the meter runs every second. Proving AI value has to be instrumented, continuous, and measured at the token level, tied to what actually shipped, which is a product problem rather than an engagement problem. The firms that productise that measurement will win an enormous amount of work, and the ones attempting it manually will be compressed by the technology they are advising on.
What to check this quarter
This is directional, as always, and you should check my math against your own invoices rather than take mine. But three things follow, and they are checks rather than recommendations. Can you see what share of your coding spend is input rather than output, and do you know whether caching is switched on across every tool you pay for? Do you route on cost per accepted output, or on cost per request, which is the number your vendor console happens to show you? And can you say what proportion of AI-written code in your repositories was reviewed by a person, which is a question about your own engineering data rather than about any vendor’s dashboard.
Most organisations cannot answer the first, guess at the second, and have never asked the third. That gap is the reason a measured view of AI ROI stopped being a reporting exercise this year, and it is why the record of what your AI did, kept across every tool and every token, is the thing I would build before the next budget cycle rather than after it. The capex reckoning is already deciding which line items survive.
One question worth taking into your next budget review, and you can answer it from what you already have: if AI ate into your budget this year, what did it give back, and can you show it?
I’m Paul, co-founder of Olakai. Measuring what AI actually costs and what it actually returns, across every tool and every token, is the work I spend my days on. Your AI is an investment, so let’s measure it like one.