Nobody agrees how big the AI funding gap is
Estimates of 2026 hyperscaler infrastructure spending run from $660bn to $800bn. Whether that is reckless depends entirely on which revenue you count, and serious analysts do not agree.
The capital expenditure numbers are not in dispute. Estimates for combined 2026 hyperscaler capex run from around $660–690bn to $775–800bn, depending on who is counting and what they include. That is roughly double 2025, and it works out at something close to $2bn a day.
What is in dispute — far more than the coverage suggests — is whether that spending is dangerously ahead of revenue.
The same question, two very different answers
One widely repeated framing puts the annual gap between AI infrastructure spending and AI ecosystem revenue at around $600bn, and describes it as widening.
A different analysis of the same buildout runs the numbers as a return-on-investment bridge and reaches a much calmer conclusion: to justify the capex at a 10% return threshold, the Big Five need roughly $68bn of AI-attributable annual revenue by end-2028; at 15%, about $101bn. Against annualised AI cloud revenue already around $150bn in Q1 2026, that analysis concludes the required revenue is achievable, with a credible gap appearing only at more demanding return thresholds.
Those are not small differences of emphasis. One says the industry is spending roughly $600bn a year more than it earns. The other says the revenue required is already arriving.
Both are produced by people who do this professionally.
Why the numbers diverge
The gap is not arithmetic, it is definitional, and three choices do most of the work.
What counts as AI revenue. Only direct model API sales? Cloud revenue attributable to AI workloads? Advertising improvements driven by AI ranking? Subscription products with AI features? Each broader definition moves the number by hundreds of billions.
What counts as AI capex. Data centres serve AI and everything else. One analysis attributes about 75% of total capex to AI; another might take a very different share. Servers also have multi-year useful lives, so comparing a single year's capital spending to a single year's revenue compares a stock to a flow.
What return you demand and by when. Requiring 25% by 2028 produces a gap. Requiring 10% by 2028 does not.
None of this means one side is dishonest. It means "the AI funding gap" is not a measured quantity in the way the phrase implies, and a specific dollar figure quoted without its definition is close to meaningless.
What to do with an unresolved question
The temptation is to pick the analysis matching your prior. The more useful move is to notice what both sides agree on, because that is the part you can plan against.
Both agree the capital is enormous and front-loaded. Both agree returns are expected later than the spending. Both agree — and history supports it — that capital has led revenue in every infrastructure buildout from railways to fibre, and that the capacity generally outlives the companies that financed it.
What follows is a planning assumption rather than a market call: the capability persists, the price is uncertain in both directions.
Prices could keep falling, if the buildout completes and competition holds. They could rise, if returns disappoint and providers reprice toward profitability — and the grid constraints on data centre capacity push that way independently.
Building against that uncertainty
Keep model choice a configuration value. If switching providers is a config change, repricing is an inconvenience. If your prompts, tool schemas and parsing are welded to one vendor's API shape, it is an unplanned project.
Know your cost per user action. Not the monthly bill — the cost of one person doing one thing. That is the number that tells you which features survive a price rise. Most teams cannot state it.
Notice when your margin depends on someone else's investment thesis. If a product only works commercially at current inference prices, that is a real dependency. It may well be fine. It should be a conscious position rather than an assumption.
Do not treat cheap tokens as a moat. Whatever you can build because inference is cheap, so can everyone else, for the same reason.
The honest position
I do not know whether this is a bubble, and I would be sceptical of anyone in software who claims to.
What I am fairly confident about is that a number as contested as this one should not be load-bearing in anybody's strategy. The useful response is not to pick a side but to keep your options cheap — which is good practice regardless of how the financing resolves, and costs almost nothing if it resolves well.
Building something like this?
We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.