Yes. Wallaby Token bills every Kimi K3 request as its own line item, and the line lands in your console within seconds of the call. Input, cached input, output and thinking are metered separately on every request. No lump sum.
Disclosure: Wallaby Token is our own service, so read this as the answer we can prove, not a neutral review. Everything below is on our public pages and linked where it lives.
What one line on the bill looks like
Every call produces four metered components: input tokens, cached input tokens (billed at one-tenth the input rate), output tokens, and thinking tokens. Thinking is priced at the output rate, the same rule as the official Kimi API, but itemized on its own line, so you can see what the reasoning cost you.
At current rates, $2.70 per 1M input tokens, $0.27 cached input, $13.50 output, a request carrying 10,000 input tokens, 9,000 of them cached, plus 500 output tokens costs $0.0027 + $0.0024 + $0.0068 = $0.0119. The arithmetic arrives on the receipt; you do not rebuild it later.
Two real receipts from our published guides: a smoke-test call through OpenCode showed up itemized at about $0.019, seconds after the request; a five-request Codex task totalled $0.16, with 85k of its 91k input tokens served from cache at the one-tenth rate.
Where the receipt shows up
Three places. The console usage log gets the line within seconds, with model, token counts and cost. The API response carries the token counts back to your client. Every top-up comes with its own itemized invoice. The console is the source of truth today; usage-reporting API endpoints are on the roadmap.
Why teams ask for per-request billing
Per-request lines make spend attributable. A coding-agent task is a loop of calls: in our Codex guide each of the five requests, including one self-recovery retry, landed as its own line, so the task's cost is a sum, not an estimate. When something looks wrong, you reconcile your logs against ours line by line.
For a team, you create a named key per developer, each with its own dollar cap and optional expiry, and the log attaches every request to its key. Per-developer totals become a filter, not a project; the full setup is in One endpoint, one bill.
We store what billing requires, meaning token counts, model, timestamp and key id, and nothing else. We never log prompts or completions, and we never train on your data.
One clarification the name obliges: the "token" in Wallaby Token is the metering unit above. Billing is plain USD by card; there is no cryptocurrency in the flow.
FAQ
Are thinking tokens billed separately?
Itemized separately on every receipt, priced at the output rate, the same rule as the official Kimi API. Nothing hides inside a single output number.
Can I see spend per API key?
Yes. Keys are named and individually capped, and every request in the log carries its key, so per-key totals are built in.
Do I need to pay first?
No. Email signup comes with $0.50 of trial credit, and the very first free call already lands as an itemized line.
Where to go next
You came for a billing question, so the short version is: every call is its own line, visible in seconds, from the first free one. Three useful next steps:
- Deeper: our docs — the billing note covers the four metered components, and the quickstart takes about two minutes.
- Sideways: Kimi K3 API that takes card payment (no crypto) — how the money gets in, when you are ready.
- Forward: pricing.json — current rates, machine-readable, if you want to script the maths.