Summary

/status appears to report the session-selected/default model instead of the effective model used for a reply when a channel-level channels.modelByChannel override is active.

This makes channel model routing look broken even though the actual reply execution uses the channel override.

Environment

• OpenClaw: 2026.5.28 (e932160)
• OS: macOS 15.7.3, Darwin 24.6.0, x64
• Node.js: v25.5.0
• Package manager/runtime install: package install, pnpm
• Gateway mode: local gateway over loopback websocket
• Gateway service: managed LaunchAgent, running
• Channel: Telegram group/topic session
• Default agent model: openai/gpt-5.5
• Affected route type: channels.modelByChannel.telegram["<telegram-group-id>"]

All local paths, hostnames, IPs, group IDs, user IDs, account names, and session IDs are intentionally omitted or replaced with placeholders.

Relevant Configuration Shape

A Telegram group is configured with the default agent model set to openai/gpt-5.5, plus a channel-level model override similar to:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai/gpt-5.5"
      },
      "models": {
        "openai/gpt-5.5": {
          "agentRuntime": { "id": "codex" }
        },
        "xai/grok-4.3": {
          "alias": "Grok"
        }
      }
    }
  },
  "channels": {
    "modelByChannel": {
      "telegram": {
        "<telegram-group-id>": "xai/grok-4.3"
      }
    }
  }
}

No session-level /model override is active. The session-selected model has been reset to the agent default, openai/gpt-5.5.

Reproduction Steps

1. Configure an agent default model, for example openai/gpt-5.5.
2. Configure a Telegram group/channel override through channels.modelByChannel.telegram, for example xai/grok-4.3.
3. In that Telegram group, use /models or equivalent session controls to remove any session-specific model override and return the session-selected model to the default.
4. Run /status in the same group.
5. Send a normal message that triggers a model response.
6. Compare /status with runtime session/trajectory metadata for the normal response.

Expected Behavior

/status should make the effective model clear for the current channel/session.

Acceptable outputs would include either:

• reporting xai/grok-4.3 as the current effective model when the channel override is active, or
• reporting both values, for example:
  • selected/default model: openai/gpt-5.5
  • effective channel override: xai/grok-4.3

The important point is that an operator should be able to tell which model will actually be used for normal replies in that channel.

Actual Behavior

/status reports the session-selected/default model:

openai/gpt-5.5

However, normal reply execution in the same Telegram group uses the channel override. Runtime/session/trajectory metadata for the same conversation shows an effective model equivalent to:

{
  "configuredModel": "openai/gpt-5.5",
  "selectedModel": "xai/grok-4.3",
  "model": "grok-4.3",
  "provider": "xai",
  "modelId": "grok-4.3",
  "modelApi": "openai-responses",
  "runtime": "OpenClaw Default"
}

So /status and actual execution disagree from the operator's point of view.

Additional Observations

• channels.modelByChannel is accepted by config validation and is applied by normal reply execution.
• The behavior reproduces after clearing a session-level model override, which makes /status show the agent default while the channel override remains effective for normal turns.
• This is separate from agent routing through bindings or Telegram topic agentId; the issue is specifically about the status/reporting path for channels.modelByChannel.
• The normal reply path appears to resolve channels.modelByChannel before selecting the provider/model.
• The /status path appears to render the selected/default session model and does not consistently display the effective channel override.

Suspected Cause

The /status renderer or command path likely receives the session/default model before channel-level model resolution has been applied.

There appears to be some support for showing a channel override note, but it only seems to appear when the model already passed into status matches the channel override. If the status command starts from the default/session-selected model, the channel override is not surfaced even though normal execution will use it.

Impact

This makes /status unreliable for confirming model routing in Telegram groups/channels that use channels.modelByChannel.

Operationally, this can lead users to believe:

• channels.modelByChannel is not working,
• the gateway did not reload config,
• a /models session override is still active or inactive incorrectly, or
• the wrong model is being billed/used,

when the actual normal response path is using the intended channel override.

Suggested Fix

Have /status resolve and display the same effective model that the normal reply path would use for the current channel/session.

If both a session-selected model and a channel-level override are relevant, show both with clear labels, for example:

Model: xai/grok-4.3
Source: channels.modelByChannel.telegram[<current-channel>]
Session/default model: openai/gpt-5.5

or:

Selected: openai/gpt-5.5
Effective: xai/grok-4.3 (channel override)

Privacy Note

This report intentionally omits or generalizes:

• real Telegram group IDs,
• user IDs,
• account names,
• local filesystem paths,
• hostnames/IP addresses,
• session IDs,
• message contents not needed for reproduction.