What happened
OpenCode has published usage, cost, and ranking data for Moonshot’s Kimi K3.1 Pro. The page ranks the model 23rd in OpenCode usage over the last week and reports 128 billion tokens in its recent momentum view. It also lists approximately 22,000 unique users and 59,372 completed sessions. The dashboard identifies the model as an October 2026 release, with text, image, and video inputs, a one-million-token context window, and a maximum output figure of 131,000 tokens. Its knowledge cutoff is listed as unknown.
The daily chart gives the shape of the early uptake. It shows 7.6 billion tokens on October 23, then 30 billion on October 24, 25 billion on October 25, 31 billion on October 26, 26 billion on October 27, and 8.7 billion on October 28. The unique-user chart lists 1,500 users on October 23, 5,300 on October 24, 3,800 on October 25, 4,600 on both October 26 and 27, and 1,900 on October 28. The page’s peer list places Kimi K3.1 Pro below Moonshot’s Kimi K2.7 Code at 159 billion tokens and above OpenAI’s GPT-5.6 Luna at 101 billion tokens in the listed recent-volume comparison.
OpenCode also exposes observed usage economics. It reports total spend of $50,000, input cost of $2 per million tokens, output cost of $10 per million tokens, an average session cost of $0.84, and 2.2 million average tokens per session. The displayed input cache ratio is 100%. Its geography table assigns 23 billion tokens, or 18%, to the United States; Germany accounts for 8.3 billion, China 7.7 billion, Brazil 6.3 billion, India 4.7 billion, and Russia 4 billion. Those figures describe activity observed by OpenCode, rather than all Kimi usage or all developer usage of the model.
The page is therefore not a release announcement and does not make performance claims. It is a platform-level usage snapshot. It makes visible that Kimi K3.1 Pro was not merely listed as an option: within the dashboard’s observation window, users ran many large sessions through it. The data also makes the role of caching visible. A large average token count can coexist with a modest displayed average session cost when nearly all reported input tokens are served from cache.
What the archive adds
This is a new fact on a known rollout. Earlier Field Notes covered Moonshot’s Kimi K3.1 Pro API release, its availability in Kimi Code and the Kimi app, and its addition to OpenCode Go. The new evidence is not another access announcement: it is the first supplied public usage snapshot for the model on OpenCode.
Trend signal
No supplied pattern or archive assumption genuinely fits this evidence. The dashboard measures observed tokens, sessions, and spend, but it does not establish completed work, review outcomes, or a change in an agent architecture.
Why now
The timing follows the October rollout. The dashboard’s daily series begins on October 23, while the archive records K3.1 Pro becoming available through Moonshot and OpenCode Go on October 24. Early usage data is most useful now because it captures the adoption shape immediately after availability, before a longer history smooths the launch period into an average.
Connections to other events
The archive places this alongside the rollout of K3.1 Pro and K3.1 Pro Highspeed into Kimi Code and the Kimi app. OpenCode Go then added K3.1 Pro. The dashboard provides a distinct layer of evidence: the earlier items concerned where the model could be accessed, while this one concerns observed use after access was available.
Why it matters
For teams selecting models for coding agents, a public ranking is not a quality verdict. It can still be operationally useful. The figures show whether a model is attracting actual workload in a specific harness and reveal the shape of that workload: here, sessions average 2.2 million tokens and the displayed cache ratio is effectively complete. That combination matters for budget modeling, prompt and repository-context design, and interpretation of token-based bills.
The data also cautions against treating headline context limits as the whole story. Kimi K3.1 Pro is listed with one million tokens of context, but observed sessions average above that token count because session accounting and cached input can reflect repeated or accumulated work. A team should test its own task mix, cache behavior, latency, output quality, and failure handling rather than infer them from aggregate activity.
Limits and uncertainty
This is data from one public OpenCode dashboard, not independently audited market research. The page does not define every collection method in the supplied material, identify the users, separate experimentation from production work, or report task success, latency, reliability, or user retention; retention is marked pending. It reports rounded aggregate values, and the current page’s 128 billion tokens and 22,000 users differ slightly from an earlier supplied dashboard snapshot. That is consistent with a live, updating dataset, but it means the figures should be read as a time-bounded observation rather than stable totals. The cost and cache numbers are displayed metrics, not a guarantee of what another provider route or team will pay.
Skill to build now
Instrument coding-agent sessions by task rather than tracking model tokens alone. This week, record input tokens, output tokens, cache hits, wall-clock duration, tool failures, reviewer acceptance, and total cost for a small set of representative repository tasks. Then compare a cold-context run with a repeated-context run. The OpenCode snapshot makes clear why this matters: high token counts and low apparent session cost can coexist when caching dominates. Your own logs should show whether that relationship holds for your prompts, codebase, and provider path.
Reader takeaway
Kimi K3.1 Pro’s early OpenCode data is a real adoption signal, not proof that it is the best coding model. Its value is in the operational detail: substantial observed volume, very large sessions, and near-total displayed input caching. Use it to form testable questions about your own agent economics, not to replace evaluation.
Open question
Will the next OpenCode updates show durable user retention and completed-work quality, or primarily a launch-period spike in exploratory long-context use?