GLM 5.2 Review: My Honest Take After Daily Use vs Opus 4.7

Opus 4.7 in Claude Cowork on the left. GLM 5.2 in opencode on the right. Same kind of task, different price tag.

A few months back I wrote a Minimax vs GLM retrospective where I said GLM 5.1 was a serious coding model and the price made it almost unfair. GLM 5.2 dropped, I rolled it into my daily setup, and the answer is the same. Only more so.

If you're paying for Opus 4.7 today and the math is starting to bug you, this is the model worth running side-by-side. Here's my GLM 5.2 review after a couple months of real production work.

What Changed Since My Last GLM Post

Three things moved.

First, GLM 5.2 actually shipped. It's a real generational step on top of 5.1, not a point release. Coding is sharper, follow-through on long tasks is better, and there's a 1 million token context window now, which I'll come back to because it matters more than the version number.

Second, my use case got harder. The first version of my portfolio site ran on GLM 5.1 through opencode and that was the test back then. Now I'm using GLM 5.2 to manage Draftly.blog, both the headless CMS and the vibe-coded app itself. The model has been migrating that stack across WordPress, Vite, and Next.js without losing the thread, and that's not a polite use case for a cheap model.

Third, I'm comparing it against Opus 4.7 specifically, which is what I run in Claude Code today. Sonnet 4.6 too, when I need speed. Those are the things that have to feel close, or GLM stays as a fallback. Right now it's earned its way into my daily rotation.

The Real Test: Draftly.blog Across Three Stacks

Draftly started life on WordPress, got rebuilt as a Vite prototype, and now lives on Next.js. That kind of migration is brutal for any model because the patterns don't transfer cleanly. WordPress thinks in templates and hooks. Vite thinks in modules. Next.js wants you to think in server components and route segments. A coding agent that can hold one of those mental models usually flails when you cross over.

GLM 5.2 hasn't flailed. It has held the headless CMS layer and the app layer in mind at the same time, made the right calls about which pieces of the old codebase to port and which to throw away, and it did most of it while I was off doing other things. That's the thing I keep being surprised by. It's not just answering questions about code anymore. It's running.

A GLM 5.2 session on Draftly.blog inside opencode. The Context panel on the right is where the 1M window earns its keep.

I don't want to oversell this. Opus 4.7 would have done the same migration with fewer prompts and probably a cleaner intermediate state. But GLM 5.2 finished, and it didn't need me babysitting every step. For a model at this price tier, that's the bar that matters.

Why GLM 5.2 Punches Above Its Weight

There's a story you could tell where GLM 5.2 is just a really good model, full stop. I don't think that's the whole story. Two pieces of the setup matter as much as the weights.

The harness matters. I run GLM through opencode, and opencode behaves a lot like Claude Code. Same kind of tool loop, same shape of context handling, same vibe when you're working in it. If you're coming from Claude Code, the muscle memory transfers. That alone papers over a lot of small gaps between models, because the agent loop is doing as much work as the underlying tokens.

The MCPs matter. The GLM coding subscription ships with a set of MCP servers that are actually good. File tools, search, the connectors I'd reach for in Claude. I didn't have to cobble together a tool layer to make this comparable to what I'm used to. It was comparable out of the box.

And the 1M context window matters more than I expected. The Draftly migration involves the whole CMS schema, the old WordPress export, the new Next.js routes, and a handful of integration files. With 200K I'd be chunking and re-chunking constantly. With a million, I just hand it the project and ask. That's a different mode of work, and once you get used to it, going back to a smaller window feels painful.

A real session from the Draftly work: 159K tokens deep into a 1M window, with 14 user messages and 97 assistant responses still in scope. That's the mode of work the bigger window unlocks.

The Pricing Used to Be Almost Unfair (Buyer Beware)

I'm grandfathered into a legacy Z.ai coding plan at $81 a quarter. That price has more than doubled in the last few months. When I wrote about GLM 5.1 the math was cleaner. At $81 a quarter it's still cheaper than running Opus on usage-based billing, but the value proposition isn't what it was, and new buyers will pay more than I do.

If you're shopping Z.ai today, the caveat to internalize is that prices can move on you mid-subscription. I got hit by one of those moves. The Reddit threads will give you a sense of how often it has happened to other people too. Plan for the possibility that whatever you sign up for this quarter could be a different number next quarter. That's part of buying into a Chinese AI provider in 2026.

Z.ai's current public pricing. My grandfathered $81 a quarter sits well under the Pro tier shown here. New buyers don't get my deal.

Volatility aside, the lived experience is still that I'm getting a Claude-shaped tool for what one or two heavy days of Opus would cost on usage-based billing. For a side project like Draftly that doesn't have revenue justifying Claude-grade spend, that math is the whole game. Just go in with eyes open.

The Other Catch: Z.AI's Uptime (And How I Work Around It)

Reliability is the other catch. Z.ai has had ongoing connectivity issues and occasional flat-out downtime. I'm not going to pretend that's not annoying. When their servers go down mid-task it stalls whatever you're building.

The fix is the same one I gave in my Minimax post: run GLM through OpenRouter instead of Z.ai directly. The Z.ai coding plan still applies, you still get the same model, but the front door is more stable. Since I switched, I've had basically zero downtime issues. If you're putting GLM into any kind of unattended workflow, this isn't optional. Day one, route through OpenRouter.

I Just Canceled My Minimax Subscription

A side effect worth flagging. In the Minimax vs GLM post I described a split-brain setup. Minimax orchestrating, GLM coding. That was the right call at the time. It's not anymore.

GLM 5.2 through OpenRouter does both jobs well enough that I dropped the Minimax sub. Orchestration on 5.2 isn't quite as crisp as Minimax 2.7 at its best, but it's close, and the simplicity of running one model on one provider is worth the small step down. One subscription, one model, one tool loop. That's the kind of setup I want to live in.

Where Opus 4.7 Still Wins

I'd be lying if I said GLM 5.2 was at parity. Opus 4.7 still wins on a few things I won't compromise on for paid client work:

• Nuance on ambiguous prompts. Opus tends to ask the right clarifying question. GLM tends to just start building.
• Code review and refactor passes. When I want a second set of eyes on a tricky change, Opus catches more.
• The "feel" of the output. Opus's code reads like a thoughtful senior wrote it. GLM's reads like a fast junior. Both work.

For Draftly, where I'm the QA loop, GLM is fine. For client work, I'm still running Claude Code on Opus 4.7. Right tool for the cost.

My Backup Plan If Claude Goes Away

The honest test of any second-best model is what you'd do if the first-best disappeared. If Claude Code and Claude Cowork were gone tomorrow, my answer is GLM 5.2 through OpenRouter, in opencode, on the Z.ai coding plan. That's the setup I'd live in, and I wouldn't be panicking.

That's the strongest thing I can say about a model that costs me roughly $27 a month. If you're running an always-on agent, a side project, or you just want to see what the Claude-alternative ecosystem looks like in 2026, this is the one to try first.

Running GLM 5.2 in production? I'd love to hear how it's holding up on your side. Drop me a note on LinkedIn.