A single campus, four companies deep
The hyperscale data center campus in Abilene, Texas, has become one of the clearest examples of how AI cloud capacity actually gets built today. Crusoe, an infrastructure developer, builds and co-owns the physical site, turning capital, land, power, and Nvidia systems into a finished campus. Crusoe then leases that site to Oracle, which installs and operates the cloud layer as Oracle Cloud Infrastructure. OpenAI is the end customer, consuming the training and inference capacity that results. Four distinct companies sit inside what looks, from the outside, like a single OpenAI or Oracle cloud deployment.
Structure Research confirmed in October 2025 that the first phase of the campus was online, with Oracle Cloud installed as the anchor tenant, describing time-to-market as the project's defining achievement. By December 2026, the campus is projected to reach more than 700 megawatts of live capacity, a scale that places it among the largest AI-dedicated sites built anywhere to date, and one that took roughly a year to move from early construction to substantial live load.
The economics of being the landlord
Crusoe's internal projections, viewed through research firm Sacra, put the Abilene site's lease revenue at roughly 11 million dollars in 2025, climbing to approximately 250 million dollars in 2026 as more of the campus comes online and starts generating rent. That growth curve illustrates the business model clearly: Crusoe earns by leasing finished physical capacity to an operator, functioning as what Sacra's research describes as a fast build partner, converting capital and physical assets into leasable hyperscale capacity for Oracle to run, a different business entirely from CoreWeave's model of selling GPU cloud time directly to end users.
That model sits alongside, rather than competes with, the broader Stargate build-out. Oracle and OpenAI's original partnership, announced in July 2025, covered 4.5 gigawatts of capacity, and the overall Stargate program has since grown to more than 5 gigawatts under development across multiple sites. Abilene is one piece of a much larger commitment, and Crusoe's role there is a template that is likely to repeat at other sites as the program scales further.
Why the layering matters to your risk assessment
If your organization ever signs a cloud or AI infrastructure contract that touches Oracle Cloud Infrastructure capacity built on a site like Abilene, your actual exposure runs through every layer of this stack, not just the name on your invoice. A dispute between Crusoe and Oracle over lease terms, a financing problem on Crusoe's side, a construction delay, or a change in OpenAI's own demand for the underlying capacity can all affect whether your workload lands on schedule, even though none of those parties appear anywhere in your contract with Oracle.
This is not a reason to avoid OCI or any provider using a similar structure. It is a reason to understand that the brand name on a cloud contract increasingly describes the operator, not the full ownership and financing chain behind the physical infrastructure. The further removed your workload is from a vendor's own owned-and-operated data centers, the more layers of counterparty risk sit between your SLA and the actual racks running your code. That distance is rarely disclosed up front, which means the burden sits on the buyer to ask the right question before signing rather than after a delay has already happened.
This pattern is becoming the norm, not the exception
Abilene is not an isolated arrangement. As AI infrastructure demand has outrun what any single hyperscaler can self-finance and self-build, developers like Crusoe have positioned themselves specifically as capacity wholesalers, building sites that get leased to Oracle, Microsoft, or other operators rather than selling cloud services directly under their own brand. That structure lets hyperscalers scale faster than their own balance sheets would otherwise allow, by converting a developer's capital and construction speed into capacity the hyperscaler can then resell.
For buyers, the practical effect is that an increasing share of the capacity marketed under a familiar hyperscaler name was built and financed by a separate developer. Knowing that a developer sits behind the operator is manageable with the right diligence questions. Assuming every site is owned and operated end to end by the hyperscaler whose logo is on the contract leaves procurement and risk teams blind to a layer of counterparty exposure that a decade of traditional cloud contracting never had to account for.
What this means for your next contract
Before signing a multi-year commitment tied to a specific region or campus, ask your provider directly whether the underlying site is owned and operated by them or leased from a third-party developer, and if it is leased, ask what contractual protections exist if that developer relationship changes. This is a reasonable diligence question now, not an unusual one, given how common the Crusoe-Oracle-OpenAI structure has become across the industry in the past year.
Build the answer into your risk register alongside the usual vendor concentration and data residency checks. A cloud contract's delivery promise is only as strong as the weakest link in the chain of landlords, builders, and financiers standing behind it, and in 2026 that chain is longer, and less visible, than most procurement processes are currently set up to evaluate. The Abilene model will keep repeating as long as demand keeps outrunning what any single hyperscaler can self-finance, so treat the diligence question as a permanent addition to your contracting checklist rather than a one-time exercise for this particular deal.
