GLM 5.2 vs Claude: An Open Model Just Pulled Even on Coding
GLM 5.2 lands within a point of Claude Opus 4.8 on coding benchmarks, at roughly a fifth of the cost. The score isn't the whole story: open weights doesn't mean it runs on your laptop, and Claude still wins the hard 20%.
Every few weeks a new model “beats Claude.” Most of the time the claim falls apart the moment you read past the headline. GLM 5.2 is the first one in a while where the headline is roughly true. And the part underneath it is more interesting than the benchmark itself.
GLM 5.2 shipped in mid-June: open weights, MIT-licensed, a 753B mixture-of-experts model with around 40B active parameters per token. On its own published benchmarks it lands within about a point of Claude Opus 4.8 on the hard coding tests. It runs at a fraction of the price. And for most people, it still isn’t something you run yourself.
All three of those are true at once. That’s what makes it worth a closer look.
A point behind, not a tier behind
On Zhipu’s numbers, GLM 5.2 trails Opus 4.8 by roughly a point on the agentic software-engineering and tool-use suites. FrontierSWE is 74.4 against 75.1, MCP-Atlas 76.8 against 77.8. On Terminal-Bench it edges ahead. Independent reviewers have it as the strongest open-weight coding model available right now.
Worth saying plainly: those headline scores are the vendor’s. A launch benchmark is a marketing artifact first and a measurement second. Take the numbers as a rough map of where the model sits, not a verdict on whether it’ll do your work. The distance between “wins a benchmark by a point” and “is interchangeable on your codebase” is exactly the gap this post is about.
But even discounted, the shape of the result is new. Open-weight models used to trail the frontier by a clear tier. This one trails by a rounding error.
The real gap is cost
The difference you actually feel isn’t the score. It’s the invoice.
GLM 5.2 runs around $5–6 per million tokens, input and output combined. Opus 4.8 is about $30. Same task, a fifth of the bill. For a one-off question that’s noise. For high-volume agentic work it’s the line item that decides which model goes in the loop. A coding agent grinding through a repo makes hundreds of tool calls per task, and the per-call price adds up fast.
This is also where “open weights” earns its keep even if you never download anything. An open model with a credible license creates price pressure and portability that a closed API doesn’t. You’re not married to one vendor’s pricing page.
”Open weights” isn’t “runs on your laptop”
This is the part the headlines skip, and it’s the one I’d want a developer to walk away with.
GLM 5.2 is a 753B-parameter model. Downloading the weights does not mean your machine can serve them. Even as a mixture-of-experts with ~40B active parameters, the whole model has to be resident to route across experts, and that’s far past what a laptop or a single consumer GPU holds. Even quantized, you are not fitting a 753B model on a MacBook.
So in practice, for almost everyone, GLM 5.2 is still an API or a hosted coding plan. The honest framing isn’t “local model replaces cloud model.” It’s “open, cheaper cloud model pulls even with the expensive one.” That’s a real shift. Just not the one the word “local” implies.
Where Claude still wins
The gap is shrinking. It hasn’t closed. A few places where the frontier still earns its price:
- Large codebases. Holding context across many files without losing the thread.
- Long agentic chains. Multi-step tool use that has to stay coherent all the way to the end, not just on step one.
- Hard reasoning. The genuinely gnarly bug that needs depth, not a plausible-looking patch.
These are the tasks where a one-point benchmark delta widens into something you can feel. For routine generation and well-scoped changes, an open model now clears the bar. For the hard 20%, you still reach for the frontier.
Read it as a cost decision, not a downgrade
That’s the new part. For the first time, switching off a frontier coding model isn’t accepting worse output you tolerate to save money. For most of your work the quality is comparable, and for the part that isn’t, the frontier model is still one keystroke away.
The benchmark won’t tell you which side of that line your own work falls on. Your own codebase and your own bugs will. So before you switch anything, run it on a handful of tasks you actually care about and see where it breaks down.
If you do, I’d like to know where it fell short.