Convert every published weekly cap into active coding hours and the picture is blunt: all three Z.ai GLM tiers wall 25 hours into the week, Alibaba’s Qwen Coding Pro walls at 37.5 hours, and OpenAI’s Codex plans sit at a 50-hour threshold — on this index’s modeled caps, because OpenAI publishes none. Anthropic doesn’t publish enough to compute a number at all.
No vendor states its weekly limit in hours. Z.ai publishes prompts per week, Alibaba publishes requests per week, OpenAI says only that “additional weekly limits may apply,” and Anthropic describes weekly limits without a single number. Hours are the unit a working developer actually budgets in — so we did the conversion the vendors won’t.
The conversion is one line of arithmetic
Hours to the wall = weekly cap × window length ÷ per-window limit. If a plan allows 400 prompts per 5-hour window and caps you at 2,000 prompts per week, the cap holds exactly five full windows — 25 active hours. This is the `hoursToWeeklyCap` computation the live index runs for every plan with a disclosed cap.
One property makes the number unusually trustworthy: once the weekly cap binds, it does not depend on any usage assumption. The tokens-per-interaction slider, the hours-you-actually-code slider — none of it moves this figure. It is a fixed ratio of two numbers the vendor chose, which is why it deserves to be a headline stat rather than a footnote.
Every capped plan, converted
Only eight of the 64 plans in the index disclose (or credibly imply) a weekly cap on top of their rolling window. Here is each one, converted. “Published” means the vendor prints both numbers; “modeled” means the cap is this index’s own estimate because the vendor confirms a cap exists but won’t number it.
| Plan | 5-hour limit | Weekly cap | Cap status | Hours to the wall |
|---|---|---|---|---|
| Z.ai GLM Lite | ~80 prompts | ~400 prompts | published | 25h |
| Z.ai GLM Pro | ~400 prompts | ~2,000 prompts | published | 25h |
| Z.ai GLM Max | ~1,600 prompts | ~8,000 prompts | published | 25h |
| Qwen Coding Lite | 1,200 requests | 9,000 requests | published (tier discontinued) | 37.5h |
| Qwen Coding Pro | 6,000 requests | 45,000 requests | published | 37.5h |
| Codex Plus | ~45 messages | ~450 (modeled) | unpublished | ~50h |
| Codex Pro 5× | ~230 messages | ~2,300 (modeled) | unpublished | ~50h |
| Codex Pro 20× | ~900 messages | ~9,000 (modeled) | unpublished | ~50h |
| Claude Pro / Max 5× / Max 20× | dynamic | exists, no number | unpublished | not computable |
Z.ai: every tier walls 25 hours in — upgrading doesn’t buy endurance
All three Z.ai tiers hit the weekly wall after exactly 25 active hours, because Z.ai’s own devpack docs set every weekly cap at precisely 5× the 5-hour cap: Lite is ~80 prompts per 5 hours against ~400 per week, Pro is ~400 against ~2,000, Max is ~1,600 against ~8,000. Five full windows, then the week is over.
That ratio is the finding. Paying up from Lite to Max buys 20× the throughput inside a window, but zero additional endurance across the week. A developer coding 40 active hours loses the last 15 of them on any tier. To Z.ai’s credit, both numbers are printed plainly — flagged as estimates (“actual available usage may vary”) on the docs page behind the subscribe page — which is more than most of this cohort manages.
Qwen: 37.5 hours, and both numbers are official
Alibaba’s Qwen Coding Pro ($50/mo) walls after 37.5 active hours: the Model Studio coding-plan doc publishes 6,000 requests per 5 hours, 45,000 per week, and 90,000 per month. 45,000 ÷ 6,000 is 7.5 full windows — 37.5 hours. That clears a standard 37.5-hour European contract week almost to the minute and falls 2.5 hours short of an American 40.
The discontinued Lite tier (closed to new subscribers since March 20, 2026, per the same doc) lands at the same 37.5-hour threshold: 1,200 requests per window against 9,000 per week. Same design philosophy as Z.ai — the weekly ceiling is a fixed multiple of the window — just with 2.5 more windows of headroom.
Codex: a 50-hour threshold — but it’s our number, not OpenAI’s
Codex’s weekly cap models out to a 50-hour threshold on all three tiers, and that threshold sits past a normal work week — at 40 active hours, Codex shows no weekly wall at all on the index’s default assumptions. Be clear about the provenance, though: OpenAI’s pricing page publishes 5-hour ranges and the sentence “additional weekly limits may apply” on every plan, and nothing more. The 450 / 2,300 / 9,000 weekly figures in the table are this index’s reconstruction — 10× each plan’s midpoint 5-hour estimate — not OpenAI-published numbers, and they carry the same uncertainty as any modeled figure.
If the model is right, the practical read is favorable: a cap that binds only past 50 active hours is a cap most subscribers never feel. Raise the index’s active-hours assumption above 50 and the wall appears; below it, the 5-hour window is Codex’s only operative constraint.
Anthropic: a wall with no number on it
Anthropic confirms weekly limits exist on Claude plans but publishes no figure to convert — the plan-choice doc describes Max tiers only as “5×” and “20×” Pro capacity per session, the Claude Code plan doc describes how the 5-hour reset and weekly limits apply without numbering either, and the cost-management docs cover team spend limits and rate tables without a weekly usage figure anywhere. The pricing page gives you $20, $100, and $200 — and no denominator.
So the honest entry for all three Anthropic tiers is “not computable.” For a buyer whose real question is “how many hours of my week does this plan survive,” that is itself a data point: Z.ai and Alibaba print both numbers, OpenAI prints one, and Anthropic prints neither.
How to read this
A “prompt” in Z.ai’s accounting is not a “request” in Alibaba’s, and an agentic session can burn native units far faster than an interactive one — so treat hours-to-wall as the plan’s designed endurance, not a stopwatch guarantee. What the conversion removes is the unit games: stated in hours, a 25-hour week-killer and a 50-hour non-event stop looking like comparable “weekly limits.” The index computes this live for every capped plan, and re-checks it as you move the assumptions.
See where your plan walls, at your usage →