Wait... How is Kimi K3 (“Software” ) Already Sold Out??

A lot has happened in the last week. But one thing stuck out to me the most: a screenshot of the pricing page for Kimi K3, Moonshot AI’s new flagship model, with every subscription tier ($15, $31, $79, $159 per month) greyed out. It’s supposed to be a software application, and open source/weights but… it’s…

Sold out.

Software usually doesn’t sell out, so it was kind of funny to see that. A “sold out” button on a software product jumped out to me as super weird.

But obviously, it’s only weird until you realize the binding constraint is physical. Moonshot’s own statement removed any doubt: demand for K3 in the first 48 hours approached the ceiling of their GPU capacity, so they paused new subscriptions to protect service for existing customers, and will release new slots “in batches” as they add compute. They also announced they will split their membership into two products: one for chat and office work, one for coding workflows to “more precisely allocate computing power.”

As an electricity person, something important stands out. It’s kind of like a supplier hit a capacity constraint, curtailed new load to protect firm customers, queued interconnection requests for batch release, and redesigned its tariff structure to manage allocation across customer classes. Weird behavior for software.

Through the CHR Lens

The Compute Heat Rate framework1 asks one question of every AI workload: how many dollars of token revenue does it generate per megawatt-hour it consumes? That number (the workload’s tolerance for electricity cost) determines who builds, who bids, and, crucially, who curtails first when power gets scarce.

So where does K3 sit? Its API prices are published: $3 per million input tokens, $15 per million output. Run those prices through the same revenue-per-server accounting used across the CHR index, at identical hardware and throughput assumptions, and K3 is right smack in the middle of the CHR tier distribution as a mid-tier product. Which makes total sense.

K3’s CHR is still over $5,000 per MWh. Which is still eye-wateringly high compared to current energy prices. If those data centers could simply pay more for electricity, to get more of it, and thus sell more K3 subscriptions, I’m sure they would. And the CHR tells you just how much more they would pay.

So actually, “sold out” is exactly what the CHR framework predicts. Capacity bound at an aggressively priced model. Price below your competition and demand will find your capacity ceiling almost immediately; K3 found it in 48 hours, so they have to ration customers when compute is the scarce input.

The Giant Open-Source Misnomer

There’s a lot of talk about the potential for open source and/or open weight models breaking AI data center economics meaningfully. There’s fear that this commoditizes to zero and there won’t be revenue to support facilities long-term. People are afraid open source/open weights could collapse the economics like it can in actual software, if open source is better than closed, and free.

But that is a total misnomer in this market, and it’s pretty obvious why. At least for now, AI can’t be free like software. The GPUs and the energy are the binding constraints, and they are physical. K3 couldn’t just copy its software more times to sell more units, it’s basically a physical utility that has finite supply. Even if or when K3 or other open weights are available for free, someone has to build the data center, buy the GPUs and run them in the physical world, and clearly the demand to pay for that as a service is there and seemingly insatiable.

As long as that continues, the CHR will stay high even for open source models. In a world of AI abundance, electrons continue to be scarce.

---

Methodology: revenue-per-server comparisons use identical hardware, throughput, and token-mix assumptions across models per the CHR index conventions; K3 API pricing verified on Moonshot’s live platform documentation. Tier tolerance references are from the published Q2 2026 CHR Index at computeheatrate.com/chr-index.

Hans Royal is the originator of the Compute Heat Rate (CHR) framework. All views are his own and do not represent those of any employer or affiliated organization.