Feature Request: Expose Kimi Code usage limits and reset times through ACP

Feature Request: Expose Kimi Code usage limits and reset times through ACP

I am developing an ACP client for Visual Studio 2026 and would like
to display the same usage information that users can currently see in
the Kimi Code Console / /usage.

At the moment, ACP is the entry point for IDE integrations, but it does
not appear to expose quota state, usage percentages, remaining capacity,
or reset times. The docs describe kimi acp as the subprocess entry
point for IDEs, while quota information is currently exposed through the
console or /usage.

There are related issues about quota UX and ACP token usage, but I could
not find a feature that exposes the full quota/reset state to ACP
clients.

Use case

Third-party IDE integrations need to show users:

• total usage
• Kimi / Code usage split
• 5-hour Code usage
• 7-day Code usage
• current percentage used
• remaining capacity if available
• reset time for each quota window
• membership / plan status if available
• whether the user is currently quota-blocked

This would allow IDEs to reproduce a Usage Progress panel directly
inside the editor, without requiring users to open the Kimi web console.

Proposed ACP capability

Add a capability such as:

{
  "usage": true
}

Then expose a request such as:

{
  "method": "usage/get"
}

Example response:

{
  "usage": {
    "total": {
      "label": "Total usage",
      "usedPercent": 0,
      "resetAt": "2026-08-01T00:00:00Z"
    },
    "codeFiveHour": {
      "label": "5-hour Code usage",
      "usedPercent": 0,
      "resetAt": "2026-07-06T17:11:00Z"
    },
    "codeSevenDay": {
      "label": "7-day Code usage",
      "usedPercent": 0,
      "resetAt": "2026-07-13T12:11:00Z"
    }
  }
}

Optional fields

If available, it would also be useful to expose:

{
  "limit": 1200,
  "used": 300,
  "remaining": 900,
  "unit": "requests_or_tokens",
  "isBlocked": false,
  "blockReason": null,
  "planName": "Kimi Code",
  "timezone": "Europe/Paris"
}

Why this matters

ACP is used by IDE clients, so it should allow those clients to surface
critical user-facing state. Quota and reset information directly affects
whether users can continue coding, and hiding this information outside
the IDE creates friction.

This would help:

• Visual Studio integrations
• VS Code extensions
• JetBrains ACP clients
• Zed ACP clients
• custom dashboards
• accessibility-focused IDE extensions

My goal is to make Kimi more accessible inside Visual Studio 2026 by
reproducing the Usage Progress panel directly in the IDE.

Related issues

• #2150 --- Quota / usage display UX
• #2394 --- ACP token usage reporting

I believe this proposal complements those issues by exposing quota
information through ACP so that all IDE clients can provide a consistent
user experience.

Start with the kimi acp subprocess entry point and the existing console or /usage quota flow, then review related issues #2150 and #2394. Define the ACP capability and request shape, including which usage windows, reset times, plan details, and blocked state can be supported; done means an ACP client can retrieve enough data to render a usage panel.