Kimi K3.1 Pro

Pricing that follows usage

Subscription fatigue is real, and the AI market has earned it. Month after month, users pay flat fees for capacity they did not use, while heavy days get throttled behind fair-use clauses. The subscription is a bet by the vendor that you will underuse the product. It would be nice, once, to buy the thing you actually consumed.

Kimi K3.1 Pro is built on that nicer premise. At Kimi K3.1 Pro, the independent playground and API service for Moonshot AI's flagship model, the billing unit is the credit, and every request is priced by the work it actually caused. This piece follows the money through the whole lifecycle, from a new account's first free request to the settlement line on a volume account, because billing is where the real product philosophy shows.

The unit: simple on purpose

The exchange rate fits in one sentence: 1 USD equals 10,000 credits. From there the packs scale linearly. Starter is $10 for 100,000 credits, Pro is $100 for 1,000,000 credits, and Volume is $1,000 for 10,000,000 credits, all at the same unit rate and all with no expiry.

Two design choices in the Kimi K3.1 Pro credit model stand out. Same unit rate at every tier means volume buying buys convenience, not a better price to be optimized around; there is no cliff where one more dollar halves your cost. And no expiry means an occasional user's balance is still there next quarter, which quietly removes the use-it-or-lose-it pressure that subscription pricing weaponizes.

Every pack includes the full product: the online playground, API key management, and request usage and credit history, so the ledger is not a premium feature. Features are not held hostage to tiers, so the only thing a bigger pack buys is more headroom for the same work.

The lifecycle: reserved, then settled

The mechanics of a single request inside Kimi K3.1 Pro are worth knowing precisely, especially for developers wiring up automated spend alerts.

Before a request executes, Kimi K3.1 Pro reserves credits against it. The request runs, and afterward the reservation is replaced by a settlement based on actual usage: input tokens, cache usage and output tokens, including audio transcription where that preprocessing step was used. A successful request carries a minimum charge of one credit, even when its measured usage rounds to nothing.

The sequence matters for two practical reasons. First, during a request your true committed spend is the reservation, not your last settled balance, so balance checks in automation should account for in-flight work. Second, because settlement measures what was actually consumed rather than estimating up front, the receipt for each request is an audit record: you can look at any charge and trace it to a request, with its input, its output and its cost.

That traceability is the feature. A monthly invoice that is a mystery is a tax; a per-request ledger is a tool. Reconciliation stops being a monthly archaeology project.

What moves the number

With Kimi K3.1 Pro's usage-based billing, the levers are concrete. Input size is the obvious one, and it interacts with the model's headline capability: the upstream context window is 1,048,576 tokens, so long-context requests are genuinely possible, and genuinely billed by their size. Cache usage is the quiet ally here, since repeated context that the service can cache is billed through the cache rate rather than at full input price. Output length is the lever most users control directly: a request asked for a focused answer pays for a focused answer.

Audio adds one more line: when a recording is uploaded, the speech-to-text step that turns it into a transcript is part of billed usage, disclosed rather than buried. And the adjustable thinking levels of Kimi K3.1 Pro influence output volume directly, since requests that reason at higher effort produce more intermediate tokens on the way to their answer. A team that manages its spend is really managing three habits: what it attaches, what it asks for, and how hard it asks the model to think.

None of these levers inside Kimi K3.1 Pro require contacting support or changing plans. They are ordinary controls in an ordinary session, which is the point: when pricing is legible, cost management stops being an accounting project and becomes part of using the tool well.

Starting at zero

New accounts receive 10 welcome credits with a Google sign-in and no payment method, so the first audit of Kimi K3.1 Pro's billing system can be done with the vendor's money. Email verification-code sign-in is currently disabled, Google is the door, and it opens straight onto the full interface. During the welcome window, the full billing apparatus, reservations, settlements, the usage and credit history screens, is visible on requests that cost you nothing, which is the right way to learn it. It is hard to feel cheated by a system you have already read.

When real spend begins, the same Kimi K3.1 Pro ledger continues. There is no plan change, no feature gate, no new dashboard to learn between free and paid. The account you evaluated with is the account you build on, and its OpenAI-compatible API draws from the same balance as the playground.

The philosophy, made explicit

Independent services live or die on whether users believe their bills, and the billing design of Kimi K3.1 Pro is built to be believed: a fixed exchange rate, linear packs with no expiry, reservation-then-settlement per request, per-request history, and limits like the one-credit minimum stated in the open. The service also states plainly what it is, an independent door to Moonshot AI's flagship model routed through OpenRouter, and what it is not, an official Moonshot AI website.

Pay-as-you-go is easy to say and rarely done cleanly. Done cleanly, it changes behavior: you stop budgeting attention around a billing cycle and start spending where the work is. With Kimi K3.1 Pro, the bill ends up shaped exactly like the work, which is the only fair shape for it.