openclaw - 💡(How to fix) Fix Agent-level model field ignored during session creation — falls back to global default [4 comments, 2 participants]

Summary

The model field on agent definitions in agents.list[] is being ignored during session creation. Sessions always resolve to agents.defaults.model.primary (the global default) instead of the agent-specific model.

Environment

• OpenClaw version: 2026.4.20
• OS: macOS (Apple Silicon)
• Channel: Discord

Config (relevant parts)

Agent definition

{
  "id": "tars-v4flash",
  "name": "Tars",
  "workspace": "/Users/example/v4flash-agent",
  "model": "deepseek-v4-openrouter/deepseek/deepseek-v4-flash",
  "thinkingDefault": "off"
}

Channel binding

{
  "agentId": "tars-v4flash",
  "match": {
    "channel": "discord",
    "peer": { "kind": "channel", "id": "CHANNEL_ID" }
  }
}

Global default

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "anthropic/claude-opus-4-6"
      }
    }
  }
}

Custom model provider

{
  "models": {
    "providers": {
      "deepseek-v4-openrouter": {
        "baseUrl": "https://openrouter.ai/api/v1",
        "api": "openai-completions",
        "models": [{
          "id": "deepseek/deepseek-v4-flash",
          "name": "DeepSeek V4-Flash (OpenRouter)"
        }]
      }
    }
  }
}

Expected behavior

When a message arrives in the bound Discord channel, the gateway should:

1. Route to agent tars-v4flash via the binding ✅ (this works)
2. Create a session using the agent's model field (deepseek-v4-openrouter/deepseek/deepseek-v4-flash) ❌ (this fails)

Actual behavior

• The binding correctly routes to tars-v4flash
• The session name correctly shows agent:tars-v4flash:discord:channel:CHANNEL_ID
• The workspace is correctly set to the agent's workspace
• BUT the model resolves to anthropic/claude-opus-4-6 (global default)

Workarounds attempted (none permanent)

1. Per-session model override via /model — works temporarily but reverts on session refresh/restart
2. Adding the custom model to agents.defaults.models — required for override to work, but doesn't fix root issue
3. Gateway restarts — no effect, fresh sessions still resolve to global default
4. /new to force fresh session — no effect, new session still uses global default
5. Multiple config reloads — no effect

Code analysis

The model resolution functions in the gateway code appear correct:

resolveAgentEffectiveModelPrimary(cfg, agentId) {
  return resolveAgentExplicitModelPrimary(cfg, agentId) 
    ?? resolvePrimaryStringValue(cfg.agents?.defaults?.model);
}

The agent-level model IS checked first in resolveAgentEffectiveModelPrimary(). The bug appears to be that session creation calls a different code path that doesn't consult this function, or the result is being overwritten.

Impact

This caused significant unintended API spend — sessions that should have been running on a cheap model ($0.14/$0.28 per 1M tokens) were silently running on Opus ($5/$25 per 1M tokens). The user had no indication the model was wrong until they checked API billing.

Notes

• A second gateway on a different machine with a similar setup does NOT have this bug (agent-level model works correctly there). This may be version-dependent or related to config ordering.
• The model field is correctly parsed from config (confirmed via config.get).
• This is NOT a stale session issue — completely fresh sessions exhibit the same behavior.