Moonshot AI is about to hand you the largest open-weight model ever built — and the first thing to understand is that "open" is a licensing word, not a cost word. Kimi K3, the 2.8-trillion-parameter model that went live via API on July 16, 2026, has its full open weights scheduled to drop by July 27. The moment they do, every founder who has been renting frontier intelligence will ask the same question: should I run this myself?

Here is the short, skimmable answer, up front: for a team of one, rent the API — self-host only when the reason is control, not cost. The weights alone are about 1.4TB, a realistic deployment needs 16×H200 or more, and the API costs less than the electricity bill on that cluster unless you are pushing enormous, sustained volume. The rest of this piece is the math behind that sentence.

What Kimi K3 actually is#

K3 is a mixture-of-experts model with 2.8 trillion total parameters that activates 16 of 896 experts per token. It is natively multimodal, ships a 1-million-token context window, and runs an always-on "thinking" mode. Moonshot released it hosted-first on July 16 and committed to open weights by July 27 — which is what makes the parameter count historic: nothing this large has ever been released with open weights.

It is not a toy. K3 took the number-one spot in the Frontend Code Arena at 1,679 points, passing Claude Fable 5 (1,631), GPT-5.6 Sol (1,618), and GLM-5.2 (1,587). On the broader Artificial Analysis Intelligence Index it scores 57 and ranks fourth of 189 models, on par with Claude Opus 4.8 and GPT-5.5. So the question isn't whether it's worth building on — it is. The question is how you consume it.

The self-host reality: ~1.4TB of weights#

The headline number that kills most solo self-hosting dreams is memory. In MXFP4 — a 4-bit floating-point format with per-block scaling, supported natively on NVIDIA Blackwell and AMD MI400 — the weights compress to roughly 1.4TB, down from about 5.6TB in FP16. That's an impressive reduction, and it's still enormous.

Do the arithmetic on where 1.4TB fits:

This is a datacenter model. There is no "run it on a spare GPU over the weekend" path.

The cost math a founder should actually run#

Rented, K3 is $3 per million input tokens and $15 per million output tokens. Self-hosted, you pay for a continuously-running multi-node GPU cluster whether you send one token or a billion.

The break-even is stark. A 16×H200 cluster running around the clock lands well into five figures a month. As a back-of-envelope line: roughly $15,000 of API spend buys about a billion output tokens. So unless you are sustaining on the order of a billion output tokens every month — enough to keep that cluster near saturation — the API is both cheaper and infinitely less work. Below that line, self-hosting means paying for idle silicon.

For almost every solo founder, CEO, or early-path builder, you are nowhere near that line. Rent it.

When self-host actually wins#

Cost is the wrong axis for the small team. The right one is control, and there are three honest reasons to own the weights:

  1. Data residency / compliance. If a contract or regulator forbids sending customer data to a third-party endpoint, inference in your own VPC isn't a cost decision — it's the only compliant option.
  2. Version permanence. A hosted endpoint can be changed or deprecated under you. Open weights you've downloaded are pinned forever; your July 2026 behavior is reproducible in 2028.
  3. Private fine-tuning. If your moat is a model tuned on proprietary data, you need the weights. The API can't give you that.

None of these are about beating the sticker price. If your reason for self-hosting is "it'll be cheaper," re-run the math above — it won't be, not at your volume.

The move this week#

Treat July 27 as an availability event, not an action item. The weights dropping means K3 becomes a model you could own — most of you shouldn't. Wire up the API, ship, and measure your real token volume for a month. If it climbs toward a billion output tokens, or a compliance requirement lands, revisit self-hosting with actual numbers in hand. Until then, the boring answer is the correct one: rent the frontier, own your product.

For the adjacent decision — which open-weight model to bet on as China's labs ship in a fortnight — see Qwen 3.8 Max vs Kimi K3. And if the workload you're sizing is agent code execution rather than raw inference, the sandbox economics run the same rent-vs-own way in which agent sandbox to use in 2026.