Testing GLM 5.2 Inside Claude Code on a Real SDK for Five Dollars

A Claude Code bill that keeps creeping upward is a good reason to shop for a cheaper engine. The usual suspect is GLM 5.2, an open-weight model from a Chinese lab that benchmark posts keep praising. Instead of reading more of those posts, a developer put five dollars on OpenRouter and aimed the model at a real codebase, a generative UI SDK built for React Native, checking every line it returned. The audit cost 59 cents and the build cost four dollars. The details are worth walking through, including a near-mistake about what code should ever be sent to a hosted model.

Why test it at all

Two motives drove the experiment. The first was cost. A model priced at a tenth of the usual rate that handled even half the workload would hand real money back, especially for someone who runs many agents at once, sometimes a whole harness of them. The second was curiosity about Chinese labs, which ship quickly and post eye-popping benchmark scores, but whose models had never been tried on the developer's own code.

The rule for the test was simple: use the one codebase the developer knows better than anyone, and verify every claim in the output.

The setup is shorter than expected

GLM 5.2 comes from Z.ai. It appeared in mid-June, has a one-million-token context window, and is widely described as coding like a frontier model for a fraction of the price. Public numbers support the buzz. OpenRouter's Design Arena ranks it within the top one percent for code, drawn from 3,243 head-to-head tournaments. That is still somebody else's benchmark, and benchmarks are other people's code.

Claude Code doesn't care what sits behind it. It speaks the Anthropic API format and reads two environment variables to decide where requests go. Point those at another endpoint and the whole tool keeps functioning, with the same agent, file editing and test running but a different brain behind them.

OpenRouter served as the endpoint. One account and one API key can be routed to dozens of providers, Z.ai included, so there was no need for a separate billing relationship with a foreign lab just to run one experiment. A few dollars of top-up gives access to any model behind a single key. The path has three steps.

Create the key. Make an API key on OpenRouter and add a few dollars of credit. GLM 5.2 has no free tier, though the credit stretches far: the whole experiment fit inside five dollars with room left over. The credit limit field on the key acts as the safety net, and here it was a hard cap of five dollars. After the experiment, the dashboard showed $4.59 of that cap used, covering everything described below.

Point Claude Code at it. A handful of settings does the job: the base URL goes to the OpenRouter API, the auth token is the OpenRouter key, and the default Opus and Sonnet model names are both set to the GLM 5.2 identifier.

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

With that in place, starting Claude Code means talking to GLM. Returning to Claude takes only commenting those lines out. That is the entire switch.

Pin the provider. Most people skip this step, and it matters. On OpenRouter one model name can be served by a long list of companies, and prices vary widely, from under a dollar per million tokens to above three. The spread is not coincidence. Some hosts run quantized copies of the model, which are smaller, faster and measurably dumber, and the Providers tab even includes a quantization filter for that reason. Left on auto-routing, a request might land on one of those hosts, and the tester would end up judging a compressed knockoff while believing it was the real thing.

For a fair comparison, routing was set to Z.ai directly, the first-party host, with fallbacks switched off. Every request then reached the genuine full-precision model and nothing else. If fairness is the goal, this toggle decides the outcome.

The near-mistake: not all of the code is shareable

The SDK is open source, but the same repository holds material that is not: a dynamic onboarding kit, billing, tenant logic, and the work meant to earn money. Sending the whole monorepo to a hosted model in another country is the sort of casual leak that only gets noticed after the fact.

Before anything ran, then, a clean copy was built. Only the showable parts went in, namely the SDK package and an example app with its agent backend, while the commercial code stayed on the developer's own disk. Then came the dull but important check. The copy was searched for the words that would give the game away, such as onboarding, billing, tenant and stripe, and the result was zero hits before a single token left the machine.

That habit is the real lesson. A cheap model does not change the rule. Public code may go to a hosted API. Private code stays local or does not go at all. The same reasoning once led the developer to choose a pricier but EU-safe model for a client backend, and it holds just as well when the experiment is only for fun.

Task one: read the SDK and say where it breaks

The first job was a pure reading test. GLM was asked to audit the architecture as though a new generation of tooling were about to be built on it: find the load-bearing seams, name the files, say what would crack first. One rule mattered most. Every claim had to cite a real file and line, and uncertainty had to be admitted rather than papered over with invention.

The model read forty-one files and returned an audit that surfaced three real problems the developer already knew about:

• Component types are sealed into the bundle at app start, so an agent cannot define a new component at runtime, which is exactly what the next feature requires.
• Streaming silently does nothing on the primary agent path, since the adapter responsible never got a streaming method written.
• A drift bug had been ignored: the SDK can render thirteen components, but the server allows only eleven and tells the model about just seven, leaving two perfectly good components unreachable through the agent.

None of it was taken on trust. Each citation was checked with grep against the code, and they held up. File paths and line numbers were correct, and the model had not invented a single function. It even caught something nobody had flagged: a backend comment proudly saying it used the latest Claude models, sitting right above code that actually calls a cheaper OpenAI model. A stale comment had turned into a small lie. That is a sharp catch from a model the developer had been ready to dismiss.

The audit cost 59 cents and took six minutes.

Task two: change the code

Reading is where every model looks clever, so the next step was to let it touch the code. It received the hardest fix from its own audit: end component drift for good. The SDK would become the single source of truth, a manifest would be generated from it, and the server would read that manifest instead of a hand-typed list, so the two could never diverge again. A test had to fail if they ever did.

The model completed every part. A manifest came out of the SDK, the server was switched over to consume it, the two stranded components became proper built-ins and so turned reachable at last, and a guard test for drift was added. The developer's own run of the suite showed ninety-two passing tests, the original eighty-seven untouched plus five new ones. Then came a deliberate attempt to break it: deleting a component from the manifest by hand and re-running the guard. It failed loudly, in the right place. The safety net had teeth.

Along the way the model also ran into an annoying toolchain trap, a React Native syntax issue that stops the test runner from loading certain files. It neither hid the problem nor gave up. It built a small workaround and recorded the issue as a caveat in its report, an honesty worth more than a tidy-looking result.

The catch

The build cost four dollars against 59 cents for the read, and that gap is what the hype videos leave out. On reading, GLM was a clear win: about ten times cheaper than the usual setup, and three times faster. On building it succeeded, but most of the four dollars went on grinding through the test harness, a loop of run, read the error, edit and run again, repeated across roughly three hundred turns. Only about thirty of those steps were real code changes. The rest was stamina.

So the conclusion is narrower than "GLM replaces the existing setup." For reading, reviewing, auditing and explaining a codebase, work where the model thinks hard once and returns an answer, GLM 5.2 is a genuine bargain and worth choosing on purpose. For long unattended building, where cost accumulates in debugging loops, it still gets there, yet the savings shrink and the case for a frontier model returns.

One afternoon, five dollars and familiar code produced a definite answer where a feed of hot takes never would, which made it the cheapest research of the month.

Putting it to routine use

Two routes follow, depending on the code.

For anything public, the OpenRouter config stays in a commented block inside the Claude Code settings. For a cheap second opinion on an open-source repository, an architecture read or a "what is wrong with this" question, remove the comment marks, fix the provider to Z.ai and let GLM handle the heavy reading for pennies. Claude stays the default when it is time to build.

For anything private, the model goes to the code and not the other way round. That means local weights or nothing.