On 2026-08-20, a paper applying LLM-driven predictive decision-making to data center cooling, workload scheduling, and energy draw surfaced in the arXiv forward feed as 2608.18503. Its contents are unverified: the paper itself was not retrievable at research time, and no number from it should be quoted yet. The question it raises, though, is worth answering now with the evidence that does exist: should an LLM sit anywhere near the control loop of a physical plant? The short answer is no for actuation, maybe for advisory, and the strongest available benchmark on LLM planning over operational data explains why.
What does “LLM predictive control” actually mean in a data center?
The phrase covers three distinct architectures with very different risk profiles: an advisory layer that recommends setpoints a human or a classical controller approves, a planner that sequences workloads and maintenance windows subject to hard constraints, and a closed-loop actuator whose outputs directly drive chillers, pumps, and fan walls.
Vendors currently shipping AI-branded DCIM add-ons blur these categories deliberately, because “AI-optimized cooling” sounds the same in a procurement deck whether the model emails a suggestion or writes to a BACnet register. The distinction matters more than any benchmark. An advisory system that is wrong most of the time costs an operator some patience. A closed-loop system that is wrong once at the wrong moment can trip thermal thresholds, violate SLAs, or damage hardware. Before evaluating any claimed savings, the first question to ask a vendor is which of the three architectures their product implements, and where the hard stop sits between a generated recommendation and a physical action.
The middle category is where procurement pressure lands hardest, because it sounds safer than actuation while carrying most of the same reliability problems. A workload scheduler makes decisions that are reversible on the timescale of hours, which is more forgiving than a chiller setpoint but less forgiving than a recommendation a human reads before acting. Scheduling errors also compound quietly: a planner that is subtly wrong about thermal headroom will keep producing confidently wrong placements until someone audits the placement history, and the symptom will show up as a hot aisle rather than as a log line.
Classical model predictive control, the incumbent in serious facilities, works from an explicit thermodynamic model of the plant: it predicts how temperatures evolve under candidate actions, optimizes over a receding horizon, and respects constraints by construction. Its failure modes are well understood because its model is inspectable. An LLM-based controller replaces that explicit model with a learned policy over text or tokenized telemetry, and its failure modes are correspondingly less inspectable. That tradeoff is the entire decision.
How reliable are LLM planners on live operational data?
The best available benchmark evidence says not very: across 4,800 primary records1 in SemPlan, a benchmark for structured semantic planning over enterprise data, no tested LLM planning approach exceeded 26% answer correctness.1
The spread across approaches is instructive. Direct SQL generation, the naive approach of asking the model to emit a query, achieved 22.25% answer correctness.1 A bounded tool-agent baseline, where the model could invoke constrained tools, reached 22.58%. The best-performing approach, structured semantic-request generation, reached 25.67%.1 A clarification-driven stateful variant landed at 24.25%.1 Four architectures, all engineered to constrain the model’s output, and the winner is still wrong on roughly three of four records.
Two caveats belong next to those numbers. First, SemPlan measures structured planning over enterprise data, not thermodynamic control. Query planning and cooling control are different tasks, and this article does not claim the 22 to 26% figures1 transfer directly to plant operations; the benchmark is evidence about LLM decision reliability on live operational data in general, not about chillers. Second, the SemPlan results come from a single preprint with its own lab conditions, and answer correctness is a strict metric that penalizes partially correct plans. Even with both caveats applied generously, the direction of the evidence is hard to argue with: when LLMs plan against real operational state, error rates are measured in the tens of percent, not the fractions of a percent that a control loop demands.
Should an LLM advisor replace classical MPC?
No. The evidence supports LLMs as a supervised advisory layer at most, with actuation authority staying in classical MPC and existing DCIM automation, and every model-generated action passing through deterministic validation before it touches the plant.
The decision framework reduces to four axes, and the LLM loses on the ones that matter for actuation.
Reliability floor. A control loop needs its decision-maker right essentially all the time, because errors compound through the plant’s thermal inertia. MPC’s correctness is bounded by model fidelity and constraint handling, both auditable. The SemPlan results show LLM structured planning at 22 to 26% correctness on operational data.1 Even if a well-tuned domain-specific controller does far better, “far better” has to be demonstrated under stated test conditions, not assumed.
Domain transfer. LLMs are trained on text, and the transformer architecture underneath them was introduced for sequence modeling at NeurIPS 2017 in “Attention Is All You Need”, not for physical control. Nothing about the architecture provides the constraint satisfaction guarantees that MPC gets from its optimizer. A vendor claiming strong cooling results from a general-purpose LLM is claiming a transfer result, and transfer claims need transfer evidence.
Actuation authority. This is the axis with a clean answer. Advisory recommendations, anomaly triage, report drafting, and maintenance-window suggestions are all places where a wrong answer is caught by a human or a downstream validator. Closed-loop setpoint control is where a wrong answer is a thermal event. Keep the LLM on the advisory side of that line.
Auditability. MPC decisions can be replayed against the model that produced them. An LLM’s reasoning cannot be fully reconstructed after the fact, which becomes a compliance problem the moment a regulator asks why a specific energy decision was made. Energy-efficiency reporting obligations are tightening across jurisdictions, and “the model suggested it” is not an audit trail.
What failure modes does an LLM add inside a physical plant?
An LLM in a control loop inherits three failure classes that classical control does not have: hallucinated actions, unbounded latency variance, and audit gaps that surface only when someone files a report.
Hallucination is the obvious one. A language model asked to reason about a plant state it has not seen will produce a plausible-looking action anyway; generating fluent output under uncertainty is what these models do. In a query-planning context, a hallucinated join produces a wrong number in a dashboard. In a plant, a hallucinated setpoint produces a thermal excursion. The SemPlan authors constrained their models with structured outputs and tool boundaries precisely to contain this, and still landed under 26% correctness.1
Latency is quieter but operational. MPC solves its optimization in deterministic time, sized to the control interval. An LLM’s response time varies with prompt length, context state, and whatever is happening on the inference backend, and a cooling control interval does not wait for a slow token stream. Any architecture that puts an LLM in the fast path of a control decision needs a deterministic fallback that fires when the model misses its deadline, which means the classical controller has to exist anyway, which raises the question of what the LLM was for.
The fallback requirement also sets the economics. If classical control has to stay in the loop as the safety net, the LLM layer becomes an additional system to license, host, monitor, and patch, stacked on top of a controller that already meets the plant’s requirements. The honest framing for that spend is marginal optimization on top of a working control system, and the question that follows is whether the marginal gain clears the added operational cost. In a market where the headline numbers are vendor-reported, that question rarely gets asked in the procurement meeting.
The audit gap is the slowest failure mode and the one most likely to be discovered by a regulator rather than an engineer. When an LLM influences energy decisions across a fleet, the aggregate effect shows up in efficiency reporting. If the reasoning behind those decisions cannot be reconstructed, the operator carries the compliance risk while the vendor carries none. The referenced arXiv preprint’s listing page is a useful reminder here: arXiv hosts more than three million articles across eight subject areas, and a listing carries no replication or peer-review signal. A preprint proposing LLM control of a data center is a research artifact, not a validation result. (arXiv itself is now an independent nonprofit, having completed its separation from Cornell on July 1, 2026; the organizational change does not change what a listing means.)
What should you demand from AI-branded DCIM vendors?
Demand three things before any pilot: independently verified results under stated test conditions, a hard architectural boundary between recommendation and actuation, and an audit trail that survives a regulator’s questions.
The reference point everyone cites in this market is Google’s data center cooling work, now under Google DeepMind after the April 2023 merger of DeepMind and Google Brain. Those cooling results are widely cited and genuinely influential, but the savings figure is vendor-reported by the organization that operates the data centers and sells the adjacent cloud capacity, and it does not appear in any independently verified source available to this article. It should be quoted, if at all, with that provenance attached. A self-reported result from one of the best-resourced engineering organizations on earth, applied to plants it designed and instrumented itself, is not a forecast of what a vendor add-on will do in a colocation facility with mixed tenancy and decade-old instrumentation.
The pattern to watch for is scope creep by press release. A product that ships as an advisory layer and performs harmlessly can be repositioned as “autonomous optimization” in the next quarter’s deck without the architecture changing or the validation improving. The actuation boundary should be contractual, not aspirational.
Where does the evidence stand, and where is the buy/wait line?
The evidence supports buying advisory tooling and waiting on closed-loop control: no fetched source validates any data-center-specific performance claim for LLM control, the only anchored benchmark shows LLM planning over operational data at 22 to 26% correctness1, and the most famous cooling result in the industry is vendor-reported.
That verdict deserves its asterisks stated plainly. The motivating paper for this article, arXiv 2608.18503, was observed in the forward feed on 2026-08-20 but never retrieved, so nothing it claims about cooling, scheduling, or energy draw could be checked, and this article cites none of its numbers. The DeepMind cooling result is real history but self-reported history. SemPlan is a strong result about enterprise query planning and a weak proxy for thermodynamic control. What remains after those caveats is a structural argument rather than an empirical one: the components that make LLM control attractive (learned patterns, natural-language interfaces, cross-system reasoning) are exactly the components that make it unauditable, and the reliability bar for a physical plant is set by physics and SLAs, not by benchmark averages.
The buy line, then: advisory systems that draft, triage, and recommend behind a human or a deterministic validator are defensible purchases today, priced as productivity tooling rather than as energy savings. Anything that writes to the plant should be treated as a research collaboration, contracted with third-party verification under your test conditions, bounded actuation authority, and a classical MPC that never leaves the loop. If predictive control trims a fraction of a PUE point across a fleet, the economics of the AI buildout genuinely shift, but the first operator to get there will do it with verifiable numbers, and none of the numbers in this market are verified yet.
Frequently Asked Questions
Why does arXiv’s 2026 independence from Cornell not validate the LLM control paper?
arXiv’s transition to an independent nonprofit on July 1, 2026, changes its governance but not its publication model. Listings on the platform remain preprints without peer review or replication signals, so the organizational shift does not add any verification weight to the unverified claims in arXiv 2608.18503.
How does the SemPlan benchmark’s 25.67% correctness rate compare to MPC requirements?
The 25.67% correctness rate in SemPlan indicates that LLM planners are wrong in roughly three out of four cases on enterprise data. This error rate is orders of magnitude higher than the near-zero failure tolerance required for physical plant control, where a single incorrect setpoint can trigger thermal excursions or SLA violations.
What specific contractual clause should limit LLM actuation authority in DCIM contracts?
Contracts should explicitly define the LLM’s role as advisory only, prohibiting direct writes to BACnet registers or chiller setpoints without a deterministic validation layer. This clause ensures the classical MPC remains the sole actuator, preventing scope creep where an advisory tool is repositioned as autonomous control in future updates.
Why is the transformer architecture’s origin in sequence modeling a risk for physical control?
The transformer architecture, introduced in 2017 for text sequence modeling, lacks the built-in constraint satisfaction guarantees found in classical optimizers. This architectural mismatch means LLMs cannot inherently respect hard physical boundaries like temperature limits, requiring external validation layers that add latency and complexity to the control loop.
