GLM-5.2 technical review: strong on coding, token-hungry, and likely partially distilled

GLM-5.2 Technical Review: Strong on Coding, Token-Hungry, Questionable Generalization

Zhipu's GLM-5.2 is delivering impressive benchmark scores and real-world coding performance, but the underlying technical picture is messier than the headlines suggest.

The immediate concern is distillation. Open-source model labs, particularly Chinese competitors, have faced accusations of training on closed-source API outputs—Anthropic publicly accused Alibaba of this practice. With GLM-5.2, the distillation question is harder to pin down but potentially more pervasive. As the public internet and GitHub become increasingly saturated with LLM-generated code and text, training on those repositories effectively amounts to distillation, even if no proprietary API calls are involved. The model is absorbing quirks and conventions baked into closed-source outputs—specific phrasings, code patterns, formatting choices—without directly consuming them.

Distilled models typically generalize worse than their sources suggest. They score well on benchmarks, sometimes "accidentally" because the benchmark itself may be drawn from similar source material. But take GLM-5.2 off its strongest domains—coding—and the performance drops noticeably. Creative writing and open-ended tasks reveal the brittleness. This pattern should prompt skepticism of headline benchmark numbers.

Where GLM-5.2 actually shines: coding. By multiple accounts, the model performs genuinely well on code generation and reasoning tasks. That strength is real and worth acknowledging. The model is competent.

But the market for mid-tier models remains unclear. OpenRouter data shows the most-used open-source models are the smallest, cheapest ones—DeepSeek-Flash and similar—deployed for high-volume, single-purpose tasks like receipt OCR or expense categorization. Every receipt processed, every routine task automated, doesn't need frontier intelligence. At the other end, security-critical applications and coding agents require the best available models regardless of cost. The middle—models like GLM-5.2 positioned between tiny, efficient models and frontier labs—struggles to find defensible use cases beyond hobbyists who want competitive coding performance without paying OpenAI's token rates.

There's also a structural problem: token hunger. GLM-5.2 consumes more tokens than some competitors, which compounds the unit economics problem for a non-frontier model in a market increasingly bifurcated between "pay whatever it costs for the best" and "minimize cost for routine work."

The monetization risk runs deeper. If government approval regimes for accessing frontier models stretch to months, organizations may simply wait and adopt whatever open-source alternative has matured by approval time. A company waiting for GPT-7 access could sidestep the entire process by adopting GLM-6 or an equivalent in the interim. That dynamic threatens the moat around controlled-access frontier models and complicates the government's emerging strategy of gating advanced AI behind approval processes.

GLM-5.2 is a capable model and shouldn't be dismissed. But it sits in a commercial dead zone where neither cost nor performance justifies adoption over the extremes.