TL;DR
- GLM 5.2 is the open-weight model everyone is benchmarking right now: a tenth of Claude's price, a one million token context window. Instead of reading takes, I ran it on my own SDK.
- The setup is five lines in your Claude Code settings, routed through OpenRouter. Pin the Z.ai provider and turn off fallbacks, or you might be testing a quantized knockoff.
- The architecture read: 41 files, every citation real, 59 cents, six minutes. The build: it worked, 92 tests green, but cost four dollars, most of it test-loop stamina.
- My split now: GLM for the reading, Claude for the building. Private code never leaves my machine, cheap or not.
This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.
My Claude Code bill had been bothering me for a while. Not scary numbers, just creeping ones. I run a lot of agents, sometimes a whole harness of them at once, and the number at the end of the month kept drifting up. So I went looking for a cheaper engine, and the thing everyone kept pointing at was a Chinese open-weight model called GLM 5.2.
Two reasons I wanted to try it. One was pure cost. If a model a tenth of the price could do even half my work, that's real money back. The other was a curiosity I'd been avoiding, if I'm honest. The Chinese labs have been shipping fast, the benchmarks look absurd, and I had never actually run one of their models on my own code to see past the marketing.
So I put five dollars on OpenRouter and decided to stop reading takes. I'd run GLM on the one codebase I know better than anyone, my own generative UI SDK, and check every line of what it gave back.
This is what I did, what it cost, and the part I got wrong before I started.
The setup, because it's shorter than you think
GLM 5.2 is an open-weight model from Z.ai. It came out in the middle of June, it has a one million token context window, and the thing people keep saying about it is that it codes like a frontier model for a fraction of the price. The public numbers back the noise up: on OpenRouter's Design Arena board it sits in the top one percent for code, across more than three thousand head-to-head tournaments. I didn't want to take that on faith either. Benchmarks are somebody else's code.
The public claim, as of this week: top one percent for code on Design Arena, 3,243 tournaments. This article is me checking it against my own repo.
Claude Code doesn't care which model sits behind it. It speaks the Anthropic API format, and it reads two environment variables to decide where to send requests. Point those at a different endpoint and the whole tool keeps working, same agent, same file editing, same test running, different brain.
I used OpenRouter as the endpoint. The reason is simple: one account, one API key, and it can route that key to dozens of model providers including Z.ai. I didn't want a separate billing relationship with a Chinese lab to run one experiment. OpenRouter sits in the middle, I top up a few dollars, and I can try any model behind one key.
Here's the whole path, start to finish.
Three steps to set it up.
First, make the key. On OpenRouter you create an API key and put a few dollars of credit on the account. There's no free GLM 5.2 tier, but the credit goes a long way, my whole experiment ran on five dollars and I didn't finish it.
Creating the key. The credit limit field is the safety net: mine got five dollars, hard cap.
The same key after the experiment: $4.59 of the five dollar cap used. Everything in this article ran inside that.
Second, point Claude Code at it. Five lines in your Claude Code settings:
ANTHROPIC_BASE_URL = https://openrouter.ai/api
ANTHROPIC_AUTH_TOKEN = your_openrouter_key
ANTHROPIC_DEFAULT_OPUS_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_SONNET_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_HAIKU_MODEL = z-ai/glm-4.5-air
Drop that in, start Claude Code, and you're talking to GLM. To go back to Claude you comment it out. That's the entire switch.
Third, and this is the step most people skip, pin the provider. On OpenRouter the same model name can be served by a long list of different companies, and the prices are all over the place, from under a dollar per million tokens to over three. That spread is not a coincidence. Some of those hosts run quantized copies of the model, smaller and faster and measurably dumber, and the Providers tab even has a quantization filter because of it. If you let OpenRouter auto-route you might land on one of those, and then you're testing a compressed knockoff while thinking you're testing the real thing.
Same model name, a dozen hosts, a real price spread. This is why you pin the provider.
I set the routing to Z.ai directly, the first-party host, and turned off fallbacks. Every request hit the real full-precision model and nothing else. If a fair comparison is the point, this toggle is the whole game.
The part I got wrong: my own code is not all mine to share
Here's the mistake I almost made. I was about to point a third-party model at my whole monorepo.
My SDK is open source. But sitting in the same repo are the things that are not open: the dynamic onboarding kit, the billing, the tenant logic, the work that's supposed to make money. Sending that to a hosted model in another country is exactly the kind of casual leak you only notice after it's gone.
So before anything ran, I built a clean copy. I pulled out only the showable parts, the SDK package and the mental coach example with its agent backend, and I left the commercial code on my disk where it belongs. Then I did the boring but important step: I searched the copy for the words that would give the game away, onboarding, billing, tenant, stripe, and confirmed there were zero hits before a single token left my machine.
That habit is the whole point. The model being cheap doesn't change the rule. Public code can go to a hosted API. Private code either stays local or it doesn't go at all. I wrote about choosing a more expensive but EU-safe model for a client backend a while ago for the same reason, and the logic didn't change just because this one was fun to try.
Task one: read my SDK and tell me where it breaks
The first job was a pure reading test. I told GLM to audit the architecture as if I were about to build a new generation of tooling on top of it. Find the load-bearing seams. Name the files. Tell me what will crack first. And the rule that mattered most: cite a real file and line for every claim, and if you're not sure, say so instead of inventing something.
It read forty-one files. Then it handed me an audit that found the three real problems I already knew were there.
It found that my component types are sealed into the bundle when the app starts, which means an agent can't define a new component at runtime, which is the exact thing my next feature needs. It found that streaming is quietly dead on my main agent path, because the adapter that handles it never implemented the streaming method. And it found a drift bug I'd been ignoring, where my SDK can render thirteen components but the server only allows eleven of them and only tells the model about seven, so two perfectly good components were unreachable through the agent.
I didn't take its word for any of this. I went through its citations and grepped each one against the code. They were real. The file paths were right, the line numbers were right, and it hadn't made up a single function. It even caught something I hadn't flagged: a comment in my backend that proudly says it uses the latest Claude models, sitting directly above code that actually calls a cheaper OpenAI model. A stale comment that became a small lie. Good eye, for a model I was ready to dismiss.
That audit cost fifty-nine cents and took six minutes.
Task two: now fix one of them
A read is one thing. Reading is where every model looks smart. So I said: ok, you can read my code. Now touch it.
I gave it the hardest fix from its own audit: kill the component drift for good. Make the SDK the single source of truth, generate a manifest from it, and have the server read that manifest instead of its own hand-typed list, so the two can never fall out of sync again. And write a test that fails if they ever do.
It did it. It generated the manifest, rewired the server to read it, promoted the two orphaned components into real SDK built-ins so they were finally reachable, and wrote a drift guard test. When I ran the suite myself, ninety-two tests passed, the original eighty-seven untouched and five new ones added. Then I tried to break it on purpose. I deleted a component from the manifest by hand and re-ran the guard. It failed, loudly, exactly where it should. The safety net had teeth.
It also hit a genuinely annoying toolchain trap along the way, a syntax issue in React Native that stops the test runner from loading certain files, and instead of hiding it or giving up it built a small workaround and then wrote the problem down in its report as a caveat. That honesty is worth more to me than a clean-looking result.
The catch, because there is always a catch
The build cost four dollars. The read cost fifty-nine cents.
The receipt behind the "ten times cheaper" line: same audit, same 41 files, priced twice.
That's the number nobody in the hype videos mentions. On the reading task GLM was a clear win, ten times cheaper than what I usually run, and three times faster. On the build it succeeded, but it spent most of those four dollars not on the fix itself but on grinding through the test harness, run the tests, read the error, edit, run again, over and over, three hundred turns of it. The actual code changes were maybe thirty of those steps. The rest was stamina.
So the lesson I'm keeping is not "GLM replaces my setup." It's narrower and more useful than that. For reading, reviewing, auditing, explaining a codebase, the kind of work where the model thinks hard once and hands you an answer, GLM 5.2 is a genuine bargain and I'll reach for it on purpose. For long unattended building, where the cost is paid in debugging loops, it works, but the price gap closes and the reasons I pay for a frontier model come back into focus.
Five dollars, one afternoon, my own code, and a clear answer instead of a feed full of opinions. That's the cheapest research I've done all month.
How I actually use this now
Two routes, depending on the code.
For anything public, I keep the OpenRouter config above in a commented block in my Claude Code settings. When I want a cheap second opinion on an open-source repo, an architecture read, a "what is wrong with this," I uncomment it, pin Z.ai, and let GLM do the heavy reading for cents. Claude stays my default for the building.
For anything private, the model goes to the code, the code doesn't go to the model. Local weights or nothing.
If you want the exact settings block, the provider-pinning step, and the little script I use to strip a repo down to the showable parts before sending it anywhere, reply LOCAL and I'll send it over.
This was one experiment in a longer thread I keep at Code Meet AI, where I document how I actually use AI to ship real products, receipts included. It's the hosted-model sibling of my post on running Claude Code offline with a local LLM. Next week: the full three-way comparison, GLM against the frontier models on the same tasks.
If you have run GLM 5.2 or another cheap model on real code, where did it hold up and where did it fall apart for you? I'm still calibrating my own split, and the build-cost number surprised me most.
Top comments (0)