Bug Report

Summary

The model parameter on sessions_spawn() is silently ignored. The response returns modelApplied: true, but the sub-agent runtime always uses the orchestrator's default model instead of the requested model.

Environment

• OpenClaw version: 2026.4.27 (cbc2ba0)
• Platform: macOS (Apple Silicon)
• Gateway config: ~/.openclaw/openclaw.json

Steps to Reproduce

1. Spawn a sub-agent with a specific model override:

   sessions_spawn(model="venice/qwen3-coder-480b-a35b-instruct-turbo", ...)

2. Response returns modelApplied: true
3. Check the sub-agent trajectory: "model":"zai-org-glm-5-1" — always the orchestrator default

Evidence

Spawned 4 test sub-agents. All returned modelApplied: true. All trajectories show the same model:

Trajectory files confirmed via grep "model" <session>.trajectory.jsonl.

Impact

• Critical for multi-model orchestration. The entire point of model on spawn is to route coding tasks to coding models, research to research models, etc.
• Sub-agents burned through their entire output token budget on exploration/thinking (because GLM-5.1 thinks heavily before writing), hit stopReason: "length", and produced zero output files in 3 consecutive attempts to build a project.
• Related: maxTokens was also artificially capped at 8192 for GLM-5.1 in models.json (workaround: bumped to 32000 locally), but the model override bug is the primary blocker.

Expected Behavior

Sub-agent should use the model specified in the model parameter.

Workaround

None effective. Building directly in the orchestrator session instead of spawning sub-agents.

Related

• Also affects model parameter on sessions_spawn() for any model that differs from the orchestrator default.
• Token output cap issue: 20 Venice models in models.json had maxTokens: 8192 (artificially low) — local workaround applied but upstream default should be corrected.