Before you move AI compute out of Utah, check whether stored energy makes staying the better choice.
ExpertOrbit compares staying, waiting and moving - then shows the cash cost, estimated carbon, deadline feasibility, and whether storage changes the answer.
Historical-data simulation. Estimated costs and emissions.
Same 12 jobs. Three policies. One honest comparison.
Here's the cost, estimated carbon, modeled on-time performance, Utah compute energy, and stored energy used - including when storage helps and when it doesn't.
On narrow screens, scroll the table sideways for all energy and emissions columns.
| Policy | Modeled on-time deadline jobs | Cash cost | Estimated CO₂e | Utah compute energy (kWh) | Stored energy used (kWh) |
|---|
Immediate at home: start every job now on its home grid, including the pinned Virginia job. Carbon-only routing: minimize estimated CO₂e over feasible grid-only site/start choices, with cash breaking ties. ExpertOrbit: minimize cash + the selected carbon weight × emissions, with moving, waiting and shared stored energy. Pinned jobs stay home in all three policies.
The workload contains 10 deadline jobs and two continuous services. The services run throughout the same modeled evaluation horizon and are included in cost, emissions and energy totals, but excluded from the deadline metric. It checks modeled finish times, not real GPU or site capacity. The percentage under Utah compute energy is the share of Utah-home compute energy still scheduled in Utah; every modeled GPU uses 0.7 kW, and the Virginia-home job is excluded from that denominator. Stored energy used is kWh delivered to compute after storage conversion losses, not energy charged into the battery. Charge-time electricity, emissions and the 90% round-trip loss are included in reported cost/emissions. Same 12-job queue, clock, deadlines, transfer charges and data treatment. If no feasible route exists, the job is unassigned and not on time; totals cover assigned jobs only, so unassigned work earns no savings claim. Assigned counts include the two continuous services. One simulation replay, not held-out validation, measured savings, a global optimum or a benchmark of named competitors.
Proposed implementation path: Slurm / Kubernetes → ExpertOrbit ← grid / price forecasts; ExpertOrbit ↔ Torus controller → scheduler decision → execution. Demonstrated today: the ExpertOrbit scheduling simulation only. These adapters, forecast feeds, controller calls and execution path are proposed, not connected.
A weight in the objective, not a market price. "Spend less" sets it to $0; "Cut carbon" sets it to $200. Objective = cash + carbon price × tCO₂e.
| Route | Cash | CO₂e | Objective |
|---|
Does this decision survive uncertain California data?
The EIA-930 extract for California (CISO) has large negative cells. The data package documents two treatments: A excludes negative cells (the default, used above); B nets them in. Under B five afternoon slots go negative, which is not physically meaningful. The same job, deadline, carbon price and storage are run under both.
| Treatment | Site | Start | Source | Cash | CO₂e | Objective |
|---|
These are estimates against starting now in Utah, using real historical EIA generation data and stated modeling assumptions. This demonstrates the routing decision, not a measured production deployment.
chosen sitenight at the chosen startdashed line: the move from home
One lever moves the whole decision
The carbon price is a weight in the objective, not a market price. Drag it and the route, start time, cash and emissions update together. When a cleaner route costs more cash, the page says so.
What the chart shows
Every candidate for this job, one point each: a site, a start hour inside the deadline, and an energy source. Left is cheaper in cash, lower is cleaner. The dashed line joins points of equal objective at the current carbon price; the chosen point has the lowest cash plus carbon-weighted emissions. At a $0 carbon price that line is vertical and the choice is cash alone.
Same job, same start, grid only
When the chosen route uses stored energy, this compares it with the identical start on the grid, so the storage effect is isolated.
Against the two existing approaches
Carbon-aware routing and storage scheduling both exist. Here the same job and queue run under each rule with the same model and inputs: routing alone (move or wait, grid only), storage alone (run now in Utah, stored energy when it is cheaper), and both in one decision. Stand-ins for those approach classes inside this simulation, not any named product.
| Rule | This job | Cash | CO₂e | Objective | Queue objective |
|---|
Other scenario inputs
Every job in the queue, routed by the same rule
Cash and estimated emissions are reported separately from the objective that picked each route. The selected job is marked.
| Job | Kind | Power | Hours | Deadline | Decision | Where | When | Cash | kgCO₂e | Objective |
|---|
Storage in Utah, next 48 hours
A feasible dispatch envelope: the hours the model could charge and discharge within capacity, power and round-trip limits, starting empty. It is not the queue's actual used-discharge trace; routes draw from this envelope only when it lowers their objective.
could chargecould dischargegrid hour, bar height is objective per MWhstate of charge, 0 to capacity
What this demonstrates today, and what comes next
Midway through this project we found the Green Software Foundation's Carbon Aware SDK, which already describes choosing when and where to run, including "follow the sun." That made us question the contribution and sharpen the question to the one above. ExpertOrbit does not claim to have invented carbon-aware scheduling or to be the first router.
Carbon-aware routing and storage scheduling both exist. ExpertOrbit's decision is different in one respect: for each job it chooses among moving, waiting and spending stored energy in a single carbon-weighted objective, with stored energy priced at the hour it was charged and accepted only when the full charge-and-discharge trajectory is feasible. The page then shows the same job at the same start on grid alone, so the storage effect is separated from the timing effect. We have not surveyed every product and claim no uniqueness.
Demonstrated today
- One job with a deadline gets a site, a start hour and an energy source: wait, move, or use modeled stored energy in Utah.
- Cash, estimated emissions and the carbon-weighted objective are compared separately against starting now in Utah, and the deadline is checked.
- Grid intensity is estimated from real historical EIA-930 generation by fuel; Utah pricing uses the published Schedule 9 energy charges; everything modeled or assumed is labeled.
- The storage model is a chronological state of charge with declared limits, validated so energy is never spent before it is stored.
Next, with real operating data
- Coordinating the compute scheduler with the site's energy controller: which job stays in Utah, waits, or moves, given its deadline and the site's constraints. This demo explores a simplified version of that and claims nothing more.
- Torus already advertises AI charge and discharge scheduling and forecasting for its storage (Torus Nova, flywheel), so saving stored energy for later is not a new idea on its own, and this model does not optimize how finite stored energy is allocated across jobs. We have not established that Torus lacks the coordination above, and we do not claim that it does.
- Replacing the historical profile with live grid data and forecasts, and the price models with market data.
- Measured outcomes. Nothing on this page is a measured saving, a real GPU availability, or a Torus integration or endorsement.
Method, inputs and assumptions
Everything the router reads, with what is real and what is modeled. Nothing here is hidden; it is folded so the decision comes first.
Read the calculation methodThe rule, and how storage is priced
For a job, each candidate is a site, a start hour within the deadline, and an energy source for each hour (grid, or stored energy in Utah where available). Cash = Σ price × kWh + egress. Emissions = Σ intensity × kWh. Objective = cash + λ × tCO₂e, with λ the carbon price. The router takes the lowest objective; cash and emissions are reported alongside so the tradeoff is visible.
Stored energy is priced once: the charging hour's cash price and intensity divided by the 0.9 round trip. The storage model is chronological: it starts empty, charges and discharges within its power limit, and never spends energy before it has stored it. The router uses stored energy only when it lowers the objective for that hour.
Without storage, Utah competes on its grid alone. In the EIA-930 week behind this page, PacifiCorp East (PACE), the balancing authority for the Utah site, had an estimated generation-based intensity between about 400 gCO₂e/kWh in mid-afternoon and 670 overnight, the highest of the six. Rocky Mountain Power's winter tariff is highest on weekdays from 6 to 9 am and 6 to 10 pm. Torus's Lasso software manages storage built from Spin flywheels and Pulse LFP batteries; the capacity and round trip here are representative assumptions, not Torus specifications, and this page is independent of Torus.
Emissions intensity is estimated from generation by fuel; the full method, column choices and exclusion counts are in METHOD.md, generated by agg3.js from the bundled EIA-930 extract (provenance) into the hourly derived file. Sources: EIA-930 Hourly Electric Grid Monitor, Rocky Mountain Power Utah tariffs (Schedule 9), Open-Meteo, a public GPU cluster trace.
Inputs, and which are real
| Input | Status | Detail |
|---|---|---|
| Generation by fuel per balancing authority | historical | Hourly net generation by fuel for PACE, BPAT, CISO, ERCO, MISO and PJM, Oct 21 to 27, 2026 UTC, as a seven-day historical profile by hour of day. Not a forecast. Blanks stay missing, negative values are excluded and counted per column, storage discharge is not counted as generation, and imports are not traced. A balancing authority's mix is not a city's exact supply. CISO's estimate is sensitive to large negative "Other Fuel Sources" values in the source (about 52 gCO₂e/kWh on average between excluding and netting them), so its rank is uncertain; the other five move by under 1. The timestamped hours are in the hourly derived file and the method in METHOD.md; the raw extract is the bundled CSV from the EIA-930 Hourly Electric Grid Monitor. |
| Emissions intensity | estimated | Estimated generation-based emissions intensity: fuel shares times illustrative lifecycle factors (coal 1000, gas 430, oil 800, nuclear 12, hydro 24, wind 11, solar 45, geothermal 38, other 600 gCO₂e/kWh). The factors are assumptions in the range of published medians; they are not cited per value and not plant-specific. Not EIA carbon data and not a measured saving. |
| Weather per site | stand-in | A clear-sky curve stands in for weather. The "Load live weather" button fetches Open-Meteo's 48-hour forecast when the page is hosted on a normal domain; it then scales each region's solar and wind shares from the weekly average. |
| Utah electricity price | published tariff | Rocky Mountain Power Schedule 9, winter (Oct to May): $0.049417/kWh on-peak, $0.025118/kWh off-peak; weekday peaks 6 to 9 am and 6 to 10 pm. Base high-voltage energy charges only. The $13.75/kW monthly demand charge is not modeled; it depends on the month's peak 15-minute demand, which this hourly data cannot show. |
| Other sites' electricity price | model | Regional base price with a diurnal shape; solar-heavy regions dip at midday. Not market data. |
| Job queue | simulated | Twelve jobs with durations and GPU counts loosely shaped like a public GPU cluster trace (Alibaba PAI). Power at 0.7 kW per GPU. |
| Storage in Utah | assumed | Chronological state of charge. Initial charge 0 MWh (declared). Capacity from the slider, power limit one quarter of capacity per hour (4-hour system), 90% round trip split evenly between charging and discharging. Representative values, not Torus specifications. |
| Carbon price | chosen | A weight, not a market price. Objective = cash + carbon price × tCO₂e. Shown separately from cash and emissions everywhere on this page. |
| Cost to move data | assumed | Flat $/GB from the slider, charged once in cash when a job leaves its home site. |
Mode and timing
Mode: historical snapshot. All sites are compared at the same UTC instants and shown in local time. The result depends on the wall-clock time the page is opened, because the tariff windows and the hour-of-day profile are aligned to now.