Skip to content

fix(kimi): stop sending temperature, which Kimi pins per model - #16

Merged
klaus993 merged 1 commit into
mainfrom
fix/kimi-omit-temperature
Sep 1, 2026
Merged

fix(kimi): stop sending temperature, which Kimi pins per model#16
klaus993 merged 1 commit into
mainfrom
fix/kimi-omit-temperature

Conversation

@klaus993

@klaus993 klaus993 commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Third and hopefully last link in the chain from #14 -> #15.

What happened

#15 set thinking: 'disabled' on kimi-k2.6. The next /kimi run came back with a 400, posted as a proper error comment (the #15 hardening working as intended):

Review failed: Kimi API request failed with status 400: invalid temperature: only 0.6 is allowed for this model

Disabling thinking is precisely what moved k2.6 into its non-thinking regime, where the temperature: 1 this workflow has always sent is rejected.

The rule

From the Model Parameter Reference:

Parameter kimi-k3 kimi-k2.7-code kimi-k2.6
temperature Fixed at 1.0 Fixed at 1.0 1.0 thinking / 0.6 non-thinking

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.

The fix

Stop sending it. Hardcoding 0.6 would 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.

temperature becomes a string input defaulting to '', added to the payload only when non-empty, mirroring thinking:

+ (if $temperature == "" then {} else { temperature: ($temperature | tonumber) } end)

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 is lambda_compiler_kit (a custom prompt), so changing the input type from number to string breaks nobody.

Verification

YAML parses; inputs resolve to model=kimi-k2.6, thinking=disabled, temperature=''. Payload construction exercised across the thinking x temperature matrix, asserting on has() rather than eyeballing that both keys are genuinely absent (not null) when their input is '', and present with the right value when set.

Not verified against the live API -- that needs the merge plus a v1 move. v1 currently points at d66ba3f (#15), which 400s on every review.

#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
@klaus993
klaus993 merged commit 5458fb3 into main Sep 1, 2026
@klaus993
klaus993 deleted the fix/kimi-omit-temperature branch September 1, 2026 19:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant