Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

`GET /coding/v1/usages` reports contradictory quota: `usages.limit_7d.used_ratio = 0` while the weekly quota is exhausted and the API returns 403

Aperta
  • Qualcosa non va?
#3,951 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
api

Direzione di ricerca

Start by locating the managed quota response parser and the managedQuotaEntrySchema/managedQuotaUsagesSchema definitions referenced in the issue. Compare the raw /usages response keys and values with the parsed limit_7d data, then check the related quota handling tests or add coverage so exhausted weekly usage is represented consistently or the authoritative field is documented.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What version of Kimi Code is running?

2.0.0

Which open platform/subscription were you using?

managed:kimi-code (Kimi For Coding), global region — base_url = "https://api.kimi.ai/coding/v1"

Which model were you using?

kimi-for-coding

What platform is your computer?

Linux x86_64, Ubuntu 24.04.5 LTS

What issue are you seeing?

GET {base_url}/usages returns three different views of the same quota state, and they contradict each other. Two of them say the weekly window is completely free while the account is actually out of weekly quota.

Running a prompt fails with a hard 403:

$ kimi -p "/status"
error: failed to run prompt: provider.auth_error: 403 You've reached your weekly (7-day)
usage limit. Your quota will reset when the current 7-day window ends.

Immediately afterwards, with a freshly refreshed token, the usage endpoint returns HTTP 200 with this body:

{
  "usage": {
    "limit": "100",
    "used": "100",
    "resetTime": "2026-09-24T02:09:07.465054Z"
  },
  "limits": [
    {
      "window": { "duration": 300, "timeUnit": "TIME_UNIT_MINUTE" },
      "detail": {
        "limit": "100",
        "remaining": "100",
        "resetTime": "2026-09-21T01:09:07.465054Z"
      }
    }
  ],
  "usages": {
    "limit_5h": { "used_ratio": 0, "reset_time": "2026-09-21T01:09:06Z" },
    "limit_7d": { "used_ratio": 0, "reset_time": "2026-09-24T02:09:06Z" }
  }
}

The inconsistency:

Field Says Reset
usage.used / usage.limit 100 / 100 → exhausted 2026-09-24 (weekly)
usages.limit_7d.used_ratio 0 → nothing used 2026-09-24 (weekly)
usages.limit_5h.used_ratio 0 → nothing used 2026-09-21 (5h)
limits[0].detail.remaining 100 of 100 → free 2026-09-21 (5h)

usage and usages.limit_7d describe the same 7-day window — they share the same reset timestamp — but report opposite states. The 403 confirms usage is the correct one, so usages.limit_7d.used_ratio appears to be stale or never populated.

Why it matters

Any client that reads usages.limit_7d.used_ratio concludes there is 100% of weekly quota left and keeps sending requests, each of which is rejected with 403. That is the natural field to read: it is the only one expressed as a ratio and the only one that splits the 5h and 7d windows explicitly.

Possibly related: field naming

The response uses snake_case (used_ratio, reset_time, limit_5h, limit_7d). Strings extracted from the 2.0.0 binary suggest the client-side schema declares these in camelCase:

managedQuotaEntrySchema = object({ usedRatio: number, resetAt: string().optional() });
managedQuotaUsagesSchema = object({
  limit5h: ..., limit7d: ..., monthTotal: ..., monthCode: ...
});

I could not confirm whether a key transform is applied before validation, so this may be a non-issue — but if the schema is applied directly to the raw response, those fields would never match and the parsed quota would come back empty.

Expected behaviour

usages.limit_7d.used_ratio should reflect the same state as usage.used / usage.limit (here: 1.0, not 0). Alternatively, if usages is deprecated in favour of usage + limits[], documenting which field is authoritative would be enough.

How to reproduce
  1. Use an account whose weekly (7-day) quota is exhausted — confirmed by a 403 on any prompt.
  2. GET {base_url}/usages with Authorization: Bearer <access_token>.
  3. Compare usage.used / usage.limit against usages.limit_7d.used_ratio.
Lingua principale
TypeScript
Stelle
7.7k
Fork
1.3k
Merge medio
12h 34m
PR unite (30g)
307

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MoonshotAI/kimi-code

Tutte le issue di MoonshotAI/kimi-code

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.