openclaw - 💡(How to fix) Fix Ollama Cloud provider fails in agent/Gateway path with non-alternating conversation roles [1 participants]

Summary

Ollama Cloud works directly with the configured OLLAMA_API_KEY, but using the same ollama provider as an OpenClaw agent/Gateway model fails because the request sent through OpenClaw's agent path is rejected by Ollama Cloud with a non-alternating conversation roles error.

This is related to, but distinct from, #66505. The direct cloud provider path exists and can reach Ollama Cloud; the remaining problem appears to be the agent/Gateway conversation replay/adapter path.

Environment

• OpenClaw: 2026.4.23 (a979721)
• Platform: Linux arm64
• Provider config: models.providers.ollama
• Ollama mode: cloud-only
• Base URL: https://ollama.com
• API adapter: api: "ollama"
• Credential source: OLLAMA_API_KEY env var
• Test model: ollama/gemma3:4b

Configured provider shape, with secrets omitted:

{
  "models": {
    "mode": "merge",
    "providers": {
      "ollama": {
        "baseUrl": "https://ollama.com",
        "api": "ollama",
        "apiKey": "OLLAMA_API_KEY",
        "models": [
          {
            "id": "gemma3:4b",
            "name": "gemma3:4b",
            "input": ["text"],
            "contextWindow": 128000,
            "maxTokens": 32000
          }
        ]
      }
    }
  },
  "plugins": {
    "entries": {
      "ollama": { "enabled": true }
    }
  }
}

Direct Ollama Cloud API test succeeds

Using the same OLLAMA_API_KEY, this direct call succeeds:

curl -sS --max-time 90 \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer ${OLLAMA_API_KEY}" \
  https://ollama.com/api/chat \
  -d '{
    "model": "gemma3:4b",
    "messages": [
      { "role": "user", "content": "Responde exactamente: OK_CURL_OLLAMA" }
    ],
    "stream": false
  }'

Observed result:

HTTP_STATUS: 200
model: gemma3:4b
done: true
done_reason: stop
content: OK_CURL_OLLAMA

So the API key, model, endpoint, and Ollama Cloud availability are all valid.

OpenClaw agent/Gateway path fails

After selecting/using ollama/gemma3:4b through the OpenClaw agent/Gateway path, OpenClaw reaches the Ollama provider but the candidate fails and falls back to another provider.

Relevant gateway log excerpt:

model_fallback_decision
requestedProvider: ollama
requestedModel: gemma3:4b
candidateProvider: ollama
candidateModel: gemma3:4b
reason: format
status: 400
errorPreview: 400 {"error":"Conversation roles must alternate user/assistant/user/assistant/... (ref: db7e8576-df9a-4d97-9654-514c298f2a43)"}
nextCandidateProvider: xiaomi
nextCandidateModel: mimo-v2-pro

Then the fallback model succeeds, which can make the user-facing response look successful even though Ollama was not the model that answered.

Expected behavior

When ollama/gemma3:4b is selected as the model, OpenClaw should normalize or replay the Gateway/agent message history into a sequence accepted by Ollama's native /api/chat API, or otherwise strip/merge unsupported/non-alternating roles before sending the request.

Actual behavior

The request sent through OpenClaw's agent/Gateway path is rejected by Ollama Cloud with:

Conversation roles must alternate user/assistant/user/assistant/...

OpenClaw then silently falls back to another configured model.

Why this matters

#66505 was closed as implemented because cloud-only Ollama is now supported. That part works. However, in practice the provider is not usable as an OpenClaw agent model in this setup because the integrated Gateway/agent path sends a conversation format that Ollama Cloud rejects.

This makes the direct Ollama Cloud provider look configured and available, while actual agent turns may be handled by fallback models instead.