GLM Coding Plan is a coding subscription with shared usage quotas for supported tools. It is a different purchase from unrestricted, pay-per-token API access. The official overview advertises an entry price from $18 per month; the subscription page is the place to confirm the current tier and billing quote.
The quota system is now credit-based. Older comparisons using a fixed number of prompts can mislead because a short edit and a long repository conversation consume different amounts. We checked the current official documentation on 5 October 2026.
GLM Coding Plan pricing and tier quotas
| Tier | Five-hour credit allowance | Weekly credit allowance |
|---|---|---|
| Lite | 2,000 | 10,000 |
| Pro | 12,000 | 60,000 |
| Max | 28,000 | 140,000 |
GLM Coding Plan official overview · checked 5 October 2026.
We have not confirmed the current Pro, Max or annual checkout amounts in a signed-in account. The $18 starting figure is the overview’s public claim, not a quote for every tier or billing period. Use the official subscription page to obtain the final quote.
What our earlier GLM experience establishes
Malik’s existing June article records using GLM-5.2 through Claude Code and includes the original referral and subscription screenshots. That is useful evidence of the earlier purchase and client setup. It does not establish how today’s models perform on a fresh coding benchmark, and the old price screenshots should not replace a current checkout quote.
The practical takeaway is to choose a plan for the client you actually use. A coding assistant can send context, tool results and follow-up requests beyond the short instruction you type. Count that whole interaction when evaluating a subscription. Our GLM invite and earlier setup guide preserves the historical screenshots separately from the newer quota information.
How the credit calculation works
The documentation weights uncached input, cached input and output separately, then divides the weighted total by 10,000. For GLM-5.3 it lists multipliers of 6.9, 1.7 and 24 respectively. For GLM-5.3-Flash they are 2.3, 0.56 and 8. The model and context therefore affect consumption even when the task description is unchanged.
Illustrative GLM-5.3 request
A request with 10,000 uncached input tokens and 1,000 output tokens would use (10,000 × 6.9 + 1,000 × 24) ÷ 10,000 = 9.3 credits before any applicable time-based reduction. This is a calculation from the published formula, not a measured coding session.
If the same input were split into 5,000 uncached and 5,000 cached tokens, the corresponding calculation is (5,000 × 6.9 + 5,000 × 1.7 + 1,000 × 24) ÷ 10,000 = 6.7 credits. Actual caching behaviour must be observed in the tool; merely repeating a question does not prove that input will be billed as cached.
Using the Flash multipliers for the first scenario gives 3.1 credits. That lower calculated consumption does not establish equivalent coding quality or completion time. Model selection is a separate evaluation, and a cheaper request that needs several retries may be poor value.
Why both quota windows matter
The five-hour quota can constrain a concentrated session even when your weekly balance is healthy. The weekly quota can constrain repeated sessions despite a refreshed shorter window. Budget the busiest working block and the whole week, rather than converting the weekly allowance into a promised number of prompts.
Track total credits for a completed change: planning, file reads, edits, failed attempts and verification. That gives a more useful baseline than the cheapest individual request. Reserve capacity for correcting errors before deciding a plan comfortably covers your work.
A plan-selection worksheet for a real coding week
Record usage for three kinds of work: a small change in a familiar file, a change requiring repository exploration, and a debugging session with repeated verification. For each, note the selected model, starting balance, ending balance and whether the change passed its checks. This produces a useful cost per completed task rather than a misleading cost per prompt.
As an allowance comparison, imagine a completed change uses 120 credits. Ten such changes in one busy block require 1,200 credits, within Lite’s listed five-hour allowance. Twenty require 2,400 and exceed that allowance, even if the weekly balance is healthy. These assumed task costs are planning inputs, not measurements from Malik’s older setup.
Now consider ten blocks using 1,200 credits each during a week. The total is 12,000, beyond Lite’s 10,000 weekly allowance. A larger short-window balance alone would not resolve that weekly limit. Conversely, spreading a concentrated workload across more time may reduce the immediate constraint without changing its total consumption.
Include a reserve for fixing unsuccessful changes. An agent that produces a patch quickly but needs repeated corrections can consume more credits and review time than a slower successful run. Keep reliability, your review effort and quota use as separate observations; a generous allowance is not a code-quality score.
When a higher tier is worth comparing
Lite is the natural allowance to examine for occasional eligible coding work. Compare Pro when your observed busy blocks or weekly workload exceed Lite, and Max when those same observations exceed Pro. Do not buy the highest tier just because an agent can run continuously. First identify whether the limiting factor is quota, the client’s setup, model suitability or your ability to review the output.
Supported clients and ordinary API billing
The official FAQ restricts the subscription to supported tools and the documented coding endpoints. Supported coding clients share the plan quota. It says calls through that plan do not automatically fall back to the account’s cash balance when the quota runs out.
Do not point a production app at an ordinary API endpoint and assume the coding subscription covers it. Confirm the tool, model and endpoint in the official setup guide. The practical question is whether your actual workflow is eligible, not simply whether it can send a compatible API request.
Avoid paying twice for different access routes
An editor subscription, a coding-model subscription and an ordinary API balance can be separate purchases. Before connecting a client, inspect which provider and endpoint its configuration selects. A successful response proves connectivity; it does not prove that the intended subscription paid for that response.
If you need API access for an application or a non-coding agent, compare the billing route discussed in our Synthetic.new subscription and invite guide. That is a different type of access, with its own limits. It should be shortlisted by workload rather than treated as interchangeable with a coding-only plan.
Cancellation instructions currently conflict
The FAQ says to cancel at least 24 hours before renewal, while the usage policy specifies three days. Until the provider reconciles them, plan around the earlier three-day deadline and confirm the effective cancellation in your account. Both sources describe the subscription as non-refundable.
Temporary consumption campaigns also have dated terms. Do not use a short-lived reduction to promise an evergreen quota multiplier. Our existing GLM invite guide keeps the site’s current invite destination; this article does not establish a new coupon. Related guides are in AI coding tools.
How this guide was prepared: Malik Hasnain’s earlier client and offer evidence is historical. The current quota analysis uses official documentation checked on 5 October 2026; the examples above are arithmetic, not a new coding test. See how AIX Radar evaluates tools for the evidence standard.
Check GLM Coding Plan plans. Confirm the billing period, final amount and renewal terms before paying.
