Kimi K3.1 Pro Quota Reset: The 25% Rule and API Billing

The announced Kimi K3.1 Pro quota reset restores up to 25 percentage points of your monthly subscription allowance; it does not promise to clear every rate limit. Check the monthly usage meter first, then inspect the separate Kimi Code window if coding requests still fail. If work cannot wait, a pay-as-you-go API route provides separately billed access, with its own key, endpoint, balance, and limits.

In its October 25 announcement, Moonshot accepted responsibility for rate limits and unnecessary quota consumption on the K3.1 Pro subscription plan. It announced compensation for subscribers on every plan, alongside changes intended to reduce unnecessary subagent calls and output length.

The rules below reflect the announcement and official documentation checked as of 2026-10-26.

How much quota does the 25% reset restore?

The announcement translates into subtracting 25 percentage points from monthly usage, with a floor of zero. For the same monthly allowance, assuming no intervening consumption or scheduled billing-cycle refresh:

used_after = max(0, used_before - 25)

Equivalently:

remaining_after = min(100, remaining_before + 25)

Here, each value is a percentage of the monthly allowance.

Monthly allowance used before	Expected usage after adjustment	Expected allowance remaining
18%	0%	100%
25%	0%	100%
60%	35%	65%
100%	75%	25%

These are calculated examples, not observed account results. A subscriber who had used less than 25% gets that consumed amount restored; the formula does not create an allowance above 100%.

The distinction between percent and percentage points matters. Reducing 60% usage by 25% of that usage would leave 45% used. The announced adjustment instead leaves 35% used.

Moonshot described the restored amount as equivalent to one week of usage. That describes the size of the compensation; it does not establish a guaranteed week of coding time, a new weekly reset schedule, or extra subscription days. Use the next refresh time shown on your subscription page for your normal billing cycle.

The stated deadline for the usage-bar update was “end of day PST” for the October 25 announcement. Check the account display after that deadline rather than assuming the announcement itself proves that your account has already been adjusted.

Do Kimi subscription, Kimi Code, and API keys share the quota?

Kimi membership and Kimi Code share the monthly membership pool, while the public Kimi API Platform has separate pay-as-you-go billing. An API key can belong to either system, so the presence of a key alone does not identify which allowance you are spending.

The membership usage rules explain that membership features draw from one token-metered credit pool. Kimi Code adds shorter usage windows on top of that monthly allowance.

The current Kimi Code membership guide distinguishes new and legacy plans:

Plan group with Kimi Code access	Rolling five-hour limit	Weekly limit	Shared monthly allowance
New Plus, Pro, Max, and Ultra	Applies	Does not apply	Applies
Legacy Andante, Moderato, Allegretto, and Allegro	Applies	Applies	Applies

Legacy weekly quota refreshes every seven days from the subscription date. Both groups can still be blocked by the monthly total. Go does not include Kimi Code; K3.1 Pro itself requires new Plus or higher, or legacy Moderato or higher.

Consequently, a blanket statement that Kimi has no weekly limits is incomplete. It describes the new coding-eligible plans, not every existing subscription. Restoring monthly allowance also does not establish that an exhausted five-hour or legacy weekly window has been cleared.

Kimi Code requests from its CLI, Desktop, VS Code, and supported third-party clients use the same account entitlement. Creating another Code API key or moving from Claude Code to OpenCode does not create a fresh subscription allowance. Enabled Extra Usage can provide a paid continuation through that membership billing path.

By contrast, Moonshot’s API pricing documentation explicitly describes the public API Platform as pay-as-you-go and distinct from membership and Kimi Code. The reset announcement does not establish any refund, balance credit, or rate-limit reset for that separate API account.

For a longer explanation of the windows, see Kimi Code Limits: 5-Hour, Legacy Weekly, Monthly, and 429 Errors. Its quota-error status codes differ from the current official reference; use the current mappings below when diagnosing a request.

What still consumes quota after the change?

Useful model work still consumes tokens, including work performed by subagents. Moonshot’s announcement says it is reducing unnecessary calls and output; it does not make delegation or long answers free.

Kimi’s subagent documentation explains that each subagent works in an independent context and consumes model tokens separately. Delegation can therefore add input and output work, especially when several agents inspect overlapping material. For a small task, the main agent may complete the same job with fewer calls.

Start with a bounded task when checking consumption. For example, paste this into a coding client with a repository open:

Read this repository's README and test configuration.
Identify the command for running its existing tests.
Work in the main agent without spawning subagents.
Do not modify files or run tests.
Answer in at most 100 words, citing the files that establish the command.
If no test command is documented, say so.

This produces something you can check: the repository’s test command and supporting file locations. It also makes unnecessary delegation easier to spot than a broad request to review the entire project.

The prompt is guidance, not a hard spending cap. Inspect the client’s activity view to see whether it delegated, and use recorded consumption to assess the result. A shorter visible answer alone does not demonstrate lower total usage.

Keep the model and reasoning settings steady while comparing runs. The model configuration guide says changing models or thinking effort can invalidate the context cache and increase consumption. It also documents approximately twice the quota usage for k3.1-pro-highspeed compared with standard k3.1-pro, so use the standard model when evaluating quota efficiency unless speed is the deciding requirement.

Keep thinking enabled: K3.1 Pro rejects requests that disable it. Reducing the final answer’s length is a different control from disabling reasoning.

How do you verify the reset and lower consumption?

Check the credit restoration separately from the cost of a new task. Combining them in one observation can hide both: a credit adjustment lowers the meter while another running agent raises it.

1. Record the right meters. In Kimi’s web interface, open your avatar → Settings → Subscription. Record the plan, whether the displayed percentage means used or remaining, the next refresh time, and the timestamp with time zone. In Kimi Code, also run /usage and inspect the Console’s shorter-window status.

2. Compare the adjustment without other activity. Pause other membership-consuming sessions while checking. If you captured a pre-adjustment reading, compare it with the formula above after the update appears. Account for any intervening tasks or normal monthly refresh; without an earlier reading, you cannot reconstruct the exact credit from the current bar alone.

3. Measure one small task after the adjustment settles. Record usage immediately before the bounded repository prompt, then check the task’s usage entry after it finishes. Kimi’s usage FAQ documents consumption records and warns that display updates can have a brief delay.

4. Compare equivalent work. Keep the repository, model, reasoning setting, available tools, and task objective consistent. Record cache information when available rather than assuming two runs have identical cache conditions. Compare the allowance consumed and whether the answer actually completed the task.

If you have no comparable earlier run, this establishes a baseline for future work; it cannot prove how much a backend change saved. If the percentage display is too coarse to distinguish a small request, inspect the detailed record before spending more quota on repeated trials.

When requests still fail, use the complete message. As of 2026-10-26, the official Kimi Code error reference lists these quota cases under HTTP 429:

Recognizable Kimi Code message	What to check
You've reached your 5-hour usage limit	Check the Console’s five-hour reset time.
You've reached your weekly (7-day) usage limit	Check the legacy plan’s weekly window.
You've reached your monthly usage limit for this billing cycle	Check the shared monthly meter and adjustment.

Repeated retries do not replenish an exhausted allowance. Server overload is a separate condition, so restored monthly credit can coexist with an unsuccessful request.

If the promised adjustment is still missing after the stated deadline and the display has updated, contact Kimi membership support with the plan, timestamps, and redacted before-and-after usage evidence.

When should you switch to a separately billed API?

Use a metered route when the task is worth paying for independently and waiting for a subscription window would block it. If preserving the existing Kimi session is more important, first check whether your account offers Extra Usage. That paid wallet is shared by Kimi and Kimi Code; enable its monthly spending cap before relying on it for continued work.

Choose the billing route and budget

Match the endpoint, model ID, and key source as a set. These are the overseas OpenAI-compatible base URLs; tool-specific Anthropic configurations use different base paths.

Route	Base URL	Standard K3.1 Pro model ID	Billing path
Kimi Code	https://api.kimi.ai/coding/v1	k3.1-pro	Membership entitlement; eligible Extra Usage can take over
Kimi API Platform	https://api.moonshot.ai/v1	kimi-k3.1-pro	Separate pay-as-you-go API account
BetterToken	https://www.bettertoken.ai/v1	kimi-k3.1-pro	Separate BetterToken API balance

BetterToken’s live model catalog listed kimi-k3.1-pro on 2026-10-26 with Chat Completions and Anthropic Messages routes. Its model guide specifies that Responses is not enabled for this model. This is independent API access, not a Kimi subscription allowance.

For scale, Moonshot’s current global API prices list standard kimi-k3.1-pro at $2 per million ordinary input tokens and $10 per million output tokens, before applicable tax. A hypothetical request using 100,000 input tokens at the $2 rate and 10,000 total billed output tokens costs:

(100,000 / 1,000,000 × $2) + (10,000 / 1,000,000 × $10) = $0.30

This estimate assumes no paid tool calls, cache hits, or one-hour cache writes. Standard five-minute cache writes also cost $2 per million tokens; a token is not charged again as ordinary input on top of its cache-write category. Use billed token counts, not the length of the visible answer.

BetterToken has its own current prices. A subscription percentage cannot establish which route is cheaper, and an agent task may make many requests beyond its final visible reply.

Verify one request before moving an agent session

For the BetterToken route, select your own API key in the console, confirm model access and usable balance, and run one small request. The following example follows the documented request format; it was not run against a paid inference account for this article.

Use Bash, with curl and jq installed. When read waits, paste your key and press Enter; the input remains hidden.

set -o pipefail
read -rs BETTERTOKEN_API_KEY && export BETTERTOKEN_API_KEY

curl --silent --show-error --fail-with-body \
  https://www.bettertoken.ai/v1/chat/completions \
  --header "Authorization: Bearer ${BETTERTOKEN_API_KEY:?API key is required}" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "kimi-k3.1-pro",
    "stream": false,
    "messages": [
      {"role": "user", "content": "Reply with exactly: API_OK"}
    ]
  }' |
jq '{
  model,
  answer: .choices[0].message.content,
  finish_reason: .choices[0].finish_reason,
  usage,
  error
}'

The response body is the result; this non-streaming request needs no job polling. Check for the requested API_OK answer, a completed response, and usage information. Match the request to its model, status, token usage, and charge in the BetterToken dashboard before moving a larger task.

To continue in Cline, open Use your own API key, choose OpenAI Compatible, and enter the table’s BetterToken base URL, your BetterToken key, and kimi-k3.1-pro. Save, reload the extension, and start with the same small repository task. For OpenCode, follow its custom Chat Completions provider configuration.

Claude Code’s BetterToken configuration uses the Anthropic-compatible base https://bettertoken.ai, without /v1. Follow that tool’s authentication instructions rather than copying the Chat Completions base into its configuration.

If the smoke test returns 401, recheck the BetterToken key. For 404 or a model lookup error, check the exact endpoint and model ID. For a rate-limit or balance error, inspect that API account’s own response and dashboard before retrying; the subscription reset does not establish the state of a separately billed route.