A 200 response means your API request arrived. It does not necessarily mean the model behaved as the parameter name suggests. In one Kimi K3 route check, reasoning_effort=low and effort=low were both accepted, yet the recorded reasoning-token counts remained essentially the same: 50, 59, and 64. Only thinking: disabled brought the count to zero.
That is a small observation with a large operational implication: if a setting is meant to manage reasoning spend, a successful HTTP response is the beginning of verification—not the end.
Disclosure: I work with OrcaRouter and used it to run this evaluation. One OpenAI-compatible key gave me access to every model in this test, without changing how any model answered.
AI-generated illustration featuring official model logos; logos and model names are used descriptively and remain the property of their respective owners.
Compare model routing and usage through OrcaRouter.
The request was accepted; the usage did the talking
Kimi’s vendor documentation says its effort setting can be low, high, or max, defaults to max, and that thinking cannot normally be disabled. But documentation, a gateway’s request validation, and the usage returned from the exact route your application uses are three different things.
In this check, the decisive evidence was not the status code. It was the returned accounting. On the tested Kimi route, accepted low-effort requests did not show a meaningful reduction in recorded reasoning tokens; disabling thinking did. That does not establish how every Kimi endpoint behaves, nor how another provider’s route will interpret the same field. It does show why teams should inspect the data that comes back from the route they actually deploy.
The broader Rewind Runner case study makes the cost angle concrete. With vendor-default parameters, Kimi recorded 53,800 reasoning tokens across four turns. A parameter being accepted by a gateway is not evidence that it changed the provider’s compute behaviour.
A case study, not a leaderboard
The controlled portion covered GPT-5.6 Terra and Kimi K3: four ordered prompts, vendor-default parameters, and one run per model per round. That is n=1 per run or attempt—not a benchmark and not proof of stable behavior. The rewind check was behavioural: a headless browser looked for matched pre-rewind frames moving backward, rather than judging whether the game was fun.
Claude Opus 5 belongs outside this comparison. It was tested separately through Anthropic’s native messages endpoint, with the full brief delivered at once and a time-boxed feedback loop. It must not be ranked against the controlled Terra/Kimi run, and no apparent speed, cost, token, or search-count observation here should be read as a general winner claim.
There was also a brief human play report: one named, non-blinded player, without a rubric. That is useful color about a play session, not quality ground truth and not evidence that a level is impossible.
This is a first-party Rewind Runner test record, not a universal model ranking.
What API users should do next
If reasoning controls matter to your budget or response time, log four things for representative requests: returned usage, latency, completion status, and the actual output. Then change one parameter at a time and compare the records. A 200 is a transport result. Your usage data is the closer thing to a receipt.
The practical takeaway is simple: treat accepted parameters as hypotheses until the route’s returned usage confirms their effect.
Sources
First-party Rewind Runner records: Kimi route parameter-acceptance and usage observations; vendor-default four-turn usage record; Rewind Runner evaluation scope and test record.
This evaluation was run through OrcaRouter. The author works with OrcaRouter; model access does not imply affiliation with, endorsement by, or sponsorship from model providers. Model names and logos are used descriptively. All trademarks belong to their respective owners.
