/coding/v1/usages returns zeroed usedRatio on both rate windows during verified usage

Summary

GET /coding/v1/usages (both api.kimi.com and api.kimi.ai) returns usedRatio: 0 for both rate windows (limit5h, limit7d) at all times for this account — including during verified heavy usage — while the web app's GetSubscriptionStats shows the real ratios for the same windows with identical reset timestamps.

Environment

• kimi CLI 0.43.1 on Linux
• Account: Allegro (legacy plan), REGION_OVERSEA, userId dafi9ks8k36dhc0j4eh0
• Auth: CLI OAuth login (managed service), no API key involved

Steps to reproduce

1. Log in via the CLI OAuth flow.
2. Consume real quota: a single session this morning used 10.6M tokens (K3 / K3-256k models) over ~2.5 hours.
3. During the session, GET https://api.kimi.com/coding/v1/usages with the OAuth access token (also tried api.kimi.ai).

Observed

{"code":0,"data":{"kind":"ok","quota":{"extraUsage":null,"usages":{
  "limit5h":{"resetAt":"2026-09-18T12:07:12Z","usedRatio":0},
  "limit7d":{"resetAt":"2026-09-23T23:07:12Z","usedRatio":0}}}}}

Both windows read integer 0, on both regional endpoints, at every hour tested. The same zero shows in the CLI's own /usage panel (which reads this endpoint): "5h limit 0% used / Weekly limit 0% used" — while the same panel reports 10.6M tokens of session usage.

Expected vs actual (same account, same minute)

The web app (www.kimi.ai/settings/subscription) calls GetSubscriptionStats and shows real figures for the same windows:

{"ratelimitCode5h":{"ratio":0.1719,"resetTime":"2026-09-18T12:07:12.717Z"},
 "ratelimitCode7d":{"ratio":0.346,"resetTime":"2026-09-23T23:07:12.717Z"},
 "subscriptionBalance":{"amountUsedRatio":0.0711,"expireTime":"2026-10-10T00:00:00Z"}}

Reset instants match the /usages payload to the second — same windows, different numbers. The endpoint returns correct reset boundaries with zeroed ratios.

Notes

• The CLI's own bundled schema declares usedRatio as a float (number()), so integer-zero emission under verified load looks like a server-side counter/serialization bug rather than intended behaviour.
• No limit_month_total / limit_month_code entries are present in the response, though the CLI schema supports them.
• Related: #1569 (totalQuota always 99), #2937 (third-party quota display policy). This report is specifically about the returned ratios being zero during real usage.

Ask

1. Fix /coding/v1/usages to return the true per-window ratios, or document the intended semantics if 0 is meaningful here.
2. Alternatively, expose the subscription-stats figures (5h / 7d / monthly code usage) on the coding API so first-party and opt-in third-party tooling can read real quota state.

Start by tracing the CLI /usage panel to the request for GET /coding/v1/usages, then inspect the bundled schema that defines usedRatio. Compare the displayed values with the raw response and the documented subscription-stats values; done means the CLI exposes accurate window ratios or clearly documents the endpoint's intended zero semantics.