Kimi K3 vs GLM-5.2: Capability Against Deployability

These two models are usually compared on an intelligence index, where Kimi K3 sits around 57 and GLM-5.2 around 51, and the comparison ends there. That gap is real, but it is the least decision-relevant thing about them.

The differences that will actually change your architecture are the licence, the active-parameter count, and the fact that they are strong at two different jobs. Take them in that order.

The licence divergence is the hard constraint

GLM-5.2 ships under MIT. No revenue threshold, no regional restriction, no separate agreement. You can fine-tune it, redistribute it, and build a commercial inference product on top of it without asking Z.ai anything.

Kimi K3 does not. The weights are published — 1.56TB of them, released on 26 July 2026 — but under a custom kimi-k3 licence. Products above roughly 100 million monthly active users or $20 million monthly revenue carry an attribution requirement, and any Model-as-a-Service business with aggregate revenue over $20 million in a twelve-month period needs a separate agreement with Moonshot. Moonshot consistently says "open weight" rather than "open source", and means it.

For an internal engineering team, none of this bites. For anyone whose product is inference, it is a gate that appears at exactly the point you become successful, and it is worth resolving before you build on it rather than after.

Active parameters decide what you can serve

Both are mixture-of-experts models, and the totals are misleading. K3 is 2.8T total with roughly 104B active per token. GLM-5.2 is around 744B total — Z.ai's own post says 753B — with about 40B active.

Total parameters set your memory floor; active parameters set your compute per token. K3 activates roughly two and a half times as much per token as GLM-5.2, and needs several times the memory to hold. In practice this means K3 is a multi-node deployment for anyone, whereas GLM-5.2 is at least in the conversation for a single well-specified node.

It also shows up in price. Moonshot lists K3 at $3 per million input tokens and $15 per million output, with cached input at $0.30. Z.ai's official rates for GLM-5.2 are around $1.40 and $4.40, with third-party providers listing lower. Roughly a three-times gap on output, before any caching.

One more operational difference: GLM-5.2 exposes two reasoning effort levels, high and xhigh. K3 launched with a single level. If your workload benefits from dialling depth down on easy tasks, that lever exists on one model and not the other.

They are good at different things

This is where the aggregate index actively misleads you.

K3 wins on human preference for generated code. Arena ranked it first on Frontend Code at 1,679 points, ahead of Claude Fable 5, in blind developer voting. Artificial Analysis put it at 1547 Elo on their private long-horizon knowledge-work evaluation, behind only Fable 5, while using 21% fewer output tokens than the previous Kimi generation.

GLM-5.2 wins on long agentic sessions in a terminal. Z.ai reports 81.0 on Terminal-Bench 2.1 under the Terminus-2 harness, with 82.7 best reported — the first open-weight model past 80 at its June 2026 release, up from 62.0 a generation earlier. It reports 62.1 on SWE-bench Pro, 74.4 on FrontierSWE and 76.8 on the public MCP-Atlas set.

Those are vendor-run numbers on the GLM side and blind human voting on the K3 side, which is not a like-for-like comparison. But the shapes are consistent with how each lab describes its model, and they map cleanly onto two different workloads: a developer iterating on UI in a chat window, versus an unattended agent grinding through a repository for three hundred tool calls.

Where GLM-5.2 wins outright

Cost per completed task, when both models complete the task. If your work is routine — bounded refactors, test generation, code review of small diffs — the cheaper model finishing successfully is simply the better outcome, and the capability gap never becomes visible.

GLM-5.2 posts 62.1% on SWE-bench Pro, which is a respectable showing on real repository tasks rather than puzzle-shaped ones. The GLM-5.2 guide goes through where it holds up and where it does not.

It is also the model you can hand to anyone. MIT licensing means no procurement conversation, no commercial review, and no restriction on what you build on top of it — which for some teams settles the question before any benchmark does.

Route rather than choose

The framing of picking one model is mostly an artefact of tools that only let you configure one. If your stack can route, the sensible arrangement is GLM-5.2 as the default with K3 reserved for a narrow set of triggers.

Good triggers are mechanical, not vibes: the task touches more than some number of files, the cheap model has already failed a verification gate twice, or the work is user-facing interface code. Everything else stays on the default and you never think about it. Model routing and fallbacks covers the plumbing.

The one thing worth measuring before you commit either way is escalation rate — the share of tasks the cheap model cannot finish. If that number is low, the premium model is a rounding error you do not need. If it is high, you are paying twice for every escalated task and should promote the stronger model to default.

A decision rule

Answer three questions in order and you rarely need the benchmarks at all.

1. Will you resell inference? If yes, and you expect to clear $20 million, GLM-5.2 removes a legal conversation that K3 requires. That alone often settles it.
2. Is a human waiting? Interactive work rewards K3 on output quality and GLM-5.2 on cost and effort control. If your users judge the code by looking at it, the blind-preference result is the most relevant evidence you have.
3. How long are your agent runs? Under twenty tool calls, this comparison barely matters and you should be looking at cheaper models entirely. Over a hundred, GLM-5.2 is the one with the benchmark profile built for it.

The comparison you should actually run

Both models are available through OpenAI-compatible endpoints, so swapping between them is a configuration change. Use that.

Take ten tasks from your git history that took more than twenty tool calls. Run each through both models on the same harness, same system prompt, same starting commit. Record turns to completion, total output tokens, and whether you would merge the diff.

The metric that decides it is cost per completed task, not price per token. K3 costs more per token and often uses fewer of them; GLM-5.2 costs less per token and may need more turns. Which way that lands depends on your tasks, and there is no way to know without measuring.

Keep the eval. Both labs ship frequently, and a result from July is already stale by October.