Kimi K3 vs GLM 5.2: Benchmarks, Pricing, and the Right Pick for Your Workflow

Kimi K3 is the stronger model. GLM 5.2 is the more practical one. That split runs through every dimension of this comparison, and the right choice depends on which side of it you land on.

Moonshot AI's Kimi K3 (2.8 trillion parameters, July 16) and Zhipu AI's GLM 5.2 (753 billion parameters, June 13) are both open-weight MoE models with million-token context windows built for agentic coding. K3 scores higher on independent benchmarks and adds native vision. GLM 5.2 costs roughly a third as much, runs 5x faster, fits on a fraction of the hardware, and ships under a plain MIT license where K3 carries commercial conditions. Below is the full breakdown, with every benchmark labeled by source.

Kimi K3 and GLM 5.2 at a glance

The spec sheet shows two models built for the same job at very different scales.

K3 is nearly four times larger in total parameters. But in MoE land, total parameters determine how much the model can store, not how much it computes per token. The active parameter counts are closer to each other than the headline numbers suggest.

Architecture: how each model handles scale

1. Kimi K3's hybrid attention and extreme sparsity

K3's architecture represents a philosophical bet: partly replace the transformer's standard attention mechanism to make million-token contexts fast, not just possible.

Source

Screenshot 2026-07-21 at 2.20.24 PM.png The model activates 16 of 896 experts per token, a sparsity ratio of roughly 1.8% by expert count, which works out to 104 billion active parameters of 2.8 trillion total. Moonshot calls the framework Stable LatentMoE. Layered on top is Kimi Delta Attention (KDA), a hybrid linear-attention mechanism that interleaves linear and full-attention layers in a 3:1 ratio. According to Moonshot's technical blog, KDA cuts KV-cache memory by up to 75% at million-token lengths, which is how Moonshot prices the 1M window flat without a long-context surcharge.

Attention Residuals let each layer selectively pull useful representations from earlier layers rather than passing everything through a fixed residual path. Moonshot reports roughly 25% training efficiency gains from this at under 2% extra compute cost. Combined with Gated MLA for key-value compression, these changes add up to what Moonshot claims is a 2.5x improvement in overall scaling efficiency compared to K2.

The deployment cost reflects the scale. Moonshot's own guidance recommends 64 or more accelerators. Post-release, SGLang publishes per-hardware serving recipes that start lower: 8 GPUs on B300, GB300, or MI350-class silicon, 16 on B200, GB200, or H200, and 32 on H100. Even with MXFP4 weights and MXFP8 activations, the Hugging Face repository runs to roughly 1.56 TB (1.42 TiB).

2. GLM 5.2's IndexShare and reasoning toggles

GLM 5.2 optimizes a more conventional transformer to make million-token context affordable rather than architecturally novel.

The key innovation is IndexShare: a lightweight sparse-attention indexer reused across every four transformer layers. Z.ai reports this cuts per-token FLOPs by 2.9x at 1M context length, according to GLM 5.2's technical documentation. The model also uses multi-token-prediction speculative decoding with KVShare, which reuses the target model's KV cache for draft layers, raising draft acceptance length by up to 20%.

On reasoning control, the two models have converged. GLM 5.2 offers two selectable modes: High produces lighter, faster chains of thought for routine tasks, and Max activates full reasoning for hard problems. K3 launched locked to maximum effort but now exposes three levels, low, high, and max, with max as the default. Neither model lets you disable thinking entirely.

What GLM retains is evidence rather than granularity. Z.ai has published figures showing High mode cuts token usage roughly 2-2.5x with minimal quality loss on routine tasks. Moonshot has not published equivalent data for K3's lighter settings, so the size of the saving is known on one side and unmeasured on the other. That matters because reasoning tokens bill at the output rate, and a model that thinks longer burns more of them on every request.

Benchmark comparison

Benchmark numbers are the most contested part of any model comparison, so source discipline matters here more than anywhere else. Every score in this section is labeled by source tier: independently verified (tested by a neutral evaluator on a standardized harness) or vendor-reported (published by the model's own lab, not yet independently replicated on the same harness).

1. The independent baseline (Artificial Analysis Intelligence Index)

Artificial Analysis provides the cleanest cross-model comparison. Its Intelligence Index v4.1 runs nine evaluations on a standardized harness, including GDPval-AA v2, Terminal-Bench v2.1, SciCode, Humanity's Last Exam, and GPQA Diamond.

Scores from Artificial Analysis, July 2026. Both models tested at max reasoning effort on the same harness.

K3 leads by six points overall, seven points on the coding sub-index, and seven on the agentic sub-index. For context, GLM 5.2 at 51 was the top-scoring open-weight model before K3 shipped. K3 now holds that position, ranking fourth overall behind Claude Fable 5 (~60), GPT-5.6 Sol (~59), and roughly on par with Claude Opus 4.8 (~56).

Artificial Analysis also breaks down individual evaluations. The widest gaps appear on agentic and knowledge-work tasks, while pure knowledge and reasoning benchmarks show a tighter race:

All scores independently verified by Artificial Analysis. K3 figures reflect the July 23, 2026 snapshot cited on Moonshot's model card.

One result worth flagging: GLM 5.2 has a significantly better non-hallucination rate on AA-Omniscience (72% vs 49%). K3 answers more questions correctly but fabricates more answers when it doesn't know something. For production applications where incorrect answers are worse than no answer, that tradeoff matters.

2. Vendor-reported coding and agentic scores

Moonshot published a comparison table in its K3 technical blog testing K3 and GLM 5.2 on coding harnesses. These are vendor-reported numbers, meaning Moonshot ran both models, and the results have not yet been independently replicated on these specific benchmarks.

All scores from Moonshot's K3 technical blog. Vendor-reported; not independently replicated on these specific harnesses.

The pattern is consistent: K3 leads on everything Moonshot tested. The widest gaps appear on long-horizon tasks like SWE Marathon (42.0 vs 13.0) and Automation Bench (30.8 vs 12.9). Bounded, shorter tasks like GPQA-Diamond show near-parity (93.5 vs 91.2).

Source

One important caveat on the coding numbers: the two models were not run on the same harness. Moonshot's model card footnotes state that K3's Terminal-Bench 2.1 score used the Kimi Code harness while GLM 5.2 was evaluated with Claude Code, and that GPT models used Codex. The harness influences the score, sometimes by double digits, so these rows measure two different systems rather than two models under identical conditions.

For a deeper look at GLM 5.2's benchmark performance across more evaluations, including SWE-bench Pro (where GLM 5.2 scored a vendor-reported 62.1, topping GPT-5.5's 58.6), see Emergent's dedicated breakdown.

3. The apples-to-apples datapoint (Terminal-Bench 2.1)

One benchmark cuts through the vendor-reported vs independently-verified fog: Terminal-Bench 2.1, where both models have been measured by independent evaluators on the same benchmark version.

Z.ai reports GLM 5.2 at 81.0. Vals, an independent evaluator, measured K3 at 80.9. On the same benchmark version, the two models are effectively tied.

That single datapoint reframes the entire narrative. Moonshot's own table puts the same benchmark at 88.3 for K3 and 82.7 for GLM, a 5.6-point gap, using the Kimi Code harness on one side and Claude Code on the other. The independent figures land six points lower for K3 and within a point of each other. The vendor-reported gaps of 5-29 points across Moonshot's table may therefore reflect harness differences and evaluation setup as much as pure capability. K3 still leads on the broader agentic and knowledge-work suites where Artificial Analysis confirms the gap.

Pricing and the real cost per task

K3 costs more per token, and the gap widens because K3 defaults to maximum reasoning effort on every request.

Pricing as of July 2026.

The output price gap is the headline: $15.00 vs $4.40, meaning GLM 5.2 is about 3.4x cheaper on generated tokens. On Artificial Analysis's blended pricing (which uses a 7:2:1 cache-hit/input/output ratio), K3 comes to $2.31 per million tokens vs $0.90 for GLM 5.2.

But the metric that actually matters for budgeting is cost per completed task, not cost per token. Artificial Analysis measures this at $0.94 for K3 and $0.47 for GLM 5.2. K3 is roughly double, not triple, because it tends to be more token-efficient in its final answers despite the higher per-token rate.

Two structural factors widen the effective gap beyond the 2x sticker:

K3 defaults to maximum reasoning. The reasoning_effort parameter now accepts low, high, and max, but max is the default and thinking cannot be turned off. Unless you set the parameter explicitly on every call, each request pays a full reasoning trace at $15 per million output tokens. GLM 5.2's High mode is documented to cut token usage roughly 2-2.5x with minimal quality loss on routine tasks. K3's lighter settings exist but Moonshot has not published comparable savings figures, so the lever is there on both sides and only measured on one.

K3's caching economics are genuinely strong. Moonshot reports above 90% cache-hit rates on coding traffic through its Mooncake architecture. At $0.30 per million cached input tokens, the effective input cost collapses for workloads that reuse a large prompt prefix. If your usage pattern is iterative coding with a stable repo context, K3's input bill drops dramatically.

What $100 of API spend buys you

A worked example to make the cost difference concrete:

Calculated from official output pricing. Task estimates use Artificial Analysis cost-per-task figures.

For high-volume workloads, that 2x task gap compounds quickly. A team running 1,000 agent tasks per month pays roughly $940 with K3 and $470 with GLM 5.2 at these rates.

For a comparison of how GLM 5.2's pricing stacks up against other open-weight models, see GLM 5.2 vs DeepSeek V4 Pro.

Open weights, licensing, and self-hosting

Both models ship downloadable weights. They do not ship them on the same terms.

GLM 5.2 has its full 753 billion parameter weights published on Hugging Face under the MIT license with no regional restrictions and no revenue triggers. The community has already produced multiple quantization formats: BF16 (~1.5 TB), FP8 (~750-860 GB, fits a single 8x H200 node), and 4-bit GGUF (~376 GB, runnable on 4x H100 via llama.cpp). Day-one runtime support exists across vLLM, SGLang, Transformers, KTransformers, and xLLM. One production note from the Z.ai documentation: GLM 5.2 emits a newer <tool_call> format, and on SGLang you need the --tool-call-parser glm47 flag, or tool calls silently remain as raw text.

Kimi K3 published full weights on July 27, 2026, alongside a technical report. The license is not MIT. Moonshot wrote a bespoke document called the Kimi K3 License, tagged license:other on Hugging Face, which reads like MIT for most of its length and then adds two commercial conditions:

• Model-as-a-Service resellers, meaning anyone giving third parties inference or fine-tuning access with control over inputs and parameters, must sign a separate agreement with Moonshot once combined licensee and affiliate revenue passes $20 million over any consecutive 12 months
• Products above 100 million monthly active users or $20 million in monthly revenue must display "Kimi K3" in the interface

Internal use and access through certified inference partners are exempt. Artificial Analysis classifies the license as requiring a separate agreement for commercial use rather than as an openly licensed release. For teams choosing between these two specifically, that is now the cleanest differentiator on the licensing axis: GLM 5.2 is MIT with no conditions, and K3 is not.

The self-hosting calculus also still favours GLM by a wide margin. K3's Hugging Face repository runs to roughly 1.56 TB (1.42 TiB) even with MXFP4 quantization. Moonshot's own guidance recommends 64 or more accelerators, and SGLang's post-release recipes start at 8 GPUs on the newest Blackwell and MI350-class silicon, rising to 32 on H100. GLM 5.2 on a single 8-GPU H200 node at FP8 is a different operational class entirely.

For teams comparing GLM 5.2 against its predecessor in the Kimi family, see GLM 5.2 vs Kimi K2.7 Code.

Multimodality, speed, and context window

Vision: K3 has it, GLM 5.2 does not

K3 takes text, images, and video in one native architecture. GLM 5.2 is text only. If your workflow involves feeding the model screenshots, design mockups, chart images, or video, K3 is the only option between these two. GLM 5.2 will not read an image at all.

This is not a minor capability gap. FastAI's Jeremy Howard, who otherwise rated GLM 5.2 positively for coding, flagged the missing vision as its main limitation. For frontend development, visual debugging, and any task where the model needs to see what it's building, K3's native multimodality is a structural advantage.

Speed: GLM 5.2 is dramatically faster

Artificial Analysis measures GLM 5.2 at 193 output tokens per second. K3 generates 39 tokens per second. That is a 5x throughput difference.

Speed measurements from Artificial Analysis, July 2026.

For interactive coding sessions where you wait for each response, that latency difference is felt directly. GLM 5.2 responds in about a third of the time. For batch processing or autonomous agent runs where latency matters less, the speed gap is still relevant because faster throughput means more tasks completed per hour.

Context: both 1M, different approaches

Both models accept roughly one million tokens. K3's context window is 1,048,576 tokens with no separate output cap at that length. GLM 5.2 matches the input window but caps maximum output at 128K-131K tokens per response.

The architectural approaches differ. K3's KDA hybrid attention is designed to stay coherent and cheap over very long sequences, which is why Moonshot prices the 1M window flat. GLM 5.2's IndexShare accomplishes the same flat pricing through a different mechanism, reusing a sparse-attention indexer across transformer layers.

Both models get verbose with reasoning tokens at long context. Artificial Analysis measured K3 generating roughly 24,000 total output tokens per Intelligence Index task (18,000 reasoning + 6,000 answer), while GLM 5.2 generated roughly 43,000 (37,000 reasoning + 6,000 answer). GLM 5.2's reasoning is nearly twice as verbose, which partly explains why its cost-per-task ($0.47) is higher than its raw per-token pricing would suggest.

When to pick Kimi K3 vs GLM 5.2

Start with the workload, not the leaderboard. The table below maps common scenarios to the model that fits best, with the reasoning in one line.

You don't have to choose one exclusively. A routing pattern that several teams have adopted: run GLM 5.2 as the high-volume default and escalate to K3 only on the hardest, multimodal, or longest-horizon tasks. That split captures the strengths of both without overpaying on routine work.

For teams exploring other Kimi K3 alternatives across both open-weight and closed-flagship options, Emergent's dedicated roundup covers six models spanning different price and capability tiers.

Beyond the model comparison

If you're not building AI infrastructure and just need a working app, there's a simpler path. Emergent lets you describe an application in plain language and get a production-ready, full-stack product with a real backend, real integrations like Stripe, MongoDB, and Shopify, and code you own. It runs Claude, OpenAI GPT, and Google Gemini under the hood through its Universal LLM Key, so you get frontier model capabilities without managing API keys or comparing token prices.

Skip the model comparisons and API setup. Describe your app and let Emergent handle the rest. Start Building and see how far a prompt gets you.