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

Ollama API error ({}): {}. Is Ollama running? (brew install

Error message

Ollama API error ({}): {}. Is Ollama running? (brew install ollama && ollama serve)

What it means

The ZeroClaw Ollama provider sent a chat request (send_request_inner) and Ollama answered with a non-success HTTP status. The response body is sanitized and embedded in the message; the 'Is Ollama running?' hint covers the case where the configured base_url reaches a service that is not a healthy Ollama instance. Note that a fully-down server normally surfaces earlier as a reqwest connection error through the `?` operator, so this specific error means something did answer, with a 4xx/5xx.

Source

Thrown at crates/zeroclaw-providers/src/ollama.rs:739

        ::zeroclaw_log::record!(
            DEBUG,
            ::zeroclaw_log::Event::new(module_path!(), ::zeroclaw_log::Action::Note),
            &format!("response body length: {} bytes", body.len())
        );

        if !status.is_success() {
            let raw = String::from_utf8_lossy(&body);
            let sanitized = super::sanitize_api_error(&raw);
            ::zeroclaw_log::record!(
                ERROR,
                ::zeroclaw_log::Event::new(module_path!(), ::zeroclaw_log::Action::Fail)
                    .with_outcome(::zeroclaw_log::EventOutcome::Failure),
                &format!(
                    "Ollama error response: status={} body_excerpt={}",
                    status, sanitized
                )
            );
            anyhow::bail!(
                "Ollama API error ({}): {}. Is Ollama running? (brew install ollama && ollama serve)",
                status,
                sanitized
            );
        }

        let chat_response: ApiChatResponse = match serde_json::from_slice(&body) {
            Ok(r) => r,
            Err(e) => {
                let raw = String::from_utf8_lossy(&body);
                let sanitized = super::sanitize_api_error(&raw);
                ::zeroclaw_log::record!(
                    ERROR,
                    ::zeroclaw_log::Event::new(module_path!(), ::zeroclaw_log::Action::Fail)
                        .with_outcome(::zeroclaw_log::EventOutcome::Failure),
                    &format!(
                        "Ollama response deserialization failed: {e}. body_excerpt={}",
                        sanitized

View on GitHub (pinned to 88bb9c8533)

Solutions

Confirm Ollama answers: curl http://localhost:11434/api/tags (or your configured base_url + /api/tags).
Match the configured model tag exactly against `ollama list` and run `ollama pull <tag>` for anything missing.
Start or restart the service: `ollama serve` in the foreground, or `brew services start ollama` / systemd unit for persistence.
Verify the ollama provider entry's base_url/endpoint in ZeroClaw config points at the real Ollama port with no proxy in between.
Read the sanitized body excerpt in the zeroclaw WARN log event ('Ollama error response: status=... body_excerpt=...') — it carries Ollama's own error text.

Example fix

# before — tag does not match `ollama list`
[providers.models.ollama.local]
model = "llama3"

# after — exact tag from `ollama list`
[providers.models.ollama.local]
model = "llama3:8b"

Defensive patterns

Strategy: try-catch

Validate before calling

# Pre-flight before the chat call: Ollama up + model present
curl -sf http://localhost:11434/api/tags | jq -e --arg m "$ZC_OLLAMA_MODEL" '.models[]?.name == $m' >/dev/null && echo ready

Try / catch

Match the anyhow error message for the 'Ollama API error (' prefix and parse the embedded status: 5xx → retry with exponential backoff (transient); 404 → fail fast with 'ollama pull <model>' guidance; other 4xx → surface the sanitized body. Always log the sanitized body the provider already attached.

Prevention

Run Ollama under a service manager (brew services / systemd) so it auto-restarts
Pull configured model tags at deploy time, not lazily at chat time
Pin exact model tags in config and diff them against `ollama list` in CI
Probe /api/tags in container/orchestrator health checks

When it happens

Trigger: POST to Ollama /api/chat returns non-2xx: 404 'model not found' when the configured model tag was never pulled, 500 on a malformed or oversized request, or a proxy/other process occupying the configured base_url port and returning an error status.

Common situations: Model tag typo in config (llama3 vs llama3:8b); forgot `ollama pull` on a fresh machine; ollama serve crashed while base_url still resolves; base_url points at an OpenAI-compatible gateway instead of the native Ollama API; an Ollama version that rejects newer request fields.

Related errors

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