Effective weekly allowance appears reduced ~3–5× without announcement — instrumented before/after data. Terms change, or metering regression?

Setup

• Kimi Code Membership (Vivace tier), used for agentic coding workloads since mid-July.
• We run client-side instrumentation: a wire-level JSONL ledger built by directly investigating the API calls via scripts — recording, per day, raw token volume (fresh input + cache reads + output) across our two local seats. All figures below come from that ledger plus the account console; each number names its source. Figures marked "subscriber estimate" are workload characterizations, not ledger measurements.
• Quota-system disambiguation up front (per #2150, the two independent quota systems): "drain %" figures below are the Kimi Code weekly usage percentage from the account console (same metric in both periods); token volumes are client-side wire measurements (our ledger, not your dashboard).

Measured data

Workload characterization for the 08-15 row, so the 47% has honest context (subscriber estimate, not ledger-measured): roughly three working sessions producing under 10 PRs of output in total, plus some discussion participation, one seat active. In week 1, materially heavier all-day usage produced ~13%/day.

The arithmetic

• Week-1 anchor: ~7.8M fresh+output ≈ 13% weekly drain → implied weekly billable allowance ≈ 55–90M tokens.
• This week: ~11.7M fresh+output over two days ≈ 61% drain → implied weekly billable ≈ 19M tokens.
• Same seats, same workload class, 3–5× lower measured daily volume, ~2.3× higher drain rate. Under constant terms that combination is not possible. If cache reads (25–50× our fresh volume, effectively free in the week-1 arithmetic) were additionally re-priced, the effective change is larger still.
• Corroboration: in the current weekly window, ~47% was consumed in roughly one day by one seat (console screenshot available), versus ~13%/day in week 1 under heavier all-day load.

Timeline

The change coincides with the K3 capacity measures (the announced pause of new subscriptions to protect existing subscribers). We have found no changelog or announcement describing a change to existing subscribers' Kimi Code allowances in the same window.

Known limitations of our data (stated up front)

• The ledger covers our two local seats only; if anything else drew on the account, the implied reduction shrinks proportionally.
• 07-27 → 07-30 are absent from the ledger; the week-1 average is built from active days.
• Neither limitation changes the direction: same seats, lower measured volume, faster drain.

Related

• #2150 (two independent quota systems — addressed above by naming the source of every figure)
• #2318 (measured-vs-claimed token discrepancy — same measurement class as this report)

The ask

1. Was the effective Kimi Code weekly allowance for existing subscribers changed as part of the K3 capacity measures (including any re-pricing of cache reads)? If yes: please document it in the changelog/status page so subscribers can plan against real numbers.
2. If no such change was made: please treat this as a possible metering regression and investigate — we are happy to share the full day-level ledger privately for correlation with your billing records.

Either answer is genuinely useful. What we cannot plan against is a number that changes silently.

Start by reading related issues #2150 and #2318, then compare the wire-level ledger figures with the account-console weekly drain data described here. Done means determining whether existing-subscriber allowances or cache-read pricing changed, or whether the behavior is a metering regression, with the outcome documented or correlated against billing records.