[BUG] Custom temperature disabled but sending as 0

[brunocasado]

Describe the bug
If custom temperature is disabled, it's sending 0 to model

To Reproduce
Steps to reproduce the behavior:

1. Go to 'settings'
2. Click on 'providers'
3. Scroll down to 'advanced settings'
4. do not mark use custom temperature

Expected behavior
Shouldn't send the temperature since models can be configured with a default temp

Screenshots

What version of zoo are you running
i.e. 3.54.1

[proyectoauraorg]

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.)

[edelauna]

I think option A would be preferred. What’s the risk though, are there any providers which make temperature required?

[proyectoauraorg]

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?