Ollama local models time out in PicoClaw (120s fixed HTTP timeout) while same models respond fine via direct Ollama API

[Musawer1214]

Quick Summary

Using PicoClaw with local Ollama models (qwen3:8b, qwen3:4b) consistently times out with context deadline exceeded, while the same models respond normally via direct Ollama API (/v1/chat/completions) on the same machine.

Environment & Tools

• PicoClaw Version: v0.1.2 (Windows x86_64 release binary)
• Go Version: N/A (release binary run)
• AI Model & Provider: ollama/qwen3:8b, ollama/qwen3:4b via local Ollama (http://127.0.0.1:11434/v1)
• Operating System: Windows
• Hardware: Ryzen 7 8845H, 32GB RAM
• Channels: CLI (picoclaw agent ...)
• Ollama Version: 0.13.5

Steps to Reproduce

1. Start Ollama server:

ollama serve

2. Use config with local Ollama:

{
  "agents": {
    "defaults": {
      "model": "ollama/qwen3:8b",
      "workspace": "~/.picoclaw/workspace",
      "restrict_to_workspace": true,
      "max_tokens": 4096,
      "max_tool_iterations": 20
    }
  },
  "providers": {
    "ollama": {
      "api_key": "local",
      "api_base": "http://127.0.0.1:11434/v1"
    }
  }
}

3. Run PicoClaw:

picoclaw agent -m "What is 2+2? Reply with one number."

(also reproduced with fresh session key: -s bench-fresh-1)

❌ Actual Behavior

PicoClaw retries and then fails after timeout:

• repeated warning:
  failed to send request: Post "http://127.0.0.1:11434/v1/chat/completions": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
• final error:
  LLM call failed after retries... context deadline exceeded

Observed wait is about ~6 minutes total (multiple retry cycles).

✅ Expected Behavior

PicoClaw should successfully complete local Ollama requests on this hardware, similar to direct Ollama API results, or at least allow configurable timeout for local providers.

💬 Additional Context

Direct Ollama API calls succeed on same machine (same models/prompts), e.g.:

• qwen3:8b: ~31s, ~75s, ~22s for 3 test prompts
• qwen3:4b: ~28s, ~20s, ~41s for 3 test prompts

Suspected root cause in repo:

• pkg/providers/openai_compat/provider.go sets fixed HTTP client timeout:

client := &http.Client{
    Timeout: 120 * time.Second,
}

Request:

• Please make provider timeout configurable (config/env), and/or increase timeout for localhost/Ollama use cases.
• Optional: add streaming path for OpenAI-compatible providers to reduce blocking timeout behavior.

[bjarnel]

You are right regarding where in the code it would need to be implemented. I changed that to 600 and recompiled to get longer timeouts.

That a query sent from picoclaw is slower than when you query ollama directly is context related. An agentic AI has a big system prompt (context). Granted picoclaws system prompt is a lot smaller than Openclaw (I love this as it makes it more usable with local ai). But long prompts murders performance on a CPU (assuming you are running on a CPU).

I tried running qwen3:1.7b on cpu, single picoclaw query was 6+ minutes, I put in an ancient rx 570 4gb (Vulcan) and same query is less than 30 seconds (and I get better results with lm studio than with ollama)

[Musawer1214]

I am trying to resolve the issue and will create a pull request in this repo, so that local llms will work fine in this, the problem is almost solved just little adjustmenents and documentations needed, then I will create a pull request.
and I am running on CPU, and will take a lot time for the agentic work, because small models does not give that much performance in tool using.

[nikolasdehor]

I investigated this and confirmed the root cause. The 120-second HTTP timeout is hardcoded in two places:

1. pkg/providers/openai_compat/provider.go:34 — the HTTP client for all OpenAI-compatible providers (Ollama, Groq, DeepSeek, vLLM, etc.):

   client := &http.Client{Timeout: 120 * time.Second}

2. pkg/agent/loop.go:861 — the session summarization context timeout (also 120s)

There is currently no config option to override this timeout. The ProviderConfig struct lacks a timeout field, and there is no PICOCLAW_HTTP_TIMEOUT env var support.

Existing PRs addressing this

I found two open PRs tackling this:

PR	Author	Approach
#278	@jsykes	Adds agents.defaults.timeout config field, passes it through to the HTTP provider. Clean and minimal (+17/-5 lines).
#432	@Musawer1214	Auto-detects local endpoints (isLocalAPIBase()) and sets 10-min timeout. Broader scope but bundles unrelated fixes.

Recommendation

This is also a duplicate of #312, which requests the same feature.

The ideal solution combines both approaches:

• Per-provider timeout config field (from Add configurable timeout for LLM provider and session summarization #278's approach)
• Auto-detect local endpoints with longer defaults (from providers: increase local openai-compatible timeout for ollama #432's isLocalAPIBase())
• Also fix the summarization timeout in loop.go:861

Workaround for now: Since Go's http.Client respects context deadlines, a temporary fix would be to increase the agent's max_tool_iterations and rely on the model to retry, but this is not ideal. The real fix is the configurable timeout.

[nikolasdehor]

Two competing PRs address this:

• PR Add configurable timeout for LLM provider and session summarization #278 by @jsykes — adds agents.defaults.timeout config field (minimal, 17-line diff, collaborator-endorsed). I reviewed and approved it.
• PR providers: increase local openai-compatible timeout for ollama #432 by @Musawer1214 — auto-detects local endpoints and gives 10min timeout (broader scope, bundles 4 unrelated fixes). I recommended splitting it.

I'd suggest merging #278 first (simple, focused) and then layering the auto-detection from #432 on top as a follow-up. That gives users both: explicit timeout config AND zero-config for local models.

Also: #312 is a duplicate of this issue.

[irtiq7]

I am getting the same error. I am running using phi4-mini. Is there any solution?

[nikolasdehor]

@irtiq7 The same workaround applies — the 120-second hardcoded timeout in pkg/providers/openai_compat/provider.go is the root cause. phi4-mini on CPU can easily exceed that for agentic prompts with the full system context.

Until PR #278 is merged (adds configurable timeout in config), your options are:

1. Build from source with increased timeout — change 120 * time.Second to 600 * time.Second in provider.go:34
2. Use a GPU — even a low-end one dramatically reduces inference time (as @bjarnel noted, an RX 570 brought 6+ min queries down to <30s)
3. Try a smaller model — phi4-mini is 3.8B params, but even at that size, CPU inference with PicoClaw's system prompt can be slow

The fix in PR #278 is clean and minimal (+17 lines). Hopefully it gets merged soon.

[sipeed-bot]

@Musawer1214 Hi! This issue has had no activity for over 2 weeks, so I'm closing it for now to keep things tidy. If it's still relevant, feel free to reopen it anytime and we'll pick it back up.