Tool calling on K3 follows the OpenAI shape, so if you have written function-calling code before, it works here. The two things worth knowing are specific to this model: reasoning always runs before a tool decision, and the API supports loading tools dynamically rather than declaring a fixed set.
The basics
| Shape | OpenAI-compatible tools array |
| Selection control | tool_choice |
| Dynamic loading | Supported — narrow the tool set per call |
| Reasoning before calls | Always on, not configurable |
Because the API is OpenAI-compatible, existing tool definitions usually transfer without modification. What changes is behaviour, not schema.
Why always-on reasoning helps here
Agents rarely fail at calling a tool. They fail at choosing which one, and at deciding when to stop. Both are reasoning problems.
On K3 every tool decision gets a reasoning pass — there is no configuration in which the model reflexively grabs the first plausible function. That produces better tool selection at the cost of a latency and token floor on every call. For a tool-using agent this is a good trade; for a high-frequency single-tool endpoint it is overhead you cannot remove.
Use dynamic loading — offer fewer tools
The most useful and least used feature here. An agent offered eighty tools reasons worse than the same agent offered the eight relevant to the current step: more surface to consider, more plausible-but-wrong options, longer reasoning.
Practical pattern:
- Classify the step — what kind of work is this?
- Pass only the tools that step could legitimately need.
- Widen the set only if the model reports it cannot proceed.
This improves accuracy and cuts reasoning tokens at the same time, which is a rare combination.
Failure modes to instrument
- Truncation mid-sequence. Check
finish_reasonon every response. A cut-off tool-call sequence that your code treats as complete is the most common silent agent failure. - Cost per run, not per call. Reasoning on every tool decision across a hundred-step run adds up. Budget the run.
- Schema drift. Tool descriptions are prompt text. Vague descriptions produce wrong tool selection, and the fix is almost always a better description rather than a better model.
- Cache breakage. Tool definitions belong in your stable cached prefix. Reordering them between calls silently costs you the $0.30 rate.
More on Kimi K3
Start with the complete Kimi K3 guide for the overview, or go deeper:
Ready to go deeper?
Read the full Kimi K3 guideFrequently Asked Questions
Does Kimi K3 support function calling?
Yes, in the standard OpenAI-compatible shape — a `tools` array with `tool_choice` for selection control. Existing tool definitions written for the OpenAI API usually transfer without modification. K3 also supports dynamic tool loading, so you can narrow the available set per call.
What is dynamic tool loading?
Passing only the tools relevant to the current step rather than your entire catalogue. It improves tool selection — a model offered eighty tools chooses worse than one offered the eight that apply — and reduces reasoning tokens at the same time.
Why is my Kimi K3 agent making wrong tool calls?
Usually one of three things: too many tools offered at once, vague tool descriptions, or silent truncation. Narrow the tool set per step, treat tool descriptions as prompt engineering rather than documentation, and check `finish_reason` on every response before acting on it.
