[Feature] Let paid Coding Plan subscribers spend their Coding Plan tokens inside chat.z.ai (shared quota / priority / model unlock)

Summary

Allow paid Coding Plan subscribers to use their Coding Plan token quota inside chat.z.ai — to expand the live chat's per-conversation token limits, raise request priority, and/or unlock models that are otherwise gated behind the chat-side plan.

Today, the Coding Plan quota (api/coding/paas/v4) and the chat.z.ai quota (chat.z.ai) are billed and tracked as two completely separate pools. A user who has paid for a Max Coding Plan still hits the regular Free/Pro chat limits when they switch tabs to chat.z.ai — even though they've already paid Z.AI for a large monthly token budget. This is both a billing-fairness issue and a retention issue.

Current Behavior

• A user subscribes to a Coding Plan (Pro or Max). Their token quota is scoped to programmatic API / coding-tool usage at https://api.z.ai/api/coding/paas/v4.
• The same user, when using chat.z.ai in the browser, is subject to a completely separate quota / plan:
  • Per-message and per-5-hour limits are calculated against the chat-side plan only.
  • Coding Plan tokens are not applied — they sit unused if the user is primarily in chat.z.ai for a given task.
  • Model availability on chat.z.ai is gated by the chat plan tier, regardless of whether the user's Coding Plan would already grant access to that model via API.
• Practical effect: a Max Coding Plan user who lives in chat.z.ai for an afternoon of debugging gets rate-limited the same as a free user, then has to context-switch to a terminal + curl/SDK to "actually use what they paid for."

Desired Behavior

1. Quota sharing / fallback. When a user's chat.z.ai quota is exhausted (or about to be), allow the system to draw from the Coding Plan token pool for the remainder of that billing cycle — instead of hard-stopping or downgrading the user.
2. Priority boost. Paid Coding Plan users get the same request priority on chat.z.ai that they already get on the API endpoint — no separate "chat priority" upgrade required.
3. Model unlocking. Any model the user's Coding Plan already grants access to (e.g. glm-4.6, glm-4.5-air, future coding-tuned variants) should be selectable in chat.z.ai without an additional chat-side upgrade.
4. Unified usage dashboard. The customer portal should show a single "monthly token budget" view that combines Coding Plan + Chat usage, with a clear breakdown — so users can reason about one pool, not two.
5. Per-conversation toggle (optional). Let the user explicitly opt a given chat.z.ai conversation into "use Coding Plan quota" mode — useful for heavy debugging sessions where they want to explicitly consume the coding budget rather than the chat budget.
6. No double-billing. A token consumed on chat.z.ai should decrement exactly one pool, not both. The choice of which pool should be configurable (default: chat-first, then coding fallback) and visible at the time of consumption.

Why this matters

• Fairness. Users are paying Z.AI twice for the same underlying compute (Coding Plan + Chat Plan), with no way to let one subsidize the other. That feels punitive, especially for Pro/Max subscribers.
• Retention. The single most common reason a paid user opens a support ticket is "I paid for Max, why am I being rate-limited in chat?" Eliminating that friction directly reduces churn.
• Product coherence. "Coding Plan" already implies the user is a developer who uses Z.AI across multiple surfaces (API, coding tools, chat). Pretending chat is a separate product with separate billing is artificial — the same person is on both sides.
• Competitive parity. OpenAI, Anthropic, and others increasingly let a single subscription (e.g. ChatGPT Pro / Claude Max) cover both chat-side usage and API-adjacent usage under one quota. Z.AI's split model is now an outlier.

Use Cases

• Long debugging session in chat.z.ai. A Max Coding Plan user pastes a 50k-token stack trace and asks for triage. They blow through the chat 5H limit in two messages. Today: blocked for 5 hours. With this feature: chat-side quota runs out, then seamlessly continues on Coding Plan quota.
• Trying a coding-tuned model in chat. A user wants to sanity-check a model that's available via their Coding Plan but not exposed on chat.z.ai for their chat tier. Today: not possible without an upgrade. With this feature: the model shows up in the chat model selector because the Coding Plan grants it.
• Single monthly budget. A team lead wants to allocate "Z.AI spend" for the month across chat + API. Today they have to manage two budgets. With this feature: one pool, one dashboard, one line item.

Related

• #122 — chat.z.ai: switch model mid-conversation. This feature is a prerequisite for #122 being useful at scale — without quota sharing, switching to a higher-tier model mid-chat just triggers rate-limiting faster.
• #123 — Customer portal 5H next reset shows date only. Same "portal needs unified, accurate usage info" theme; a unified token dashboard (this issue) and an accurate reset timestamp (#123) should ship together.
• #125 — Private helpdesk / support ticketing. The #1 support ticket topic this would eliminate is "I paid for Max, why am I rate-limited in chat?" — fixing the root cause reduces load on the (currently missing) helpdesk.

Notes

• Implementation-wise, this is a billing-side change, not a model-side change: the chat backend already knows how to call the same models the API exposes; it just needs to be authorized to debit the Coding Plan pool when the chat pool is empty.
• Suggested v1 scope: (a) fallback-only (chat quota first, then coding) and (b) model unlocking. The unified dashboard and per-conversation toggle can be v2.
• If there's a hard business reason to keep the pools separate (e.g. chat-side margins differ from API-side), a reasonable middle ground is a conversion ratio (e.g. 1 Coding Plan token = 0.8 chat tokens) — but it must be transparent and visible before consumption, not a silent surcharge.

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

No implementation files, tests, or entry points are identified. Start by reviewing the Coding Plan and chat.z.ai quota behavior described here alongside issues #122, #123, and #125, then clarify the v1 scope. Done should include an agreed quota fallback and model-unlocking design with no double-billing; dashboard and per-conversation controls are listed as v2.