Three stories, one finding
On 27 July 2026 the Wall Street Journal reported that Nvidia is negotiating a guarantee of roughly 250 billion US dollars. It would allow OpenAI to lease compute from a 10-gigawatt campus in southern Ohio, being built by a SoftBank energy subsidiary on the site of a decommissioned uranium enrichment plant. Separately, Nvidia is apparently discussing financing the chips that would go into that facility – a volume of up to 350 billion. The full campus is estimated at more than 500 billion. Reuters has not confirmed the report. The criticism came immediately anyway: investor Michael Burry commented publicly that a chip vendor was guaranteeing a customer's spending on that same vendor's chips.
The same weekend, a second story ran much more quietly. Microsoft is rationing capacity in Azure. Demand exceeds supply so clearly that incoming compute is actively allocated – between customer workloads, first-party services, research workloads and replacement hardware. Individual regions are considered full, customers report refused capacity requests and migration projects stalled halfway. Microsoft has not even made a secret of the priority logic: when capacity is tight, its own AI products come first – the Copilots in Microsoft 365, in GitHub and in security. The situation is expected to persist until at least the end of 2026.
And third, on 27 July Moonshot AI released the weights of Kimi K3: 2.8 trillion parameters, around 1.4 terabytes of download, by a wide margin the largest openly released language model ever. In the Frontend Code Arena it currently holds first place ahead of Western frontier models. These three stories are filed in three different sections – finance, IT operations, model comparison. Read together, they produce a single finding: the bottleneck in the AI economy is no longer how clever a model can be. The bottleneck is compute. And compute is currently not being distributed by price, but by rank.
What Microsoft says openly – and what follows from it
The most interesting sentence of the past few days did not come from the billion-dollar story but from the capacity debate. When compute is scarce, Microsoft prioritises its own Copilot products over customer workloads. That is not an accusation from critics, it is stated allocation logic. And it describes a constellation that would normally be flagged instantly in a procurement process, yet is almost never raised in the cloud: the provider you buy compute from sells a product on the same hardware that competes with yours – and it decides who gets served first.
Translated to a mid-sized AI project, that means: if your quoting assistant runs on a hosted frontier model and the same infrastructure simultaneously serves the provider's own Copilot, you are standing in a queue in which you are not at the front. Not out of malice, but because every rationing needs an order. And that order reasonably follows the strategic value to the provider, not the value to you.
Quota is not capacity
In practice this becomes visible through a distinction that almost never appears in project plans. A quota is an upper limit your provider grants you administratively. Capacity is the physical question of whether hardware is actually free at the moment of the request. The two are used interchangeably in everyday speech but are independent of each other. If a region is saturated, raising the quota does not help – the request fails anyway, and the error does not say a limit was reached, it says the requested resource class is currently unavailable in that region. Anyone who reflexively requests a higher quota in response to a capacity problem is addressing the wrong cause.
Availability is not covered by any standard SLA
The second point is the more uncomfortable one. The usual availability commitments from hyperscalers refer to running resources: an already started instance, an already booked service should be reachable a given percentage of the time. They say nothing about whether you will get a new resource at all. A refused allocation is technically not an outage – nothing was ever running that could fail. So it creates no claim, no credit, no escalation path. A provider can fully honour its availability commitment and at the same time tell you it has nothing to give you right now.
If you genuinely want guaranteed capacity, you have to reserve and pay for it separately – in Azure, for example, through capacity reservations that secure allocation in advance, whether or not you are currently using it. That is a legitimate option, but it costs money, and it is the opposite of the elastic billing model usually used to justify cloud adoption. The honest sentence is: elasticity upwards was always a promise resting on the quiet assumption that enough is there. That assumption does not currently hold.
Why the price you are planning on is not a market price
Back to the Nvidia story – not as a stock-market topic but as a price signal. When a chip vendor guarantees the lease obligation of its largest buyer and simultaneously finances that buyer's chip purchases, demand for those chips is no longer purely an expression of what customers are willing to pay. Part of it is carried by the supplier itself. Whether you consider that a smart investment or circular financing is a question for analysts. For a company planning a budget for the next two years, the relevant conclusion is a different one: the numbers from which price trends are derived are currently not being produced in a normal market.
This matches a finding we worked through against list prices in an earlier analysis of the Kimi K3 effect: per performance class, prices have not fallen since early 2025, they have risen slightly. What reliably gets cheaper is yesterday's quality; the current frontier model costs roughly what the previous frontier model cost. Anyone basing an AI budget on the expectation that inference will get cheaper by itself is planning on a number that currently carries a great many asterisks.
The real difference between open and proprietary: the number of queues
This is where the third story comes in, and differently from the obvious reading. The obvious reading is: open weights mean independence, because you can run the model yourself. We worked that reading through concretely in an earlier article and rejected it. Running a model with 2.8 trillion parameters yourself requires a double-digit number of high-end accelerators even with aggressive quantisation; the realistic order of magnitude is a mid five-figure to low six-figure sum per month for compute alone. For a company with twenty to fifty employees, that is not an option but a calculation you do once and then put away.
For mid-sized companies the value of open weights lies elsewhere, and it is rarely named. It lies in the fact that several independent providers can host the same model. A proprietary model has exactly one operator, so exactly one queue, one price list, one priority logic and one moment at which it can be deprecated. An open model with serious performance can sit with several providers, including European ones with data residency in the EU. So the practical difference is not control over the model – you have that in neither case. The difference is the number of doors you can walk through when one of them is closed.
And that is the news 27 July holds for companies. Not that a Chinese model leads a benchmark – rankings change monthly. But that for the first time there is a freely available model at a performance level where switching does not mean a noticeable loss of quality. Six months ago, provider independence in AI was a statement of intent. As of this week it is an option with documented numbers behind it – provided your own system can actually make use of it.
What this means in practice
The decisive sentence is: the ability to switch is an architectural property, not a contract clause. If you only procure it once allocation dries up, you procure it too late – changing model provider in a system that has grown organically is not a configuration change, it is a project. Three levels need to be distinguished.
Contractual
- Establish which customer class you are in with your provider. Framework agreements with committed spend and pure pay-as-you-go accounts are demonstrably treated differently during allocation crunches.
- Check what your availability commitment actually covers – distinguishing cleanly between operating existing resources and allocating new ones. The second case is generally not covered.
- For genuinely business-critical workloads, ask whether a paid capacity reservation is cheaper than the risk of a standstill. That is a calculation, not a matter of belief – but it has to be done before the shortage.
- For every AI provider, read the notice period for model deprecation. Model deprecations are the most common forced switch, and the notice periods are often shorter than your own migration effort.
Architectural
- Encapsulate provider-specific calls behind your own thin layer instead of scattering a provider SDK across the application. Little work at the start, a great deal of work in hindsight.
- Build your own evaluation set from real cases in your own operation – thirty to fifty is enough to begin with. Without that set, the question of whether an alternative model is good enough cannot be answered in hours, only in weeks.
- Treat prompts and model assignment as configuration, not code. A switch should be a change in one place, not in thirty.
- Have at least one secondary provider tested under production-like conditions before you need it. An emergency plan never executed is not an emergency plan.
Operational
- Sort your use cases by whether they are interactive or deferrable. A chat assistant in a customer conversation tolerates no delay; an overnight document analysis does. Deferrable workloads are the cheapest reserve during a shortage, because they can be moved in time or region.
- Know which use case genuinely needs a frontier model. A large share of what runs on frontier models in companies runs there out of habit – and those are exactly the workloads you can move first during a shortage.
- Name the emergency before it happens: what concretely happens if your main provider allocates no additional capacity for two weeks? If nobody can answer that, that is the result of the exercise.
What explicitly does not follow
This analysis is not an argument against large cloud providers, and certainly not a recommendation to buy hardware now. Running your own accelerators is, for the vast majority of companies, the most expensive conceivable answer to a problem that will probably never hit them at full force. It is also not an argument for switching to an open model on principle – the data protection questions with a Chinese provider remain and are covered in detail elsewhere. And the Nvidia story is so far unconfirmed; it works as a signal, not as a fact.
What does follow is something more sober: the quiet assumption that compute is available in any quantity at any time was right enough for fifteen years that nobody checked it. In the AI layer it currently does not hold. Anyone planning an AI project should from now on treat capacity like any other supply chain – with the question of who gets served ahead of you in an emergency, and with at least one second source you have already used.
Conclusion
The three stories of this week say the same thing. The guarantee says: capacity is so scarce and so expensive that it has to be pre-financed. The rationing says: it is distributed by rank, and the provider is standing in the queue itself. The open weights say: for the first time there is a viable alternative to exactly one queue. For a mid-sized company the consequence is neither panic nor a change of provider, but a capability: being able to switch without it becoming a project.
That capability costs a few days up front – an abstraction layer, your own evaluation set, an honest sorting of use cases. Retrofitted, it costs a multiple of that, and precisely at the moment when you need it and have no time. That is the whole recommendation, and it is unspectacular: the question is not which model is currently the best. The question is how long it would take you to use a different one.