Hi, I’m preparing a small API integration using kimi-k2.6 with web search.
I noticed that the current K2.6 pricing page says web_search is being updated, is not recommended in the near term, and that the related documentation is outdated.
I also found the current Official Tools / Formula API documentation, which documents:
moonshot/web-search:latest
using:
GET /v1/formulas/{uri}/tools POST /v1/chat/completions POST /v1/formulas/{uri}/fibers
The Official Tools documentation says its example is verified with kimi-k3, but also says that another model such as kimi-k2.6 can be used by replacing the model field.
Could you please clarify:
Is the warning on the K2.6 pricing page specifically about the older built-in builtin_function.$web_search flow?
For a new Kimi K2.6 API integration, is moonshot/web-search:latest via the Formula API the currently recommended web-search mechanism?
Is that Formula web-search path currently supported with kimi-k2.6, or should new web-search integrations use kimi-k3 instead?
Should builtin_function.$web_search now be considered legacy/deprecated for new integrations?
We have not made our first real API call yet; we’re trying to implement the currently recommended contract before doing so.
Hi, thanks for the careful reading — your understanding is essentially correct. Short answers first:
Yes. The warning on the K2.6 pricing page refers to the older builtin_function.$web_search flow.
Yes. For a new integration, moonshot/web-search:latest via the Formula API is the currently recommended web-search mechanism.
kimi-k2.6 works — and technically, any model does. The Formula path is just a normal tool-call contract declared into the model’s context, so it’s model-agnostic; use it with kimi-k2.6 by swapping the model field. What changed on kimi-k3 is that we no longer support builtin_function.$web_search there — Formula is the only web-search path on K3.
Yes, treat it as legacy.builtin_function.$web_search should be considered legacy/deprecated for new integrations.
Some background on the two mechanisms, since it explains the recommendation:
builtin_function.$web_search is our earlier implementation — essentially a built-in workflow. A small judge model decides whether a search is needed, triggers a search round, and the cached results are handed back so your conversation continues. The judge model is very fast, but the trade-off is that the decision to search isn’t made by the main model itself.
Formula (moonshot/web-search:latest) declares a tool directly into your model’s context — it behaves like a normal tool call. The model itself decides when and how to invoke it, and the server-side implementation executes the search. This makes much better use of the model’s own understanding (multi-round search, query refinement, etc.).
The underlying web search service is the same in both cases — the same search that powers Kimi Chat — so you can consider the search results equivalent. What differs is who decides to search and how flexible the loop is.
Because we want search behavior to be driven by the model’s own judgment, kimi-k3 no longer includes builtin_function.$web_search; the Formula path is the only path there, and it’s the direction we’re investing in.
Just a heads-up, I’m actually the developer behind the Formula API. If anything in the docs or behavior feels off, please feel free to file an issue. If you can share specific details about your experience, I’d be more than happy to make improving it a top priority.
Thanks — that completely resolves the mechanism question for us.
One last billing detail: for moonshot/web-search:latest through the Formula API today, what is the web-search/Fiber tool-call price: $0, $0.005, or another amount?
Also, are Formula search-result tokens charged only when they are subsequently passed back through /chat/completions?
A billing record is generated after the POST /v1/formulas/{uri}/fibers call.
A bit more detail on how the billing breaks down:
Tool-call pricing: Because the Formula API uses the exact same underlying search engine as the older built-in mechanism, the flat cost remains identical at $0.005 per query. You can always verify the most up-to-date tool pricing details here: https://platform.kimi.ai/docs/pricing/tools.
Token charging & Fibers: The process is essentially billed in two distinct parts. When you make the POST /v1/formulas/{uri}/fibers call, the server executes the search tool, and a billing record for that specific tool execution ($0.005) is generated immediately. Then, when you take those retrieved search results and pass them back into POST /v1/chat/completions for the model to read, the text itself is counted and charged as standard input context tokens.
So, you are charged the flat fee for the search action at the Fiber step, and standard token rates for the text volume at the completions step.
Thank you very much for taking the time to answer both questions so clearly and thoroughly.
This was genuinely one of the most helpful support interactions I’ve had with a developer platform. You didn’t just answer the immediate questions — you explained the reasoning behind the architecture, clarified the migration direction, and then gave us the exact billing semantics we needed to make an informed implementation decision. That saved us a lot of uncertainty and probably quite a bit of unnecessary trial and error.
It’s also really reassuring to hear this directly from the developer behind the Formula API. The design makes a lot more sense now, and Formula looks like a very clean direction for new integrations.
Thanks again for being so responsive, precise, and transparent. If this level of developer support is representative of where the Kimi platform is heading, that’s a very good sign.
Much appreciated — and please pass my thanks along to the team as well!