[Bug] OpenClaw runtime treats the model field as --agent, causing valid model IDs to fail

[shenhuanjie]

Deployment environment

• Deployment type: Self-hosted
• Multica CLI / daemon: v0.4.7 (commit b1d5fa4ff)
• OpenClaw: 2026.7.1-2 (0790d9f)
• OS: fnOS (Linux x64)
• OpenClaw runtime mode: local

What happened?

After explicitly setting the following value on an OpenClaw-backed Multica agent:

model = minimax-cn/MiniMax-M3

mentioning that agent in an issue comment consistently fails. The UI only reports:

openclaw returned no parseable output

Clearing the Multica agent's model field makes OpenClaw work again.

Evidence from the daemon log

The Multica daemon actually executed:

openclaw agent --local --json \
  --session-id <redacted> \
  --agent minimax-cn/MiniMax-M3 \
  --message <redacted>

OpenClaw wrote the following error to stderr:

Error: Unknown agent id "minimax-cn/MiniMax-M3". Use "openclaw agents list" to see configured agents.

Three attempts produced the same result:

Attempt	stdout	stderr	Result
1	0 bytes	Unknown agent id "minimax-cn/MiniMax-M3"	failed after approximately 3.3s
2	0 bytes	same as above	failed after approximately 3.4s
Retry	0 bytes	same as above	failed after approximately 3.4s

A successful chat task on the same runtime did not include --agent:

openclaw agent --local --json \
  --session-id <redacted> \
  --message <redacted>

That task completed successfully and returned 614 bytes of output.

Root cause

For most providers, Multica uses the model field as an LLM model ID. The OpenClaw adapter, however, interprets the same field as an OpenClaw agent ID:

Multica model -> openclaw agent --agent <value>

minimax-cn/MiniMax-M3 is a provider/model identifier, not an agent ID registered in openclaw agents list. OpenClaw therefore exits immediately.

This exposes three separate problems:

1. Inconsistent field contract: the same model field represents an LLM model for most providers but an agent ID for OpenClaw.
2. Missing validation: the UI/API accepts arbitrary model strings without checking whether they correspond to a registered OpenClaw agent ID.
3. Hidden underlying error: OpenClaw clearly reports Unknown agent id on stderr, but Multica only surfaces openclaw returned no parseable output.

Steps to reproduce

1. Create a Multica agent backed by an OpenClaw runtime.
2. Set the agent's model field to a valid LLM model ID, for example minimax-cn/MiniMax-M3.
3. Mention the agent in any issue comment.
4. Observe that the task fails and the UI reports openclaw returned no parseable output.
5. Inspect the daemon log and observe the actual Unknown agent id stderr message.
6. Clear the model field and retry; the task succeeds.

Expected behavior

The product should establish one explicit contract for this field.

Option A: treat the field as an OpenClaw agent ID

• Rename the field to OpenClaw Agent or OpenClaw Agent ID when the selected provider is OpenClaw.
• Only allow values discovered through openclaw agents list.
• Validate the agent ID when saving through either the UI or API.
• Keep the underlying LLM model bound to the OpenClaw agent itself.

Option B: preserve consistent model semantics across providers

• Make model always represent an LLM model ID.
• Do not pass it directly to OpenClaw as --agent.
• Add a separate field for selecting an OpenClaw agent ID.

Regardless of the selected contract, Multica should surface OpenClaw's actual stderr startup error in the task failure instead of replacing it with a generic parsing error.

Related issues and pull requests

• [Feature]: gateway/WebSocket runtime mode to eliminate agent cold-start latency in chat #1549 mentions the same model -> --agent behavior in item 4, but that issue primarily concerns gateway and cold-start performance. This issue focuses specifically on field semantics, validation, and error reporting.
• OpenClaw provider forwards unsupported flags and ignores AgentInstructions #1332 fixed the previous behavior of passing --model directly to OpenClaw. Mapping Multica's model field to --agent introduced the current semantic mismatch.
• [Bug]: OpenClaw Agent - openclaw returned no parseable output #3822 and Fix OpenClaw unparseable output diagnostics (ZIC-81) #5413 address diagnostics for no parseable output. Even after stderr reporting is improved, the model field contract and validation problem will remain.

[Bohan-J]

Thanks for the detailed report — your diagnosis is correct, and I want to explain the underlying mechanism so the behavior makes sense.

Why model is passed as --agent for OpenClaw

For most runtimes, the agent's model field is an LLM model ID that Multica forwards to the CLI. OpenClaw is different because of how OpenClaw itself works:

• In OpenClaw, the LLM is not selected per-invocation. It is bound to a pre-registered agent at registration time (openclaw agents add/update --model ...).
• At run time, openclaw agent has no --model flag — you pick a registered agent by id with openclaw agent --agent <id>, and that agent already carries its own model.

So for the OpenClaw runtime, Multica reuses the same model field as an OpenClaw agent selector, and the daemon forwards its value straight through as --agent <value>. That is also why the model dropdown for an OpenClaw runtime is populated from openclaw agents list — every entry there is an agent id, not an LLM model id.

When you set model = minimax-cn/MiniMax-M3, Multica ran openclaw agent --agent minimax-cn/MiniMax-M3. Since minimax-cn/MiniMax-M3 is a provider/model LLM identifier and not a registered agent id, OpenClaw couldn't resolve it and exited immediately with Unknown agent id. Clearing the field works because Multica then omits --agent entirely, so OpenClaw falls back to its default agent.

What to do right now

1. Register (or reuse) an OpenClaw agent bound to the model you want, e.g.
   openclaw agents add my-minimax --model minimax-cn/MiniMax-M3 (or openclaw agents update ...).
2. Run openclaw agents list and copy the agent id it shows.
3. Put that agent id (not the LLM model id) into the Multica agent's model field — or leave it blank to use OpenClaw's default agent.

On the three problems you raised

All three are valid and we agree with the framing:

1. Inconsistent field contract — the same field meaning an LLM model for most providers but an agent id for OpenClaw is a genuine foot-gun. We're evaluating how to make this explicit for OpenClaw (clearer labeling / restricting the field to discovered agent ids) rather than leaving it as free text.
2. Missing validation — correct, the value is currently stored without checking it against openclaw agents list. This is tied to the contract decision above.
3. Hidden underlying error — agreed, openclaw returned no parseable output swallowed OpenClaw's real stderr. A fix is already in progress that appends the process exit status and the captured stderr tail to the failure, so you'll see the actual Unknown agent id ... message in the task result instead of the generic one.

Thanks again — this was a well-scoped report and it helps.