The operator already pays for it. The blind spot is attribution.
A neutral layer that joins compute telemetry to power, cooling and facility infrastructure, so an operator can meter, attribute, price, and plan the physical economics of AI compute per tenant.
Customer: GPU clouds, neoclouds and colocation operators running multiple tenants. Everything below is a working argument for what to build next — not a claim about what already exists.
What we are actually deciding
A thesis is only useful if it changes what gets built. This is the call, the reasoning, and the condition that would reverse it.
Prioritize GridMind for the first paid pilot, conditional on securing one operator who grants read-only telemetry access and names a commercial decision that depends on a better number.
If no operator grants read-only compute and power telemetry within roughly four weeks, the Agent Environment becomes the temporary primary validation track, because it can be tested faster with less infrastructure access.
- The buyer already carries the cost line; there is no need to create a new budget or new demand.
- Value is provable before billing changes: a reconciled cost model is useful as evidence on its own.
- The work integrates with systems operators already run, rather than asking them to adopt a new stack.
- The moat — a normalized economic model and history — compounds with every zone measured.
If the gate is not met, the honest move is to stop or narrow — not to build a broader product to justify the work already spent.
Two theses, one sequence
Both products are incubated by the same lab. They share a way of working, not a codebase, a data plane, or a release cadence.
Read the table as sequencing, not as a verdict on merit. GridMind has the stronger economic case; the Agent Environment has the faster test.
Tenants buy GPU hours. Nobody can price the rest.
The invoice shows compute. The bill shows electricity. Between them sit cooling, rack and facility capacity, network, storage and shared overhead — and in a multi-tenant GPU environment, none of it is cleanly attributable to the tenant that caused it. Operators answer commercial questions with a spreadsheet and a rule of thumb.
Knowing a tenant has 40 GPUs does not tell you what those GPUs cost in power, cooling and shared capacity.
Compute telemetry and facility meters rarely share a clock, a tenant identity, or a unit of account.
Flat GPU pricing hides the cost differences between power zones, cooling headroom and utilization.
Decisions about the next few megawatts are made without a defensible per-tenant cost baseline.
Sources, and what they do not prove
Public evidence can validate a problem and still leave the business case open. Each source below is paired with the claim it cannot support.
Data-center electricity demand is a material, quantified driver of grid demand, which makes power economics an operator problem, not a footnote.
It does not show that any operator will buy a metering layer for tenant-level allocation.
Commercial GPU capacity is being planned at a scale where power and cooling are first-order commercial constraints.
It is a company announcement; it does not describe an unmet tooling requirement.
Cost allocation is a solved, standardized discipline in the Kubernetes layer — and it stops at compute.
It does not cover facility power, cooling or rack-level physical economics.
Scheduling and cluster utilization are already a mature, well-served product category.
It does not answer what a scheduled workload costs physically, or how to bill for it.
Allocation, showback and chargeback are established disciplines with known methods and failure modes.
It does not validate allocation of physical infrastructure, which has different constraints.
Who owns which layer
Positioning is a map of who already owns what. A gap only matters if the customer feels the pain on the other side of it.
What gets built, and what does not
- Read-only first: observe and reconcile before anything is recommended, and long before anything is controlled.
- Every cost line is labelled measured, allocated, or not claimed — with its source, timestamp and confidence.
- Cooling and overhead are apportioned under a rule the operator approves, shown under alternatives.
- Facility-specific allocation is configuration, not a rewrite — the engine is shared, the model is per site.
- Signed agents, encrypted telemetry, tenant isolation, RBAC, audit, and edge operation where the network requires it.
One cluster or zone, one or two tenants, 8–32 GPUs, at least fourteen days of representative load, reconciled against existing meters and current allocation rules — three to four weeks.
- Collectors for existing GPU, workload and tenant telemetry
- At least one layer of power measurement: PDU, rack, UPS or facility meter
- Normalization into tenant, workload, resource, power, cooling and facility lines
- An allocation methodology agreed in writing before any number is produced
- Reconciliation against invoices and meters, with every discrepancy listed
- A cost model for one named commercial decision, with confidence ranges
Who pays, for what
A GPU cloud, neocloud, managed GPU provider or high-density colocation operator running multiple tenants, with a pending decision on pricing, power pass-through or expansion.
- A tenant-level cost view that separates compute from power, cooling and overhead.
- Defensible allocation rules that survive a customer negotiation.
- Evidence for power pass-through, energy-aware pricing or premium tiers.
- Visibility into underutilized capacity and where the next constraint will appear.
- A shared economic model for infrastructure, finance and commercial teams.
- Fixed-fee pilot scoped to one zone, with a written reconciliation report
- Monthly platform fee per monitored cluster or infrastructure zone
- Optional modules: energy-aware billing, power pass-through, capacity planning, optimization
- No transaction take rate; customer contracts and tariffs stay with the operator
- The normalized tenant to workload to compute to power to cooling to cost model
- Facility-specific allocation models and the history behind them
- Deep integrations with GPU, Kubernetes, DCIM, PDU, BMS and meter systems
- Operator workflow lock-in once billing and planning depend on the numbers
What would make this wrong
The next four weeks
A thesis becomes real when a stranger pays for the outcome. These are the steps, the gates, and the conditions under which we stop.
Source inventory, meter boundaries, tenant labels and a written methodology agreed before any number is produced.
01Read-only collection across the zone. No writes, no control, no invoices.
02Compare the model against meters and invoices, and list everything that cannot be explained.
03Model the named commercial decision, state the conditions under which it holds, and get a paid-conversion decision.
04- At least fourteen days of representative load with trustworthy meters
- A named operations or finance owner who signs off on the output
- A meaningful share of consumption reconciled, with the remainder explained
- One commercial decision with a quantified financial or capacity impact
- Agreement to a paid production phase, not just an enthusiastic readout
- No read-only access to both compute telemetry and one layer of power measurement
- No decision is waiting on a better number — the data would be interesting but useless
- Unattributable usage dominates the zone and cannot be reduced
- The operator insists on billing-grade accuracy the instrumentation cannot support
Evidence here is public energy reporting, vendor specifications and one operator scale announcement. It establishes that physical constraints are real and that adjacent categories stop short of tenant-level physical economics. It does not establish that operators will buy — that remains the open question, and the first paid pilot is the test.
Read the argument, then test it with us
Every claim on this page is falsifiable. If you run the infrastructure, or the business, this is where we would rather be corrected than impressed.
RelayForge is a product lab. SentraZero, PowerIQ and the Outbound Engine are case studies, not products.