warpdotdev/warp · error · anyhow::Error

Could not retrieve the agent-mode model list from the server

Error message

Could not retrieve the agent-mode model list from the server (the request failed or returned no models). Try again later.

What it means

`classify_agent_mode_base_model_id` validates a `--model` id against the fetched agent-mode model list. When the list request failed or returned zero models (`list_unavailable`), a non-matching id is reported as a retrieval problem rather than a bad id — the point is to distinguish 'we could not check' from 'the id is wrong'. Retrying later is the intended remedy.

Source

Thrown at app/src/ai/agent_sdk/common.rs:61

        model_id,
        &valid_ids,
        llm_prefs.agent_mode_models_unavailable(),
    )
}

/// Classifies a user-supplied agent-mode model id against the available model
/// list, distinguishing "the model list fetch failed (so the list is empty or
/// stale)" from "the id is genuinely not in a valid list".
fn classify_agent_mode_base_model_id(
    model_id: &str,
    valid_ids: &[LLMId],
    list_unavailable: bool,
) -> anyhow::Result<LLMId> {
    let llm_id: LLMId = model_id.into();
    if valid_ids.contains(&llm_id) {
        Ok(llm_id)
    } else if list_unavailable {
        Err(anyhow::anyhow!(
            "Could not retrieve the agent-mode model list from the server \
             (the request failed or returned no models). Try again later."
        ))
    } else {
        let suggestions = valid_ids
            .iter()
            .map(|id| id.to_string())
            .collect::<Vec<_>>()
            .join(", ");
        Err(anyhow::anyhow!(
            "Unknown model id '{model_id}'. Try one of: {suggestions}"
        ))
    }
}

pub(super) fn parse_ambient_task_id(
    run_id: &str,
    error_prefix: &str,

View on GitHub (pinned to e72fd7aacb)

Solutions

Retry the command after a short delay — catalog outages are usually transient
Check connectivity and auth to the server (re-login if the session expired)
Run without --model to use the default model while the catalog is unavailable
If it persists, check server status/support — the model list endpoint itself is failing

Defensive patterns

Strategy: retry

Validate before calling

async fn fetch_model_ids_with_retry(tries: u32) -> Option<Vec<LLMId>> {
    for i in 0..tries {
        if let Ok(list) = fetch_agent_mode_models().await {
            if !list.is_empty() { return Some(list); }
        }
        tokio::time::sleep(std::time::Duration::from_secs(1u64 << i)).await;
    }
    None
}
// Treat None as 'list unavailable': warn and use the default model instead of hard-failing.

Try / catch

match classify_agent_mode_base_model_id(&id, &valid_ids, list_unavailable) {
    Ok(llm) => llm,
    Err(e) if list_unavailable => {
        // Transient catalog outage: retry once, then proceed with the default model and warn
        log::warn!("model list unavailable ({e}); falling back to default model");
        default_llm()
    }
    Err(e) => return Err(e),
}

Prevention

Distinguish empty/failed list from a real list before validating ids
Retry catalog fetches with backoff
Show an 'unavailable' state in UIs instead of rejecting valid ids

When it happens

Trigger: Passing `--model <id>` to an agent command when the server's model-list request failed (network/auth error) or returned an empty list, so valid_ids is empty or stale and the id cannot be confirmed.

Common situations: Model-catalog outage or server incident; expired auth breaking the list call; offline or proxied environments; startup races where the catalog has not loaded yet.

Related errors

AI-assisted analysis of warpdotdev/warp@e72fd7aacb (2026-08-16). Data as JSON: /api/errors/3700357b1f4476ae. Report an issue: GitHub.