openclaw - 💡(How to fix) Fix [Bug]: Telegram `/think` inline-button menu ignores per-session `/model` override, always resolved against `agents.defaults.model` [1 comments, 2 participants]

Summary

On [email protected], the Telegram /think inline-button menu is generated from agents.defaults.model instead of the current session's model, so the menu never reflects per-session /model overrides. The hardcoded argument description string ("off, minimal, low, medium, high, xhigh") is also displayed verbatim in the menu title regardless of which levels the provider actually supports, producing a visible mismatch between the title text and the offered buttons.

The Discord side of the same /think command was fixed in 2026.4.20 (changelog: "Discord/think: only show adaptive in /think autocomplete for provider/model pairs that actually support provider-managed adaptive thinking") because Discord's slash-command autocomplete resolver does pass provider/model. Telegram's inline-button path was not updated.

Affected

• Channel: telegram
• Gateway: [email protected] (115f05d) (and earlier)
• Command: /think (also /thinking, /t)
• File: dist/extensions/telegram/bot-Dm2NPcQu.js (the call site)
• File: dist/commands-registry-CUdwdf0_.js (the resolver design)

Steps to reproduce

1. Configure Gateway with:
   • agents.defaults.model.primary: "minimax/MiniMax-M2.7"
   • A model like anthropic/claude-opus-4-7 available via /model switching
2. In a Telegram chat: run /model opus47 (or /model anthropic/claude-opus-4-7).
3. Wait for model switch to take effect (session_status now reports anthropic/claude-opus-4-7).
4. Run /think (no argument) to open the inline-button menu.

Expected

Menu should offer the thinking levels supported by the current session model (claude-opus-4-7): off, minimal, low, medium, high, xhigh, adaptive, max.

Actual

Menu offers the thinking levels supported by agents.defaults.model (minimax/MiniMax-M2.7): off, minimal, low, medium, high, adaptive.

Additionally, the menu title text is "Choose off, minimal, low, medium, high, xhigh for /think." — it comes from the hardcoded arg.description string and mentions xhigh, while the buttons don't include xhigh at all and include adaptive instead. Users see contradictory info.

Root cause

1. Telegram caller doesn't pass provider/model

dist/extensions/telegram/bot-Dm2NPcQu.js around line 1128:

const menu = commandDefinition ? resolveCommandArgMenu({
    command: commandDefinition,
    args: commandArgs,
    cfg: runtimeCfg,
    // ⚠️ no provider, no model
}) : null;

2. resolveCommandArgMenu doesn't accept them either

dist/commands-registry-CUdwdf0_.js around line 126:

function resolveCommandArgMenu(params) {
    const { command, args, cfg } = params;   // ⚠️ provider/model not destructured
    ...
    const choices = resolveCommandArgChoices({
        command, arg, cfg,
        // ⚠️ no provider, no model passed through
    });
    ...
}

3. Fallback resolves from agents.defaults.model

resolveCommandArgChoices (same file) then falls back to resolveDefaultCommandContext(cfg), which reads agents.defaults.model via resolveConfiguredModelRef(...). So for every Telegram user, regardless of their per-session /model choice, listThinkingLevels(provider, model) is always evaluated against the default agent model.

Contrast: Discord path works

dist/extensions/discord/provider-CraktAkD.js builds the same menu but explicitly resolves the context and threads provider/model through:

const choices = resolveCommandArgChoices({
    command,
    arg,
    cfg,
    provider: context?.provider,   // ✓ from interaction context
    model: context?.model,         // ✓ from interaction context
});

Suggested fix

1. Extend resolveCommandArgMenu to accept and forward provider/model:

function resolveCommandArgMenu(params) {
    const { command, args, cfg, provider, model } = params;
    ...
    const choices = resolveCommandArgChoices({
        command, arg, cfg, provider, model,
    });
    ...
}

1. In dist/extensions/telegram/bot-Dm2NPcQu.js, resolve the current session's model (the same way resolveSessionModelRef(...) is used elsewhere) and pass it in. A reasonable source is the already-loaded session entry for baseSessionKey, or — since resolveCommandRuntimeContext already has threadSpec/route — the same ref used by the subsequent chat dispatch in the non-menu branch.

2. Consider making the /think arg.description dynamic rather than a hardcoded "off, minimal, low, medium, high, xhigh" string in commands-registry.data-*.js:723, or at minimum omit it from the menu title when a dynamic choice list is available, so the title can't contradict the buttons.

Workaround for users

Users can bypass the button menu by typing the argument inline:

/think xhigh
/think max

These text-form commands are dispatched through the normal command handler which does resolve against the session model, so they work correctly on Opus 4.7 even though the buttons don't offer them.

Related

• #67888 (Opus 4.7 adaptive-thinking detection — fixed in 2026.4.20)
• Changelog 2026.4.20: "Discord/think: only show adaptive in /think autocomplete for provider/model pairs that actually support provider-managed adaptive thinking" — same class of fix, Discord only.
• Changelog 2026.4.20: "Thinking: only expose max for models that explicitly support provider max reasoning, and remap stored max settings to the largest supported thinking mode when users switch to another model." — this remapping kicks in at execute time, but the button menu is still misleading at discovery time.