Bug Report: Gateway Ignores ollama2 baseUrl, Routes All Requests to ollama (11434)

Status: Not submitted yet
Date: 2026-04-06
OpenClaw Version: 2026.4.2 (d74a122)
Severity: High - Multi-provider configuration broken

Summary

When configuring multiple Ollama providers (ollama on port 11434 and ollama2 on port 11435), the Gateway routes ALL requests to the first provider (ollama on port 11434), completely ignoring the baseUrl configured for ollama2.

Environment

• OpenClaw Version: 2026.4.2 (d74a122)
• OS: macOS 26.3.1 (arm64), Apple M4
• Node: v25.8.1
• Ollama: v0.20.0 (two instances running on ports 11434 and 11435)

Configuration

{
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434",
        "apiKey": "ollama-local",
        "api": "ollama",
        "models": [
          { "id": "gemma4:e2b", "name": "gemma4:e2b", "contextWindow": 32000 }
        ]
      },
      "ollama2": {
        "baseUrl": "http://127.0.0.1:11435",
        "apiKey": "ollama-local",
        "api": "ollama",
        "models": [
          { "id": "gemma4:e2b", "name": "gemma4:e2b", "contextWindow": 16384 }
        ]
      }
    }
  },
  "agents": {
    "list": [
      {
        "id": "coco",
        "model": "ollama2/gemma4:e2b"
      }
    ]
  }
}

Expected Behavior

When coco agent makes LLM requests, they should be routed to ollama2 at http://127.0.0.1:11435.

Actual Behavior

All requests are routed to ollama at http://127.0.0.1:11434, regardless of provider configuration.

Evidence

1. Configuration Files Show Correct baseUrl

$ cat ~/.openclaw/agents/coco/agent/models.json | jq '.providers.ollama2.baseUrl'
"http://127.0.0.1:11435"

$ cat ~/.openclaw/openclaw.json | jq '.models.providers.ollama2.baseUrl'
"http://127.0.0.1:11435"

2. Network Connections Prove Bug

After Gateway restart and test message:

$ lsof -i :11434 -i :11435
COMMAND   PID  USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
ollama   6692 robin    4u  IPv4 0xb32a81fdbf6e8b21      0t0  TCP localhost:11434 (LISTEN)
ollama   6692 robin   11u  IPv4 0x...                    0t0  TCP localhost:11434->localhost:58024 (ESTABLISHED)
ollama   6692 robin   16u  IPv4 0x...                    0t0  TCP localhost:11434->localhost:58026 (ESTABLISHED)
ollama   6697 robin    4u  IPv4 0x1ffc39c301d9c01a      0t0  TCP localhost:11435 (LISTEN)  # <-- NO CONNECTIONS!
node    12325 robin   28u  IPv4 0x...                    0t0  TCP localhost:58024->localhost:11434 (ESTABLISHED)
node    12325 robin   36u  IPv4 0x...                    0t0  TCP localhost:58026->localhost:11434 (ESTABLISHED)

Key observation: Port 11435 has zero ESTABLISHED connections from the Gateway (node process), despite coco agent being configured to use ollama2.

3. Gateway Logs Show ollama2 Provider Usage

2026-04-05T18:00:15.774Z warn agent/embedded {"subsystem":"agent/embedded"} low context window: ollama2/gemma4:e2b ctx=16384 (warn<32000) source=modelsConfig
2026-04-05T18:03:49.786Z warn agent/embedded {"subsystem":"agent/embedded"} [compaction-diag] end ... provider=ollama2/gemma4:e2b ...

Gateway correctly identifies ollama2/gemma4:e2b as the provider, but still routes to wrong port.

4. Direct API Tests Succeed on Both Ports

$ curl -s -X POST "http://127.0.0.1:11435/api/generate" -d '{"model":"gemma4:e2b","prompt":"hi","stream":false}'
{"model":"gemma4:e2b","created_at":"2026-04-05T...","response":"Hi! How can I help..."}  # SUCCESS

$ curl -s -X POST "http://127.0.0.1:11434/api/generate" -d '{"model":"gemma4:e2b","prompt":"hi","stream":false}'
{"model":"gemma4:e2b","created_at":"2026-04-05T...","response":"Hello..."}  # SUCCESS

Both ports respond correctly when called directly.

Root Cause Hypothesis

The Gateway's HTTP client likely has a connection pool cache bug:

1. When ollama provider is initialized first (port 11434), it creates an HTTP connection pool
2. When ollama2 provider is initialized, it incorrectly reuses the same connection pool instead of creating a new one for port 11435
3. All subsequent requests go through the cached connection to 11434

This explains why:

• The configuration shows correct baseUrl: "http://127.0.0.1:11435"
• Gateway logs show provider=ollama2/gemma4:e2b
• But network connections only go to 11434

Workaround

Currently, the only workaround is to use the default ollama provider (port 11434) for all agents, as ollama2 configuration is effectively ignored.

Steps to Reproduce

1. Configure two Ollama instances on different ports (e.g., 11434 and 11435)
2. Add both as separate providers in openclaw.json
3. Assign an agent to use ollama2/... model
4. Send a message to that agent
5. Observe network connections - all go to port 11434

Impact

• Users cannot use multiple Ollama instances simultaneously
• Workload isolation is impossible
• Different model configurations per provider are ignored
• Resource management (GPU allocation, rate limiting) across instances is broken

Submission Links

• GitHub Issue: https://github.com/openclaw/openclaw/issues/new?title=Bug%3A+Gateway+ignores+baseUrl+for+ollama2%2C+routes+all+requests+to+ollama+port&labels=bug

Related Files

• /Users/robin/.openclaw/openclaw.json - Main configuration
• /Users/robin/.openclaw/agents/coco/agent/models.json - Agent model config
• /Users/robin/.openclaw/agents/coco/agent/auth-profiles.json - Auth profiles

Diagnosis Session

• Date: 2026-04-05 to 2026-04-06
• Channel: Telegram (@cloudai26)
• Agents involved: cloud (diagnosis), coco (test agent)