Skip to article
Devlog 002 / 6 August 2026 / Marcin “HCK” Firmuga

The Best GPU Can Still Be a Bad Purchase

Scaling Laws treats AI hardware as a dated asset: it loses value with time, gets hit again by successor generations and can bottleneck on the rest of the server.

The hardware screen cannot be a shopping list

A normal upgrade menu asks one question: which item has the biggest number? That would kill the hardware side of Scaling Laws. The interesting decision is not whether the next accelerator is faster. It usually is. The decision is whether buying it now is better than renting for six more weeks and waiting for the generation behind it.

The underlying hardware economy is already built around that timing problem. The player-facing purchase and configuration flow is the active work now.

Depreciation happens twice

Owned accelerators lose resale value just by getting older. Then a meaningful successor can apply another phased hit. Those are deliberately separate pressures. A fleet can be perfectly functional and still become a bad place to keep capital.

That means the newest hardware is not automatically the safest choice either. Buying on launch day can mean high price, weak availability and zero information about the next price move. Waiting has an opportunity cost. Buying has a balance-sheet cost.

Current simulation rule

Owned accelerators lose value through calendar age and again when meaningful successor generations arrive. The purchase UI exposing that risk is still in active development.

A GPU is not a server

The compute pool also checks whether the rest of the machine can feed the accelerators. Host CPU, node memory and fabric all matter. If one of them is badly undersized, the owned cluster can run at a fraction of its nominal rating.

I want the purchase UI to make that obvious without turning into a motherboard manual. The player should understand “my accelerators are starved” before they need to understand every bandwidth number behind the penalty.

Cloud is expensive for a reason

Rented compute avoids most of that configuration risk. Capacity arrives provisioned and the player pays for petaflops instead of assembling a rack. That flexibility is why it costs more. It is also why cloud can be the correct answer even when owned compute is cheaper per FLOP on paper.

The game needs all three steps — cloud, colocation and eventually an owned datacenter — because each one moves risk from the provider back onto the company.

The feature I am building now

The next UI work is not adding another accelerator card. It is the actual decision surface: rent or buy, inspect launch timing, configure the supporting parts, see the expected usable compute and understand the resale risk before committing the cash.

If the player can still solve that screen by sorting one column from high to low, I have not finished it.

Current status

This note describes work visible in the current project or simulation foundation. Planned pieces remain labelled on the public roadmap instead of being written here as if they already shipped.