fix(kimi): stop sending temperature, which Kimi pins per model - #16
Merged
Conversation
#15 set thinking to 'disabled' on kimi-k2.6, and the next review came back 400: invalid temperature: only 0.6 is allowed for this model Disabling thinking is what moved k2.6 into its non-thinking regime, where 1.0 -- the value the workflow has always sent -- is rejected. From the parameter reference: kimi-k2.6: fixed at 1.0 in thinking mode and 0.6 in non-thinking mode; other values return an error. Do not pass temperature explicitly when calling these models. Every Kimi model pins it: kimi-k3 and kimi-k2.7-code at 1.0, kimi-k2.6 at 1.0 or 0.6 depending on thinking. Hardcoding 0.6 would be correct only while both the model and the thinking setting stay exactly as they are today, and would break silently the moment either moves. Omitting the field is the only choice correct for every model. temperature becomes a string input defaulting to '', and is added to the payload only when non-empty, mirroring how `thinking` already works. No caller passes temperature (only lambda_compiler_kit passes an input at all, a custom prompt), so the type change breaks nobody. Source: https://platform.kimi.ai/docs/api/models-overview
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Third and hopefully last link in the chain from #14 -> #15.
What happened
#15 set
thinking: 'disabled'onkimi-k2.6. The next/kimirun came back with a 400, posted as a proper error comment (the #15 hardening working as intended):Disabling thinking is precisely what moved k2.6 into its non-thinking regime, where the
temperature: 1this workflow has always sent is rejected.The rule
From the Model Parameter Reference:
kimi-k3kimi-k2.7-codekimi-k2.6temperature1.01.01.0thinking /0.6non-thinkingThe fix
Stop sending it. Hardcoding
0.6would be correct only while the model stays k2.6 and thinking stays off -- it would break the moment either moves, which is exactly the trap that produced this PR. Omitting the field is the only value correct across all three models.temperaturebecomes a string input defaulting to'', added to the payload only when non-empty, mirroringthinking:Anyone who needs an explicit value can still pass one as a string.
Compatibility
No caller passes
temperature. Across all 12 consumers, the only one that passes any input islambda_compiler_kit(a customprompt), so changing the input type fromnumbertostringbreaks nobody.Verification
YAML parses; inputs resolve to
model=kimi-k2.6,thinking=disabled,temperature=''. Payload construction exercised across thethinkingxtemperaturematrix, asserting onhas()rather than eyeballing that both keys are genuinely absent (notnull) when their input is'', and present with the right value when set.Not verified against the live API -- that needs the merge plus a
v1move.v1currently points atd66ba3f(#15), which 400s on every review.