Bug type

Behavior bug (incorrect output/state without crash)

Summary

In Discord, the native /think choice list does not show xhigh for a session using openai-codex/gpt-5.4, even though the backend supports xhigh for that model.

Steps to reproduce

1. Use OpenClaw on Discord.
2. Switch the session model to openai-codex/gpt-5.4.
3. Open the Discord native /think command and inspect the available thinking choices.
4. Observe that xhigh is not offered in the choice list.

Expected behavior

When the current session model is openai-codex/gpt-5.4, the Discord /think choice list should include xhigh.

Actual behavior

xhigh is missing from the Discord /think choices even though the model supports it.

In local verification, the backend/model-selection logic includes openai-codex/gpt-5.4 in XHIGH_MODEL_REFS, and listThinkingLevels(provider, model) should append xhigh for supported models.

This makes the issue look like a Discord native command / dynamic choices mismatch rather than a model capability problem.

OpenClaw version

2026.3.13 (61d171a)

Operating system

Debian GNU/Linux 12 (bookworm)

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

discord -> openclaw -> openai-codex

Config file / key location

Standard gateway/session setup; reproduced in a normal Discord-connected session. No secret values included.

Additional provider/model setup details

This was reproduced with an OpenAI Codex-capable session. The issue appears to be channel/UI-specific rather than a provider rejection from the model layer.

Logs, screenshots, and evidence

Local source evidence from the installed build:

const XHIGH_MODEL_REFS = [
  "openai/gpt-5.4",
  "openai/gpt-5.4-pro",
  "openai/gpt-5.2",
  "openai-codex/gpt-5.4",
  ...
];

function listThinkingLevels(provider, model) {
  const levels = ["off", "minimal", "low", "medium", "high"];
  if (supportsXHighThinking(provider, model)) levels.push("xhigh");
  levels.push("adaptive");
  return levels;
}

Observed behavior in practice:

• Discord /think choices did not expose xhigh
• backend/source indicates xhigh is valid for openai-codex/gpt-5.4

Impact and severity

• Affected: Discord users using xhigh-capable models such as openai-codex/gpt-5.4
• Severity: Medium (does not fully break the session, but makes a supported option undiscoverable / appear unsupported)
• Frequency: Reproducible in the affected session state
• Consequence: Users may conclude xhigh is unavailable on Discord even when the backend supports it

Additional information

My current hypothesis is that Discord native command choices are not being resolved from the effective current session model in this case, or are using stale/default model context.

I am intentionally not claiming a confirmed root cause yet—only that the Discord-side choice list appears inconsistent with the installed model-selection logic.