Every Ollama-backed NemoClaw deployment using compatible-endpoint is broken by default. The onboard wizard auto-selects openai-responses API mode, which causes OpenClaw to send the system prompt using the developer role. Ollama silently discards this role, so the model receives zero tool definitions, zero personality, and zero context. The agent appears functional (text responses work) but cannot use any tools.

Environment

• NemoClaw v0.0.16, OpenShell v0.0.26, OpenClaw v2026.4.2
• Sandbox host: DietPi2 (Intel Core i7-10710U, 64GB RAM, no discrete GPU, DietPi/Debian)
• Inference: Ollama 0.20.7-rocm on AMD Ryzen AI 9 HX 370 (Radeon 890M iGPU, 32GB shared VRAM), MicroK8s
• Model: gemma4:26b (also reproduced with qwen3-coder, nemotron-nano)
• Provider: compatible-endpoint
• First observed on v0.0.13, confirmed still present on v0.0.16

Steps to reproduce

1. nemoclaw onboard with Ollama as compatible-endpoint (any Ollama v0.20.0+ instance)
2. Wizard probes /v1/responses endpoint -- Ollama returns a valid response (the endpoint exists)
3. Wizard sets api: "openai-responses" in sandbox config
4. OpenClaw sends the 24K-character system prompt (23 tool definitions, workspace files, personality) using the "developer" role
5. Ollama silently discards the "developer" role message (it only recognizes system, user, assistant)
6. Model receives user messages with zero tool definitions

Expected behavior

System prompt delivered to model. Agent can use all 23 tools.

Actual behavior

System prompt silently dropped. Model has no tools, no personality, no context. The model generates text responses that reference tools ("I'll create that file now") but never executes them. No error is logged; no diagnostic output explains why tool calls fail.

Over 9+ hours of testing across multiple models, every agent interaction ended in embedded_run_failover_decision: timeout. The only clue in logs was read tool called without path (WARN level) -- the model was guessing at tool schemas it never received.

Root cause

The Responses API uses "developer" as the role for system-level instructions. Ollama's /v1/responses endpoint exists (so the wizard's probe passes), but Ollama does not implement the developer role. Messages with unrecognized roles are silently dropped.

The wizard's validation is too shallow: it checks whether the /v1/responses endpoint returns a valid HTTP response, but does not verify that the backend actually processes the developer role correctly.

This also affects LiteLLM as a proxy -- LiteLLM's /v1/responses endpoint exists but returns empty/error responses for some backends, causing the same false positive during onboard validation (see also #1134 for related provider validation issues).

Workaround

After onboard, patch the sandbox config:

{
  "api": "openai-completions",
  "models": [{
    "compat": {
      "supportsDeveloperRole": false,
      "supportsReasoningEffort": false
    },
    "reasoning": false
  }]
}

Or prevent during onboard:

NEMOCLAW_PREFERRED_API=openai-completions nemoclaw onboard ...

After applying either workaround, the first tool call succeeded immediately -- confirming that the system prompt delivery was the only issue.

Suggested fixes

1. Default to openai-completions for Ollama providers. The Responses API + developer role combination is incompatible with Ollama's current implementation. Since Ollama is a primary compatible-endpoint target, this should be the safe default.
2. Test tool-calling end-to-end during wizard validation. Instead of only probing whether /v1/responses returns HTTP 200, send a minimal tool-call test (e.g., a read tool with a known path) and verify the model executes it. This would catch the developer role drop immediately.
3. Log a warning when the system prompt is sent via developer role. If the model's first response contains no tool references despite a 23-tool system prompt, flag it: "Model may not have received tool definitions -- check API mode."

Impact

This affects every NemoClaw deployment using Ollama (any version with /v1/responses) as a compatible-endpoint backend. The agent is non-functional for tool use but appears to work for text, making the failure extremely difficult to diagnose without deep log analysis.