Summary

Follow-up to #67435 (closed by #67457) — the fix in #67457 strips the literal "ollama/" prefix from model IDs in buildOllamaChatRequest, but the same bug class survives for custom-named Ollama-compatible providers (e.g. ollama-spark, ollama-studio2, ollama-remote). The custom provider name is still being prepended to the model field on outbound /api/chat requests, producing 404 {"error":"model '<provider>/<model>' not found"} at high volume in cron-fired contexts.

Filing as a separate issue rather than re-opening #67435 because the surface is broader: the strip in #67457 is hardcoded to "ollama/" rather than generalizing to any provider key.

Reproduction

# Works (bare model name):
$ curl -s -X POST http://10.x.x.4:11434/api/chat \
    -H 'Content-Type: application/json' \
    -d '{"model":"qwen3:32b","messages":[{"role":"user","content":"ping"}],"stream":false}'
# HTTP 200, normal response

# Fails (mimics gateway sending the prefixed name):
$ curl -s -X POST http://10.x.x.4:11434/api/chat \
    -H 'Content-Type: application/json' \
    -d '{"model":"ollama-spark/qwen3:32b","messages":[{"role":"user","content":"ping"}],"stream":false}'
{"error":"model 'ollama-spark/qwen3:32b' not found"}
# HTTP 404, ~5ms latency (Ollama catalog miss fast path)

The Ollama-side error format and sub-millisecond response latency matched the gateway's failure pattern verbatim during a passive packet-flow analysis (gateway log at one end + backend journalctl at the other) — same path (/api/chat), same source IP, same 404 latency profile, same error body shape.

Environment

• OpenClaw: 2026.4.24 (cbcfdf6) — also reproduced on 2026.4.21 and 2026.4.22 prior to upgrade
• Host: macOS 15.x, Apple Silicon
• Affected providers in openclaw.json: ollama-spark, ollama-studio2 (custom-named, all "api": "ollama")
• Routing fired from agent context (cron-isolated heartbeats fanning out through fallback chain)

Volume + impact

In a 24h window before workaround was applied: 2,058 model_not_found events on /api/chat across the affected providers. Bursts of ~131 events per 30-min cron tick when ~18 cron-fired Maximus heartbeats fan out through the fallback chain.

Workaround currently in use: removed the affected models from custom-named providers' models arrays in openclaw.json so the broken routes never get tried. The fallback chain reaches anthropic/claude-haiku-4-5 instead. Volume of those specific 404s is now near-zero. Cost: cloud-cost on what should be a local route.

Suspected root cause

PR #67457 added stripOllamaPrefix(modelId) (or equivalent) that pattern-matches the literal string "ollama/". For custom-named ollama providers, the upstream-keyed string is "ollama-spark/qwen3:32b" (or similar), which doesn't match the literal pattern and passes through to the request body unchanged.

Suggested generalization: strip <provider-key>/ for any provider whose effective api resolves to "ollama", not just the literal "ollama" provider key.

Tested not the cause

• Ollama backend reachability — direct curl with bare name returns 200 from the same machine
• Model name correctness — qwen3:32b is the exact name shown by ollama list on the backend
• HTTP path — confirmed via backend journalctl that gateway hits /api/chat, same as my direct curl
• Backend capacity — backend serves bare-name requests successfully even under parallel load (5x concurrent /api/chat with bare name → all 200)

Related

• #67435 — original ollama/ prefix bug (CLOSED by #67457 on 2026-04-16)
• #57811 — separate but related: No API provider registered for api: ollama in cron context (OPEN since 2026-03-30; works around by switching to api: openai-completions)
• #52471 — Control UI sent wrong provider prefix ollama/ instead of ollama-remote/ (CLOSED 2026-04-25)

Suggested fix area

Wherever PR #67457 introduced the literal-ollama/ strip in buildOllamaChatRequest — generalize to strip any leading <provider-key>/ segment, gated on the resolved api being "ollama". The provider key is already known at request-build time (it's the routing key that delivered us into buildOllamaChatRequest). A regression test mirroring #67457's tests but with a custom-named ollama-remote (or similar) provider would lock this in.

Filed by DSS as a follow-up to a closed bug. Happy to provide additional logs, configuration, or coordinate with maintainers on testing a fix candidate.