Neoclouds as a Configuration Problem

What a neocloud is, how its economics work, why that creates a configuration and capacity-planning problem — and what we need validated.

Sanjay Mittal

Founder & CEO
Predictika.ai

Email: sanjay@predictika.com

How to read this

Our assessment is that this might be the strongest target we have examined but that it splits into three tiers, and the tier with the loudest revenue is the tier where our pitch is weakest.

Sections "What is a neocloud" and "How the economics work — and why they are brutal" are deliberately educational. Anyone who has not followed this market closely will not see the configuration problem until they understand how a neocloud makes and loses money, because the problem is created by the financing structure rather than by the technology. If you already know the sector, start at Section "Why this is a configuration problem".

What is a neocloud

A neocloud is a cloud provider built around one thing: renting GPU compute for AI training and inference. No databases, no servers, no hundreds of managed services. The catalog is small and centered on raw compute, bare-metal or thin virtualization, and fast networking. The category emerged after late 2022, when demand for AI compute outran what the hyperscalers could allocate.

Verified figures, with the caveat that analysts differ: the ecosystem now numbers roughly 190 to 200-plus distinct operators worldwide. Revenue was above $25 billion in 2025 by one estimate; another puts 2026 at around $20 billion rising toward $180 billion by 2030, and Synergy Research forecasts the segment approaching $400 billion by 2031. JLL puts the five-year revenue CAGR at 82%. Pricing typically runs 60 to 85 percent below hyperscaler list rates for equivalent silicon.

The customer base is no longer only startups. Verified: Microsoft has committed over $60 billion across neocloud partnerships, including roughly $23 billion to Nscale; Meta signed $14.2 billion with CoreWeave and $3 billion with Nebius; Anthropic announced a $50 billion partnership with Fluidstack. The hyperscalers themselves are now customers, because building their own capacity takes years and several neoclouds already hold sites with secured power.

How the economics work — and why they are brutal

This section is the one that matters. Everything in Sections "Why this is a configuration problem" onward follows from it.

1. The core instrument: take-or-pay
   Verified: the central contract is a multi-year take-or-pay agreement. A customer commits to a fixed quantity of GPU capacity at a fixed rate for two to five years and pays whether they use it or not. The neocloud then borrows against that contracted cash flow to buy the GPUs. Contract structures resemble infrastructure assets more than technology services.

    

   

    

   Verified: private credit lenders underwrite three things — contracted backlog, utilization rate, and GPU residual value. Idle GPUs depreciate without generating income to cover loan payments. CoreWeave's reported backlog of roughly $66.8 billion is simultaneously future revenue and the foundation of its borrowing capacity.
2. The knife edge: about 70% utilization

    

   The single most important number in this market: a debt-financed GPU cluster breaks even at roughly 70% utilization. Below that, the cluster is losing money against its own loan. Verified reporting suggests clusters running at 55–65% utilization, which creates strong financial pressure to raise on-demand prices, enforce minimum commitments, and push customers toward long-term reserved contracts.

    

   Consider what that implies. A five-point error in projected utilization is the difference between a profitable cluster and one that cannot service its debt. There is no comparable sensitivity in most businesses. And utilization is not an operational metric that emerges at the end of the quarter — it is the cumulative consequence of every quote the sales team has issued.
3. Three demand tiers, sold against one physical asset

    

   

    

   Verified: not all capacity can be sold on long-term contracts, and monetizing the unused remainder is a standing operator challenge. So, the operator is continuously deciding how much of a given cluster to lock into cheap multi-year commitments versus hold back for higher-margin on-demand — a decision that must be made per cluster, per GPU generation, per region, and years in advance.
4. A race against depreciation
   GPUs lose value as new generations arrive. Verified pricing illustrates the erosion: H100s rent for roughly $2.85–3.50 per hour at the budget tier, down 64–75% from a 2023 peak above $8. Each new generation carries a scarcity premium that decays as supply catches up. The business has been described as racing depreciation to the bank — capacity that sits idle in year one is value that cannot be recovered later.
5. Supply is hard-constrained, and lead times have stretched
   Verified: the bottleneck has moved from chip fabrication to advanced packaging. TSMC's CoWoS capacity is reported fully allocated through mid-2027. Procurement decision cycles that once ran three to six months are now projected over eighteen to twenty-four months, and the primary decision criterion has shifted from best price at purchase to guaranteed availability over the contract duration.
6. And the deals themselves are stalling
   Verified, and worth understanding because it shapes the sale: colocation providers are reluctant to build without signed commitments; neoclouds are reluctant to commit without secured GPU supply and customer contracts; and GPU availability depends on hyperscaler allocation decisions. The result is a three-sided dependency loop that stalls otherwise viable deals for months. Deal sizes have grown — what were once large requirements of 4 to 10 MW are now entry points, 50 MW is increasingly common, and no single colocation provider in most markets can absorb 50 MW under one roof on a reasonable timeline.

Why this is a configuration problem

A neocloud must solve three problems that are normally owned by different teams and different tools. The coupling between them is not incidental — it is the business.

1. Build
   This is the AI data center configuration problem we have already modeled to component level: power envelope, redundancy, rack and row geometry, cooling architecture, network fabric, GPU and node selection, and the discrete capacities of PDUs, busway and CDUs. Neoclouds face it in a sharper form than colocation tenants because they also carry the time dimension — time-to-power decides who profits, and a site that energizes two quarters late is two quarters of contracted revenue at risk.
2. Allocate
   This layer barely exists in conventional configuration problems, and it is what makes neoclouds distinctive. Capacity is committed in time. A three-year take-or-pay signed today consumes specific GPUs in specific racks in a specific region until 2029. Layer several hundred such contracts across multiple sites and GPU generations, and the question “what is actually free in Region 2 in Q3 next year on Blackwell-class hardware” becomes genuinely hard — and it is the question every quote depends on.
3. Quote
   An enterprise asks for a specific cluster: a GPU count and generation, an interconnect topology, a storage tier and throughput, an SLA, a region, a start date and a term. Answering requires knowing whether it can be physically delivered, whether the capacity is uncommitted at that time, what it does to utilization on the affected clusters, and whether the resulting price clears the margin and covenant tests.

    

   The claim stated plainly: every quote a neocloud issues is simultaneously a physical feasibility question, a temporal allocation question, and a debt covenant question. We are not aware of any product that spans all three. Conventional CPQ does not model physical capacity; capacity planning tools do not price; and neither is connected to the covenant.

The constraint structure

1. Physical — from the build model
   
   • Provisioned power against usable power after redundancy; cooling capacity; PUE overhead
   • Rack U and row slot geometry; discrete PDU and busway ratings; weight and cord counts
   • Fabric: leaf and spine port counts, oversubscription ratio, cable reach, rail-optimized topologies for scale-up domains
   • Storage throughput per GPU for the workload class; parallel filesystem sizing
2. Temporal — the allocation layer
   
   • Capacity committed per cluster, per generation, per region, over a date range
   • Site energization dates and GPU delivery schedules, both uncertain
   • Contract start dates, terms, renewal and expiry, and the capacity they release
   • Depreciation schedules and generation refresh timing
3. Commercial and financial
   
   • Utilization against the break-even threshold, per financed cluster
   • Debt covenants tied to contracted backlog and utilization
   • Margin floors by tier, and the reserved-versus-on-demand mix decision
   • Take-or-pay exposure: what has been promised that may not be deliverable
4. Sovereignty and jurisdiction — a growing constraint family
   Verified: sovereign requirements are now a first-class constraint rather than a preference. The driver is the conflict between the US CLOUD Act and European rules including GDPR and the EU AI Act, and CLOUD Act exposure follows the jurisdiction in which the provider is incorporated rather than where the servers physically sit. Gartner has named “geopatriation” a top strategic technology trend for 2026, estimating that sovereign cloud spending will shift 20% of workloads from global to local providers, and that by 2030, 75% of European and Middle Eastern companies will have geopatriated workloads — against 5% in 2025.
   For a configuration model this adds constraints of exactly the kind we handle well: workload must run in jurisdiction X, on infrastructure owned by an entity incorporated in Y, with staff cleared to Z, on hardware procured under a specific national program. These are hard, checkable, and they interact with capacity allocation.

What goes wrong — the error modes we would claim to prevent

• Overselling capacity that cannot be delivered. A take-or-pay commitment the physical build cannot meet on the promised date. The remedy is buying capacity on the open market at a loss, or breaching.Why this is a configuration problem
• Underselling and stranding. Capacity that energizes with no contract against it, depreciating against a loan while utilization sits below break-even.
• Overstating deliverable capacity in the model itself. Our own data center work found that a naive model — treating power as continuous, ignoring PDU discreteness, rack overhead and the row slots consumed by cooling gear — overstates deliverable performance by around 20%. For a colocation tenant that is embarrassing. For a neocloud that has sold multi-year contracts against that capacity and borrowed against those contracts, it is a solvency question.
• Mix errors. Locking too much capacity into cheap multi-year commitments, or too little, discovered only when the utilization curve is already set.
• Jurisdiction errors. A workload placed on capacity that fails a sovereignty or residency requirement, discovered at audit.

Segmentation — where to play and where not to

Why we are unusually well positioned

• We already have the build model. An AI data hall modeled to component level, including the discreteness that breaks naive models. That is the Tier 1 and Tier 2 build-side asset, and it exists today.
• The fidelity ladder lands harder here than anywhere. A 20% overstatement of deliverable capacity is a different order of problem when contracts and debt are written against it.
• No incumbent to displace. These are companies two to four years old. Contrast telecom, where Amdocs and Netcracker own the catalog, and even towers, where structural consultants are established.
• Technical buyers. They will understand what a constraint engine is without translation.
• Roughly 200 companies worldwide. A real addressable market, against four operators in Indian telecom.
• The engine does more than configuration. The same core that checks a cluster design against power and rack limits can check an AI copilot's answer to a covenant or sovereignty question, or govern a sequence of actions an AI agent takes against capacity and pricing. Our EU261 and Klarna BNPL work shows LLMs alone get this kind of multi-rule question wrong 20–50% of the time depending on setup.

Honest risks

• Cash and covenants. Many of the long tail spend every dollar on GPUs, and debt covenants make software capex compete directly with hardware.
• Consolidation. Verified commentary notes the commercial case rests substantially on GPU scarcity, a condition expected to ease as hyperscalers expand. A meaningful fraction of the 200 will not exist in three years, so pipeline churn should be assumed.
• Engineering-led culture. Many will build their own. Our answer is the one we give Flex: of course, you could — the question is whether you should, before your next financing round. The wider engine gives a second answer: build it, and let us validate what you or your copilot generates against the constraints that matter.
• Speed. A market moving this fast may not stop to buy software. Short time-to-value is not optional here.
• Our own knowledge. We have modeled the physical build. We have not modeled the allocation or covenant layers, and we do not know how these companies operate internally today. That is what Section 10 is for.

Two adjacencies

The crypto retrofit. Verified: several neoclouds began as cryptocurrency mining companies. Converting a mining site to AI is a distinct and hard problem — the site has power and a shell, but the wrong cooling, the wrong density, the wrong network and the wrong redundancy. That is a residual-capacity problem, structurally identical to the tower loading case, with the same minimum-edit repair shape.

Flex SpinCo's customers are neoclouds. If we model the grid-to-chip stack for SpinCo, the same model serves the buyers of that stack. Worth holding as a possible channel rather than treating the two as separate campaigns.

What we need validated

Order of magnitude answers are sufficient throughout. Questions 1 to 5 would settle the verdict on their own.

1. For a mid-size neocloud, how many enterprise quotes are issued per month, and what is the typical contract value and term?
2. When a customer asks for a specific cluster in a specific region starting on a specific date, what actually happens internally? Who answers, using what, and how long does it take?
3. Is capacity allocation tracked in a system, or in spreadsheets? Is it connected to the quoting process at all?
4. Has anyone signed a contract they subsequently could not deliver on the promised date? What did it cost?
5. Is the reserved-versus-on-demand mix decision made systematically, or by judgment?

6. Who designs the physical clusters — in-house engineering, the OEM, or an integrator? How much is genuinely configured versus taken as a reference architecture?
7. How accurately is deliverable capacity known before a site energizes? Has anyone been materially surprised?
8. For operators retrofitting former mining sites, what fraction of the existing shell and power train is actually reusable?

9. Is the 70% break-even figure broadly right, and does it vary much by financing structure?
10. Are debt covenants written against utilization, backlog, or both — and does anyone check a quote against them before it is issued?
11. How is utilization forecast today, and how far ahead?

12. For sovereign and national programs, what constraints are actually written into the procurement — incorporation jurisdiction, staff clearance, hardware provenance, data residency?
13. Are those constraints checked systematically, or handled by legal review case by case?

14. Who would own a tool like this inside a neocloud — revenue operations, infrastructure engineering, or finance?
15. Is there budget for software at a company whose capex is dominated by GPUs and constrained by covenants?
16. What is a realistic time-to-value expectation before they lose interest?

17. Does the mega tier use or plan to use AI agents for capacity or pricing decisions, and if so, how do they govern a sequence of agent actions against covenant limits?
18. Is any part of the scheduling or bin-packing logic AI-assisted or AI-generated, and if so, what currently checks it against power, thermal, or topology limits?

Sources and confidence

Verified from public sources: the operator count of roughly 190–200-plus; the revenue estimates and CAGR quoted, with the caveat that analysts differ; the 60–85% pricing gap to hyperscalers; the take-or-pay contract structure and borrowing against contracted cash flow; the roughly 70% break-even utilization and reported 55–65% operating levels; the three underwriting criteria; CoreWeave's reported backlog; the hyperscaler commitments including Microsoft's $60 billion-plus and Anthropic's Fluidstack partnership; H100 pricing decline; CoWoS allocation through mid-2027 and the shift in procurement cycles; the three-sided deal deadlock and deal sizing; the crypto-mining origins of several operators; and the sovereignty and geopatriation figures attributed to Gartner.

Our inference, not verified: the three-layer decomposition in Section "Why this is a configuration problem"; the claim that no product spans all three; the error modes in Section "What goes wrong — the error modes we would claim to prevent"; the tier segmentation and the recommendation to skip Tier 3; and every judgment about how these companies operate internally, of which we have no direct knowledge; and the claim that a reasoning-copilot or agent-governance angle reopens Tier 1, or meaningfully answers the engineering-led-culture risk in Section "Honest risks"".