Zhipu Max Weekly Quota Suddenly Reset — Should Developers Be Happy or Worried?

Last night (June 23), Zhipu GLM Coding Plan Max subscribers received an unexpected “gift” — their weekly quota was reset.

Some developers woke up in the morning to find their Max plan’s weekly usage drop from its previous high down to 1%, while the weekly reset countdown remained unchanged. In other words, this was not the normal cycle reset, but rather a manual quota refresh triggered from Zhipu’s backend.

The news first appeared on the Linux.do forum, where the original poster wrote: “I woke up this morning to find my Max plan weekly usage at 1%, looks like it got reset.”

It sounds like good news. But if you’ve been following Zhipu’s Coding Plan for a while, you’ll know that such “surprises” often hide deeper issues.

I. First, about this reset: What happened?

The Zhipu GLM Coding Plan has three tiers: Lite, Pro, and Max. Max is the highest tier, the most expensive monthly fee, and theoretically the most generous quota.

All these plans have a "weekly quota" mechanism — the number of tokens or prompts you can use per week is capped, and once you’ve used them up, you have to wait until the next week’s reset. The original intention of this design was to prevent a small number of users from consuming all resources in a short time, affecting others’ experience.

But here’s the problem: Normally, weekly quota resets happen at fixed times, such as midnight every Monday. This reset happened midweek, with no official announcement.

From user feedback, the characteristics of this reset are:

• Scope of impact: So far only confirmed among Max plan users, no clear reports from Pro or Lite users
• Reset magnitude: Weekly usage dropped directly to zero (displayed as 1%)
• Reset time: Evening of June 23, not a regular cycle point
• Official stance: As of publication, Zhipu had not issued any statement

What does this mean? Either it’s a system bug, some form of compensatory action, or a backend adjustment to the quota algorithm. In any case, users are left “unsure what’s going on.”

II. Zhipu’s quota mechanism: A messy account

To understand why this reset makes people feel “happy yet uneasy,” we need to figure out how Zhipu’s Coding Plan quota mechanism actually works.

Frankly, it’s a messy account.

2.1 Official claim vs actual experience: How big is the gap?

Zhipu’s official claim is that the Pro plan quota is about 15 times that of Claude Pro. That sounds tempting — Claude Pro costs $20/month and, using the Opus model for coding, many people hit the 5‑hour cooldown in under 20 minutes; if Zhipu could provide 15x that volume, the value would be staggering.

But test results tell another story.

A developer ran a complex task on the GLM‑5.1 model, only to find their weekly usage jump to 8%. After just half a day of intensive use, it reached 10%. At that consumption rate, there’s no way it lasts a week.

Their personal conclusion: The actual quota is about 1.5 to 2 times that of Claude Pro + Opus, an order of magnitude below the official “15x” claim.

Why such a big gap? The problem lies in how “quota” is measured.

2.2 Prompts ≠ number of requests: the devil in the details

Both Zhipu and MiniMax’s Coding Plans use “Prompts” as the billing unit, but the definition of this word is extremely vague.

According to analysis on Zhihu, 1 Prompt ≈ 15 individual prompt requests. In other words, when you think you’ve bought 2000 Prompts, they may actually only cover around 130 complete conversation turns.

And that’s not all. Besides total quota limits, there are also:

• QPS limits: how many requests per second
• Concurrency limits: how many requests can be processed simultaneously
• Token processing rate limits: tokens per second
• 5‑hour sliding window: some limits are calculated over a sliding window, not fixed periods

Stacking these together means you might have 95% of your quota left, but the system still refuses to serve you.

This is not hypothetical. In March, a V2EX user complained: bought the Max plan, only used under 5% of the quota (about 95% remaining), but the API returned a 429 error saying “your account has reached the rate limit.”

Users expect the plan to be like “unlimited monthly broadband” — pay once and use freely. But the actual pricing logic is more like “bandwidth billing” — you pay for total data, but the instantaneous bandwidth is capped.

This mismatch in understanding is the root cause of Zhipu’s Coding Plan reputation issues.

2.3 Old plans “graduated”: the April incident

In April, Zhipu did something that annoyed long‑time users: announced that GLM Coding Plan old packages (the no‑weekly‑limit version) would stop auto‑renewal as of April 30.

That’s right, the earliest Coding Plans had no weekly quota at all. Early adopters enjoyed true “unlimited monthly” service. But as the user base grew, Zhipu clearly found the model unsustainable, introduced the weekly quota mechanism, and forced migration of old users.

As compensation, Zhipu gave affected users two months of the corresponding new plan for free. But compensation aside, the downgrade from “unlimited” to “limited” was very real.

This explains the mixed feelings about the sudden reset: on one hand, it’s nice to get quota back; on the other, such opaque moves make the quota policy feel even less certain — if it can be reset today, could it suddenly tighten tomorrow?

III. Horizontal comparison: Quota chaos among domestic AI Coding Plans

Zhipu is not the only vendor whose quota mechanisms leave users confused. The entire domestic AI Coding Plan track has similar issues.

3.1 Billing units: each with their own definition

Different vendors use all kinds of units:

| Vendor | Unit | Conversion relationship | |------------|------------|----------------------------------| | Zhipu | Prompts | 1 Prompt ≈ 15 requests | | MiniMax | Prompts | similar to Zhipu | | Aliyun | Requests | direct count | | Volcano Engine | Requests | direct count |

This inconsistency makes cross‑product comparisons difficult. If you have 2000 Prompts with one, 10,000 requests with another — which is more? You can’t tell without calculating.

3.2 Quota windows: sliding vs fixed

Another pitfall is the time window for quotas.

Some vendors use a fixed window: e.g., reset at midnight every Monday — simple and clear.

Some use a sliding window: e.g., a 5‑hour sliding window from when you start using. This means if you start heavy usage at 2 pm, run out by 3 pm, your first chunk of quota only comes back at 7 pm — not at some fixed time.

Sliding windows are unfriendly to heavy users. If your work style is “go hard for a few hours,” you’re likely to hit the quota cap and then have to wait far longer than expected.

3.3 Transparency: generally failing

Almost all domestic AI Coding Plans fall short in transparency:

• Plan pages don’t list specific QPS, concurrency, or token rate limits
• API rate limit headers are incomplete — lacking remaining quota and reset time
• Quota policy changes rarely come with advance notice

This means developers can’t implement precise traffic control when coding. You don’t know your remaining quota or when you’ll hit a wall — you’re just guessing.

This is not how a mature API product should be.

IV. The real pain point for developers: It’s not about money

Interestingly, many developer complaints about Coding Plans are not “too expensive,” but “don’t feel secure using them.”

4.1 The value of the mental account

Someone wrote on Zhihu (paraphrased):

Besides saving a few dozen yuan, the more important value of a plan is removing token anxiety — not having to watch every call’s cost, not having to choose between “let the AI try again” and “never mind, I’ll fix it manually.” The peace of mind in your mental account can be worth more than the actual money saved.

This is exactly the point of Coding Plans: transform pay‑per‑use anxiety into the certainty of a subscription.

But if quota policies are opaque, actual quota is far from advertised, and sudden resets happen, this certainty is broken. Users buy “peace of mind” but get “constant anxiety.”

4.2 Speed: an overlooked experience killer

Beyond quota, speed is another underestimated pain point.

A developer reported that running a complex task on GLM‑5.1 took over an hour. That’s essentially unusable in production — you can’t expect users to wait an hour.

Slow speed has many causes: model reasoning speed, server load, network latency, etc. But to users, the cause doesn’t matter — the result does. If a model is both slow and quota‑limited, no amount of cheapness helps.

4.3 Capability vs usability: not the same

GLM‑5.1’s capabilities are genuinely strong. Many evaluations place its coding quality between Claude Sonnet 4.6 and Opus 4.6, tying with Opus in some cases.

But strong capability ≠ high usability.

A model needs several conditions to be production‑worthy:

• Strong capability (GLM‑5.1 has this)
• Sufficient speed (questionable)
• Adequate quota (questionable)
• Good stability (insufficient data)
• Solid documentation and tooling (room for improvement)

Zhipu does well on the first, but has obvious shortcomings in the rest.

V. What does this reset mean? Possible interpretations

Returning to the weekly quota reset event, there are several ways to read it.

5.1 Optimistic: Zhipu is compensating users

One possibility: Zhipu realized recent quota policies were too aggressive, hurting user experience, so they manually refreshed quotas as compensation.

If so, it shows Zhipu is listening to feedback and willing to act — a positive sign.

5.2 Neutral: Backend algorithm adjustment

Another: Zhipu is adjusting how quotas are calculated or counted, causing displayed data to change.

This may not be “giving more quota,” just a change in display. In this case, actual usable volume may not have increased.

5.3 Pessimistic: System bug or human error

It could also be pure technical issue — a backend bug or operator error resetting some users’ data.

If so, Zhipu may “roll back” the reset later, restoring quotas to their prior state.

Whatever the case, silence is not optimal. Even a brief statement — “We adjusted a mechanism, details later” — beats letting users speculate.

VI. Practical advice for developers

Given the situation, if you are using or considering Zhipu’s Coding Plan, here’s some advice:

6.1 If you’re already a Max user

• Use this reset to clear your backlog. The quota’s back — make use of it.
• Monitor quota use. Add rate‑limit handling to your code to catch issues early.
• Have a backup plan. Keep at least one alternative AI coding tool.

6.2 If you’re on the fence

• Trial before paying. If Zhipu offers a trial, test it in real work scenarios — not just with demos.
• Calculate true costs. Don’t just look at sticker price; figure out per‑unit output costs. A cheap but tight‑quota, slow plan may be worse than a pricier but stable one.
• Follow community feedback. Linux.do, V2EX, and Zhihu have lots of real user reports that are more reliable than official marketing.

6.3 General advice

• Don’t over‑rely on any single vendor. Domestic AI Coding Plans are still early‑stage, and less mature than leading overseas products.
• Build multi‑model workflows. Use different models for different tasks to avoid single points of failure and leverage each model’s strengths.
• Stay alert to changes. This space moves fast — last month’s “best choice” may already be outdated.

VII. What Zhipu should do

From a product perspective, here’s what Zhipu could improve:

7.1 Transparency

Clearly list all limits on the Coding Plan page:

• Exact definition of weekly quota (tokens or requests? how converted?)
• QPS limit
• Concurrency limit
• Token rate limit
• Precise sliding window rules

Users don’t fear many limits — they fear not knowing them.

7.2 API info completeness

Include full quota info in API response headers:

• Remaining quota
• Next reset time
• Specific reason when limits are hit

This lets developers implement precise traffic control rather than hitting a wall unexpectedly.

7.3 Build communication channels

When adjusting quotas or experiencing system issues, promptly notify users through official channels (announcements, email, in‑app messages). Don’t let them “discover” changes on forums.

Trust builds bit by bit — and is spent the same way. Each opaque move spends from that trust account.

VIII. Conclusion

The Zhipu Max weekly quota reset is neither huge nor trivial.

On a larger scale, it exposes common shortcomings in domestic AI Coding Plan maturity: opaque quota mechanisms, gaps between promotion and reality, weak user communication.

On a smaller scale, it’s just a data change, possibly “corrected” tomorrow, leaving no trace.

Either way, it’s a reminder: When choosing AI tools, don’t just look at model capability — look at overall product usability. A smart but unreliable assistant is worse than a slightly less capable but stable one.

GLM‑5.1’s model strength is real. Zhipu’s task is to wrap that into a product developers can use comfortably and confidently.

At present, there’s still a way to go.

---

If you’re using Zhipu’s Coding Plan too, feel free to share your experience in the comments — especially whether usable quota has actually changed after this reset, and whether speeds have improved. Real‑world data is more valuable than any analysis.

---

References

• Zhipu Max Quota Reset Last Night - Linux.do — first discussion thread about this event
• Zhipu: GLM Coding Plan Old Packages Auto‑Renewal Ends April 30 - ITHome — official report on Zhipu plan migration policy
• 2026 Domestic AI Coding Plan Money‑Saving Guide - Zhihu — cross‑vendor comparison of domestic AI Coding Plans