[Feature] "Reset Slots" — capped manual quota resets (3/week) so users can break through 5H / weekly limits without waiting

Summary

Add a "Reset Slots" feature: when a Coding Plan user hits a 5-hour (5H) or weekly quota limit, they can manually trigger a quota reset without waiting for the natural window to elapse. Each user gets a small, capped number of these manual resets per week (suggested: 3 per week), so the feature is useful for real emergencies without becoming a way to bypass the plan's fair-use ceiling entirely.

This directly addresses the most common pain point reported by paying developers: a long-running agentic task hits the 5H wall mid-pipeline, and the user is forced to either context-switch to another tool, switch accounts, or hard-stop work for hours — even though they have ample monthly quota left.

Current Behavior

• Coding Plan quota is enforced via two windows:
  • 5H window — rolling 5-hour cap on tokens / requests.
  • Weekly window — weekly cap (typically larger).
• When either window is exhausted, the user is hard-blocked until the window naturally resets:
  • 5H window: up to ~5 hours of dead time.
  • Weekly window: up to several days of dead time at the end of the cycle.
• There is no user-initiated reset — the user cannot trade anything (slots, credits, future quota) to shorten the wait.
• Practical impact on agentic / coding workflows:
  • A 30-minute agent run hits the 5H wall on the last tool call → entire run is wasted, work stops for hours.
  • A weekly cap hit on a Thursday blocks all weekend work, even though the user has budget left in the next week's cycle.
• Workarounds users currently resort to: (a) second account, (b) switching to a different provider mid-task, (c) abandoning the task. All three are bad outcomes for Z.AI.

Desired Behavior

1. "Reset Slots" — capped manual resets.
   • Each Coding Plan subscriber gets a fixed number of manual reset slots per week (suggested: 3 per week on Pro, 5 per week on Max — final numbers up to the team).
   • Consuming one slot immediately resets the 5H window (and optionally the weekly window, with a higher slot cost — e.g. 2 slots for a weekly reset).
2. Self-serve, in-portal.
   • A "Reset now (1 slot)" button in the customer portal, on the quota / usage page, next to the "5H next reset" timestamp.
   • Confirmation modal showing: how many slots remain this week, when slots refill, and exactly which window will be reset.
3. Clear accounting.
   • Slots are per-week, refill on the same schedule as the weekly window (not stacking indefinitely).
   • Unused slots do not roll over — keeps the feature as an emergency valve, not a parallel quota.
   • Slot consumption is logged in the usage dashboard, alongside normal token usage, so users can audit their own resets.
4. No silent abuse.
   • Hard cap on slot count per week prevents the feature from becoming a way to bypass the plan ceiling.
   • Optional: rate-limit slot consumption (e.g. max 1 slot per 30 minutes) to discourage panic-spending all 3 in a row on the same runaway agent.
5. Discovery / affordance.
   • When the user hits the 5H or weekly wall, the error message should prominently surface: "Hit your limit? Use a Reset Slot to continue now (3 left this week)." — not just "rate limited, try again later."
   • In-chat (chat.z.ai) and in-tool (Claude Code / Cline / ZCode Agent error responses) should surface the same affordance, with a deep link back to the portal reset button.

Why this matters

• Agentic workflows are bursty. A single runaway agent (especially with auto-compact, sub-agent fan-out, or multi-step tool use) can burn an entire 5H window in minutes. Punishing the user with hours of dead time for what is often a single bad prompt is disproportionate.
• Paying users expect a "panic button." Every comparable developer-facing product (OpenAI API, Anthropic Console, AWS, Vercel) has some form of "buy more / reset now" affordance for hard rate limits. Z.AI's hard-stop-with-no-override is an outlier.
• Weekend / deadline scenarios. A user who hits the weekly wall on Friday evening cannot work all weekend. 1–2 manual resets would unblock the weekend without meaningfully changing the plan economics.
• Support load. The current "I'm blocked, please reset my quota" support tickets (filed in Discord today, per #125) disappear entirely if users can self-serve.

Use Cases

• Runaway agent mid-pipeline. An agentic coding session burns the 5H cap on the 8th of 10 planned tool calls. User uses 1 slot → cap resets → agent finishes the run.
• Friday-evening deadline. User is at 90% of the weekly cap on Friday, has weekend work to finish. Uses 1 slot → continues working → finishes Saturday without waiting for Monday's reset.
• Iterative debugging. User runs the same expensive prompt 4 times while iterating. Each run hits the 5H wall. 3 slots = 3 extra iterations in the same evening.
• Avoiding account-switching. Instead of maintaining a "backup" Z.AI account for rate-limit emergencies, the user just spends a slot — single account, single billing, cleaner audit trail.

Pricing / Slot Allocation (suggested)

These numbers are a starting point — the team can tune them based on actual quota-utilization data. The key constraint is: slots must be scarce enough that they're an emergency valve, not a parallel quota.

Related

• #123 — Customer portal 5H next reset shows date only. Strongly synergistic: once Reset Slots ship, the same "5H next reset" field in the portal should also show "Reset Slots remaining: 3" right next to the timestamp. Both fixes belong together.
• #127 — Use Coding Plan tokens inside chat.z.ai. Complementary: #127 lets users spend their coding quota in chat; this issue (#128) lets them reset that quota on demand. Together they make the quota system feel like a tool the user controls, not a wall they hit.
• #125 — Private helpdesk. "Please reset my quota" is one of the top support-ticket categories today; this feature eliminates that category entirely.

Notes

• Implementation cost is low: the backend already tracks both windows and their reset times — a manual reset is just "set window_reset_at = now() and decrement slots_remaining." The work is mostly UX (button + confirmation + affordance in error messages).
• Consider a soft cap on weekly resets (e.g. 2 slots for a weekly reset, not 1) to avoid the feature being used to effectively double the weekly ceiling.
• If the team prefers a different mechanism (e.g. "bonus tokens" instead of "reset slots"), the underlying user need is the same: give the user a small, capped, self-serve way to break through a hard rate-limit wall without waiting. The slot metaphor is just the cleanest UX for it.

Regards,
Roman
http://www.rommark.dev
VIbe Coders Telegram Channel: https://t.me/VibeCodePrompterSystem

Start with related issue #123 and locate the quota/usage page, the customer portal reset control, and the quota-limit error responses mentioned here. Define the slot allocation and weekly reset rules before implementation; done should include self-serve resets, visible accounting, and consistent affordances across the listed surfaces.