Kimi K3 API Pricing: Cache Write Fees, TTL, and moonshot-v1 404s

Blog / Troubleshooting

Kimi K3 API Pricing: Cache Write Fees, TTL, and moonshot-v1 404s

Kimi K3 API pricing is quoted per million tokens: ¥2 for cache-hit input, ¥20 for cache-miss input, ¥100 for output, with a context window of 1,048,576 tokens. There is also a new line item, a cache write fee: ¥20 for a 5-minute TTL and ¥40 for a 1-hour TTL. If an older project suddenly started returning 404, it is most likely calling a retired model (kimi-k2.5 or the moonshot-v1 family) and needs to move to K3 or another model that is still on sale.

This article reflects the situation as of October 2026, based on the Kimi Open Platform (Moonshot AI) pricing page and changelog. Prices can change, so check the official pages again before you pay.

How is K3 priced?

The pricing page lists these prices for kimi-k3 (per million tokens):

ItemPrice
Input, cache hit¥2.00
Input, cache miss¥20.00
Output¥100.00
Cache write, 5-minute TTL¥20.00
Cache write, 1-hour TTL¥40.00

The same page lists a few cheaper options. All have a 262,144-token context, and the page does not list cache write fees or TTL tiers for them:

ModelCache hitCache missOutput
kimi-k2.7-code¥1.30¥6.50¥27.00
kimi-k2.7-code-highspeed¥2.60¥13.00¥54.00
kimi-k2.6¥1.10¥6.50¥27.00

Which one you pick depends on the task. K3 is worth it when you need a million-token context or the strongest capability. For everyday coding tasks, try a cheaper model first and compare the results.

What is the cache write fee, and how do you choose a TTL?

According to the pricing page, the cache comes in two tiers, 5 minutes and 1 hour, and defaults to 5 minutes if you don't specify one. A hit within the TTL is billed only at the cache-hit price, and each hit automatically renews the TTL without charging another write fee. How to set the TTL in a request is covered in the official docs.

The deciding factor is the interval between your requests. The example below is hypothetical and only illustrates the arithmetic: a fixed 100,000-token prefix called 20 times in a row, counting only the input cost of that prefix, and assuming the first request pays only the write fee and is not also billed as a cache miss (your actual bill is the source of truth).

Scenario5-minute TTL1-hour TTLNo cache
One call every 2 minuteswrite ¥2 + 19 hits ¥3.8 = ¥5.8¥4 + ¥3.8 = ¥7.820 × ¥2 = ¥40
One call every 10 minutesexpires every time and is rewritten, about 20 × ¥2 = ¥40¥4 + ¥3.8 = ¥7.8¥40

The takeaway is simple. If requests are dense and arrive less than 5 minutes apart, the 5-minute tier is cheaper. If gaps are longer than 5 minutes but within an hour, the 1-hour tier wins. If the prefix changes on every call, caching does nothing for you and the write fee is pure extra cost. After launch, calibrate these assumptions against a week of real billing data. For how to check a bill line by line, see Why your API bill looks wrong.

Getting a 404: model retirement or an outage?

The changelog states that in August 2026, kimi-k2.5 and the entire moonshot-v1 family (including the vision-preview models and moonshot-v1-auto) were retired on all platforms, in China and internationally. Calls to them now return 404, and the official recommendation is to migrate to K3. The log gives only the month, not an exact date.

Work through it in this order:

  1. Check the model field in your request first. If it is kimi-k2.5 or moonshot-v1-*, the model is retired and this is not a network problem.
  2. Switch to kimi-k3 or another model from the tables above and send the request again with the same key. If it succeeds, retirement was the cause.
  3. If it still fails, check for an outage: open /en/down/kimi and /en/status/moonshot and compare the official status with cdnping's probe results.
  4. If the status looks normal but you still can't connect, use the approach in Is ChatGPT down or is it my network? to separate server-side problems from local network problems. It applies to Kimi as well.

One more migration note: K3's prices differ from the old models, so estimate the monthly cost before you change the model name. Its output price is the highest in the tables.

What changed in the file API, and what should you check?

The same changelog lists these file API changes:

  • Newly generated file IDs now carry a file_ prefix.
  • Parsing of complex content such as tables and formulas has been improved.
  • Images no longer go through OCR text extraction. For image understanding, upload with purpose=image.
  • When you upload a file with a name that already exists, the server automatically renames the new file.

Use this checklist:

  • Does any code use a regex or length check based on the old ID format?
  • Does any flow upload images through the file API and then rely on OCR results? If so, switch to purpose=image.
  • Does anything look files up by unique file name? Duplicate names get renamed, so use the returned ID instead.
  • For table and formula documents whose parsed output has changed, rerun your acceptance samples.

How do you avoid being caught off guard by retirements and price changes?

Model retirements and price changes usually show up in the official changelog first. cdnping's /en/changes monitors changelogs and pricing pages from many providers, records additions and removals line by line, and offers an RSS feed. The full tracking method is in How to find out right away when an LLM API price changes. For other recent changes on the Kimi platform, see Kimi Open Platform September updates. If you are weighing access options other than going direct to the vendor, Official API vs. cloud vendor vs. gateway compares them.

Sources

Related articles

Keep reading