Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Ollama provider routing bug: model selection shows ollama7/ollama8 but requests sent to ollama:default (localhost) [1 comments, 1 participants]

Official PRs (…)
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.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60089•Fetched 2026-04-08 02:36:30
View on GitHub
Comments
1
Participants
1
Timeline
3
Reactions
0
Author
rodolphebertrandrodolphebertrand
Participants
rodolphebertrandrodolphebertrand
Timeline (top)
labeled ×2commented ×1

Root Cause

  • Provider fallback cannot work because requests never reach the configured providers
  • All 7 Ollama instances are configured but only localhost is used
  • Model failover mechanism cannot trigger because wrong provider is called

Fix Action

Workaround

Currently using ollama/... (localhost) as it has cloud models authenticated via ollama signin, but this defeats the purpose of having multiple instances for redundancy.

Code Example

"providers": {
  "ollama8": {
    "baseUrl": "http://192.168.2.105:11438",
    "api": "ollama"
  },
  "ollama7": {
    "baseUrl": "http://192.168.2.105:11437",
    "api": "ollama"
  },
  "ollama": {
    "baseUrl": "http://127.0.0.1:11434",
    "api": "ollama"
  }
}

### Steps to reproduce

## Steps to Reproduce

1. **Configure multiple Ollama providers** in `~/.openclaw/openclaw.json`:

---
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Bug Description

When selecting a specific Ollama provider (e.g., ollama7/qwen3.5:397b-cloud or ollama8/qwen3.5:397b-cloud), OpenClaw displays the correct provider in the status card, but all API requests are sent to ollama:default (127.0.0.1:11434) instead of the selected provider's configured baseUrl.

Environment

  • OpenClaw version: v2026.4.2 (d74a122)
  • Previous version: v2026.4.1 (same bug present)
  • Config: Multiple Ollama providers configured (ollama6, ollama7, ollama8, ollama105, ollama100, ollama129, ollama1055) with different ports on 192.168.2.105

Expected Behavior

When user selects ollama7/qwen3.5:397b-cloud, requests should be sent to http://192.168.2.105:11437 (ollama7 baseUrl).

Actual Behavior

  • Status card shows: Model: ollama7/qwen3.5:397b-cloud · 🔑 api-key (ollama7:default)
  • Ollama logs show: POST "/api/chat" | 127.0.0.1 (localhost, not 192.168.2.105:11437)
  • auth-profiles.json remains empty {} even after model selection

Impact

  • Provider fallback cannot work because requests never reach the configured providers
  • All 7 Ollama instances are configured but only localhost is used
  • Model failover mechanism cannot trigger because wrong provider is called

Workaround

Currently using ollama/... (localhost) as it has cloud models authenticated via ollama signin, but this defeats the purpose of having multiple instances for redundancy.

Config Snippet

"providers": {
  "ollama8": {
    "baseUrl": "http://192.168.2.105:11438",
    "api": "ollama"
  },
  "ollama7": {
    "baseUrl": "http://192.168.2.105:11437",
    "api": "ollama"
  },
  "ollama": {
    "baseUrl": "http://127.0.0.1:11434",
    "api": "ollama"
  }
}

### Steps to reproduce

## Steps to Reproduce

1. **Configure multiple Ollama providers** in `~/.openclaw/openclaw.json`:
   ```json
   "providers": {
     "ollama8": {
       "baseUrl": "http://192.168.2.105:11438",
       "api": "ollama"
     },
     "ollama7": {
       "baseUrl": "http://192.168.2.105:11437",
       "api": "ollama"
     },
     "ollama": {
       "baseUrl": "http://127.0.0.1:11434",
       "api": "ollama"
     }
   }
Restart the gateway:


openclaw gateway restart
Start a new session and select a specific Ollama provider:


/model ollama7/qwen3.5:397b-cloud
Verify status card shows the correct provider:


🧠 Model: ollama7/qwen3.5:397b-cloud · 🔑 api-key (ollama7:default)
Send a message in the session

Check Ollama logs:

Copy
journalctl -u ollama -f

Observe the bug: Request shows 127.0.0.1 instead of 192.168.2.105:11437:


[GIN] 2026/04/03 - 01:18:02 | 200 | 4.469727163s | 127.0.0.1 | POST "/api/chat"
Check auth-profiles.json (optional - shows profiles are not being created):


cat ~/.openclaw/agents/openclaw-config/agent/auth-profiles.json
# Returns: {}

### Expected behavior

When user selects ollama7/qwen3.5:397b-cloud, requests should be sent to http://192.168.2.105:11437 (ollama7 baseUrl).

### Actual behavior

Status card shows: Model: ollama7/qwen3.5:397b-cloud · 🔑 api-key (ollama7:default)
Ollama logs show: POST "/api/chat" | 127.0.0.1 (localhost, not 192.168.2.105:11437)
auth-profiles.json remains empty {} even after model selection

### OpenClaw version

 v2026.4.2 (d74a122)

### Operating system

ubuntu

### Install method

_No response_

### Model

ollama

### Provider / routing chain

openclaw

### Additional provider/model setup details

_No response_

### Logs, screenshots, and evidence

```shell

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The most likely fix involves updating the OpenClaw configuration to correctly map the selected Ollama provider to its corresponding baseUrl.

Guidance

  1. Verify provider configuration: Ensure that the providers section in the OpenClaw configuration file (~/.openclaw/openclaw.json) correctly lists all Ollama providers with their respective baseUrls.
  2. Check for default provider override: Investigate if there is a default provider setting that might be overriding the selected provider's baseUrl, causing requests to be sent to 127.0.0.1:11434 instead.
  3. Review auth-profiles.json handling: Examine why auth-profiles.json remains empty even after model selection, as this might be related to the issue of requests not being routed to the correct provider.
  4. Test with a single provider: Temporarily configure OpenClaw with only one Ollama provider to see if the issue persists, which can help determine if the problem is related to provider selection or a more fundamental configuration issue.

Example

No specific code example is provided due to the lack of direct code references in the issue. However, ensuring the providers section in ~/.openclaw/openclaw.json is correctly formatted, such as:

"providers": {
  "ollama7": {
    "baseUrl": "http://192.168.2.105:11437",
    "api": "ollama"
  }
}

is crucial for proper provider configuration.

Notes

The issue seems to stem from a configuration or routing problem within OpenClaw, rather than an issue with the Ollama providers themselves. The fact that the status card shows the correct provider but requests are sent to the default provider suggests a mismatch between the displayed provider and the actual provider used for requests.

Recommendation

Apply a workaround by manually specifying the baseUrl for each provider in the OpenClaw configuration and ensuring that the default provider does not override the selected provider's settings. This approach can help mitigate the issue until a more permanent fix is found.

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?
Loading…

FAQ

Expected behavior

When user selects ollama7/qwen3.5:397b-cloud, requests should be sent to http://192.168.2.105:11437 (ollama7 baseUrl).

#api#chain error#conversation history#tool integration#LLM response

Still need to ship something?

×6

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

Back to top recommendations

TRENDING