# GLM Coding Plan Review: Four Months of GLM-5.3 Behind Claude Code
> Z.ai's GLM Coding Plan measured from the inside: what a Max tier delivered to a fleet of unattended Claude Code workers from July to November 2026, which meter actually stops you (it is not the credits), what the attempts died of, what the same tokens cost at list price, and which tier fits which kind of week.
- Canonical: https://jedarden.com/guides/glm-coding-plan/
- Published: 2026-11-09
- Last verified: November 9, 2026 (2026-11-09)
- Tested with Claude Code 2.1.319 and Codex CLI 0.167.0 — telemetry through November 9, 2026. (2026-11-09)
- Tags: glm, z-ai, claude-code, subscriptions, fleet-ops, cost
---
**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.
| Tier | Per month (yearly billing) | Credits per 5 hours | Credits per week |
|---|---:|---:|---:|
| Lite | $18 ($12.60) | 2,000 | 10,000 |
| Pro | $80 ($56) | 12,000 | 60,000 |
| Max | $168 ($117.60) | 28,000 | 140,000 |
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:
| Model | Input | Cached input | Output |
|---|---:|---:|---:|
| GLM-5.3 | 6.9 | 1.7 | 24 |
| GLM-5.3-Flash | 2.3 | 0.56 | 8 |
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:
```json
{
"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
| ISO week | GLM sessions | Output tokens | API errors |
|---|---:|---:|---:|
| W31 | 1,188 | 22.8M | 1,481 |
| W32 | 8,036 | 50.4M | 241 |
| W33 | 6,808 | 44.5M | 905 |
| W34 | 3,347 | 42.3M | 1,891 |
| W35 | 13,063 | 73.1M | 741 |
| W36 | 6,222 | 93.8M | 4,483 |
| W37 | 8,335 | 70.2M | 16,170 |
| W38 | 6,506 | 132.5M | 67,526 |
| W39 | 5,517 | 139.9M | 21,475 |
| W40 | 1,897 | 26.3M | 10,042 |
| W41 | 1,448 | 20.4M | 1,421 |
| W42 | 5,576 | 45.5M | 1,222 |
| W43 | 1,548 | 29.3M | 474 |
| W44 | 1,953 | 28.4M | 1,625 |
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](/guides/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.
| Month | Vendor-metered tokens | Model calls | Hours at 100% of the 5-hour window | Hours at 90% or more |
|---|---:|---:|---:|---:|
| August (from the 11th) | 34.1B | 565,900 | 11 | 18 |
| September | 50.0B | 726,016 | 0 | 1 |
| October | 8.3B | 127,384 | 0 | 0 |
| November (to the 9th) | 5.5B | 86,429 | 0 | 0 |
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.
| Claude Code on the GLM plan (2,879 failures of 8,302 attempts) | Share | Codex CLI (2,834 failures of 9,708 attempts) | Share |
|---|---:|---|---:|
| Stream cut by the gateway (HTTP 499) | 41% | Finished without shipping a commit | 32% |
| Uncommitted work left in the checkout | 12% | Close verification failed | 26% |
| `npm test` failed | 11% | Uncommitted work left in the checkout | 18% |
| Repository verify script failed | 9% | Agent exited non-zero before any gate | 6% |
| Agent hit its turn limit | 6% | Needed a human step | 3% |
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:
| Model | Sessions | Median output tokens | Median duration | Median tool calls | Shell share of tool calls |
|---|---:|---:|---:|---:|---:|
| GLM-4.7 (July to August) | 33,345 | 3,223 | 5.9 min | 16 | 70% |
| GLM-5.3-Flash | 23,933 | 11,931 | 11.4 min | 18 | 79% |
| GLM-5.3 | 5,071 | 16,998 | 15.1 min | 28 | 79% |
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.
| Month | GLM output tokens, all machines | Share on GLM-5.3 | List-price equivalent | Max tier, monthly |
|---|---:|---:|---:|---:|
| July | 102.7M | 0% (GLM-4.7, priced as Flash) | about $360 | $168 |
| August | 229.1M | 6% | about $1,200 | $168 |
| September | 546.3M | 14% | about $4,060 | $168 |
| October | 125.1M | 19% | about $1,080 | $168 |
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.
| If your week is… | Flash, off-peak | GLM-5.3, off-peak |
|---|---|---|
| Five hours of pairing | about 260 credits: Lite (3% of its week) | about 800 credits: Lite (8%) |
| A working week of pairing (30 hours) | about 1,600 credits: Lite (16%) | about 4,800 credits: Lite (48%) |
| One always-on worker | about 8,900 credits: Lite (89%), Pro at peak rates | about 26,800 credits: Pro (45%) |
| Two workers plus a day of pairing | about 18,100 credits: Pro (30%) | about 54,800 credits: Pro (91%) |
| Ten always-on workers | about 88,500 credits: Max (63%), over Max at peak rates | about 267,600 credits: over Max |
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](/data/inference-plans/) 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.