Why Your GLM Coding Plan Runs Out: Credits, Cache and Reset Windows

If a short GLM session has eaten more quota than you expected, don't upgrade yet. Check your plan version, both usage meters and the model actually serving the request. The number of messages you typed is only a small part of what the agent may have done.

For the listed plan details and their references, start with the GLM Coding Lite entry, then check which rules apply to your account.

A quick-looking code review can involve several workers reading the same files, running commands and carrying the results into another round. Meanwhile, a much longer conversation may reuse cached context. To explain the difference, you need the credit breakdown and a look at the work—not just the token total.

First identify the billing system

The July 30 announcement introduced credit-based plans while preserving specified legacy arrangements. It says subscriptions do not switch automatically. Check whether your account identifies a legacy cohort before applying a new-plan calculator. Official plan update.

For the current individual credit plans, the documented allowances are:

Five-hour credits refresh dynamically after consumption; the weekly cycle starts with subscription and resets every seven days. Credit use weights uncached input, cached input and output separately. Off-peak model use costs half the standard credit rate; peak hours are weekdays, 14:00–18:00 UTC+8. These are current documentation facts, not a guaranteed token allowance. Official allowance and calculation.

Read the two meters as separate constraints

Think of the short window as the constraint on a concentrated work session and the weekly window as the constraint on repeated sessions. A comfortable short-window balance does not prove that another full week of work is available.

Before a task, record both percentages and the reset times shown in your account. Afterward, record them again. If a reset occurred during the task, mark that observation as unsuitable for a simple before-and-after calculation. Otherwise, you might mistake replenished allowance for unusually efficient model use.

Do not assume the weekly clock starts on Monday in your timezone. Use the displayed reset timestamp. When comparing two sessions, record their actual times, including timezone, so a change in the rate period does not look like a change in model efficiency.

Separate repeated context from new work

A large total-token number can describe extensive reuse of existing context. Another session with fewer total tokens may contain more new input or generated output. The totals are answering different questions.

Use a small worksheet:

Treat missing cache data as missing. Do not infer a high cache hit rate from a long conversation or import a percentage from another user's screenshot.

Try one task you can explain

Choose a small, well-defined issue: explain one failing test, review one module, or implement one small change. Write down the acceptance condition before starting. Keep the same repository snapshot, tool and task when comparing configurations.

Start with one agent. Save the usage readings, then inspect the result manually. If you later introduce parallel work, assign distinct responsibilities so each worker has a reason to exist. Compare total useful output, not just how quickly the terminal became busy.

A hypothetical session that consumes 10% of a weekly allowance is a warning about repetition, not proof that exactly nine identical sessions remain. Later tasks may have different context, output length or rate conditions. Use several ordinary sessions to build a range rather than extrapolating a single unusually easy or difficult run.

Change the cause before buying capacity

Upgrade when useful, ordinary work repeatedly runs into the allowance. If the agent is spending its time rereading files or retrying a broken command, fix that first. More credits will let that behavior continue longer without necessarily getting the job finished.