TL;DR — GLM-5.2 ships with a 1,048,576-token context window, weights on Hugging Face under zai-org/GLM-5.2, and pricing of $0.561/M input and $1.764/M output tokens. Probes showed it nailed a multi-step reasoning problem at 218.2 tokens/sec but stumbled badly on a coding task, taking 106.8 seconds to produce only 700 tokens of truncated, unfinished code. The value case is real, but it's uneven — know which workload you're pointing it at before you commit.
Every open-weight release this year has claimed to close the gap with frontier labs at a fraction of the price. GLM-5.2 is the latest to make that pitch, and on paper the numbers back it up: a context window over a million tokens, weights published on Hugging Face, and completion pricing under two dollars per million tokens. The question that actually matters, though, isn't whether the spec sheet looks competitive — it's whether the model behaves consistently enough to build a real workload on top of it. The probes say: sometimes, and you need to know which times.
What's actually in the box
GLM-5.2 (zai-org/GLM-5.2 on Hugging Face) ships with a context length of 1,048,576 tokens — the same neighborhood as the handful of other 1M-context open-weight models that have shown up this month. Pricing sits at $0.561 per million input tokens and $1.764 per million output tokens. That completion price is the number worth sitting with: it's roughly a tenth of what a top-tier closed frontier model typically runs, which is exactly the value proposition the "after the summit" price war has been selling all year. The weights being open means you can also self-host it if the economics of your volume justify the hardware, rather than being locked into someone else's meter.
Three probes, two different models
Live probing is where marketing numbers meet reality, and GLM-5.2 produced a split result. On a reasoning task — a two-pump tank-filling word problem — it was fast and correct: 218.2 tokens/second, a full four-step derivation, and the right final answer (20 more minutes, after correctly computing the net fill rate of 30 L/min and the 1,800-liter remainder). That's a clean, well-organized answer with no wasted tokens.
The structured-extraction probe asked for strict JSON with three keys, "ONLY the JSON object," from an invoice snippet. GLM-5.2 got the values right — vendor, date, and total all correctly pulled — but wrapped the output in a markdown code fence instead of returning a bare JSON object as instructed. Minor, but if your pipeline parses raw model output without stripping fences, that's the kind of thing that breaks a production extraction job at 2 a.m. It ran at a respectable 95.7 tokens/second in 3.9 seconds.
The coding probe is the one that should give anyone pause. Asked for a straightforward interval-merging function plus a one-sentence complexity note, GLM-5.2 took 106.8 seconds and produced just 700 completion tokens at 6.6 tokens/second — and the output cuts off mid-function, before the merge loop even finishes, with no complexity statement at all. That's not a stylistic quibble; it's an incomplete deliverable. Whether that's a one-off probe hiccup or a real weak spot in this model's coding path isn't something a single transcript can settle, but it's a data point you shouldn't ignore if code generation is your primary use case.
Who should actually build on this
Start with the workloads where the reasoning probe's behavior is representative: multi-step numeric reasoning, structured business logic, policy-style Q&A, and long-document analysis that leans on the 1M-token window rather than tight code correctness. Teams doing contract review, financial reconciliation walkthroughs, or long-context summarization where the model needs to hold an entire document set in memory and reason over it are squarely in the zone where $0.561/$1.764 per million tokens beats renting frontier API access by a wide margin, especially at volume.
Structured-output pipelines — invoice parsing, log-to-JSON conversion, form extraction — are also a reasonable fit, but only if your downstream parser is defensive enough to strip markdown fences and validate schema rather than trusting a literal "return only JSON" instruction to be followed to the letter. That's cheap insurance and worth building regardless of which model you use.
Coding-agent workloads are the case I'd flag for caution based on what showed up here. A 106-second wait for an unfinished function is not something you want inside an autonomous agent loop that fires dozens of these calls per task; it either times out, produces broken diffs, or silently corrupts a multi-step plan. If your primary job is code generation or agentic tool use, this single transcript is a reason to run your own harness against your own repo before committing spend, not a reason to write the model off outright — one bad probe run doesn't prove a systemic issue, but it does mean the burden of proof is on you to verify before production.
The honest recommendation: treat GLM-5.2 as strong for reasoning-heavy, long-context, structured-data work at a price point that genuinely undercuts frontier alternatives, and treat its coding path as unproven until you've tested it against your own codebase and latency budget.
What the price war actually changes
The interesting story here isn't GLM-5.2 in isolation — it's what a $1.764/M completion price does to everyone else's roadmap. When an open-weight model with a 1M-token context and Hugging Face weights lands at roughly a tenth of frontier completion pricing, every other vendor's cost curve gets renegotiated whether they like it or not. That pressure is good for builders: it means the "near-frontier at commodity price" tier is no longer a promise, it's a shelf full of options, and the real differentiator shifts from "can it do the task" to "does it do the task reliably enough, fast enough, for what I'm paying." GLM-5.2 clears the first bar convincingly and the second bar unevenly — which, at this price, might still be a trade worth making for the right workload.
Tomorrow closes out the series with a model built on a different premise entirely — Olmo 3 32B Think, and the case for calling something "fully open" rather than just open-weight.
The numbers (measured, not quoted)
I ran three quick probes against GLM-5.2 via a hosted API today before writing this. Small sample, one snapshot in time, routed hardware I don't control — treat these as a smell test, not a benchmark:
| Probe | Wall-clock | Output tokens | Tokens/sec (effective) | Result |
|---|---|---|---|---|
| Code | 106.8s | 700 | 6.6 | completed |
| Reasoning | 2s | 447 | 218.2 | completed |
| Structured output | 3.9s | 370 | 95.7 | completed |
Effective tokens/sec includes queueing and time-to-first-token — it's what you actually experience, not peak decode speed.
Model card: context window 1,048,576 tokens · hosted pricing $0.561/M input · $1.764/M output · weights: zai-org/GLM-5.2 on Hugging Face
Credits — where it's due
- Zhipu AI (Z.ai) — for training GLM-5.2 and releasing the weights openly: zai-org/GLM-5.2. Open releases like this are why a series like this can exist at all.
- OpenRouter — the hosted API used for today's live probes and the pricing/context figures.
- The quantizers and runtime maintainers — the mostly-unpaid people who turn every open release into something that runs on real hardware within days.
Top comments (0)