Skip to content

Conversation

@neavo
Copy link
Contributor

@neavo neavo commented Feb 3, 2026

Summary

  • Add k2p5 to the exclusion list in variants() function to prevent Kimi K2.5 from incorrectly getting high/max thinking variants

Details

The Kimi For Coding provider uses k2p5 as the model ID for Kimi K2.5, which does not contain the string "kimi". This causes it to bypass the exclusion logic and incorrectly receive thinking variants support.

Confirmed with Moonshot official staff: Kimi-K2.5 does NOT support thinking budget configuration.

This is a temporary workaround. The correct solution is to fix the model ID in models.dev data to use kimi-k2.5 instead of k2p5.

Fixes #11917

Kimi For Coding provider uses 'k2p5' as model ID which bypasses the
'kimi' exclusion check. Confirmed with Moonshot official staff that
Kimi-K2.5 does NOT support thinking budget configuration.

This is a temporary fix - the correct solution is to update models.dev
data to use 'kimi-k2.5' instead of 'k2p5'.

Fixes #11917
@github-actions
Copy link
Contributor

github-actions bot commented Feb 3, 2026

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

@rekram1-node
Copy link
Collaborator

wait so kimi for coding has 2 model ids that map to same thing?

@rekram1-node rekram1-node merged commit 54e14c1 into anomalyco:dev Feb 3, 2026
6 checks passed
@neavo
Copy link
Contributor Author

neavo commented Feb 3, 2026

image

wait so kimi for coding has 2 model ids that map to same thing?

In fact, the model ID obtained via the https://api.kimi.com/coding/models endpoint is kimi-for-coding
which maps to the actual model displayed in the user console (currently K2.5)
I am not quite sure why the model ID provided in models.json is k2p5

@rekram1-node
Copy link
Collaborator

game to update it, I don't have a kimi for coding sub so I can't test unless I grab one

@luisf371
Copy link

luisf371 commented Feb 4, 2026

Please revert this change or modify to allow thinking. Kimi Code documentation is limited but the below screenshots show non-thinking (normal) and thinking (high or max) based on the variant. I conducted several runs and normal variant consistently was faster making me believe it not a matter of reasoning tokens being hidden in the background.
ksnip_20260204-001505
ksnip_20260204-001505(2)
ksnip_20260204-001507

@neavo
Copy link
Contributor Author

neavo commented Feb 4, 2026

01

I directly asked Kimi's official staff, and the conclusion I got was: K2.5 does not support reasoning configurations.

@rekram1-node
Copy link
Collaborator

@luisf371 they should not make any difference, it was a visual thing only their api doesnt support the variants

@luisf371
Copy link

luisf371 commented Feb 4, 2026

That's fair but i think we are getting confused on the intent. Yes i understand that the Kimi Code API does not support control of the thinking token efforts (think alot, think little, etc) which is what "variants" typically control.
However, k2p5 support both thinking and non-thinking, and if its anything like the official API, its controlled thru ""thinking": {"type": "disabled"}" > https://platform.moonshot.ai/docs/guide/kimi-k2-5-quickstart#disable-thinking-capability-example
For whatever reason before the change on 1.1.50 - having the variant set to "none" was thinking disabled, and high/max was thinking enabled as showed in my previous post.

I even installed their official kimi client and verified that you can select between thinking and non-thinking.
image

Thank you for what you guys contribute!

@rekram1-node
Copy link
Collaborator

Yes that's true, we can add a non thinking variant

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Kimi K2.5 model ID 'k2p5' bypasses reasoning variants exclusion

3 participants