AI Compute Capacity Contracts: A Due-Diligence Checklist for Open-Source Labs

AI compute capacity is becoming a release dependency, not just a purchasing line item. When a lab signs for access to scarce accelerator capacity, the engineering risk moves into model roadmaps, data-handling plans, reliability targets, and exit clauses. This checklist uses the reported SpaceX and Reflection AI compute agreement as a timely example, but the controls apply to any open-source AI team buying reserved GPU capacity.

TechCrunch reported that Reflection AI will pay SpaceX for access to Nvidia GB300 systems at the Colossus 2 data center near Memphis, with payments beginning July 1, 2026 and a contract running through 2029 unless cancelled under the reported terms. Reflection’s own homepage describes the company as building frontier open intelligence and making it accessible. Those two facts make the deal a useful case study: open-weight or open-source ambitions still depend on closed, physical, power-hungry infrastructure.

Why the deal changes the checklist

The headline figure is only the start. TechCrunch’s report says the agreement is worth up to $6.3 billion, but it also says either company can end the contract with 90 days’ notice after the first three months. For engineering leaders, that means the question is not “how much compute did we buy?” It is “what must be true before product, research, and community commitments depend on that compute?”

The compute layer now has product semantics

Teams used to treat accelerator access as an internal scaling problem. Today, a capacity contract can determine whether a model family ships, whether a fine-tuning service remains available, and whether open artifacts are reproducible by the community. If the infrastructure is controlled by a third party, the lab needs the same discipline it would apply to a payment processor, identity provider, or cloud region.

Decision gate

Before announcing timelines, require a signed capacity baseline, a documented exit path, and a reproducibility plan that survives partial capacity loss. The plan does not need to reveal private contract details, but it must be specific enough for research, infrastructure, and security leaders to review.

1. Treat reserved GPUs as a governed dependency

Nvidia describes the GB300 NVL72 as a rack-scale system for AI reasoning workloads, and the DGX GB300 page frames the platform as AI factory infrastructure for enterprises. That matters because buying access to this class of system is not equivalent to renting a generic virtual machine. You are depending on a tightly coupled stack of accelerators, networking, power delivery, facility operations, and software.

Inventory what is actually committed

The contract should separate physical accelerator capacity from surrounding obligations. At minimum, track the accelerator generation, rack or cluster topology, storage class, network egress, maintenance windows, security boundary, power and cooling assumptions, and the support model. If the provider uses different internal pools for training, inference, or burst workloads, document which pool your workloads can use.

Acceptance evidence

Ask for a capacity exhibit that maps promised resources to measurable units: available accelerator count or equivalent capacity, usable interconnect domain, storage throughput, queueing priority, and support response commitments. Avoid vague language such as “latest GPUs” without a dated bill of materials or an agreed substitution rule.

Separate roadmap capacity from experimentation capacity

Open-source labs often run a mix of frontier training, evaluation sweeps, inference demos, safety testing, and community artifact builds. Those workloads should not compete silently. Reserve different capacity bands or scheduling priorities so a public model release does not lose time to exploratory jobs.

2. Price the exit before the first training run

The reported Reflection AI agreement is a reminder that cancellation language can be as important as headline duration. If a contract can end on 90 days’ notice after an initial window, the lab needs a 90-day migration and triage plan before it treats the capacity as durable.

Define the minimum viable compute floor

For each model or product milestone, identify the smallest compute envelope that still supports responsible operation. A frontier training run may have no realistic fallback, but evaluation, inference, packaging, and safety regression jobs usually do. Label each workload as critical, deferrable, portable, or abandonable.

Metric

Use days-to-recover, not just dollars-per-GPU-hour. A cheaper contract that leaves the team unable to move weights, datasets, container images, evaluation logs, or observability history is not cheaper once a cancellation notice arrives.

Keep artifacts portable

Capacity buyers should standardize around portable model artifacts, reproducible data manifests, and documented runtime assumptions. If an inference stack requires provider-specific kernel modules, proprietary queueing APIs, or opaque image builds, the exit plan should say exactly how the lab will replace or isolate those pieces.

3. Put governance around open releases

Open-source positioning does not remove AI risk management duties. The NIST AI Risk Management Framework organizes AI risk work around Govern, Map, Measure, and Manage functions. For a compute capacity contract, those functions translate into review gates before the lab publishes weights, benchmarks, APIs, or system cards that depend on the reserved cluster.

Map model claims to compute evidence

Every public performance claim should link back to a run record: hardware class, training or evaluation date, dataset version, software stack, and known limitations. If a model was trained on contracted capacity but evaluated elsewhere, the publication should make the distinction clear.

Release rule

Do not publish a benchmark, safety statement, or open-weight claim unless the underlying run can be reproduced internally or explained with a documented non-reproducibility reason. For open-source labs, “we lost access to the cluster” is not an acceptable surprise after release.

Gate community-facing commitments

A lab may be tempted to promise rapid open releases once a large capacity deal is signed. Instead, separate infrastructure readiness from community commitments. A public roadmap should identify which artifacts are funded, which depend on reserved compute, and which depend on external review.

4. Inspect the software and support boundary

Hardware is only one layer. Nvidia’s AI Enterprise documentation describes an application layer with frameworks and microservices and an infrastructure layer with GPU drivers, Kubernetes operators, and cluster-management tools. A capacity buyer needs to know which side is operated by the provider and which side belongs to the lab.

Clarify who patches what

Write down who owns driver updates, container runtime updates, Kubernetes operator updates, vulnerability triage, tenant isolation, identity integration, and incident notifications. If the lab controls images but the provider controls hosts, both parties need a shared escalation path for CVEs that cross the boundary.

Evidence to request

Ask for patch cadence, incident notification timelines, supported software versions, audit evidence for tenant isolation, and a process for emergency maintenance. The goal is not to expose the provider’s internal design; it is to avoid discovering the ownership model during an outage or vulnerability response.

Design for observability without leaking research

Telemetry should cover capacity use, job failure rates, queue latency, accelerator health, storage errors, egress, and security events. At the same time, it should not leak sensitive prompt data, unpublished model weights, or private datasets. Define telemetry boundaries before production workloads arrive.

5. Build a capacity-review table

A simple review table keeps the contract from becoming a black box. The table below is intentionally vendor-neutral; adapt it to any reserved GPU, AI cloud, or colocation-style arrangement.

6. Run a pre-commit review before signing

Engineering review

Infrastructure leaders should verify that the promised environment matches workload requirements for training, inference, evaluation, and artifact packaging. If the cluster is primarily useful for one workload class, avoid using it as the foundation for all public commitments.

Security review

Security teams should evaluate identity boundaries, data movement, host visibility, software supply-chain controls, and incident response. A GPU contract is still a third-party risk contract, and the size of the accelerators does not reduce the need for basic vendor governance.

Research and community review

Researchers should define which results can be reproduced without the contracted environment and which cannot. Community teams should avoid presenting capacity access as a guarantee of open releases until the lab has tested artifact export, documentation, and independent review.

Final release gate

Approve the contract for production use only when the team can answer three questions: what exactly is reserved, how quickly can critical work move if access changes, and which public claims depend on this infrastructure? If any answer is unclear, treat the capacity as experimental until the evidence exists.

The practical takeaway

The reported SpaceX and Reflection AI arrangement shows that compute access can now be a strategic moat for open-source AI labs. But a large contract does not automatically create reliable, portable, or governable infrastructure. The winning teams will treat reserved GPU capacity as a production dependency with measurable commitments, explicit exit plans, and release gates that protect both the lab and the community relying on its work.