← Insights

GLM 5.2 vs Claude Opus: A Real Operator's Cost-Performance Call

Lenny Rachitsky swapped Claude Opus out of his agentic coding workflow for GLM 5.2 — with specific numbers. Here's what that decision means for teams deploying AI at scale.

The Signal Worth Paying Attention To

When a practitioner with 700K+ subscribers publicly replaces a flagship closed model with an open-weight alternative — and publishes the specific numbers behind the decision — that's not a benchmark post. That's an operator decision you can replicate.

Lenny Rachitsky switched Claude Opus out of his Claude Code workflow in favor of GLM 5.2, a model from Z.ai released under an MIT license. The performance delta is under one point on FrontierSWE (74.4 vs 75.1 for Opus). The cost delta is not close: $4.40 per million output tokens versus $25.00. That's roughly a 5–6x reduction for a model that performs at near-parity on the tasks most agentic coding workflows actually demand.

What This Looks Like in Practice

GLM 5.2 is self-hostable on vLLM, carries a 1M-token context window, and runs under MIT licensing — meaning teams with the infrastructure can eliminate per-token costs entirely by deploying the open weights. For organizations running agentic workflows at scale (document processing, code generation, automated enrichment pipelines), the math shifts materially fast.

This is also a useful calibration moment on how to read model releases. Closed frontier models are priced at a premium that partly reflects brand trust and partly reflects genuine capability leads. When the capability lead compresses to sub-1-point benchmark gaps, the premium becomes harder to justify operationally. That's the position Opus is now in for coding-specific workflows.

The caveat: deployment complexity is real. Self-hosting vLLM requires engineering capacity that a SaaS API call does not. For smaller teams or those without dedicated ML infrastructure, the API option ($4.40/M via Z.ai's hosted endpoint) still delivers most of the cost benefit without the ops burden.

The Actionable Takeaway

Audit your current model spend by workflow type. Not all inference is equal — a customer-facing copilot has different risk tolerances than an internal coding assistant or a batch enrichment job. For high-volume, lower-stakes agentic tasks, the case for defaulting to frontier closed models is weakening. Run a parallel eval: take your actual prompts and tasks, run them against GLM 5.2 on the hosted API, and score the outputs against your current model's baseline. If the quality holds, the cost argument writes itself.

The broader pattern here matters as much as this specific model: open-weight alternatives are closing the capability gap fast enough that 'we use Claude/GPT because it's best' is no longer a complete answer. 'Best for which workflow, at what cost, with what deployment constraints' is the right question now.