Curtailment planning
When the grid says shed, shed the right things.
A curtailment order arrives as one number: drop N kW, soon. What it becomes inside your estate is a choice between pausing whatever is biggest and pausing whatever is cheapest to pause — and the two answers differ by a killed training run. This page shows both, on the same estate, with the arithmetic printed.
Why now
Curtailment used to be a hypothetical for data centers. In Texas it is becoming a condition of connecting at all.
ERCOT's interconnection queue is now dominated by large loads — much of it exactly the kind of load a GPU estate is — and Texas Senate Bill 6 reworked how those loads connect: operators planning Texas capacity face curtailment-cooperation expectations as part of interconnection. "What can you shed, and how fast?" is turning from a resilience tabletop question into something you answer in writing, in advance. An operator who can show a governed shed plan — which workloads pause, in what order, sparing what — is in a different negotiating position than one whose plan is a breaker.
Texas is the sharp edge, not the whole story. Interconnection queues at CAISO and PJM carry the same large-load pressure, and expectations that big loads demonstrate flexibility are appearing in interconnection conversations beyond ERCOT — the regulatory detail differs by ISO, and we make no claims about any specific statute or tariff outside Texas. What travels is the planning arithmetic: whichever grid you connect to, "what can you shed, and how fast" is a question worth answering before it is asked.
planning arithmetic, not legal advice — your counsel reads the statute and your interconnection agreement; we price the shed
Two ways to shed 50 kW
Same estate, same order, two strategies. Every number below is computed live from the demo estate by the same planner the simulator runs — nothing on this page is typed in.
Blind pause (largest consumers first)
what a naive shed does: biggest consumer first, blind to criticality and checkpoint state
- 1.atlas-70b fine-tunecritical144 GPUs · 144 kW
Governed shed (idle first, critical protected)
idle allocation first, then batch, then non-critical training — critical workloads only if the target is otherwise infeasible
- 1.eval suite16 GPUs · 16 kW
- 2.research notebooks9 GPUs · 9 kW
- 3.recsys nightly train32 GPUs · 32 kW
the blind shed pauses the estate's largest consumer — the critical atlas-70b fine-tune (144 GPUs) — immediately, eating $718 of checkpoint progress; the governed shed reaches the same target from idle and batch capacity, touching 0 critical workloads · demo estate priced at $2.10/GPU-hour · power model 1 kW per allocated GPU (stated planning assumption)
What honest curtailment planning admits
Three things most shed plans quietly pretend away. The planner states all three, per plan, every time.
Infeasibility is declared, not pretended
Order a shed larger than the estate can reach by pausing workloads and the plan says so — "pausing everything reaches X kW" — instead of returning a plan that cannot deliver. A commitment you cannot meet is worse than one you decline in advance.
A pause is not an instant shed
A paused training run draws full power until its checkpoint completes — expected wait, half its checkpoint interval; worst case, the full interval, because the run may have checkpointed a moment before the order landed. Time-to-target reports the slowest drain both ways, and the worst case is the compliance clock — promise it, hope for the expected. Where a run's cadence is unmeasured, the planner reports the time as unknowable rather than inventing one.
A stale snapshot is named
Shed plans are computed from a snapshot, and estates churn. Every report carries its snapshot age; curtailment planning warns loudly past 24 hours. Re-collecting is one command.
Run it on an estate
The Curtailment tab of the simulator plans sheds at any target against the demo estate — or against your own estate.json, collected read-only and rendered entirely in your browser.