Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#3,951 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
TypeScript
スター
7.7k
フォーク
1.3k
平均マージ
12時間 35分
マージ済み PR（30日）
311

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

MoonshotAI/kimi-code のほかの issue

MoonshotAI/kimi-code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。