Kimi K3.1 Pro is reachable through three request formats: Chat Completions at `/v1/chat/completions`, OpenAI’s Responses at `/v1/responses`, and Anthropic’s Messages at `/v1/messages` [OURS — model card]. Same model string, `kimi/kimi-k3.1-pro`, same rate card, same weights behind it. The OrcaRouter entry for Kimi K3.1 Pro API lists all three endpoints at the vendor’s list price, which is why a team can point an existing client at this model without rewriting its integration layer.
The choice is not cosmetic. The three protocols carry different features, different field names and different failure modes, and picking the wrong one for your client costs more than picking the wrong model would.
Which surface, for which client
| Surface | Path | Fits |
| Chat Completions | `POST /v1/chat/completions` | Every OpenAI-compatible SDK, most agent frameworks, existing production code |
| Responses | `POST /v1/responses` | Clients built for OpenAI’s newer API — Codex-style agents, server-side state |
| Messages | `POST /v1/messages` | Anthropic-SDK clients, Claude Code-style agent harnesses |
The practical rule: use the surface your client already speaks. If your code calls `client.chat.completions.create`, keep it. If it calls the Anthropic SDK’s `messages.create`, keep that. If it is a coding agent built for the Responses API, point it there. All three reach the same model, and a rewrite buys you nothing but a regression risk.
What stays the same across all three
The model’s constraints. Thinking is always on. `reasoning_effort` accepts `low`, `high` and `max`, defaulting to `max`. `temperature=1.0`, `top_p=0.95` and `n=1` are fixed [VENDOR]. Those are properties of the model, not of the protocol: no surface gives you a non-reasoning mode or a settable temperature.
The capability set. Text, image and video input; text output; tool calling; structured JSON output; streaming. The model card lists vision, tools, JSON and reasoning as capabilities, and the parameter set includes `tools`, `tool_choice`, `response_format`, `structured_outputs`, `reasoning_effort` and `include_reasoning` [OURS].
The bill. All three endpoints bill identically: $2.00 per million input, $10.00 output, $0.20 cached, with the same automatic five-minute prefix caching [VENDOR]. A migration between surfaces does not change cost per token; it changes how many tokens you send.
Where the surfaces diverge
Field names. The completion length limit is `max_tokens` in Chat Completions and `max_completion_tokens` in the vendor’s own documentation for newer surfaces — and on this model the default is 131,072 if you set nothing, against a maximum of 1,048,576 [VENDOR]. If your client sends `max_tokens: 4096` out of habit, you have silently capped a model that can answer far longer.
Reasoning visibility. `include_reasoning` and `reasoning_effort` are both in the supported parameter list. Whether the reasoning stream is returned as a separate field, interleaved, or omitted depends on the surface and the SDK’s rendering; if your application parses the response to strip thinking, verify it against the surface you chose rather than assuming the shape from another provider.
Sampling rejections. Passing `temperature` to this model is not a preference, it is an error [VENDOR]. Two of the three surfaces make that error loud; the third may pass it through to the provider and surface it as a 400 several layers down. Testing on the surface you will deploy on is the only way to know which you have.
State handling. The Responses surface is designed around server-side conversation state; the other two are stateless request-response. That difference decides where your conversation history lives, and on a model where 95% of input tokens are cached reads [INDEPENDENT], where history lives has a direct cost consequence: a stable prefix maintained by the client is cache-friendly, while a server that rebuilds the thread may not be.
The migration checklist
Six items, in order, for moving an existing workload onto this model through any of the three surfaces.
- Point the base URL at the gateway and change one model string. `https://api.orcarouter.ai/v1` with `model=”kimi/kimi-k3.1-pro”`, or the equivalent for the Messages surface.
- Remove sampling parameters. `temperature`, `top_p`, `n` and the penalties are refused or ignored; leaving them in place is a latent 400.
- Set the completion budget explicitly, from the task, not from the default. This is the single most common cause of truncated output on this model.
- Choose an effort level and freeze it per workload. Changing effort mid-conversation breaks the cache prefix, which moves cost from $0.20 to $2.00 per million on the largest line of the bill.
- Verify tool-call formatting on the surface you chose. Function calling works across all three, but the JSON envelope differs, and an agent that parses `tool_calls` from one protocol will silently find nothing in another.
- Run ten real tasks and compare against your current model on cost per completed task, not per token. That number, not the rate card, decides whether the migration pays.
Why three surfaces is the right shape for this model
A model that is fourth on the independent index and priced at $2/$10 does not win by being the best; it wins by being the easiest frontier-adjacent model to adopt. Three protocol surfaces is exactly that strategy at the integration layer: whatever stack you already have, one string changes and you are calling it.
It also matters for the comparison this model is really in. Gemini 4 Argon, GPT-6.1 Sol and Claude Sonnet 5.5 all sit on the same $2/$10 card [INDEPENDENT]. When four models cost the same, the switching cost becomes the deciding factor, and a model that speaks your client’s protocol has a switching cost of one line.
The reverse is worth saying too: a model behind a single proprietary protocol, however good, asks you to rebuild your integration to find out. That is an expensive way to run an evaluation.
The summary
Kimi K3.1 Pro answers on Chat Completions, Responses and Messages with one model id and one rate card. Use the surface your client already speaks, delete the sampling parameters, set the completion ceiling explicitly, fix an effort level per workload, and verify tool-call parsing where you deploy. Everything else about the model — the reasoning default, the fixed sampling, the 1M window, the flat price — is the same whichever door you come in through.
Sourcing note: the three endpoint paths, the model string, the supported parameter list and the base URL are from OrcaRouter’s published model card and documentation for this model. The fixed sampling values, the always-on reasoning, the three effort levels with max as the default, the 131,072 default completion ceiling and the automatic caching with a five-minute TTL are Moonshot’s documentation, fetched 26 October 2026. The 95%-cached input shape is Artificial Analysis’s per-task decomposition. The migration checklist and the protocol guidance are ours.
