Originally published at heycc.cn. This is a mirrored copy — the canonical version is kept up to date at the source.

Kimi K3 and Qwen 3.8 "Open Weights": What Was Actually Released by 2026-07-20

Here is the claim this piece defends, and it is one a lot of competent engineers will push back on: as of 2026-07-20, neither Kimi K3 nor Qwen 3.8 is an open-weight model, and the "largest open-weight model ever released" news cycle describes a file that is not yet public anywhere. Not gated. Not staged. Not "rolling out to partners." Nothing public exists: no resolvable repository, no shard, no readable config.json, no LICENSE text. What shipped is an API, a price list, a marketing page, and a promise with a date on it.

That wording matters, and the article will hold itself to it. You cannot prove a private repository does not exist from the outside. You can prove that nothing public exists, and the difference between those two statements is the whole methodological point below.

If you disagree, good, because the disagreement is testable in under sixty seconds and this article shows you exactly how. The check costs one HTTP request. The reason nobody ran it is that the headline already sounded like a fact.

The second, sharper claim: the word "released" has quietly been redefined by AI coverage to mean "announced with benchmark numbers attached." That redefinition changes procurement decisions, it changes what teams put in architecture docs, and it makes a permissive-licence promise indistinguishable from a permissive licence.

Shelf life. This claim is explicitly dated. Moonshot has committed to publishing K3 weights by 2026-07-27. On or after 27 July 2026, the headline claim in this article expires. Re-run Probe 2 (below) against author=moonshotai before citing it. A dated update block sits at the foot of the article.

The one-minute verification, with real output

Hugging Face exposes an unauthenticated JSON API at huggingface.co/api/models. No token, no account, no web UI. Three requests settle any open-weight claim.

Tier: firsthand. Every command in this section was run on 2026-07-20 and every output block is literal, unedited API response text.

Probe 1: does the repository resolve?

for r in moonshotai/Kimi-K3 moonshotai/Kimi-K3-Instruct \
         Qwen/Qwen3.8 Qwen/Qwen3.8-Max-Preview \
         moonshotai/Kimi-K2.7-Code; do
  printf "%-35s %s\n" "$r" \
    "$(curl -s -o /dev/null -w '%{http_code}' https://huggingface.co/api/models/$r)"
done

moonshotai/Kimi-K3                  401
moonshotai/Kimi-K3-Instruct         401
Qwen/Qwen3.8                        401
Qwen/Qwen3.8-Max-Preview            401
moonshotai/Kimi-K2.7-Code           200

PowerShell equivalent, for the large share of readers who are not on bash:

'moonshotai/Kimi-K3','Qwen/Qwen3.8','moonshotai/Kimi-K2.7-Code' | ForEach-Object {
  try { $c = (Invoke-WebRequest "https://huggingface.co/api/models/$_").StatusCode }
  catch { $c = $_.Exception.Response.StatusCode.value__ }
  "{0,-32} {1}" -f $_, $c
}

And if you have neither shell handy, paste https://huggingface.co/api/models/moonshotai/Kimi-K3 into a browser address bar. Same endpoint, same answer.

The control line matters more than the failures. Kimi-K2.7-Code returns 200, which proves the probe works and that Moonshot's org is reachable. Everything K3 returns 401.

The 401 caveat, demonstrated rather than asserted

People get this wrong constantly, and the fix is a two-line experiment rather than a rule you have to take on faith. Ask the Hub for a repository name that certainly does not exist, and compare the response body to K3's:

curl -s https://huggingface.co/api/models/moonshotai/Kimi-K3
curl -s https://huggingface.co/api/models/moonshotai/definitely-not-a-real-repo-zzz9

{"error":"Invalid username or password."}
{"error":"Invalid username or password."}

Both 401. Byte-identical bodies. A nonexistent repo and a private repo are indistinguishable to an unauthenticated caller, by design, because leaking the difference would let anyone enumerate private repository names. So a 401 tells you "there is nothing here you can download" and refuses to tell you which of the two it is. That ambiguity is why a 401 can never be spun as evidence of a staged rollout, and equally why it is not proof of nonexistence. It is the absence of a signal.

Which means Probe 1 alone does not support the thesis. Probe 2 does.

Probe 2: what is actually the newest thing each org published?

curl -s "https://huggingface.co/api/models?author=moonshotai&sort=lastModified&direction=-1&limit=5" \
  | tr ',' '\n' | grep -E '"(id|lastModified|downloads)"'

"id":"moonshotai/Kimi-K2.7-Code"
"lastModified":"2026-06-15T07:49:29.000Z"
"downloads":749596
"id":"moonshotai/Kimi-K2.6"
"lastModified":"2026-05-19T09:01:54.000Z"
"downloads":1262970
"id":"moonshotai/Kimi-K2.5"
"lastModified":"2026-04-30T03:56:40.000Z"
"downloads":1075380
"id":"moonshotai/Kimi-K2-Instruct"
"lastModified":"2026-04-23T02:08:36.000Z"
"downloads":219113
"id":"moonshotai/Kimi-VL-A3B-Thinking-2506"
"lastModified":"2026-01-30T04:53:11.000Z"
"downloads":5487

The newest published Moonshot model is from 15 June 2026, a month before the K3 announcement. Same probe, author=Qwen, same literal output:

"id":"Qwen/Qwen3-ForcedAligner-0.6B-hf"
"lastModified":"2026-06-26T08:42:38.000Z"
"downloads":13076
"id":"Qwen/Qwen3-ASR-0.6B-hf"
"lastModified":"2026-06-26T08:39:37.000Z"
"downloads":87177
"id":"Qwen/Qwen3-ASR-1.7B-hf"
"lastModified":"2026-06-26T08:36:05.000Z"
"downloads":45832
"id":"Qwen/Qwen-AgentWorld-35B-A3B"
"lastModified":"2026-06-25T07:24:16.000Z"
"downloads":104365
"id":"Qwen/Qwen-Image-Bench"
"lastModified":"2026-05-28T08:07:27.000Z"
"downloads":13710

Three sub-2B speech models from 26 June, one 35B agent model from 25 June. Nothing from a 3.8 family, nothing above a trillion parameters, nothing at all since 26 June.

This is the probe the whole argument rests on, because it cannot be gamed by guessing repo names. Sorted by lastModified descending, it is the org's own publication log for public artefacts, and no amount of marketing changes what appears in it.

Now use those download counts, because they are the adoption baseline that makes the fake repo later in this article legible. Kimi-K2.7-Code accumulated 749,596 downloads in roughly five weeks of public life. Kimi-K2.6 sits at 1,262,970 across nine weeks. A genuine Moonshot weight release, on this org, converts to on the order of 10⁵ to 10⁶ downloads inside its first two months. That is the curve. Hold it against zero.

Probe 3: site-wide search, so you catch mirrors and fakes

curl -s "https://huggingface.co/api/models?search=Qwen3.8&limit=10"

[]

Empty array. Zero repositories of any owner anywhere on the Hub with that string in the name.

search=Kimi-K3 is more interesting, because it returns exactly two, and neither belongs to Moonshot:

"id":"audnai/penclaw-Kimi-K3.0-abliterated-GGUF"
"likes":14
"downloads":0
"createdAt":"2026-07-18T13:19:50.000Z"
"id":"HFVwr/kimi-k3-article-svg-preview"
"likes":0
"downloads":0
"createdAt":"2026-07-18T16:10:34.000Z"

Disclosure, because the second name invites the question: HFVwr/kimi-k3-article-svg-preview has no connection to this site or its author. It is an unrelated third-party upload with zero likes and zero downloads, reproduced here only because it is part of the unfiltered search result and removing it would misrepresent the output. The analysis below concerns the first repo only.

The zero-byte "quantised K3"

audnai/penclaw-Kimi-K3.0-abliterated-GGUF was created 2026-07-18T13:19:50Z, has gated: "manual", usedStorage: 0, and zero downloads. Its like count read 14 on the first probe and 15 when the numbers were re-checked a few hours later on 2026-07-20, which is worth stating rather than smoothing over: likes are the one field here that moves, and they are also the only field that looks like social proof. It advertises itself as an abliterated GGUF quantisation. Here is its complete file tree, fetched directly:

curl -s "https://huggingface.co/api/models/audnai/penclaw-Kimi-K3.0-abliterated-GGUF/tree/main"

[{"type":"file","oid":"a6344aac8c09253b3b630fb776ae94478aa0275b","size":1519,"path":".gitattributes"},
 {"type":"file","oid":"7ccf968a1f7e94ce5dc4995e8fed356804e9004c","size":4041,"path":"README.md"}]

Two tracked files totalling 5,560 bytes, excluding git metadata. A .gitattributes and a README. No GGUF shard, no config.json, no tokenizer, no checksum, not one byte of tensor data. A repository nominally hosting a quantised 2.8-trillion-parameter model, created nine days before Moonshot's promised weight-drop date, meaning it predates any point at which the source weights it claims to quantise could have been public.

Two readings fit those facts, and the honest move is to state both, since this article has already refused to over-read a 401.

The benign reading is the boring one and probably the likelier one: an enthusiast claimed a memorable repository name early, wrote the README they intend to ship with, and plans to push actual quants once Moonshot publishes on 27 July. People squat names for legitimate reasons all the time, and gated: "manual" is a normal setting for someone who wants to control distribution of a derestricted model.

The risk reading does not require any bad intent from this particular uploader, and that is exactly why it is worth stating. An empty repository occupying a high-traffic name during a hype window is the same shape an attacker would use. The gate is what makes it effective either way: it converts "empty repo" into "repo I have not been approved for yet," which feels completely different to a user in a hurry, and it means the fifteen people who liked it cannot see from the outside that there is nothing behind it. Fill that slot with real bytes rather than nothing, at a moment when thousands of engineers are searching that exact string, and the same structure delivers arbitrary files to a queue of people who already believe the repo is what its name says.

Do not treat repository existence as evidence of weights. Check the tree. usedStorage: 0 plus a two-file listing is conclusive and costs one extra request.

Diagram of the open-weight verification flow

What Moonshot actually said

The gap between coverage and primary source is not subtle here. Moonshot's own K3 blog post states the timeline in plain language: the full model weights will be released by 27 July 2026. K3 was announced 2026-07-16 and until that date is reachable only through the API and kimi.com.

So Moonshot did not lie. Moonshot published an announcement with an eleven-day gap between announcement and weights, which is a normal and defensible thing to do. The distortion happened downstream. Tom's Hardware headlined it as delivering the largest open-weight AI model ever, on announcement day, eleven days before any weight file was promised to exist. Cryptobriefing's piece correctly notes weights are planned for late July 2026 in the body and then frames it as a shipped open-source release in the headline. Neither outlet fabricated anything. Both compressed "will release" into "released," and headline compression is where the entire error lives.

Announcement earns the full news cycle; a weight drop eleven days later earns a fraction of it, because by then the story is old. Nobody is penalised for the gap, because coverage collapses the two events anyway. Which means the gap is more likely to widen than close, and the burden sits with the reader.

The licence has the same structure, with a weaker chain of custody than most coverage implies. The widely repeated "Modified-MIT-style licence" characterisation is not in Moonshot's blog post. It reaches you through secondary outlets reporting a vendor statement, so its correct tier is secondhand report of a vendor claim, not vendor claim. Even taken at face value it is an intent. There is no LICENSE file anywhere public, so there is no text to read, no field-of-use carve-out to check, no acceptable-use policy to diff against Llama's or Qwen's. "Modified MIT" is a phrase whose entire risk profile lives in the word modified, and that word is currently unresolved.

The architecture claims, and which of them you can check

Moonshot's technical description of K3 is specific enough to be worth recording, because precise claims are easier to falsify later.

Claim	Figure	Verifiable today?
Total parameters	2.8T	No (needs weights)
Active experts per token	16 of 896 (~1.8%)	No
Attention	Kimi Delta Attention (KDA), hybrid linear	No (needs code/report)
Residual scheme	Attention Residuals (AttnRes)	No
Context window	1M tokens	Partly, via API
Decode speedup at 1M context	up to 6.3x	No
Training efficiency gain from AttnRes	~25% at <2% extra cost	No
Scaling efficiency vs Kimi K2	~2.5x	No
Serving quantisation	MXFP4 weights, MXFP8 activations	No
API price, cache-hit input	$0.30/M	Yes, firsthand
API price, cache-miss input	$3.00/M	Yes, firsthand
API price, output	$15.00/M	Yes, firsthand

Other named techniques in the writeup: Quantile Balancing, Per-Head Muon, Sigmoid Tanh Unit (SiTU), Gated MLA.

The pricing rows are marked firsthand because they were read on 2026-07-20 directly from Moonshot's own platform documentation at platform.kimi.ai/docs/pricing/chat-k3, not from coverage of a rate card, and they match the figures in Moonshot's K3 blog post. That is the distinction this whole article turns on, so it would have been embarrassing to fudge it. Note also that pricing carries no context-length tiering across the full 1M window, which is itself a meaningful engineering fact for anyone modelling long-context cost.

For competitive positioning, the comparison prices circulating in launch coverage are z.ai GLM-5.2 at $4.40/M output, DeepSeek V4 Pro at $0.87/M output (a figure at least one source qualifies as off-peak, so treat it as a floor rather than a list price), and Claude Fable 5 at $50/M output. Those three are secondhand and were not read from vendor consoles here. K3 at $15/M output sits between the cheap Chinese tier and the frontier US tier.

Deriving the active-parameter count, because it decides everything

Everything above the pricing rows becomes checkable on the day the tensors land, and not one hour earlier. But one number is worth reasoning about now rather than waiting, because it governs whether self-hosting is a conversation at all: active parameters per token.

Moonshot has published the expert ratio, 16 of 896, without publishing the active parameter count. The two are not the same number. A MoE forward pass always includes attention blocks, shared/dense experts, embeddings, and norms, none of which are routed. So the active-parameter fraction is systematically higher than the expert fraction.

Kimi K2 gives us the calibration constant, since Moonshot published both figures for it: roughly 1.04T total with about 32B active, from 8 experts of 384 routed per token.

• K2 expert fraction: 8 / 384 = 2.08%
• K2 active-parameter fraction: 32B / 1.04T ≈ 3.08%
• Ratio of the two: ≈ 1.48

Apply that same non-routed overhead ratio to K3:

• K3 expert fraction: 16 / 896 = 1.786%
• Estimated active fraction: 1.786% × 1.48 ≈ 2.64%
• Estimated active parameters: 2.64% × 2.8T ≈ 74B

Call it 70B to 80B, with the caveat that KDA and Gated MLA change the attention block's parameter share, so the 1.48 constant is inherited rather than measured. Tier: derived, not reported. Falsify it on 27 July by reading num_experts_per_tok, n_routed_experts, hidden_size, intermediate_size and moe_intermediate_size out of config.json and summing properly.

That estimate settles the "is it 50B or 200B active" question the compute-cost framing implies: it is neither, it is around 74B, closer to the cheap end. But it also exposes why the compute framing is a trap. Activation ratio governs FLOPs per token, not resident memory. Every one of the 2.8T weights has to be somewhere addressable. At the announced MXFP4 serving precision, roughly 4 bits per weight, that is about 1.4 TB for weights alone before KV cache, activations, or any framework overhead. On 141 GB accelerators you are looking at something like 12 devices just to hold the file, realistically 16 or more once a 1M-token KV cache enters the picture.

So the honest read for a self-hoster is: cheap to run per token, brutally expensive to have running. A 2.8T MoE with 74B active is not a model you put on a workstation because the activation ratio sounded small. Anyone planning a single-node deployment off the "1.8% of experts" line is going to be surprised by an out-of-memory error, not a latency figure.

The benchmark numbers, sorted by who is making the claim

Evidence tiering earns its keep here, because three different parties made three different claims about K3 and they are all being quoted as if they were one.

Tier: self-reported, vendor primary source. From Moonshot's own suite: ProgramBench 77.8 raw pass rate, SWE Marathon 42.0, BrowseComp 91.2, DeepSWE 67.3. The blog's own benchmark footnotes name Terminal-Bench 2.1, ProgramBench, SWE Marathon, FrontierSWE, PostTrain Bench, MLS Bench Lite, KCB 2.0, OfficeQA Pro, SpreadsheetBench 2, MCP Atlas, AutomationBench, BrowseComp and DeepSWE.

Numbers I could not trace and am therefore not asserting. Widely circulated figures for K3 include OmniDocBench 91.1, AutomationBench 30.8, an 86.6 FrontierSWE comparison value for Claude Fable 5, and a DeepSWE 73.0 for GPT-5.6 Sol. None of these appear in the primary blog footnotes, and none could be traced to a named primary source. Secondary coverage does say Moonshot claims a win on OmniDocBench, but the specific 91.1 has no locatable origin. They are listed here as unsourced, which is a different and more useful status than quietly omitting them: if you see them in a comparison table this week, that table did not check either.

Tier: secondhand, named third party. Arena.ai posted that Kimi-K3 took #1 in the Frontend Code Arena with 1679 points, a seventeen-place jump from Kimi-K2.6 at #18. It ranks #1 in six of seven domains (Brand & Marketing, Reference-Based Design, Data & Analytics, Consumer Product, Simulations, Content Creation Tools) and #2 only in Gaming, behind Fable 5.

Tier: secondhand, different named third party, primary-sourced. Artificial Analysis placed K3 at #3 overall on its Intelligence Index with a score of 57, comparable to Opus 4.8 and GPT-5.5, with exactly two models ahead: Fable 5 and GPT-5.6 Sol. AA also reports an Elo of 1668 on GDPval-AA v2 and 53% on AutomationBench-AA. This is cited to Artificial Analysis's own published article rather than to an aggregator repeating it, which is the standard this piece would be hypocritical not to meet.

Both third-party results are true simultaneously. A #1 in a frontend-code arena and a #3 on a general intelligence index are not contradictory, they measure different things. But "beats Fable 5" as a headline derives from the Arena result specifically and is attributable to Arena, not to Moonshot. Moonshot's own positioning is markedly more modest: ahead of Claude Opus 4.8 and GPT-5.5 in its coding and agentic suite, behind Fable 5 and GPT-5.6 Sol overall.

Moonshot also publishes its own limitations, which is more than most vendors do. Named: sensitivity to preservation of thinking history, excessive proactiveness in ambiguous scenarios, and a noticeable gap in user experience compared with Claude Fable 5 and GPT-5.6 Sol. A vendor conceding a UX deficit in its own launch post should carry weight against any headline reading as a clean win.

The DeepSWE discrepancy is the most instructive number here

K3's DeepSWE score appears as 67.3 and 67.5. Same model, two numbers, and until you name the harness neither is usable.

Moonshot's own blog resolves it explicitly, which is to its credit: K3 scores 67.3 with the mini-SWE-agent harness on DeepSWE v1.1 tasks, and 67.5 with KimiCode, Moonshot's own agent scaffold. The higher figure is the one that travels, and it is the one attached to a harness most readers have never heard of.

The delta is trivially small and that is exactly the point. Nobody is cheating. Harness choice alone moved the figure, which means a benchmark number quoted without a named harness is not a comparable number. If 0.2 points appear from scaffold choice on a benchmark both parties run honestly, a 2-point gap between two vendors quoting different harnesses tells you nothing. Every comparison table this week listing a bare "DeepSWE: 67.5" has silently discarded the only metadata that made the number usable, and has quietly picked the agent-scaffold-assisted variant while presenting it as the model's score.

Qwen 3.8 is a weaker case still

Qwen3.8-Max-Preview was previewed 2026-07-19 at WAIC in Shanghai. The Qwen team describes it as a 2.4-trillion-parameter sparse-MoE multimodal model, the team's first multimodal model above 1T parameters, and says it is second only to Fable 5 among the systems it benchmarked. Open weights are promised "soon."

Count what is missing. No date. No licence, not even a named intent. No Hugging Face repository. No benchmark table. No model card. And no active-parameter-per-token count, which for a sparse MoE is the number determining serving cost. Note that the K3 estimate above cannot be repeated here: Qwen has published neither an expert ratio nor an activation count, so there is no calibration to apply. 2.4T total is a headline figure, not a compute figure, and without an activation count you cannot say whether serving it costs more or less than a dense 70B.

The only performance statement on record comes from Qwen developer Shuai Bai, quoted by The Decoder, saying it should beat Qwen3.7-Max on coding, full-stack development, data analysis, and office workflows. "Should beat" the previous version, from an engineer on the team, is not a benchmark. The Decoder puts it flatly: no benchmark results are available yet.

What does exist is commercial: paid preview access through Alibaba's Token Plan, plus Qoder and QoderWork at 10 percent of standard pricing, with OpenAI- and Anthropic-protocol compatibility. A discounted paid preview with API compatibility is a product launch. Calling it an open-weight release requires "open" to mean nothing.

Decision framework: what counts as released

Use this before you put a model in a design document.

Level	Test	Kimi K3 (2026-07-20)	Qwen3.8-Max (2026-07-20)
0. Announced	Vendor blog post exists	Yes (07-16)	Yes (07-19)
1. Reachable	You can send it a prompt and pay for it	Yes, API + kimi.com	Yes, paid preview
2. Repo resolves	GET /api/models/<org>/<repo> returns 200	No (401)	No (401)
3. Weights present	File tree lists shards; usedStorage > 0	No	No
4. Licence readable	A LICENSE file you can open and diff	No (Modified-MIT intent, reported secondhand)	No (nothing stated)
5. Reproducible	Named harness + config for every claimed score	Partly (DeepSWE harness named, others not)	No benchmarks at all
6. Independently run	A third party loaded the weights and got a number	No	No

A model at level 1 is a hosted API product. "Open weights" requires levels 2, 3 and 4 simultaneously. Both models are at level 1.

The wrong call, stated plainly: do not write "K3 (open weights)" or "Qwen 3.8 (open weights)" into an architecture decision record, a vendor comparison, or a build-versus-buy analysis this week. If your self-hosting plan depends on the licence permitting commercial redistribution, you are planning against a sentence in a blog post relayed by a third party. Modified-MIT could carry a monthly-active-user threshold, an output-attribution requirement, or a naming clause, and you will not know which until 27 July at the earliest. Plan against the API pricing, which is published on Moonshot's own platform docs and was read there directly for this article, and revisit self-hosting when a LICENSE file exists. If the actual requirement behind "we want open weights" is running a capable model on hardware you control, that is a solved problem today with models at level 3 or above, and the tier-by-tier economics of doing it are worked through in running AI coding agents locally. A model you can download this afternoon beats a larger one you cannot.

The other wrong call: do not download anything named Kimi-K3-* from a third-party account before Moonshot publishes. Not because any specific uploader is acting in bad faith, but because before the source weights exist there is no legitimate quantisation to download, so every candidate in that namespace is either empty or something other than what it claims.

The forward checklist: verifying the claim once files appear

The check above proves absence. Here is the mirror-image sixty-second check for 27 July, when files land and the interesting failure mode inverts from "nothing there" to "there, but not what the headline said."

R=moonshotai/Kimi-K3   # substitute the real repo id once announced

# 1. Does it resolve, and is there actual storage behind it?
curl -s "https://huggingface.co/api/models/$R" \
  | tr ',' '\n' | grep -E '"(gated|usedStorage|lastModified|library_name)"'

# 2. Shard count and index. A real 2.8T MXFP4 release is hundreds of shards.
curl -s "https://huggingface.co/api/models/$R/tree/main" \
  | tr '}' '\n' | grep -c 'safetensors'
curl -s "https://huggingface.co/$R/resolve/main/model.safetensors.index.json" | head -c 400

# 3. Is there a LICENSE blob you can actually open?
curl -s "https://huggingface.co/$R/resolve/main/LICENSE" | head -40

# 4. Confirm the derived activation estimate.
curl -s "https://huggingface.co/$R/resolve/main/config.json" \
  | tr ',' '\n' | grep -E 'experts|hidden_size|intermediate'

What to look for, in order of how badly it bites:

1. gated. If it is "manual" or "auto", "open weights" now means "open weights subject to an access request the vendor can decline." That is a materially different licence posture and it will not be in the headline.
2. LICENSE text, read in full, not by name. The risk in "Modified MIT" is the modification. Look specifically for user-count thresholds, attribution-on-output requirements, naming clauses, and any acceptable-use policy incorporated by reference. An AUP incorporated by reference is a licence term that can change after you deploy.
3. Shard integrity. The tree listing gives an oid per file, which is the git object id, not a content sha256 for LFS pointers. Use huggingface-cli download and let it verify, or compare against the .safetensors.index.json weight map. A partial upload looks a lot like a complete one if you only count files.
4. config.json against the marketing. Sum the parameters yourself. If the derived ~74B active figure above is wrong, this is where it dies, and you should trust the config over both the blog post and this article.

Update log

• 2026-07-20: Original publication. All probes run this date. Headline claim current.
• Expires 2026-07-27. Moonshot's committed weight-release date. From that date the central claim in this article must be re-tested with Probe 2 before being cited, and the forward checklist above replaces the absence check.

Verification note (2026-07-20)

Read directly from primary sources for this article: Moonshot's K3 blog post (weight date of 27 July 2026, DeepSWE 67.3 with mini-SWE-agent and 67.5 with KimiCode, the benchmark footnote list, and API pricing), Moonshot's platform pricing documentation at platform.kimi.ai/docs/pricing/chat-k3 (cache-hit $0.30, cache-miss $3.00, output $15.00 per 1M tokens), and Artificial Analysis's own article for the #3 Intelligence Index placement, the score of 57, and the two models ahead. All Hugging Face API output shown above is literal and unedited.

Caveats that matter more than the recap:

• Derived, not reported: the ~74B active-parameter estimate for K3 and the ~1.4 TB MXFP4 weight-residency figure. Both are this article's arithmetic from published ratios, and both are falsifiable against config.json on 27 July.
• Secondhand about a vendor claim, not a vendor claim: the Modified-MIT licence characterisation. It does not appear in Moonshot's blog post.
• Unsourced and not asserted: OmniDocBench 91.1, AutomationBench 30.8, FrontierSWE 86.6 for Fable 5, DeepSWE 73.0 for GPT-5.6 Sol.
• Not verified against vendor consoles: the GLM-5.2 $4.40/M, DeepSeek V4 Pro $0.87/M (possibly off-peak) and Claude Fable 5 $50/M comparison prices.
• Unpublished rather than merely unverified: Qwen3.8-Max's active-parameter-per-token count. There is no number to check, which is why no estimate is offered for it.
• Every K3 architecture figure (2.8T parameters, 16-of-896 experts, KDA, AttnRes, 6.3x decode, 25% training efficiency, 2.5x scaling, MXFP4/MXFP8) is vendor-reported and cannot be checked without weights.

Sources

• Moonshot AI: Kimi K3 announcement, benchmarks and 27 July weight date
• Moonshot platform docs: Kimi K3 chat pricing per 1M tokens
• Artificial Analysis: Kimi K3 achieves #3 on the Intelligence Index
• Hugging Face API: moonshotai models by last modified
• Hugging Face API: Qwen models by last modified
• Hugging Face API: site-wide search for "Qwen3.8"
• Hugging Face API: site-wide search for "Kimi-K3"
• Hugging Face API: file tree of the zero-byte "K3" GGUF repo
• Hugging Face Hub API reference
• MarkTechPost: Kimi K3 architecture and benchmark breakdown
• MarkTechPost: Alibaba previews Qwen3.8-Max
• The Decoder: Qwen 3.8 preview, Shuai Bai's comment and "no benchmark results are available yet"
• Cryptobriefing: K3 API pricing and the 27 July weight date
• Cryptobriefing: secondhand report of Modified-MIT licence intent
• Arena.ai: Kimi-K3 tops the Frontend Code Arena
• Tom's Hardware headline framing the announcement as a delivered release