Skip to content
Technology How it works Breeder — Hyperion Burner — Aegis Burner — MetroVolt AI-Native Architecture Magnets Fuel cycle Safety Roadmap
Solutions AI & Data Centers Defense & Government Grid & Baseload Neutron Detection Quantum
Learn Technical Library
Proof Publications Whitepapers Technical Library Open Science & Reproducibility The Honest Gates
Company About / Mission Leadership Environment Health & Safety Investors Careers Press Contact
3D Model
AI Architecture › L7 · Ecosystem & Strategy
L7 · Ecosystem & Strategy

Fleet Dispatch and Unit Commitment

Across many burner units, L7 solves a constrained scheduling problem that meets firm-power obligations while respecting maintenance, ramp, and physics limits.

THE STACK · click to jumpL7Ecosystem & StrategyL6Experience & VisualizationL5Applications & CopilotsL4OrchestrationL3Twin Modeling & AIL2Data FabricL1Control PlaneL0Foundation▲tlmctl▼L7 · ECOSYSTEM & STRATEGYThe plant in its world — integrated through one unified API.1Unified API Layerone door in/out2Grid Integrationdispatch & firm supply3Supply Chainfuel, parts, isotopes4Maintenanceservice & spares loops5Regulatorycompliance & reporting6Fleet Strategymulti-unit planningMACHINE TIEConnects the machine to grid, suppliers, and regulators — the outermost loop.KRONOS FUSION ENERGYAI-NATIVE S.M.A.R.T. GENERATORECOSYSTEM & STRATEGYSHEET 09REV. 2026-08L7 · AI-NATIVE STACK
L7 · Ecosystem & Strategy — its place in the stack (left, click any layer) and its internal components (right). Telemetry rises; control descends.

Scheduling firm power across units

A single burner follows setpoints; a fleet must decide which units run, at what level, and when they take outages, to meet aggregate firm-power obligations. L7 formulates this as a constrained optimization over a rolling horizon: minimize deviation from committed export and from planned maintenance windows, subject to each unit's ramp limits, envelope, and required service hours. No monetary objective enters; the problem is stated purely in physical availability and reliability terms.

The optimization, stated plainly

python
# rolling-horizon unit commitment (physical objective only)
# u[i,t] in {0,1} on/off ; p[i,t] export level
minimize  sum_t | sum_i p[i,t] - demand[t] |        # meet firm obligation
        + w * unmet_maintenance_penalty(u)          # honor service windows
subject to:
  p_min*u[i,t] <= p[i,t] <= p_cap[i]*u[i,t]         # capacity per unit
  |p[i,t]-p[i,t-1]| <= ramp[i]                       # certified slew
  reserve: sum_i (p_cap[i]*u[i,t]-p[i,t]) >= R[t]    # spinning reserve
  u respects planned_outage[i]                        # maintenance loops

The solver is warm-started from the previous horizon and re-solved as forecasts and unit health update. Because commitment decisions are discrete, the problem is a mixed-integer program; for fleet sizes it is solved with a rolling relaxation and repair heuristic that keeps re-solve latency low enough for intraday adjustment.

Constraints come from lower layers. Each unit's ramp and capacity are the twin-certified envelope; maintenance windows come from the predictive-maintenance service loop; reserve requirements come from the interconnection agreement. The optimizer never invents headroom a unit does not have.

Dispatch optimization also feeds the breeder foundry indirectly: burner fuel is helium-3, whose supply is gated by breeder production and, later, lunar sourcing. The scheduler treats helium-3 availability as a hard input constraint, not an assumption, so a fleet plan is never more ambitious than the fuel supply supports.

The optimizer runs today against simulated demand and a twin-modeled fleet. As real units commission from ~2030 onward, the same formulation coordinates them with no structural change.

Content reviewed August 2026 · design-and-simulation stage