Kimi K3 Open Weights: Self-Host or Buy the API in 2026?

By the OpenModels team. OpenModels is an open marketplace for LLM tokens and we sell paid access to Kimi K3, so read the buy-versus-build conclusion as interested. Every price below is either Moonshot's own published API rate or a publicly listed GPU rental rate, both checked in July 2026, and the arithmetic is shown so you can rerun it with your own numbers. Nothing here is legal advice; the license summary is a reading of the published text, not a substitute for it. For which model is smarter, see Kimi K3 vs Claude Opus. For K3 against the other Chinese flagship, see Kimi K3 vs GLM-5.2. This post is the one about whether to buy tokens at all.

TL;DR: Should You Self-Host Kimi K3?

Almost certainly not. Moonshot published the full Kimi K3 weights on 2026-07-27, 1.56 TB of them, and that changes less than it sounds. The weights alone consume essentially the entire memory of an 8x NVIDIA B200 node, which rents for $21,600 to $83,200 a month depending on where you rent it. Against Moonshot's $15 per 1M output tokens, one node only breaks even somewhere between 1.44 and 5.54 billion output tokens a month, and you would have to sustain 548 to 2,110 output tokens per second, every second, all month, to get there. That is roughly 29x to 111x a heavy agentic coding workload. The weights being public is a licensing and sovereignty event, not a cost event.

Two things were true before July 27 that are not true now. The weights are downloadable, and there is a license to read. Both of those matter. Neither of them makes running K3 yourself cheaper than buying its tokens.

What Actually Shipped on July 27

Moonshot released the API on 2026-07-16 and the weights eleven days later, one day ahead of the July 27 target published in its own technical blog.

Specs come from the model card on Hugging Face. The download size is from Simon Willison's 2026-07-27 write-up; the model card itself does not state a file size.

This corrects two lines in our earlier posts. Kimi K3 vs GLM-5.2 (2026-07-27) said K3's weights "were not published at its 2026-07-16 API launch, with Moonshot promising a release by late July 2026." They landed the same day that post went out. Chinese vs US AI Models grouped K3 flatly with the open-weight models. It is open-weight now, but under terms materially less permissive than its closest peer: GLM-5.2's model card lists its license as MIT.

"Open Weight" Is Not "Open Source"

Moonshot is careful about this and consistently uses "open weight" rather than "open source." That precision is worth preserving, because the Kimi K3 License is bespoke and carries two commercial conditions that a permissive license like MIT or Apache 2.0 does not. Artificial Analysis labels it Commercial Use Restricted.

The two conditions, as published:

1. Model-as-a-Service revenue threshold. If you operate a Model-as-a-Service business whose aggregate revenue exceeds $20 million over any consecutive twelve months, you must enter a separate agreement with Moonshot before commercial use of the weights.
2. Attribution at scale. Commercial products with more than 100 million monthly active users, or more than $20 million in monthly revenue, must display the model's branding in the user interface.

And the exemptions that matter more than the conditions do:

• Internal use is exempt. If the model and its outputs never reach a third party, neither condition binds you.
• Access through Moonshot's own products or its certified inference partners is exempt. Buying tokens is not the same as licensing weights.

Read plainly, this means the license restricts approximately nobody reading this post. If you are a startup putting K3 behind your own product, you are under both thresholds by orders of magnitude. The clause is aimed at large model-reselling businesses, which is to say at Moonshot's competitors, not at its users.

One clarification is worth making, because it is where the confusion usually lands. The license governs whoever serves the weights, not whoever calls an API. If you buy K3 tokens from any provider, including us, you are not deploying the weights, so these clauses are not yours to satisfy. They are your provider's. The "certified inference partners" exemption describes that provider's relationship with Moonshot, not your usage of the resulting endpoint, and whether any given provider holds that status is a question for that provider. We are not asserting our own status here, and you should treat any vendor that asserts it without documentation the same way.

"Not open source" is not a criticism, and it is not a reason to avoid K3. It is a reason to read the license once if you are building a business that resells model access, and to ignore it otherwise. The practical risk in this license is concentrated almost entirely in one business model.

What It Takes to Serve K3 Yourself

This is where the download stops being interesting.

A Mixture-of-Experts model does not let you load only the active experts. All 896 have to be resident, because routing decides which sixteen fire only after the token arrives. There is no useful disk-offload path at serving latency. So the memory floor is set by the full 1.56 TB, not by the 104B active parameters.

An 8x B200 node carries 1,536 GB of HBM. The weights alone are 1.56 TB. Those two numbers are within a couple of percent of each other, which means a single 8-GPU node is not a serving configuration. It is an arithmetic floor with nothing left over for the KV cache, and the KV cache is what a 1M-token context spends memory on. Published guidance points at 16x H200 (about 2.25 TB across two nodes) for full-context serving, and Moonshot recommends 64 or more accelerators for production.

We are going to price the single node anyway, because it is the most self-host-favorable assumption available, and it still loses. Every number below should be read as a floor that real deployments multiply by two to eight.

The Break-Even: Our Arithmetic, Your Numbers

Three publicly listed B200 rates, spanning neocloud to hyperscaler, at 730 hours a month:

The hyperscaler row is quoted per node (AWS p6.48xlarge on-demand) and divided out to a per-GPU figure; the other two are quoted per GPU and multiplied up. The spread is the first finding. The same eight GPUs cost 3.8x more from a hyperscaler than from a neocloud, which is a wider gap than any model-choice decision you will make this year.

Now convert each to the API spend it would have to displace. K3 output tokens list at $15 per 1M, so:

The arithmetic: $21,608 divided by $15 per 1M output tokens is 1,440M tokens. Spread across 730 hours (2,628,000 seconds) that is 548 output tokens per second in aggregate. A well-batched node can reach that rate; the demanding part is holding it every hour of the month, because the table assumes zero idle time and the break-even degrades directly with utilization.

We priced this on output tokens only, which is deliberately the most generous framing for self-hosting. Output is the expensive token, so counting the bill in output alone produces the lowest token volume that clears break-even. Mix input in and the volume you need goes up.

What that volume looks like in practice

In Kimi K3 vs GLM-5.2 we modelled a generation-heavy agentic coding month at 50M output tokens, which bills at $780 on K3. To reach the cheapest break-even above, you would need 28.8x that workload. To beat the hyperscaler rate, 111x.

If you are running 29 simultaneous copies of a heavy agentic coding operation, you are not reading a blog post to decide this. Everyone else is comparing a $780 bill against a $21,608 one.

Three Things Self-Hosting Does Not Buy You

Cached input. Moonshot prices cache-hit input at $0.30 per 1M, a 10x discount off the $3 rate. On read-heavy workloads that lever is worth more than the model choice, as we showed in the K3-versus-GLM cache tables. Self-host and you inherit the obligation to build, tune, and evict that cache yourself. It is not free and it is not automatic. Buy tokens and it is a request parameter.

Utilization. The break-even table assumes 100% utilization, which no real deployment achieves. A node at 40% utilization has 2.5x the effective per-token cost. The API bills only tokens you actually consume, so its utilization is definitionally perfect.

Substitution. Self-hosting one model commits your capital to that model. K3 is four weeks old and was preceded by GLM-5.2 by four weeks. On a token API, replacing it is a model-ID change, and a router can even do it per request. On owned hardware it is a procurement cycle.

When Self-Hosting Actually Is Right

The break-even is a cost argument, and cost is not the only reason to run your own weights. Self-hosting K3 is the correct call when:

• Data residency or air-gap requirements make sending tokens to any third party a non-starter. This is the strongest case by a wide margin, and it is a compliance decision, not a finance one. Note that internal-use deployments are also the ones the license exempts outright.
• You are already running the fleet. If you own idle B200 capacity, the marginal cost is not $21,608, and the arithmetic above does not describe you.
• You need determinism across model versions and cannot accept a provider deprecating or silently updating a route.
• Your volume genuinely clears 2 billion output tokens a month and stays there. At that point negotiate with Moonshot directly before you buy GPUs; volume pricing will likely beat both options.

Everything else is a research budget, and that is a legitimate thing to spend money on. Just do not file it under cost savings.

If You Are Buying Tokens Instead

K3 runs on the standard OpenAI-compatible shape, so there is nothing special to integrate. On OpenModels the base URL is https://api.getopenmodels.com/v1, the model ID is kimi-k3, and the same API key and credit balance covers every other model in the catalog, which matters given how fast this class of model is turning over. Copy the exact current model ID from the live listing rather than from this post: near-identical route names can bill differently, and the catalog moves faster than we republish.

Marketplace prices are directional. Our listed K3 route price is a "from" figure representing the lowest available verified route, and it moves. It is not the basis for any arithmetic in this post, and it should not be the basis for your budget either. Every number above uses Moonshot's own list price. Check the live model page and your own dashboard before committing spend.

FAQ

Can I download the Kimi K3 weights?

Yes. Moonshot published the full Kimi K3 weights on 2026-07-27 on Hugging Face, one day ahead of its stated July 27 target. The download is about 1.56 TB in MXFP4 format. Downloading is governed by the Kimi K3 License, which is not an OSI-approved open-source license.

What hardware do you need to run Kimi K3 yourself?

At minimum a datacenter GPU cluster. All 896 experts must be resident in memory because routing happens per token, so the 1.56 TB of weights sets the floor rather than the 104B active parameters. An 8x B200 node holds 1,536 GB, which the weights alone essentially fill, leaving nothing for the KV cache. Published guidance points to 16x H200 for full 1M-token context, and Moonshot recommends 64 or more accelerators for production. Consumer hardware is not an option at any quantization.

Is it cheaper to self-host Kimi K3 or pay for the API?

The API, for almost everyone. One 8x B200 node rents for $21,608 to $83,169 a month at publicly listed July 2026 rates. Against Moonshot's $15 per 1M output tokens, break-even falls between 1.44 and 5.54 billion output tokens a month, which requires sustaining 548 to 2,110 output tokens per second continuously. That is roughly 29x to 111x a heavy agentic coding workload, and it assumes 100% utilization on a single node that cannot actually serve full context.

Does the Kimi K3 license allow commercial use?

Yes, with two conditions. A Model-as-a-Service business whose revenue exceeds $20 million over any consecutive twelve months must sign a separate agreement with Moonshot first. A commercial product with more than 100 million monthly active users or more than $20 million in monthly revenue must display the model's branding in its interface. Internal use where the model and its outputs never reach a third party is exempt from both.

Who does the Kimi K3 license actually restrict?

Large model-reselling businesses, primarily. Both thresholds sit at a scale most teams never approach, and internal deployments are exempt outright. Access through Moonshot's official products or its certified inference partners is also exempt, so buying tokens from a provider is a different question from licensing weights. If you resell model access at scale, read the license text directly; otherwise it is unlikely to bind you.

Where can I use Kimi K3 without hosting it myself?

Through Moonshot's own API or any marketplace carrying the model. On OpenModels it is the kimi-k3 model ID against https://api.getopenmodels.com/v1 on the OpenAI-compatible chat-completions shape, using the same key and credit balance as the rest of the catalog. Copy the exact current model ID from the live listing, because near-identical route names can bill differently, and route prices on any marketplace are starting figures that move.

The Bottom Line

The Kimi K3 weights release is real news and it is being read as the wrong kind of news. It does not lower anyone's inference bill. What it does is give regulated and air-gapped teams a deployment path they did not have on 2026-07-26, and it puts a license on the table that is worth exactly one careful read if you resell model access and worth skipping if you do not.

For everyone else the arithmetic has not moved. A heavy agentic coding month costs $780 in K3 tokens. The cheapest node that could serve those tokens costs $21,608, and it cannot serve full context. Buy the tokens, spend the difference on the cache-hit rate, and revisit when your output volume has a "billion" in it.