Flexible Load Data Center Interconnection: Running Inference Fleets as Curtailable Compute

Most AI infrastructure plans in 2026 run into the same problem. The GPUs are on order and the building is going up, and then the utility says the full load can be firm in four or five years, once a transmission upgrade is done. The bottleneck has shifted from chips to time-to-power. A growing number of utilities now attach a second offer to that answer: if part of your load can be switched off when the grid is stressed, they can connect you much sooner.

Whether you can take that offer depends on a question most AI teams have never had to answer precisely: how much of our compute can stop on short notice without anyone noticing?

For inference fleets the answer is more than zero, and it is growing. Deloitte's 2026 technology predictions expect inference to make up roughly two-thirds of all AI compute this year. A large share of that inference runs as batch scoring, document pipelines, async agent jobs, and evaluation runs, and none of it needs a response in 300 milliseconds. Workload classification has always been a matter of cost and latency. It now also affects how soon you can get power.

Why Utilities Trade Queue Position for Curtailment

A grid is sized for its worst hours, so most of the year there is unused capacity on the wires and in the generation fleet. A load that runs flat out 99% of the time and backs off during the few hundred peak hours a year can often fit on the existing system with no new transmission. A load that insists on full power during those peaks triggers upgrades that take years.

Several moves in the past year turned this idea into tariffs and contract terms:

• Federal pressure on interconnection rules. FERC's large-load interconnection proceeding, which the Department of Energy pushed the Commission to open in late 2025, puts flexible and curtailable large loads at the center of how big consumers connect to the transmission system.
• State mandates. Texas Senate Bill 6 requires new large loads of 75 MW or more to be curtailable during grid emergencies and to disclose backup generation. In ERCOT, flexibility is now a condition of connecting.
• Hyperscaler agreements. Google announced demand response agreements with Indiana Michigan Power and TVA that cover shifting or reducing machine learning workloads during grid events. That moved flexible compute from a research topic to operating practice.
• Field testing. EPRI's DCFlex initiative runs demonstrations with utilities and data center operators to check whether data centers can deliver the flexibility they promise, with metering a grid operator will trust.

Industry commentary such as Avanza Energy's analysis of load flexibility calls this a breakthrough moment for demand-side flexibility, with data centers as the driver. We agree with the direction, and we would add one caveat. The utility gives credit only for flexibility you can demonstrate, and AI teams have not yet built that demonstration. Making that case is the work of the facilities team, the ML platform team, and the people who own the inference product, together.

For the broader planning context, see our earlier piece on AI data center power constraints and capacity planning.

Which Inference Can Actually Shed

Training jobs and real-time serving often get grouped together as "AI load." For curtailment purposes they behave very differently, and inference itself splits into several tiers.

Only T2 and T3 can stop on command with no user-visible effect. T1 can give up some power if you accept degradation, for example by moving to a smaller model or cutting reasoning effort (the same levers we covered in tuning reasoning effort per task). T0 cannot shed at a single site.

Interactive traffic also tends to peak during the same weekday afternoon and early evening hours when the grid is most stressed. So the tier you cannot shed is usually at its busiest during curtailment events. Any sizing exercise that uses average daily mix will overstate how much you can shed. Use the workload mix during the grid's peak hours.

Multi-region serving changes this. If T0 traffic can fail over to a site on a different grid, it becomes sheddable at the site level, though not across the whole fleet. IEEE Spectrum's coverage of distributed inference data centers describes this design: smaller inference sites spread across grid regions, with traffic steered toward the sites with power to spare. Startups are working on the same idea. LōD is positioning AI inference itself as a flexible grid resource that responds to grid signals.

If you do not know your mix, measure it before you negotiate. Our post on measuring where enterprise inference spend goes covers the request tagging this requires.

What a Curtailment Agreement Asks of a GPU Cluster

A curtailment agreement is a promise with a meter attached. The utility does not care how you shed. It cares that metered consumption drops to the agreed level within the agreed time and stays there for the agreed duration. The terms engineering teams need to read before anyone signs:

• Notice time. Notice can be day-ahead or close to real time. Day-ahead notice lets you pre-drain queues. Short notice means the scheduler has to react automatically.
• Event duration and frequency. Duration and frequency together set how much deferred work piles up and how much spare capacity you need to clear it.
• Firm vs non-firm megawatts. The firm number is your floor. It has to cover T0 peak plus whatever T1 you cannot degrade.
• Measurement and verification. The baseline methodology decides whether your shed counts. A baseline taken during a quiet week can make a real shed look like nothing happened.
• Conversion milestone. This is the upgrade or date when non-firm capacity becomes firm. Without one, you are agreeing to permanent interruptibility.

On the cluster side, a shed usually layers these levers, from fastest to slowest:

1. Admission control. Stop accepting new T2/T3 work at the queue boundary.
2. GPU power capping. Lower per-device power limits. Throughput drops less than power does at moderate caps, which makes this a cheap first step for T1.
3. Drain and pause. Let in-flight batch requests finish, then idle those replicas.
4. Checkpoint and suspend. Long agent runs and training jobs need resumable state. Jobs without checkpoints lose all their progress in an event. Our post on durable agents and checkpointing covers the workflow side.
5. Geographic failover. Shift T0 traffic to other regions if your architecture supports it.

The control logic is simple enough that teams often underestimate the effort needed to test it. A minimal version looks like this:

def on_curtailment_signal(target_mw: float, deadline_s: int):
    current = meter.read_mw()
    plan = []
    for tier in ["T3", "T2", "training", "T1_powercap"]:
        if current <= target_mw:
            break
        freed = scheduler.estimate_shed_mw(tier)
        plan.append(tier)
        current -= freed
    if current > target_mw:
        plan.append("T0_failover")  # last resort, needs multi-region
    scheduler.execute(plan, deadline_s=deadline_s)
    audit.log_event(target_mw, plan, meter.read_mw())

The last line matters as much as the scheduling. Every event should produce a record of the target, the actions taken, and the metered result. That record is how you prove compliance, and the next section explains why it also strengthens your position in the next negotiation. It is the same audit discipline we recommend for stopping agent fleets safely, applied to megawatts.

The Math of a Shed-Able Tier

Here is a hypothetical campus, to show how the tiering turns into a negotiating position. All numbers are illustrative.

A team plans a 200 MW inference campus. The utility can offer 120 MW of firm service in 2027. The remaining 80 MW can connect as non-firm, subject to curtailment, until a transmission upgrade finishes in 2030.

The shed works: 90 + 30 = 120 MW, which equals the firm limit. Without the shed-able tier, the team either waits until 2030 for 200 MW or builds 120 MW now and leaves a third of its planned capacity on paper for three years.

Now look at what curtailment costs in lost work. Suppose events add up to 1% of annual hours, about 88 hours. The batch tier loses 70 MW × 88 h ≈ 6,160 MWh of compute, which is about 1% of its annual 613,200 MWh. Deferrable work can be made up later, so the real cost is delay, not lost output.

That only holds if the fleet has room to catch up. If the batch tier normally runs at 100% utilization, the 88 hours of deferred work never clears and turns into missed SLAs. A curtailable fleet needs either some spare capacity outside event windows or SLAs loose enough to absorb the backlog. When power is the scarce resource and GPUs are not, running GPUs below full utilization some of the time is the price of getting powered years sooner. Most board-level models do not include this tradeoff. We cover how to frame it for finance in building the AI investment business case, and the contract side in GPU-as-a-Service pricing and contract economics.

Location matters too. Next 10's Curtail to Compute report looks at the reverse case in California: putting flexible compute where renewable output is already being curtailed, so the deferrable tier soaks up surplus energy instead of competing for scarce peak capacity. The same tier classification applies, with the flexibility pointed the other way.

Proving the Shed: The Evidence Package

Utilities have dealt with interruptible industrial customers for decades, and they have seen many paper commitments fall apart during the first real event. A team that walks in with "our batch work is flexible" gets treated like every other applicant. A team that walks in with metered proof gets a different conversation.

A credible evidence package contains:

1. A tier map in megawatts, not requests. For each tier: peak-hour draw, minimum viable draw, and shed time. Convert request volumes to power using measured per-replica draw, not nameplate GPU TDP.
2. Metered shed tests. Run unannounced drills: send a synthetic curtailment signal, record facility-level power at one-minute resolution, and show the drop meeting the target within the notice window. Repeat at different times of day, including your interactive peak.
3. Recovery data. Show how long the backlog takes to clear after a drill and whether any SLAs were missed. This is the evidence that your flexibility will hold up over a summer with many events.
4. The runbook and its owners. Who receives the signal, what fires automatically, what needs a human, and who can override. Utilities want to know that a 2 a.m. event will not wait on someone's phone.
5. Contract-ready numbers. Firm MW, curtailable MW, maximum event duration you can sustain, and maximum events per season, all derived from the tests above.

This package is your negotiating position. A team that can show 70 MW of tested, metered shed capacity is asking for something specific and checkable. A team that cannot is asking the utility to take its word.

Testing the shed also catches problems before they become penalties. Jobs that ignore pause signals, replicas that do not release memory cleanly, and checkpoint writes that saturate storage right when you are trying to reduce load all show up in drills. The fault injection practices we use for agent systems apply directly: treat the curtailment signal as a fault you inject on a schedule.

Building the Shed-Able Tier Before the Utility Asks

The order of work matters. Classification comes first, because the scheduler, the evidence, and the contract all depend on it. Concretely:

• Weeks 1 to 3: Tag every inference path by tier. Most teams find workloads labeled "real-time" that are really nightly jobs with an impatient owner. Reclassifying them is the cheapest megawatts you will find.
• Weeks 3 to 6: Make T2 and T3 pausable. Add admission control at queue boundaries, checkpoints for long agent runs, and idempotent resumption so paused jobs do not write duplicate records.
• Weeks 6 to 8: Wire the curtailment signal into the scheduler, add power telemetry per tier, and run the first drills.
• Ongoing: Re-measure the tier mix every quarter. Agent workloads are shifting toward async patterns, so the shed-able share should grow, and your contract terms should be renegotiated when it does.

Some teams should not pursue this. A fleet that is mostly interactive serving at a single site has little to offer a utility, and promising flexibility it cannot deliver is worse than taking the slower firm queue. Teams that rent all their capacity from a cloud or GPU provider should push that provider on its own curtailment terms and make sure their workloads can tolerate them.

The work in this sequence is mostly software: request classification, durable job state, queue control, and audit logging. OpenNash builds these pieces for production agent systems. Our audit maps which workloads are deferrable, the design phase sets the approval and override rules for curtailment events, and the build delivers the pausable queues, checkpointing, and telemetry that a utility will accept as evidence. The client owns all of it at handoff.

If an interconnection discussion is coming in the next two quarters, start with a tier map of your current inference traffic converted to megawatts. If you want help producing it, book a working session with OpenNash and bring a week of request logs. We will turn them into a firm and curtailable split you can take to the utility.