Power-aware scheduler for AI clusters on variable energy, turning stranded megawatts into sellable GPU capacity.

1. Power availability is now explicitly identified as the bottleneck for larger AI models and new data centers.
2. Offshore data-center infrastructure is moving from thought experiment to funded deployment, creating a new class of operators with novel scheduling needs.
3. Renewable and ocean-energy companies are now designing directly for AI compute demand instead of only selling electricity.
4. Lead investors are financing alternative AI-power architectures, which increases the number of sites that need software to commercialize variable energy.

Catalyst. Panthalassa's $140 million funding round shows that AI operators are actively moving compute toward nontraditional power sources because power availability has become the limiting factor.

The product sits above Slurm, Kubernetes, or proprietary cluster managers and turns real-time power availability into sellable compute tiers. It forecasts how many GPU-hours a site can safely promise, gates premium workloads from flex workloads, and reprices queue slots as energy conditions change. For operators, it converts stranded or intermittent power into a new revenue line without risking core SLAs. For customers, it exposes cheaper flex capacity with transparent completion windows and energy provenance. Over time, the company can build the benchmark dataset for how variable-power sites actually translate megawatts into AI throughput.

What's different. Existing cluster schedulers assume power is a static constraint, while utility software assumes compute demand is someone else's problem. This company is built around the translation layer between volatile megawatts and contractual GPU products. The moat comes from site-level data on how power variability, queue mix, and hardware behavior interact, which improves forecasting, pricing, and SLA design over time. That dataset becomes valuable not just to operators but to financiers, insurers, and customers evaluating nontraditional AI capacity.

Jobs to be done

flowchart LR
  Buyer[GPU cloud operator] --> Pain[Variable power makes capacity hard to sell]
  Pain --> Product[Power-aware GPU scheduler]
  Product --> Outcome[More sellable utilization without SLA failures]

Executive takeaways

• The beachhead is real but narrow: public energy-first AI buildouts now span fresh Panthalassa funding and site announcements that jumped from tens of MW to 166 MW and 900 MW-class projects, but the first buyer set is still a small club of neoclouds and power-backed operators.
• The strongest wedge is commercialization, not scheduling alone: hyperscaler spot/preemptible products prove demand for discounted flexible compute, while generic schedulers still treat power as a static constraint rather than a sellable product attribute.
• Incumbent risk is feature absorption by cloud and scheduler vendors, so the startup must own live power forecasting, job admission, and SLA packaging specific to variable-energy sites rather than compete as yet another cluster dashboard.
• Public GPU pricing shows that even a thin software take-rate can matter economically because each MW of AI capacity can produce high revenue density before any flex-capacity uplift.
• Adoption friction is operational rather than conceptual: infra teams already buy managed Slurm, Kubernetes, and cluster tooling, but they are cautious about inserting a new control layer into the critical path.
• Why now is stronger than the original offshore narrative alone: batteries, onsite generation, and renewable-curtailment strategies are becoming part of AI infrastructure design, expanding the number of sites that need a power-aware control plane.

Market definition

The market is software that turns constrained or variable-power AI clusters into sellable compute products for independent GPU clouds, renewable-backed data-center developers, and other operators who cannot assume flat grid-like capacity. The first buyer geography is North America, where public spot/preemptible compute markets are mature and many visible energy-first AI projects are being announced. Included are live power forecasting, admission control, flex-tier packaging, and queue orchestration above existing cluster managers. Excluded are generic schedulers, general DCIM/energy-management tools, retail GPU brokers, and vertically integrated clouds where the operator internalizes the problem instead of selling neutral control software. [3][4][6][8][10][12][22][24][27]

Customer and buyer

Primary users are capacity-engineering and cluster-operations teams who must decide which jobs can be promised under a non-flat power envelope. The economic buyer is typically the COO, VP Infrastructure, or GM of capacity at a GPU cloud or power-backed compute operator. Their urgent jobs are to protect premium SLAs, monetize flexible workloads, and stop sales teams from overcommitting a site whose available power, cooling, or energization schedule is still changing. Current alternatives are generic Slurm/Kubernetes-based queues, manual throttling, and spreadsheet capacity planning. [3][4][6][8][9][10][11][12][14][17][19][21]

Buying triggers

• A new site or expansion phase comes online with non-flat power delivery or staged energization, and the operator needs a credible way to contract capacity before utilization is stable. [1][22][25]
• The sales team wants to offer discounted flex capacity analogous to spot/preemptible compute rather than leave intermittent capacity idle. [3][6][8][20]
• Existing Slurm or Kubernetes queues stop being enough because the operator now needs policy around who gets scarce capacity, when preemption is acceptable, and how to expose those tradeoffs commercially. [10][11][12][14][17][19]

Willingness to pay

Willingness to pay is supported indirectly by existing spend on flexible compute and cluster operations. AWS and Google market interruptible capacity as 90%+ discounts to on-demand pricing, while Lambda and Crusoe publish H100/H200 pricing in the roughly $3.9 to $6.2 per GPU-hour range. That means even modest improvements in sellable utilization or safer flex-capacity packaging can justify meaningful software spend without requiring a new budget category. [3][6][16][20][32] [3][6][16][20][32]

Category dynamics

Growth signal Public energy-first AI projects stepped from 83-166 MW phases to 900 MW campus announcements in 2025-26.

Validation signals

• Panthalassa's $140M round shows investors will finance nontraditional AI-power architectures rather than assume all future capacity sits on conventional grid-backed campuses.
• Crusoe announced a new 900 MW AI campus for Microsoft and says the broader Abilene site is projected to reach 2.1 GW, signaling campus-scale demand for power-shaped AI infrastructure.
• Crusoe and Form Energy announced 12 GWh of iron-air batteries for AI data centers, indicating power-shaping is moving into the operating design of new sites.
• Soluna explicitly pitches AI loads as flexible demand and says Project Kati is a 166 MW wind-powered data center with an 83 MW first phase.
• Lambda and Runpod both expose managed Slurm / cluster offerings, which confirms operators already buy higher-level control and operational tooling on top of raw GPUs.
• AWS, Google, and Azure all market interruptible capacity products, proving demand for lower-cost compute with weaker delivery guarantees.

Regulatory & technical constraints

• Data-center energy intensity and large-load planning remain real constraints, so any commercialization layer must map promised compute to actual site energy and cooling limits.
• Flexible-capacity products only work for workloads tolerant of interruption, preemption, or completion windows.
• Integration risk is high because the product must ingest or influence Slurm, Kubernetes, or managed-cluster control planes without creating instability.
• Forecast quality depends on access to live power, cooling, and queue telemetry that often lives in separate operational systems.
• Security and operator trust matter because the software touches scheduling policy, capacity allocation, and potentially customer-facing commitments.

Competition comes from four directions: cloud platforms that already sell interruptible or reserved capacity, open-source schedulers that own job placement, neoclouds that bundle operations with capacity sales, and vertically integrated energy-first operators that solve the problem inside their own stack. The startup should not try to replace Slurm or become another GPU broker; it should own the translation layer between volatile megawatts and contractual GPU products. [3][4][8][10][11][16][18][20][21][29][35]

Why incumbents do not win by default

• Cloud platforms. AWS, Google Cloud, and Azure already train buyers to accept spot, preemptible, and reserved GPU capacity, but their products are tied to their own infrastructure and do not optimize around site-specific power envelopes, phased energization, or neutral multi-site commercialization.
• Open-source schedulers. Slurm, Kueue, and Kubernetes handle quotas, preemption, queue fairness, and job placement, but they do not natively convert changing power availability into product tiers, delivery windows, or revenue-aware admission rules.
• Neocloud operators. Lambda and Runpod sell managed clusters and capacity quickly, yet their economic center is selling standard compute inventory; a neutral control plane can still win at sites that need commercialization software before they look like a conventional cloud region.
• Vertically integrated power-first AI clouds. Crusoe is the strongest strategic substitute because it combines energy, data centers, cloud pricing, and an operations platform, but that vertical model does not win by default when operators want the software capability without outsourcing the entire infrastructure stack.
• In-house operations. Many operators can stitch together scheduler controls, spreadsheets, and manual throttling, but the operational burden of forecasting, packaging, and proving flexible capacity is precisely where specialist software should add value.

This company should sell a power-aware commercialization layer to North American GPU cloud operators bringing 10-50 MW variable-power clusters online and needing to contract capacity before site performance is stable. The initial product is not a new scheduler; it is a read-only forecasting, flex-queue, and SLA-packaging layer above Slurm, Kubernetes, or managed cluster control planes. The first customer should be a Series A or B neocloud or power-backed operator launching a behind-the-meter, battery-backed, curtailed-renewable, or offshore-adjacent site and trying to protect premium queues while monetizing cheaper flexible training capacity. The buying trigger is a site launch or expansion with staged energization or non-flat power delivery, because that is when spreadsheet planning and generic schedulers stop being commercially sufficient. Research supports a real wedge and clear willingness to pay, but the near-term market is still narrow at roughly $30.0M SAM, so expansion into additional power-constrained AI infrastructure categories is required for venture scale. Product and GTM therefore need to sequence from read-only proof, to flex-capacity packaging, to admission control only after the company has site-level forecasting data and operator trust. The biggest open market risk is volume: the inputs do not establish how many non-hyperscaler variable-power AI sites will be commercially live in the next 24 months, so early success should be judged by paid pilots and managed MW rather than broad logo count.

Problem

• Independent GPU clouds and energy-backed AI sites increasingly have usable megawatts that are intermittent, staged, or operationally unusual, but they still need to sell compute with credible delivery commitments.
• Generic schedulers and manual capacity planning allocate jobs, but they do not convert changing power envelopes into sellable product tiers, pricing, and SLA rules, so operators either idle GPUs, overconstrain sales, or risk missed commitments.

Solution

• Provide a control layer above existing cluster managers that forecasts available GPU-hours from live power and site telemetry, packages premium and flex capacity tiers, and recommends which workloads fit the current envelope.
• Start with read-only forecasting, flex-queue creation, and commercial policy tooling, then graduate to automated admission control once operators trust the forecasts and exception handling.

Why we win

• The beachhead pain is tied to a specific trigger, buyer, and workflow: new variable-power sites need a way to contract capacity safely before utilization is stable.
• Incumbent schedulers own queue mechanics, and clouds own their own spot products, but neither gives third-party operators a neutral layer that translates site-specific power volatility into contractual GPU products.
• Early deployments can compound a proprietary dataset linking power variability, queue mix, and delivered GPU-hours, which improves forecasting, pricing, and SLA design over time.

Milestones

flowchart LR
  Wedge[Variable-power site launch wedge] --> MVP[Read-only forecasting and flex-queue MVP]
  MVP --> Proof[Forecast accuracy utilization lift first paid pilot]
  Proof --> Expansion[Admission control multi-site expansion benchmarking]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 5-10 non-hyperscaler variable-power AI sites in the target geography will be commercially relevant buyers within the next 24 months.
• Operators will pay for a read-only forecasting and flex-capacity layer before demanding full scheduler replacement or full in-house builds.
• One or more early workload classes such as batch training or offline inference will accept completion windows large enough to create repeatable flex demand.
• The platform can improve sellable utilization or commitment confidence enough to justify roughly $60k-$70k per MW-year pricing.
• Early deployments will generate forecasting and commercialization data that meaningfully outperform manual planning and generic scheduler rules over time.

Open diligence questions

• How many live or funded sites in the next 24 months actually match the beachhead profile and third-party software buying model?
• What quantitative proof would make an infra leader trust this product in overlay mode, and later in admission control?
• Why will Crusoe-like vertical providers or in-house scheduler extensions not win the first deal by default?
• Which workload types create the highest early flex fill rate without unacceptable customer support burden?
• Does pricing by managed MW map to how buyers budget, or will they insist on pure usage pricing or bundled services?

Model sanity

• Revenue engine. Base-case growth comes from scaling from 2 to 8 active operators at about 10 managed MW each and roughly $660K blended annual revenue per operator.
• Must go right. The first paid pilots have to convert within about two quarters so the company reaches 4 production customers and ~40 MW under management by the end of Y2.
• Model breaks if. If the beachhead pipeline only supports 6 active operators or gross margin stays in the high-60s, downside cash falls close to the floor before the seed milestone is proven.
• Next-round proof. A seed round is justified by 4 production customers, a guarded admission-control module in market, and at least one multi-site expansion reference.

Scenarios

Sensitivity

flowchart LR
  TargetAccounts --> PaidPilots
  PaidPilots --> ManagedMW
  ManagedMW --> ProductionCustomers
  ProductionCustomers --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

Flags: The initial SAM is still narrow, so the base case depends on winning 8 of a small number of North American variable-power operator deployments by Q4Y3. · Revenue is modeled as a blended per-operator ARPU and does not separately show subscription, usage, and implementation mix by contract. · Cash collection is assumed in-period even though infrastructure operators may still pay on 45–60 day terms, which would reduce the base-case cash cushion. · Holding 70% gross margin from Y2 onward assumes site integrations become meaningfully repeatable instead of remaining service-heavy.

• Market still early. There may be too few variable-power AI clusters in production this year to support fast initial ARR growth. Mitigation: Start with any behind-the-meter or curtailed-power GPU sites, not only offshore deployments, while keeping the same product architecture.
• Integration friction. Infrastructure teams may resist inserting a new control layer into mission-critical cluster operations. Mitigation: Launch as a read-only forecasting and flex-queue product first, then earn trust before taking over admission control.
• Customers may prefer fixed-power contracts. Enterprise buyers could avoid flex capacity if the operational tradeoff feels too complex. Mitigation: Focus early sales on batch training, backfills, and offline inference workloads where price savings clearly outweigh timing flexibility.