openclaw - ✅(Solved) Fix Provider layer sends full model path to Ollama API instead of model name, causing "model not found" errors [2 pull requests, 1 participants]

lamarbrantley · 2026-04-01T15:38:48Z

[openclaw] OpenClaw sends ollama-beelink2/qwen2.5-coder:7b to Ollama instead of just qwen2.5-coder:7b, causing 0-token responses. OpenClaw sends ollama-beelink2/qwen2.5-coder:7b to Ollama instead of just qwen2.5-coder:7b, causing 0-token responses. # PR #59188: fix(provider): strip provider prefix from model ID before API call - Repository: openclaw/openclaw - Author: areporeporepo - State: open | merged: False - Link: https://github.com/openclaw/openclaw/pull/59188 ## Description (problem / solution / changelog) ## Summary - Problem: `runEmbeddedPiAgent` passes the full model path (e.g. `ollama-beelink2/qwen2.5-coder:7b`) to downstream APIs instead of just the model name (`qwen2.5-coder:7b`), causing "model not found" errors from Ollama and other OpenAI-compatible providers. - Why it matters: Multi-provider setups (local Ollama for background agents, Claude for main) are completely broken — all Ollama-routed requests fail silently with 0-token responses. - What changed: After `modelId` is initialized in `run.ts`, call the existing `parseModelRef()` to split `"provider/model"` into separate provider and model values. Same pattern already used in `agent-command.ts:636`. - What did NOT change (scope boundary): No changes to `parseModelRef()` itself, model resolution, or any other provider logic. Only the entry point in `runEmbeddedPiAgent` is touched. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor required for the fix - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #59122 - Related # - [x] This PR fixes a bug or regression ## Root Cause / Regression History (if applicable) - Root cause: `run.ts:142` accepts `params.model` as-is without parsing the `"provider/model"` format. The existing `parseModelRef()` function handles this correctly but was never called in the `runEmbeddedPiAgent` flow. - Missing detection / guardrail: No test covering the case where `params.model` contains an embedded provider prefix. - Prior context: `agent-command.ts` already uses `parseModelRef()` at line 636 for the same purpose — the embedded runner path was simply missed. - Why this regressed now: This appears to be an original omission rather than a regression. - If unknown, what was ruled out: N/A. ## Regression Test Plan (if applicable) - Coverage level that should have caught this: - [x] Unit test - [ ] Seam / integration test - [ ] End-to-end test - [ ] Existing coverage already sufficient - Target test or file: `src/agents/pi-embedded-runner/runs.test.ts` or a new focused test - Scenario the test should lock in: When `params.model` is `"ollama-beelink2/qwen2.5-coder:7b"`, the model ID sent to the API should be `"qwen2.5-coder:7b"` and the provider should be `"ollama-beelink2"`. - Why this is the smallest reliable guardrail: The split logic is a single conditional at the entry point — a unit test on the resolved model/provider values covers it directly. - If no new test is added, why not: The fix reuses `parseModelRef()` which has 66 passing tests in `model-selection.test.ts`. A dedicated integration test for the `runEmbeddedPiAgent` path would require significant test infrastructure setup. ## AI - AI-assisted - targeted local verification: `npx tsc --noEmit` (no errors in `run.ts`), `pnpm test -- src/agents/model-selection.test.ts` (66/67 pass, 1 pre-existing failure unrelated to this change) ## Changed files - `src/agents/model-selection.test.ts` (modified, +6/-0) - `src/agents/pi-embedded-runner/run.ts` (modified, +9/-1) --- # PR #59203: fix: strip redundant provider prefix from session-stored model names - Repository: openclaw/openclaw - Author: joelnishanth - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/59203 ## Description (problem / solution / changelog) ## Summary - When a session records a model with its provider as a prefix (e.g. `ollama-beelink2/qwen2.5-coder:7b` with `provider=ollama-beelink2`), the downstream API call sends the prefixed string as the model name, causing a 404 from the provider. - Adds a shared `stripRedundantProviderPrefix` helper in `model-selection.ts` and applies it in `resolveSessionModelRef` and `resolveLiveSessionModelSelection` where session-stored model names are read back. - OpenRouter vendor-prefixed names (e.g. `anthropic/claude-haiku-4.5` with `provider=openrouter`) are preserved because the vendor prefix differs from the provider key. ## Test plan - [ ] Configure an Ollama remote with a hyphenated instance name (e.g. `ollama-beelink2`) - [ ] Start a session using a model from that instance - [ ] Verify subsequent turns resolve the model without the provider prefix (no 404) - [ ] Verify OpenRouter models with vendor prefixes still work correctly - [ ] Run `npx vitest run src/agents/mod

openclaw2026-04-01 15:38:48

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#59122•Fetched 2026-04-08 02:28:25

View on GitHub

Comments

Participants

Timeline

Reactions

Author

lamarbrantley

Participants

lamarbrantley

Timeline (top)

cross-referenced ×2referenced ×2labeled ×1

OpenClaw sends ollama-beelink2/qwen2.5-coder:7b to Ollama instead of just qwen2.5-coder:7b, causing 0-token responses.

Error Message

Observe the response is empty/0-tokens with "model not found" error in logs
Ollama responds with error: {"error": {"message": "model 'ollama-beelink2/qwen2.5-coder:7b' not found"}}

Root Cause

OpenClaw sends ollama-beelink2/qwen2.5-coder:7b to Ollama instead of just qwen2.5-coder:7b, causing 0-token responses.

Code Example

{
     "providers": {
       "ollama-beelink2": {
         "kind": "openai-completions", 
         "models": {
           "qwen2.5-coder:7b": {"id": "qwen2.5-coder:7b"}
         }
       }
     }
   }

---

{
     "agent": {
       "model": "ollama-beelink2/qwen2.5-coder:7b"
     }
   }

---

curl -d '{"model":"qwen2.5-coder:7b","messages":[{"role":"user","content":"test"}]}' \
        http://localhost:11434/v1/chat/completions

---

{"model": "qwen2.5-coder:7b", "messages": [...]}

---

{"model": "ollama-beelink2/qwen2.5-coder:7b", "messages": [...]}

---

{"error": {"message": "model 'ollama-beelink2/qwen2.5-coder:7b' not found"}}

---

SSH tunnels:
localhost:11434 → beelink2:11434 (ollama-beelink2 provider)
localhost:11435 → beelink3:11434 (ollama-beelink3 provider)

---

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Summary

OpenClaw sends ollama-beelink2/qwen2.5-coder:7b to Ollama instead of just qwen2.5-coder:7b, causing 0-token responses.

Steps to reproduce

Steps to reproduce:

Configure an Ollama provider in OpenClaw config:

{
  "providers": {
    "ollama-beelink2": {
      "kind": "openai-completions", 
      "models": {
        "qwen2.5-coder:7b": {"id": "qwen2.5-coder:7b"}
      }
    }
  }
}

Set an agent to use the Ollama model:

{
  "agent": {
    "model": "ollama-beelink2/qwen2.5-coder:7b"
  }
}

Send a message to the agent (any message)
Observe the response is empty/0-tokens with "model not found" error in logs

Verify the model exists by calling Ollama directly:

curl -d '{"model":"qwen2.5-coder:7b","messages":[{"role":"user","content":"test"}]}' \
     http://localhost:11434/v1/chat/completions

(This works and returns tokens)

Expected behavior

Expected behavior:

OpenClaw should extract just the model name (qwen2.5-coder:7b) from the full model path (ollama-beelink2/qwen2.5-coder:7b)
The provider should send API requests to Ollama with only the model name:
```
{"model": "qwen2.5-coder:7b", "messages": [...]}
```
Ollama should respond successfully with tokens
The agent should provide normal responses instead of empty/0-token outputs
Multi-provider setups should work seamlessly, allowing cost optimization by routing different agents to different model providers (Claude for main, Ollama for background tasks)

Actual behavior

Actual behavior:

OpenClaw sends the full model path including provider prefix to Ollama API:
```
{"model": "ollama-beelink2/qwen2.5-coder:7b", "messages": [...]}
```

Ollama responds with error:

{"error": {"message": "model 'ollama-beelink2/qwen2.5-coder:7b' not found"}}

Agents using Ollama models return completely empty responses (0 tokens)
No visible output from affected agents (Ian, Scott, Maciej) despite them actually attempting to work
Forces fallback to more expensive Claude API for all agent operations
Multi-provider cost optimization is broken - all agents must use the same expensive provider instead of routing background tasks to local Ollama models

OpenClaw version

2026.3.28 (f9b1079)

Operating system

Ubuntu 24.04.4 LTS (kernel: 6.17.0-19-generic x64)

Install method

NPM global

Model

ollama-beelink2/qwen2.5-coder:7b

Provider / routing chain

OpenClaw → openai-completions provider → SSH tunnel → Ollama

Additional provider/model setup details

Additional provider/model setup details:

Multi-Provider Configuration:

3 Ollama providers: ollama-beelink2 (port 11434), ollama-beelink3 (port 11435), ollama (localhost)
SSH port forwarding: Local ports tunnel to remote Beelink machines
Model aliases: scott-fast → ollama/qwen2.5-coder:7b, scott-qwen → anthropic/qwen2.5-coder:7b

Affected Agents:

Ian: Configured with anthropic/claude-sonnet-4-20250514 (working)
Scott: Configured with anthropic/claude-sonnet-4-20250514 (working)
Maciej: Configured with anthropic/claude-sonnet-4-20250514 (working)

Bug Context:

Originally Ian/Scott/Maciej were using ollama-beelink2/qwen2.5-coder:7b
Switched back to Claude due to this provider bug
Cost optimization strategy: Use free/local Ollama for background agents, expensive Claude for main session
Expected workflow: openai-completions provider should strip "ollama-beelink2/" prefix before API calls

Network Setup:

SSH tunnels:
localhost:11434 → beelink2:11434 (ollama-beelink2 provider)
localhost:11435 → beelink3:11434 (ollama-beelink3 provider)

The bug prevents multi-provider cost optimization by breaking all Ollama-routed requests.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The most likely fix is to modify OpenClaw's configuration or code to extract and send only the model name to the Ollama API, without the provider prefix.

Guidance

Verify that the openai-completions provider in OpenClaw is correctly configured to strip the provider prefix from the model path before sending API requests to Ollama.
Check the OpenClaw code for any hardcoded or default behavior that might be causing it to include the provider prefix in the model path sent to Ollama.
Consider adding a configuration option or environment variable to allow specifying whether the provider prefix should be included or excluded from the model path.
Test the fix by sending a message to an agent configured to use the Ollama model and verify that the response is no longer empty and the Ollama API logs do not contain "model not found" errors.

Example

// Example of corrected API request to Ollama
{
  "model": "qwen2.5-coder:7b",
  "messages": [{"role": "user", "content": "test"}]
}

Notes

The exact fix may depend on the internal implementation of OpenClaw and its openai-completions provider, which is not fully specified in the issue. Additionally, the fix may need to account for cases where the provider prefix is required or desired.

Recommendation

Apply a workaround to modify the OpenClaw configuration or code to extract and send only the model name to the Ollama API, without the provider prefix, as this is the most direct way to address the issue and restore multi-provider cost optimization.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#api #optimization #orchestration issue #cache issue #memory leak

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix Provider layer sends full model path to Ollama API instead of model name, causing "model not found" errors [2 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fixed

PR fix notes

PR #59188: fix(provider): strip provider prefix from model ID before API call

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause / Regression History (if applicable)

Regression Test Plan (if applicable)

AI

Changed files

PR #59203: fix: strip redundant provider prefix from session-stored model names

Description (problem / solution / changelog)

Summary

Test plan

Changed files

Code Example

Bug type

Beta release blocker

Summary

Steps to reproduce

Steps to reproduce:

Expected behavior

Expected behavior:

Actual behavior

Actual behavior:

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Additional provider/model setup details:

Multi-Provider Configuration:

Affected Agents:

Bug Context:

Network Setup:

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

RELATED_DISCOVERY

TRENDING