Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de 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

Abierto
  • ¿Algo no está bien?
#3,951 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
7.7k
Forks
1.3k
Merge medio
12 h 34 min
PR fusionados (30 d)
307

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MoonshotAI/kimi-code

Todos los issues de MoonshotAI/kimi-code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.