GLM Coding Plan Review: Four Months of GLM-5.3 Behind Claude Code

The GLM Coding Plan is the cheapest way I know to keep a coding agent busy around the clock, and the thing that stops you is not the thing on the pricing page. Z.ai sells a subscription that lets Claude Code, Codex, OpenCode, Cline and about twenty other tools run GLM-5.3 and GLM-5.3-Flash instead of the vendor’s own models, for $18, $80 or $168 a month. Since July 2026 a fleet of unattended Claude Code workers on my machines has run on it: about 116,000 sessions, a billion output tokens, and 1.5 million model calls that the vendor’s own usage dashboard counted. This is what that bought, what it broke, and who should buy which tier.

TL;DR — Buy it if you want cheap, unattended throughput on work that has a test suite to catch the model: the fleet closed about 40% of its attempts on GLM against 50% for Codex at a reasoning budget that costs ten times more. Lite covers a person pairing with one agent all week. Pro covers one always-on worker on either model. Max covers a fleet of roughly eight to sixteen Flash workers by credits, which is also about where its concurrency cap sits, and that cap, not the credit meter, is the wall you will actually hit. Do not buy it as a replacement for a frontier model where a person is steering and every minute of their time counts: attempts took five times longer than Codex and a quarter of failures were the model running out of road. The five-hour credit window never bound a Max account at ten to twenty workers after the switch to GLM-5.3; the plan’s concurrency cap did, every busy hour.

What you are buying#

The plan is a credit allowance in two windows, spent through supported tools only. Prices are as displayed on the plan page on 2026-11-09; the yearly figures are billed up front.

The vendor’s own labels for the three are “one project at a time”, “6× Lite usage, one to two projects” and “14× Lite usage, two or more projects”.

A credit is a weighted token count. Every model call costs (input tokens × input weight + cached input × cache weight + output × output weight) ÷ 10,000, and the weights are what make the two models feel so different:

Off-peak usage costs half. Peak is weekdays 14:00 to 18:00 Singapore time, which is 06:00 to 10:00 UTC, so a US or European working day is almost entirely off-peak. The five-hour window starts when you first spend from it and refills five hours later; the weekly window starts at your order time and resets every seven days. The vendor’s own estimate for Max is 676 to 1,352 million GLM-5.3 tokens a week at a 95% cache-hit rate, the low end if you only ever work during Singapore’s afternoon.

Three policy lines matter more than the arithmetic. The plan may only be used inside officially supported tools, not called as an API. Benefits are exclusive to the subscriber and account sharing is prohibited. Purchases are final; there are no refunds, and the usage policy and the FAQ disagree on whether you must cancel three days or 24 hours before renewal. The policy pages say nothing either way about unattended or automated use, which is how I use it.

Setting it up with Claude Code#

Claude Code reads a handful of environment variables that point it at a different Anthropic-compatible endpoint. The vendor’s guide sets these, either through its install script or by hand in the user settings file:

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "your Z.ai API key",
    "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.3[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.3[1m]",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-5.3-flash[1m]",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1,
    "API_TIMEOUT_MS": "3000000"
  }
}

Three things the guide does not explain. The [1m] suffix asks for the model’s million-token context, which is why the auto-compact window is raised to match; a headless worker on the fleet compacted in 0.8% of sessions, against 2.5% for interactive Anthropic sessions. The default install maps all three Claude aliases to Flash and the manual snippet maps Opus and Sonnet to GLM-5.3; pick deliberately, because the output weight triples. And the 50-minute API timeout is there because long GLM-5.3 turns take minutes, not seconds; the fleet’s median GLM-5.3 attempt ran 29 minutes against 6 for Codex.

Everything in this article ran through that configuration, with one addition: the workers do not talk to the vendor directly but through a small reverse proxy of mine that counts tokens, retries on the vendor’s error codes and holds requests below a discovered rate ceiling. That proxy is where a lot of the failures below were born, and I say so where it is.

Four months, week by week#

Read it in three acts. From late July to the end of August the fleet ran GLM-4.7, the model the plan shipped with: short sessions, a median of 3,200 output tokens and six minutes, sixteen tool calls. On September 1 the workers moved to GLM-5.3 and GLM-5.3-Flash and the shape changed: median output quadrupled to 12,000 tokens on Flash and 17,000 on GLM-5.3, sessions ran eleven and fifteen minutes, and the weekly token count doubled while the session count fell. The error column exploding in weeks 37 to 39 is the concurrency wall, and the next two sections are about it. From October the fleet was deliberately cut back and a Codex fleet took the larger share of the queue, which is the comparison in Codex vs Claude Code.

Across all four machines the GLM side of that period came to 116,226 headless sessions and 1,003 million output tokens, and the vendor’s own dashboard counted 1.5 million model calls on the account between August 11, when I started polling it, and today.

The meter you can see and the one you cannot#

Every plan has a five-hour window and a weekly window. The vendor’s usage API reports the five-hour one; for this account it has never reported a weekly one, and nothing I ran was ever stopped by a weekly limit. The chart is the five-hour meter sampled every hour for 91 days.

Two things stand out. First, the window filled only in August, on seven days, for eleven hours in total, all of it on GLM-4.7 with twenty workers running flat out. After the switch to GLM-5.3 the fleet never reached 100% again, and passed 90% for exactly one hour, while sending more tokens per week than before. The median hourly reading over the whole period is 5%, the 90th percentile 38%. Second, this account was bought under the earlier prompt-counted version of the plan and prepaid for a year; it reports a Max tier but only one window. A plan bought today carries a 140,000-credit weekly cap, and September’s volume works out to several times the vendor’s own stated weekly token estimate for Max. I cannot tell you how the weekly cap behaves when you hit it, because I never did. The calculator further down tells you whether you would.

What did stop the fleet was something the pricing page does not list.

The concurrency wall#

When the vendor refuses a request it returns an HTTP 429 with a body code. Code 1302 is “too many requests in flight on this account”; 1303 and 1305 are request-rate limits; 1308 and 1310 are credit exhaustion. In four months of transcripts and proxy logs, every refusal I have was a 1302. Not one was a credit code.

The transcripts recorded 2,376 of those 429s reaching Claude Code, which retries each up to ten times before giving up. The proxy’s own logs on the three worst days of September held 178,000, 231,000 and 199,000 lines containing a 429, forty-odd percent of everything it logged, arriving in waves that match the fleet’s dispatch cycle. In one half-hour sample it completed 770 requests and absorbed 2,270 upstream refusals, with between nine and fifteen requests in flight at any moment. That is the number to remember: at the Max tier, in September, the account sustained roughly ten to fifteen concurrent model calls, and the twentieth worker bought nothing but retries.

This inverts the usual intuition about a prepaid plan. The account was credit-rich and concurrency-poor. Adding workers could not spend the credits faster; the only levers that moved credit burn were the model tier and the length of each response. The vendor’s policy page says what the limit is without saying what the number is: concurrency “is tied to your plan tier”, Max above Pro above Lite, dynamically raised during off-peak hours. The recommended “two or more projects” for Max is a reasonable gloss on ten to fifteen in-flight calls when each Claude Code turn holds one.

Two practical consequences. If you run more than one agent, a shared queue in front of the vendor is worth having: Claude Code’s own retry gives up after ten tries and the attempt dies, while a proxy that waits for a slot converts refusals into latency. And do not read the credit meter as a capacity gauge. The fleet’s five-hour meter sat at 5% while its workers spent whole minutes being refused.

What a GLM attempt dies of#

The fleet records why every attempt failed. Here are the five largest reasons for Claude Code on the GLM plan next to the five largest for Codex, over the 49 days both have traces.

The shapes differ. Codex’s failures are process failures: the work was done, or nearly, and the paperwork was not. GLM’s largest failure was not the model at all. The 499 is a request cancelled mid-stream, and 1,187 of them were my proxy’s fault: it waited for a rate-limit slot before reading the request body, a long session’s multi-megabyte body sat in the socket, and an ingress timeout cut the connection at sixty seconds. On one repository eight of thirteen attempts in an afternoon died that way after fifteen to forty minutes of work each. It was fixed on October 29 and no attempt has died of it since, but every unattended GLM setup I have seen has some version of this problem: long turns, big bodies, and a timeout somewhere in the path that was tuned for a chat.

Strip that out and GLM’s remaining failures are the model’s: tests that did not pass, verify scripts that did not pass, and the turn limit. A further 25.5% of GLM attempts ended by splitting the task into smaller ones instead of delivering it, against 20.9% for Codex; both fleets prefer to decompose rather than fail, and GLM reached for it more.

On yield, the two GLM models were indistinguishable: Flash closed 39.4% of its 6,752 attempts and GLM-5.3 41.0% of its 1,570, at the same median half hour. Codex on gpt-5.6 at its highest reasoning setting closed 54.3%, in six minutes. The gap is real and it is also not the whole story: the harnesses were pinned to different repositories, and the GLM workers held the long, grinding tail of the backlog for two months before the Codex fleet existed. Premature closes were similar across the three, 16.5% of GLM closures reopened against 18.4% for Codex.

A session on GLM looks like this, from 96,000 transcripts on one machine:

GLM-5.3 reads more and runs more commands before it writes; Flash writes sooner. Both lean on the shell more than Anthropic’s models did on the same harness (71% for Sonnet), and neither reached for subagents or web search to any measurable degree.

What the same tokens cost at list price#

The plan is a prepaid allowance, so the honest comparison is not with another subscription but with what the vendor charges for the same tokens by the million. List prices on 2026-11-09 are $1.40 input, $0.26 cached and $4.40 output for GLM-5.3, and $0.15, $0.03 and $0.50 for Flash. The fleet’s measured mix sends 5.4 uncached and 72 cached input tokens for every output token, so the list price of one million output tokens of fleet work is about $3.50 on Flash and $30.70 on GLM-5.3.

Roughly $6,700 of list-price inference for four months of a $168 plan, most of it in September. That ratio is the entire argument for the plan, and it comes with its own caveats: the ratio was achieved by a fleet that never idles, at a Max tier that was never weekly-capped, on a model whose attempts closed less often and ran five times longer. A person pairing with an agent for an evening will consume a small fraction of this and pay the same $18 or $80.

Which tier fits your week?#

The calculator below uses the fleet’s measured mix per call and the plan’s published weights to turn a week into credits. Steering hours count as one session-hour each; an always-on worker counts as 168 session-hours a week at the fleet’s measured pace of about 21 calls an hour.

The five-hour window is generous next to the weekly one. Max’s five-hour allowance refills at 5,600 credits an hour but the weekly one at 833, so nothing a single agent does will touch either, and a fleet that never stops meets the weekly cap first. Peak-hour pricing matters less than it looks: a weekday afternoon in Singapore is the small hours in America and the morning commute in Europe, so most readers will pay the half rate most of the time. The one thing the calculator cannot model is the concurrency cap, because the vendor does not publish it; the fleet’s experience is that at Max it arrives at ten to fifteen simultaneous calls, which is about where the credits run out for Flash workers too.

Where it fits, and where it does not#

Buy Lite if you are one person pairing with one agent, even all week. Ten thousand credits is a hundred to two hundred Flash sessions of fleet shape, or thirty to sixty-five on GLM-5.3, depending on when you work, for the price of two coffees. One always-on Flash worker fits too, barely, if it works off-peak.

Buy Pro for one worker that never stops, on either model, or for two people sharing a backlog. Buy Max if you run a fleet, or you want a second meter that does not fail in the same week as your Anthropic or OpenAI plan. The step from Pro to Max buys concurrency as much as credits; if you have ever seen a 1302, you want Max.

Pair it, do not replace with it. Every Claude Code or Codex plan I have measured was exhausted by about two always-on workers. The GLM plan carried twenty for a sixth of the price, at a lower close rate and a slower pace, on a queue where the test suite did the judging. The frontier model is the one you sit next to; the GLM plan is the one that works the night shift. The cost guide’s plan finder puts this plan next to twenty-five others on the same tokens-per-dollar axis.

Do not buy it to run a single agent that you watch closely, if a 29-minute attempt instead of a six-minute one costs you more than $150 a month in your own time. Do not buy it expecting the credit meter to tell you when you are out of capacity; watch for 1302s instead. And read the policy: supported tools only, no account sharing, no refunds.

Two facts a reader may weigh differently from me. The provider is a Singapore-registered subsidiary of a Beijing model lab, and its API terms state that customer content is processed in real time, not stored, and not used for training without explicit agreement. I have no way to verify either beyond the published terms, and my fleet’s work is public-repository code. If yours is not, that is a decision, not a footnote.

Records and refreshing this#

Every number above has a source file. The vendor-side series come from the account’s own usage API, polled hourly since August 11: tokens per model, model calls, and the five-hour window’s used share. The fleet-side numbers come from Claude Code’s transcripts on four machines, 158,773 files between July 9 and October 31, and from the attempt traces the fleet writes for every task since September 12. Pricing, credit weights and policy wording were read from the vendor’s pages on 2026-11-09, and the tools-tested line under the title records which Claude Code and Codex versions the setup was checked against.

Plans move. The credit system replaced prompt counting on July 30; GLM-5.3 replaced GLM-4.7 as the routed model during September; the proxy bug behind 41% of failures was fixed on October 29. A weekly check compares the installed tools against the versions recorded here and files a refresh when either moves a minor version or the telemetry horizon passes ninety days. If you are reading this after one of those has happened and the article has not been updated, trust the shape of the findings over the figures: the wall is concurrency, the weekly window binds an always-on worker, and the plan is cheapest where a test suite does the judging.