pi 1.0 made itself cheaper. Its new codemode cuts prompt tokens by roughly 40% per the official release notes — a single GPT-5.6-class request went from about 5,300 prompt tokens to 3,300. If you upgraded, you already collected that saving without changing anything.
What is left is yours. In one real 2.3-hour coding session we metered on our own gateway, 49% of the total spend went to large cache-miss calls that each followed a pause of five minutes or more. Not to thinking, not to output — to re-reading context that had been read dozens of times before, billed at the miss price because the user stepped away and the cache entry expired. We call it the pause tax, and pi 1.0 does not pay it for you.
None of this is a flaw in pi. pi is one of the cleanest coding agents we meter: four built-in tools, an honest status bar, a session tree instead of hidden state. The leaks below come from default usage patterns, and every one of them has a fix measured in minutes.
The pool you are swimming in
Based on public OpenRouter usage metrics observed on October 11, 2026, pi is the third-largest Kimi K3 consumer by token volume — about 221 billion K3 tokens over the trailing 30 days, behind Hermes Agent (299B) and Claude Code (289B). These figures move; treat them as a snapshot, not a permanent ranking. K3 sits at number eleven on pi's own model leaderboard — one data point in a wider pattern where developers pair a strong open-weight model with a minimal agent and then never look at the bill's shape.
A pool that size means the average pi-on-K3 session is almost certainly running unoptimized, because optimizing is opt-in. Here is what unoptimized looks like from the metering side.
Anatomy of one expensive session
The session below is real, from our gateway's consumption logs, anonymized to an aggregate level (we do not store conversation content; these are token and cost counters only):
- Duration: 2.3 hours, one coding task, one human.
- Input : output = 68 : 1. The agent read far more than it wrote — normal for coding work, and the reason input pricing dominates the bill.
- Input grew monotonically from 6.3k to 65k tokens. Every agent loop iteration re-sends the conversation so far, so context only inflates within a session.
- Six pauses of five minutes or longer. On our gateway, Kimi K3 prompt-cache entries use a five-minute TTL by default. Each pause let the entry expire, and the first call after the pause re-billed the entire accumulated context at the miss price. Those six calls alone were 49% of the session's total cost.
The miss price is the crux: a K3 cache hit bills at $0.27 per million input tokens on our price sheet, a miss at $2.70 — a 10× spread (per pricing.json, October 2026; the official list prices are $0.30 and $3.00). A 60k-token context that costs a cent and a half to re-read warm costs sixteen cents cold. Multiply by every coffee break in a workday.
For contrast, here is a tight session. We ran pi 1.0.4 with the pi-wallaby-provider extension on a small task ("write a palindrome function and run it"): pi's status bar reported $0.010 with a 93.9% cache-hit rate, and our console logged three itemized consume lines — $0.00204, $0.00172, $0.00611 — summing to $0.00987, one per agent loop iteration, with per-line cache-read detail. Client display and server bill agree to the rounding digit.
Four fixes, in payoff order
1. Mind the five-minute gap. The cache renews free on every hit within its TTL, so a session in active use stays warm; a session abandoned mid-task goes cold. Two habits follow. Batch your prompts: gather the three follow-ups you were going to trickle in over twenty minutes and send them in one working stretch. And when a task is done, end the session rather than parking it — the next task starts cheaper with a fresh, small context than with a stale, expensive one.
2. Tier the thinking. pi 1.0 added /thinking, which switches the reasoning effort level mid-session. The levels are not decorative. In our September 14 test runs (gateway and direct, side by side), the low tier compressed reasoning tokens to roughly 1/70 of the high tier on long tasks — a single-workload observation, directional only; results vary by prompt and task. Reserve high for the turns that deserve it — architecture, debugging, design review — and drop to low for execution and bookkeeping turns. Check your status bar: our run defaulted to medium.
3. Compact before the context compacts you. A 68:1 input-to-output ratio means you are paying to re-read, not to write. Use pi's compaction when a session runs long instead of letting 65k tokens ride every call, and branch with /tree rather than dragging dead ends forward. New in 1.0.4: models.json supports modelOverrides, so the local cost display can be made to match your actual price sheet — worth the two minutes, because an accurate status bar is the cheapest monitoring tool you have.
4. Choose the endpoint on cost per accepted output. Once cache behavior dominates the bill, the cached-input price matters more than the headline input price, and the headline price matters less than whether the output ships. The honest unit is cost per accepted output — total spend divided by outputs you ship without rescue — and we wrote up the one-afternoon measurement protocol in a separate post. The cache math specific to K3 is in Kimi K3 cached input pricing. Our own sheet sits 10% under official list across input, cached input, and output, billed in USD with per-key itemized logs — the same logs the session anatomy above came from.
Try it on the trial credit
New accounts get $0.50 in free credit — the palindrome run above cost one cent, so the credit covers roughly fifty such sessions. The full setup (one JSON block, one exported key, plus the 1.0 picker quirk where entries stay hidden until the key resolves) is in How to Use Kimi K3 in pi; the zero-config npm extension route is in Run pi with Kimi K3 on Windows or Mac.
Then run your own audit: watch the cache-hit rate in pi's status bar for one workday, count your five-minute pauses, and check the itemized log that evening. The pause tax is measurable in a day, and that is what makes it worth fixing first.
Wallaby runs inference for open-weight models with per-token metering and itemized statements, and holds customer bills to the same standard described above. See how we meter or check live status.
Note: configuration options, version numbers, and pricing in this post were verified on October 11, 2026. Tools and APIs change — cross-check the official documentation before relying on specifics.