Sticker prices for LLM APIs have misled me enough times that my first move on any new model is to convert per-million-token prices into cost per finished task. Kimi K3.1 Pro showed up this week, and the sticker looks good, so here’s that conversion.
Short version: at the listed rate, a coding-agent task I’d call typical costs about $3 uncached. That’s real money saved against a pricier model if the quality holds on your workload, and it’s a number you can only trust after you’ve read the caching rules and run your own tasks.
I haven’t called the Kimi API myself. Everything below comes from Simon Willison’s write-up and Moonshot’s own pricing page, and I’ll say which is which as I go.
What’s actually on the page
Simon’s post, dated 23 October, gives these facts. Kimi K3.1 Pro landed on the Kimi API that day. It isn’t open weights yet, but Moonshot promise full model weights by 4 November 2026. There’s a “Highspeed” version that’s two to three times faster at twice the price, except that input tokens served from cache cost the same as on the standard version. The dollar pricing is $2.00 per million input tokens and $10 per million output tokens, which Simon says matches GPT-6.1 Sol and is half the price of Claude Opus 5.5.
Moonshot’s pricing page adds a few details that matter more than the headline. All K3 series models support a context window of 1,048,576 tokens. Caching is automatic for repeated request prefixes with a default TTL of five minutes. For K3 models, cache writes are billed separately by TTL (five minutes or one hour), and cached input is billed at the cache-hit price only, with no extra charge for the write. Pricing is pay-as-you-go with no subscription, and the page says that differs from the Kimi membership and Kimi Code products.
The same page carries a migration notice. From 31 October 2026, K2 series models stop being available to newly registered users, and Moonshot plan to retire all K2 models by the end of December 2026. If you have anything still pointed at K2, that date is yours to deal with regardless of what you think of K3.1.
Cost per task, not cost per token
Per-million-token prices don’t tell you what a job costs, because agents don’t make one call. They loop. Every step re-sends the growing conversation, so input tokens pile up far faster than output tokens.
Here’s a task shape I use for back-of-envelope work. An agent makes 40 model calls to finish a task. Each call sends about 30,000 tokens of context (files, tool output, history) and gets back about 1,500 tokens. Those numbers are made up, but they’re close to what a medium coding task looks like, and you should replace them with measurements from your own logs.
def task_cost(calls, in_tok, out_tok, in_price, out_price,
cached_share=0.0, cached_price=None):
"""Prices are dollars per million tokens. cached_share is the
fraction of input tokens served from cache (0 to 1)."""
total_in = calls * in_tok
total_out = calls * out_tok
if cached_price is None:
cached_price = in_price # unknown: assume no discount
fresh = total_in * (1 - cached_share)
cached = total_in * cached_share
return (fresh * in_price + cached * cached_price
+ total_out * out_price) / 1_000_000
# Kimi K3.1 Pro at the listed standard rate, no cache discount assumed
print(task_cost(40, 30_000, 1_500, 2.00, 10.00)) # 3.0
# Highspeed at twice the price, same assumption
print(task_cost(40, 30_000, 1_500, 4.00, 20.00)) # 6.0
That’s 1.2 million input tokens and 60,000 output tokens per task. Input costs $2.40 and output costs $0.60, so $3.00. If Simon’s comparison holds and the Opus 5.5 rate is double, the same task comes to $6.00 there, and the Highspeed tier lands at the same $6.00. Multiply by 500 tasks a month and you get $1,500 against $3,000.
Two things to take from the arithmetic. First, input dominates. Output is 20 percent of the bill in this shape, so a model that talks less doesn’t save you as much as one that re-reads less. Second, the 2x speed premium brings the cost to about what Opus 5.5 would be by Simon’s comparison, so Highspeed is a latency purchase and a poor way to save money. Buy it for interactive use, where a person waits on the answer, and keep batch jobs on the standard tier.
I wrote a longer version of this sort of math, with cached-token pricing across several vendors, in my LLM pricing comparison. The shape is the same: model the loop, not the call.
Read the caching rules before you trust the number
The $3.00 above assumes zero cache benefit, and the real figure is probably lower. I say “probably” because I don’t have the cache-hit price in front of me. Simon’s post says Highspeed cache hits cost the same as standard, and Moonshot’s billing text refers to a cache-hit price, but I haven’t seen the number, and the Moonshot page I fetched didn’t render its price table without JavaScript. Check the live table before you rely on any figure here.
What I can say from the billing text is how the mechanism behaves, and that matters because it decides whether your agent benefits at all. Caching applies to repeated request prefixes. An agent that appends to a conversation sends the same prefix on every step, so it should hit. An agent that rewrites a system prompt each step, injects a timestamp near the top, or reorders its tool list will miss every time. With a five-minute default TTL, a pipeline that pauses for human review longer than that likely pays full price again after the pause.
So the work is mechanical. Put stable content first and variable content last. Keep timestamps out of the prefix. If your tasks pause for long gaps, look at the one-hour TTL option and whether its write pricing is worth it for your pattern. Then send 20 real tasks and read the usage numbers the API returns, because the sticker never tells you your cache hit rate.
The open-weights promise is a date, not a model
The headline that will get shared is that a model near the top of the benchmarks is about to be open weights. Moonshot’s own statement is that weights will be released by 4 November. That’s a little over a week away, and a promise isn’t a download.
Here’s why it matters for planning. If you’re thinking of self-hosting, you can’t size hardware, pick an inference server, or check the licence until the files exist. The licence terms decide whether you can use the model commercially for a client, and those are not something I’d assume from the word “open”. Context length matters here too. A 1,048,576-token window is great for the API and may cost a lot of memory to serve yourself, so the context you can actually afford on your own hardware may be far smaller than the number on the page.
My advice is dull: don’t build anything that depends on self-hosting K3.1 Pro until the weights are public and you’ve read the licence. Using the hosted API in the meantime costs you nothing but the data-handling question, and that one is worth a conversation with the client before you send their code to a vendor.
One benchmark score isn’t your workload
Simon reports that Moonshot’s own benchmarks put Kimi roughly level with Opus 5.5 and GPT-6 Astra, and that Artificial Analysis scored it 55. By his account, that’s ahead of Claude Fable 5.1, GPT-6 Astra and Gemini 4 Argon at 53 each, and behind Claude Opus 5.5 at 58. He also notes this is the first time a soon-to-be open-weight model has scored this high against the leaders.
I take that seriously, and I still wouldn’t switch anything on a three-point gap on an aggregate index. An aggregate averages over tasks you may never run. A model that’s two points lower overall can be better on your tool-calling format, your language, or your repo’s size. The reverse is just as likely. It’s also worth remembering that the pelican-on-a-bicycle test Simon uses is a fun smoke test of reasoning levels, and not a coding evaluation.
The check I trust is small and boring. Take 20 tasks from your real backlog, run them through the current model and the candidate with the same harness, and compare pass rate and cost per passing task. Cost per task divided by pass rate is the number that matters. At $3 per task and a 40 percent pass rate, a model costs $7.50 per success. At $6 and 90 percent, the pricier one costs $6.67. The cheaper sticker loses, and you’ll only find that out by running it.
What I’d do this week
Pull usage logs from your current agent setup and compute your real average calls, input tokens and output tokens per task. Plug them into the function above with the standard rates. If the answer is a large saving, pick 20 representative tasks and run them on K3.1 Pro through the same harness you use today. Record pass rate, total cost and cache-hit rate, and decide from those.
Set a calendar reminder for 4 November to check whether the weights shipped, and read the licence the day they do. If you have anything on a K2 model, schedule that migration before the end of December. If you want to see how I wire agents into client workflows, my portfolio has the projects.
