Is GLM-5.2 more expensive than GLM-5.1?

Not per token — the published rates are identical. But it produces substantially more output per task, measured at roughly 43,000 tokens against 26,000, so real cost per completed task rises by around 65% at the same headline price.

What is the biggest difference between the two versions?

Context went from 200K to 1M, and long-horizon agentic performance improved sharply — FrontierSWE and DeepSWE more than doubled. Single-patch coding improved only a few points, so the gain is concentrated in tasks that run long.

Should I upgrade if my tasks are short?

Probably not automatically. On bounded single-file edits the quality gain is small and the token cost is not, so the older version can be cheaper per completed task. Split your eval by task length before deciding.

GLM-5.1 vs GLM-5.2: Same Size, Same Price, Different Job

Version comparisons are usually a story about scale: more parameters, higher price, better numbers. GLM-5.1 and GLM-5.2 are not that. Z.ai shipped 5.2 in June 2026 with the same parameter count as the April release, the same maximum output length, and an identical price list.

What changed is the shape of the task the model is built to survive. That makes this an unusually clean comparison, because you can attribute every benchmark movement to training and inference changes rather than to spending more money per token.

What stayed the same

Both are mixture-of-experts models of roughly 744B total parameters with about 40B active per token — sources vary between 744B and 753B, and while that discrepancy is unresolved, every source agrees the two releases are the same size. Both are MIT licensed, with no revenue threshold and no regional restriction, which is the licensing property that decides whether you can build a product on top of the weights.

Maximum output is 128K on both. Z.ai list the same API rates for both: around $1.40 per million input tokens, $0.26 for cached input, and $4.40 per million output.

So on a spec sheet these look like the same model twice. The spec sheet is misleading.

The context window is the headline change

GLM-5.1 offered a 200K context. GLM-5.2 offers 1M — a fivefold increase, delivered alongside inference-side changes that reduce per-token compute at long context rather than simply extending the window and eating the cost.

Two hundred thousand tokens is a lot for a chat session and not much for an agent. A long agentic run accumulates tool output relentlessly: file reads, test output, stack traces, directory listings. At 200K you start compacting history partway through a serious task, and compaction is lossy in ways that are hard to predict — the detail the model needed is often the detail the summariser dropped.

At 1M, most single tasks fit without compaction at all. That is not a marginal convenience. It removes an entire class of failure where an agent loses the thread forty tool calls in.

Where the benchmark gains actually land

Z.ai publish both generations in the same table, which is more honest than most vendor comparisons. Read it with attention to which numbers moved a little and which moved a lot.

The single-patch coding numbers improved modestly. SWE-bench Pro goes from 58.4 to 62.1 — real, but a few points.

The long-horizon numbers moved by a different order of magnitude:

FrontierSWE — 30.5 to 74.4
DeepSWE — 18.0 to 46.2
Terminal-Bench — low sixties to 81.0
ProgramBench — 50.9 to 63.7
PostTrainBench — 20.1 to 34.3
SWE-Marathon — 1.0 to 13.0

Agentic tool use moved less dramatically but consistently: MCP-Atlas 71.8 to 76.8, Tool-Decathlon 40.7 to 48.2.

Reasoning improved across the board — GPQA-Diamond 86.2 to 91.2, AIME 2026 95.3 to 99.2, HMMT February 2026 82.6 to 92.5, Humanity's Last Exam 31.0 to 40.5 — with the largest relative jump on CritPt, 4.6 to 20.9.

The pattern is coherent. This is not a model that got generally better by a few percent. It is a model that got substantially better at tasks which run for a long time, and modestly better at everything else.

Two caveats before you plan around these. They are vendor-run numbers on vendor scaffolds, which typically score above a standardised harness. And SWE-Marathon at 13.0, up from 1.0, is a reminder that the very longest tasks remain mostly unsolved — a thirteenfold improvement on a number that low is progress, not a solution.

The cost nobody puts on the comparison slide

Identical per-token pricing does not mean identical cost per task.

GLM-5.2 is substantially more verbose. Artificial Analysis measure it using roughly 43,000 tokens per task against about 26,000 for the previous generation. That works out to somewhere near a 65% increase in real spend per task, at the same headline rate.

This is the single most important practical fact in the comparison, and it is invisible if you only read the price page. If you are on per-token billing and you migrate expecting the bill to stay flat, it will not. If you are on a flat-rate plan the effect shows up as latency instead, because more tokens take more time.

It also means the two models are not straightforwardly ranked. On a short task where 5.1 was already succeeding, paying 65% more tokens to succeed again is a downgrade.

A decision rule

Use the length of your typical task as the discriminator, not the benchmark table.

Long agent runs — repository-scale refactors, CI fix loops, terminal-heavy automation, anything crossing thirty tool calls. The newer model is worth its extra tokens, and the 1M context is doing real work.
Bounded single-file edits — write a function, fix a failing test, add a validation rule. The improvement is a few points and the token cost is not. Either generation is fine; the older one may be cheaper per completed task.
Documents that will not fit in 200K — no contest. This is a capability difference, not a quality one.
Latency-sensitive interactive work — measure before switching. More output tokens means more waiting, and verbosity is felt more sharply in a chat window than in a background job.

How to verify this on your own work

The comparison is easy to run because the interface is identical between the two, so the only variable is the model string.

Pick ten tasks from your git history, deliberately mixed: five that a competent developer finishes in one edit, five that took a long sequence of steps. Run each through the same harness against both models. Record three things.

Completion rate, split by task length. Averaging the two groups together hides exactly the effect you are testing for.
Total tokens per completed task, not per request. This is where the verbosity difference shows up, and it is the number that determines your bill or your wait.
Whether compaction fired. If your harness never had to summarise history on either model, the context increase bought you nothing on this workload and you should weight it at zero.

Expect the result to be split rather than clean. The likely finding is that the newer model wins clearly on the long tasks, ties on the short ones, and costs more on both — which is an argument for routing by task type rather than picking a single default.

On benchmark indices

Aggregate scores such as the Artificial Analysis Intelligence Index are useful for ruling models out, not for choosing between two versions of the same one. They are re-baselined periodically, so a figure quoted without a date can be compared against a number computed under different rules.

Where the two models differ is in a specific capability — holding a plan together over a long horizon — and no aggregate index isolates that. The task-length split above will tell you more in an afternoon than any leaderboard.