[BUG] OpenAI compatible provider setting should not enforce a temperature of 0

[azalty]

Problem (one or two sentences)

When the Roo Code UI setting for a model Custom temperature is not set, and an OpenAI compatible custom provider is used (with a custom base URL), the temperature is automatically set to 0 and passed to the provider. This should not happen, and no temperature should be passed (unless the model is one of the recognized defaults…)

Context (who is affected and when)

This issue affects users of custom OpenAI compatible providers, that do not set a custom temperature when setting up a model configuration. It might also affect other use cases, which I did not identify.

Reproduction steps

1. Add a custom OpenAI compatible model, from a non directly supported provider, like nano-gpt.com
2. Do not set a custom temperature for the model
3. Use a non directly supported model, or one that isn’t identified as having a default. On NanoGPT, that’s the case of qwen3.5-flash for example.
4. Roo Code sends a temperature of 0 to the provider, which it should not. Not passing the temperature allows the provider to use its backend default (if they set one).

Expected result

No temperature should be forced into the chat completion call

Actual result

A temperature of 0 is forced

Variations tried (optional)

No response

App Version

v3.51.1

API Provider (optional)

OpenAI Compatible

Model Used (optional)

Qwen3.5 Flash, but not really relevant

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[azalty]

Issue #7187 was similar to this one. Seems like someone overrode the fix (it had a different intent, but same problem)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause

When using the "OpenAI Compatible" provider (OpenAiHandler in src/api/providers/openai.ts), the createMessage method hardcodes a fallback temperature of 0 at line 157:

temperature: this.options.modelTemperature ?? (deepseekReasoner ? DEEP_SEEK_DEFAULT_TEMPERATURE : 0),

When the user has not set a custom temperature (modelTemperature is undefined) and the model is not a DeepSeek reasoner, the temperature is forced to 0 and sent to the provider. This overrides whatever server-side default the provider may have.

Proposed Fix

1. src/api/providers/openai.ts line 157 - Change the fallback from 0 to undefined for the general (non-DeepSeek) case:

   temperature: this.options.modelTemperature ?? (deepseekReasoner ? DEEP_SEEK_DEFAULT_TEMPERATURE : undefined),

   This ensures that when no custom temperature is set and the model is not a recognized DeepSeek reasoner, the temperature field is undefined and omitted from the API request, letting the remote provider use its own default.

2. src/api/transform/model-params.ts - Update GetModelParamsOptions to allow defaultTemperature to be number | undefined, and update getModelParams line 98 to preserve undefined through the chain:

   let temperature = customTemperature ?? model.defaultTemperature ?? defaultTemperature

   This already works correctly if defaultTemperature is undefined - the result will be undefined when none of the three sources provide a value.

3. src/api/providers/openai.ts getModel() (line 290) - Pass undefined instead of 0 as defaultTemperature:

   defaultTemperature: undefined,

4. Update tests in src/api/transform/__tests__/model-params.spec.ts and src/api/providers/__tests__/openai.spec.ts to verify the new behavior: when no temperature is configured, undefined is returned/sent instead of 0.

Scope & Safety

• The OpenAiHandler is used specifically for the "OpenAI Compatible" provider type. Actual OpenAI models use OpenAiNativeHandler (separate file), so this change does not affect them.
• DeepSeekHandler extends OpenAiHandler but overrides createMessage with its own temperature handling, so it is unaffected.
• Other providers (Anthropic, Gemini, etc.) each have their own temperature logic and are unaffected.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.