Context
PR #247 correctly fixes the OpenAI-Compatible provider's streaming path to omit temperature when no custom value is set (instead of forcing temperature: 0). However, several related gaps remain across the codebase.
Issues
1. Non-streaming path silently ignores modelTemperature
File: src/api/providers/openai.ts (lines ~232–251)
The non-streaming createMessage branch builds requestOptions without any temperature field. A user who sets modelTemperature: 0.9 and disables streaming will silently get the server's default instead of their chosen value. The streaming path (fixed in #247) correctly handles this — the non-streaming path should mirror that logic.
2. Other providers still default to temperature: 0
The same ?? 0 pattern that #247 fixed in OpenAiHandler exists in several other providers:
src/api/providers/lite-llm.ts (lines 222, 307): this.options.modelTemperature ?? 0src/api/providers/base-openai-compatible-provider.ts (line 87): this.options.modelTemperature ?? info.defaultTemperature ?? this.defaultTemperature (where this.defaultTemperature defaults to 0)src/api/providers/native-ollama.ts (lines 229, 355): this.options.modelTemperature ?? ... : 0
These providers will override the server's default temperature with 0 when the user hasn't set a custom value — the same bug that #247 fixed for the OpenAI-Compatible streaming path.
3. getModel() dead defaultTemperature: 0 (cleanup)
In src/api/providers/openai.ts (line ~298), getModel() calls getModelParams({ ..., defaultTemperature: 0 }). The returned temperature field is never used in createMessage (only info and reasoning are destructured). After #247's fix, defaultTemperature: 0 is misleading since the streaming path no longer defaults to 0. This should either be removed or the temperature computation should be centralized through getModelParams.
Expected behavior
- All code paths (streaming and non-streaming) should respect
modelTemperature when set
- When
modelTemperature is unset, temperature should be omitted (not forced to 0) so the server's default applies
- This behavior should be consistent across all providers
Related
Context
PR #247 correctly fixes the OpenAI-Compatible provider's streaming path to omit
temperaturewhen no custom value is set (instead of forcingtemperature: 0). However, several related gaps remain across the codebase.Issues
1. Non-streaming path silently ignores
modelTemperatureFile:
src/api/providers/openai.ts(lines ~232–251)The non-streaming
createMessagebranch buildsrequestOptionswithout anytemperaturefield. A user who setsmodelTemperature: 0.9and disables streaming will silently get the server's default instead of their chosen value. The streaming path (fixed in #247) correctly handles this — the non-streaming path should mirror that logic.2. Other providers still default to
temperature: 0The same
?? 0pattern that #247 fixed inOpenAiHandlerexists in several other providers:src/api/providers/lite-llm.ts(lines 222, 307):this.options.modelTemperature ?? 0src/api/providers/base-openai-compatible-provider.ts(line 87):this.options.modelTemperature ?? info.defaultTemperature ?? this.defaultTemperature(wherethis.defaultTemperaturedefaults to0)src/api/providers/native-ollama.ts(lines 229, 355):this.options.modelTemperature ?? ... : 0These providers will override the server's default temperature with
0when the user hasn't set a custom value — the same bug that #247 fixed for the OpenAI-Compatible streaming path.3.
getModel()deaddefaultTemperature: 0(cleanup)In
src/api/providers/openai.ts(line ~298),getModel()callsgetModelParams({ ..., defaultTemperature: 0 }). The returnedtemperaturefield is never used increateMessage(onlyinfoandreasoningare destructured). After #247's fix,defaultTemperature: 0is misleading since the streaming path no longer defaults to 0. This should either be removed or the temperature computation should be centralized throughgetModelParams.Expected behavior
modelTemperaturewhen setmodelTemperatureis unset,temperatureshould be omitted (not forced to 0) so the server's default appliesRelated