zeroclaw-labs/zeroclaw · error · anyhow::Error

temperature unsupported by Gemini CLI: {temperature}. Suppor

Error message

temperature unsupported by Gemini CLI: {temperature}. Supported values: 0.7 or 1.0

What it means

The gemini CLI wrapper deliberately supports only temperatures 0.7 and 1.0 (within a small epsilon); validate_temperature rejects everything else so that switching a model_provider from the API backend to gemini_cli cannot silently keep an incompatible temperature.

Source

Thrown at crates/zeroclaw-providers/src/gemini_cli.rs:92

    /// Returns true if the model argument should be forwarded to the CLI.
    fn should_forward_model(model: &str) -> bool {
        let trimmed = model.trim();
        !trimmed.is_empty() && trimmed != DEFAULT_MODEL_MARKER
    }

    fn supports_temperature(temperature: f64) -> bool {
        GEMINI_CLI_SUPPORTED_TEMPERATURES
            .iter()
            .any(|v| (temperature - v).abs() < TEMP_EPSILON)
    }

    fn validate_temperature(temperature: f64) -> anyhow::Result<()> {
        if !temperature.is_finite() {
            anyhow::bail!("Gemini CLI model_provider received non-finite temperature value");
        }
        if !Self::supports_temperature(temperature) {
            anyhow::bail!(
                "temperature unsupported by Gemini CLI: {temperature}. \
                 Supported values: 0.7 or 1.0"
            );
        }
        Ok(())
    }

    fn redact_stderr(stderr: &[u8]) -> String {
        let text = String::from_utf8_lossy(stderr);
        let trimmed = text.trim();
        if trimmed.is_empty() {
            return String::new();
        }
        if trimmed.chars().count() <= MAX_GEMINI_CLI_STDERR_CHARS {
            return trimmed.to_string();
        }
        let clipped: String = trimmed.chars().take(MAX_GEMINI_CLI_STDERR_CHARS).collect();
        format!("{clipped}...")

View on GitHub (pinned to 88bb9c8533)

Solutions

Set temperature to exactly 0.7 or 1.0
Omit temperature (None) to accept the CLI default
Use the API-backed gemini provider when other temperatures are required

Example fix

# before (config)
temperature = 0.2

# after
temperature = 0.7   # or 1.0; or remove the key entirely

Defensive patterns

Strategy: validation

Validate before calling

const GEMINI_CLI_TEMPERATURES: [f64; 2] = [0.7, 1.0];
fn gemini_cli_temperature_ok(t: f64) -> bool {
    t.is_finite() && GEMINI_CLI_TEMPERATURES.iter().any(|v| (t - v).abs() < 1e-9)
}

Type guard

fn gemini_cli_temperature_ok(t: f64) -> bool {
    t.is_finite() && ((t - 0.7).abs() < 1e-9 || (t - 1.0).abs() < 1e-9)
}

Try / catch

if let Err(e) = provider.chat_with_system(None, prompt, model, Some(t)).await {
    if e.to_string().starts_with("temperature unsupported by Gemini CLI") {
        return Ok(/* fallback: retry with Some(0.7) or None */);
    }
    return Err(e);
}

Prevention

Keep per-provider temperature tables in config validation
Prefer None over guessed values when the CLI default is acceptable
Route workloads needing custom temperatures to the API-backed gemini provider

When it happens

Trigger: Setting temperature Some(0.2), Some(1.5), or Some(0.71) on a provider of type gemini_cli; reusing one agent config across API-backed and CLI-backed providers.

Common situations: Copy-pasting an API-era temperature into CLI provider config; templates defaulting temperature to 0.0; drift after renaming providers.

Related errors

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/5d31d2ac45e2d9dd. Report an issue: GitHub.