TEWCAM prices GPU time by how much heat a GPU throws off per unit of useful work. Efficient, cool-running units cost less; wasteful ones cost more. High-priority tasks get first claim on the efficient units at a discount, and background tasks pay more.
The "thermal-entropy signal" in the proposal works out to energy per unit of compute (watts per TFLOP) at the current load. This calculator prices one example job three ways: a flat hourly rate, the TEWCAM weighting, and plain electricity pass-through plus a capacity fee. Change the inputs and compare.
Example inputs · illustrative GPU specs and prices
That it is a "novel" model. Pricing compute by energy efficiency already exists as power-based colocation billing and per-kWh pass-through; the calculator shows TEWCAM tracks those closely.
That it "decouples pricing from spot-futures dynamics." GPU supply and demand still set the base rate; a weighting on top does not remove them.
That it allows budgeting "without relying on API rate-limits." Providers set rate limits regardless of how they price.
That an "open-provenance ledger" of entropy trajectories enables arbitrage. No provider publishes per-unit thermal telemetry to buyers today.
What to try
Drop load to 20%. Idle power dominates, every GPU looks less efficient, and TEWCAM prices jump even though nothing about the job changed.
Set α to 0. TEWCAM collapses back to the flat rate.
Switch criticality to Background. The same job on the same GPU costs 25% more, which is a subsidy to high-priority users rather than a cost signal.
Raise electricity to $0.30. The pass-through option moves the way TEWCAM claims to, with no new market needed.
For our fleet
The fleet rents VPS servers and pays per API token; it does not buy GPU-hours. The useful version here is tracking cost per completed task for each agent and provider, which needs no new market.