[BUG] Custom temperature disabled but sending as 0 #242

Activity

1. brunocasado

   added

   bugSomething isn't workingSomething isn't working

   on May 21, 2026
2. brunocasado

   added the

   Bug

   issue type on May 21, 2026
3. brunocasado

   changed the title [-][BUG][/-] [+][BUG] Custom temperature disabled but sending as 0[/+] on May 21, 2026
4. proyectoauraorg commented on May 21, 2026

   

   proyectoauraorg

   on May 21, 2026

   Contributor

   More actions

   Looking into this — the behavior isn't isolated to one provider. The pattern this.options.modelTemperature ?? <default> is repeated across ~13 providers (openai, openai-native, lite-llm, mistral, lm-studio, base-openai-compatible, …), so when "use custom temperature" is off, each one falls back to its own default (often 0) and still sends temperature.

   A robust fix probably belongs in a shared layer rather than per-provider, and it hinges on a design decision: when the user hasn't set a custom temperature, should we (a) omit the temperature field so the model uses its server-side default, or (b) keep sending a provider default for backward compatibility? Option (a) matches the expectation here but changes long-standing behavior, so confirming the intended direction first would help.

   Happy to help with a PR once the preferred behavior is decided. (Related: #215 / PR #233 added a model-capability gate supportsTemperature for OpenAI-Compatible — this issue is the orthogonal user-preference case.)

   👍React with 👍1Reacted by edelauna
5. edelauna commented on May 21, 2026

   

   edelauna

   on May 21, 2026

   Contributor

   More actions

   I think option A would be preferred. What’s the risk though, are there any providers which make temperature required?
6. proyectoauraorg commented on May 21, 2026

   

   proyectoauraorg

   on May 21, 2026

   Contributor

   More actions

   No provider hard-requires it — temperature is optional on the OpenAI-compatible APIs (a server-side default applies), and the codebase already omits it conditionally in a few spots without issues (DeepSeek thinking models, the supportsTemperature gate in vercel-ai-gateway, and #233 for OpenAI-Compatible). So option A shouldn't cause 4xx errors.

   The risk is behavioral rather than an error: today, unchecking "use custom temperature" still sends each provider's default (0 for OpenAI-compatible, 1.0 for MiniMax, 0.3 for DeepSeek…). Under option A those requests omit it and the server applies its own default — which can differ — so users relying on the implicit default could see different outputs.

   Implementation-wise the toggle already disambiguates: TemperatureControl sets the value to null when unchecked, so we can omit temperature exactly when it's null/undefined and keep sending it when it's a number (including an explicit 0). Happy to put up a PR — either provider-by-provider via the existing conditional-spread pattern, or in a shared helper if you'd prefer a single place. Which do you favor?
7. proyectoauraorg

   added a commit that references this issue on May 26, 2026

   fix(openai): omit temperature when no custom value is set (Zoo-Code-O…

   ...

   fd13906
8. drvaquera

   added a commit that references this issue on May 31, 2026

   fix(openai): omit temperature when no custom value is set (Zoo-Code-O…

   ...

   f0a7f9d
9. edelauna

   added a commit that references this issue on Jun 2, 2026

   fix(openai): omit temperature when no custom value is set (Zoo-Code-O…

   ...

   9193941
10. ainthek commented on Jun 11, 2026

    

    ainthek

    on Jun 11, 2026

    More actions

    will you solve this ? it is anoying, and speed of fixes is close to RooCode (slow)