Token Plan Plus yearly upgrade: total_count and usage_count return 0 for general model — quota appears unprovisioned

[nimitbhardwaj]

Token Plan Plus yearly upgrade: total_count and usage_count both return 0 for general model — quota appears unprovisioned

Summary

After upgrading from Starter yearly ($100/yr) to Plus yearly ($200/yr) on 2 Jun 2026, /v1/token_plan/remains reports current_interval_total_count: 0, current_interval_usage_count: 0, current_weekly_total_count: 0, and current_weekly_usage_count: 0 for the general model — even after actively using the API.

The dashboard shows Plus yearly as my active subscription. The API response suggests the Plus quota pool was never provisioned to the account, and active consumption is not being recorded.

This is a separate symptom from #47 (passive remains_time drain). Both are present on the same account, and it is unclear from the API alone whether one is causing the other.

Environment

Field	Value
Plan	Token Plan Plus yearly ($200/yr) — upgraded from Starter yearly ($100/yr) on 2 Jun 2026
Model	general (Claude Code CLI via Anthropic-compatible endpoint)
Subscription Key	confirmed working for /v1/chat/completions
Probe date	4 Jun 2026

Steps to reproduce

1. Subscribe to Plus yearly (or upgrade from Starter yearly to Plus yearly mid-cycle).
2. Confirm on the dashboard that Plus yearly is the active subscription.
3. Make a few chat/completions calls using the Subscription Key.
4. Call /v1/token_plan/remains and inspect model_remains[*].current_interval_total_count, current_interval_usage_count, current_weekly_total_count, current_weekly_usage_count.

Expected behavior

For a Plus yearly subscriber, on the general model:

• current_interval_total_count should be a non-zero number representing the 5-hour quota budget.
• current_interval_usage_count should equal the tokens consumed in the current 5-hour window and increase as calls are made.
• current_weekly_total_count and current_weekly_usage_count should mirror the same accounting at the weekly window level.

Actual behavior

Across two probe runs taken 30 seconds apart, with active LLM usage in between the runs (zero usage during the 30s sleep), every relevant counter is 0:

"model_name": "general",
"current_interval_total_count": 0,
"current_interval_usage_count": 0,
"current_weekly_total_count":   0,
"current_weekly_usage_count":   0,
"current_interval_remaining_percent": 13,
"current_weekly_remaining_percent":   100

current_interval_usage_count did not move from 0 to any positive value after I used the API, so the system is either not recording consumption on the general model or it is reading from a different counter for billing/dashboard purposes.

Raw evidence

Probe run A (no usage in either 30s window):

--- snapshot 1 ---
remains_time: 4,886,524
current_interval_total_count: 0
current_interval_usage_count: 0
current_weekly_total_count: 0
current_weekly_usage_count: 0

--- snapshot 2 (30s later, zero calls) ---
remains_time: 4,856,204
current_interval_total_count: 0
current_interval_usage_count: 0
current_weekly_total_count: 0
current_weekly_usage_count: 0
delta: -30,320 ms in 30 s with usage_count flat at 0

Probe run B (after some real LLM usage between the two snapshots, then 30s of no usage):

--- snapshot 1 ---
remains_time: 4,355,685
current_interval_total_count: 0
current_interval_usage_count: 0   <-- still 0 even though I used the API

--- snapshot 2 (30s later, zero calls) ---
remains_time: 4,325,211
current_interval_usage_count: 0   <-- still 0
delta: -30,474 ms in 30 s with usage_count flat at 0

Both probe runs are reproduced on the same Subscription Key, with the same Key used for active chat/completions calls between the runs.

Related issues

• [Bug] remains_time drains passively without API calls + cache-read discount not verifiable in Token Plan Plus #47 — remains_time passive drain on Plus (same plan tier, same general model). This issue is present on the same account and likely co-occurs.
• Charged twice for Starter to Pro upgrade, but plan did not change #38 — "Charged twice for Starter to Pro upgrade, but plan did not change" — same "paid, not provisioned" pattern.
• How to add previous credits left when you upgrade #40 — "How to add previous credits left when you upgrade" — related upgrade-accounting question.
• token plan api-key 无法使用 #36 — Token Plan Starter hitting 5-hour limit with 0/0 used and a 2056 reset timestamp — looks like a different instance of the same accounting subsystem behaving incorrectly.

Impact

• Plus yearly subscribers who upgrade mid-cycle may be silently running on a zero-quota bucket, while the dashboard reports the upgrade as successful.
• The "remaining percent" shown in the console is a derived value off remains_time and does not reflect either entitlement or consumption, so the UI cannot be used to detect this state.
• Because usage is not being recorded on general, any subsequent billing reconciliation or refund calculation will under-count what was actually consumed.

Request

• Confirm whether total_count: 0 for an active Plus subscription is expected (e.g. entitlement fetched lazily on first call) or a bug.
• If a bug, please re-provision the Plus quota on the general model and confirm total_count becomes non-zero and usage_count tracks real consumption.
• Add a per-call audit trail to /v1/token_plan/remains (or a sibling endpoint) so this class of "quota not provisioned / usage not recorded" failure is detectable from outside.

[nimitbhardwaj]

Additional finding: current_interval_remaining_percent is stale and decoupled from real time

While collecting more data to confirm the original report, I noticed a third, separate defect in the same response: current_interval_remaining_percent is not updating with time on my account, even though remains_time is.

Evidence

Run	Snapshot 1 remains_time	Snapshot 1 remaining_percent	Snapshot 2 remains_time (30s later)	Snapshot 2 remaining_percent
Earlier run (no usage)	4,886,524	14	4,856,204	14
This run (after real usage)	4,355,685	13	4,325,211	13

remains_time moves second-by-second (≈1:1 wall-clock decay, matching the report from #47). current_interval_remaining_percent is frozen at the same integer for the whole 30-second window in both runs. The only deltas in the percent are 14 → 13 between the two runs, which are minutes apart.

Arithmetic consistency check

5-hour window length in ms: end_time - start_time = 1780516800000 - 1780498800000 = 18,000,000 ms.

• 4,325,211 / 18,000,000 = 24.0% ← what remaining_percent should be if it tracks remains_time
• API reports: 13%

The displayed value is not even internally consistent with remains_time and the known window length. With current_interval_total_count: 0 and current_interval_usage_count: 0, the percent field has nothing real to compute against, so it is most likely a stale or cached value from a previous state — the last time total_count was non-zero and the math actually ran.

Why this is worth tracking separately from the original report

The original report (and the matching one in #47) is about remains_time decaying in real time. This is about a different field in the same response being frozen — meaning the dashboard cannot be trusted as a signal of account health. A Plus subscriber in this state sees a plausible-looking "13% remaining" bar indefinitely while actually running on a zero-budget bucket.

Suggested fix

When current_interval_total_count is 0, either:

• recompute remaining_percent from remains_time / (end_time - start_time) directly, or
• display an explicit "—" / "unknown" / "quota unprovisioned" state in the console instead of a stale integer.

A per-probe log of the inputs used to derive remaining_percent would also make this kind of mismatch trivial to triage from outside.

Happy to run more probes (longer sleep window, comparison against a different model_name, etc.) if it helps.