Summary

After switching an existing session from the configured OpenAI default to an OpenRouter MiniMax model, /status shows a mixed state:

• selected model: openrouter/minimax/minimax-m3
• auth label: oauth (openai:default (OpenAI Codex OAuth))
• runtime label: OpenAI Codex
• OpenAI usage quota line still appears before the first live MiniMax turn

After sending a simple prompt, the actual execution appears to use the OpenRouter/MiniMax path: the session reports a MiniMax-sized context window (40k/524k) and the model replies as MiniMax M3. However /status continues to show the OpenAI Codex auth/runtime labels.

This looks like a status rendering / model-state resolution bug, not an execution routing bug.

Environment

• OpenClaw: 2026.6.1
• Configured default: openai/gpt-5.5
• Session-selected model: openrouter/minimax/minimax-m3
• OpenRouter auth: OPENROUTER_API_KEY
• OpenRouter provider config includes models.providers.openrouter.agentRuntime.id = "openclaw"
• Session: existing agent:main:main session

Reproduction

1. Start with default model:

   openai/gpt-5.5
   

2. Switch the existing session to:

   /model openrouter/minimax/minimax-m3
   

3. Run /status.

4. Send one simple prompt, for example ping.

5. Run /status again.

Observed status immediately after switching

🧠 Configured default: openai/gpt-5.5
📌 Session selected: openrouter/minimax/minimax-m3 · 🔑 oauth (openai:default (OpenAI Codex OAuth))
⚠️ Reason: session override
🧮 Tokens: 908 in / 785 out
🗄️ Cache: 99% hit · 93k cached, 0 new
📚 Context: 93k/200k (47%) · 🧹 Compactions: 2
📊 Usage: 5h 93% left ⏱1h 31m · Week 0% left ⏱1d 17h
⚙️ Execution: direct · Runtime: OpenAI Codex · Think: high · Fast: off · Text: low

Observed after one prompt

The model replied:

I am now on Minimax M3 (or_minimax3 → openrouter/minimax/minimax-m3).

Test reply: ok.

Then /status showed:

🧠 Configured default: openai/gpt-5.5
📌 Session selected: openrouter/minimax/minimax-m3 · 🔑 oauth (openai:default (OpenAI Codex OAuth))
⚠️ Reason: session override
🧮 Tokens: 40k in / 32 out
🗄️ Cache: 1% hit · 242 cached, 0 new
📚 Context: 40k/524k (8%) · 🧹 Compactions: 2
⚙️ Execution: direct · Runtime: OpenAI Codex · Think: high · Fast: off

The 524k context window strongly suggests the live call used the OpenRouter/MiniMax model route, while the auth/runtime display still came from the OpenAI/Codex default route.

Expected behavior

For openrouter/minimax/minimax-m3, /status should show coherent metadata, for example:

📌 Session selected: openrouter/minimax/minimax-m3 · 🔑 api-key (env: OPENROUTER_API_KEY)
⚙️ Execution: direct · Runtime: OpenClaw Default · Think: high · Fast: off

It should not show OpenAI Codex OAuth or Runtime: OpenAI Codex unless the effective selected model is actually using the OpenAI Codex harness.

Actual behavior

/status combines the session-selected OpenRouter model with stale/default OpenAI Codex auth/runtime metadata.

Why this matters

This makes it hard to tell whether a session is actually running through OpenRouter/OpenClaw or through the OpenAI Codex harness. It also creates billing/quota confusion because the status surface can show OpenAI usage quota while the actual prompt appears to run on OpenRouter/MiniMax.

Likely related work

Related but not the same:

• Bug: /status does not show effective model from channels.modelByChannel #89532 and PR fix(status): show effective channel model override #89602: /status can show the wrong effective model/metadata for channels.modelByChannel. The PR review already flags that auth metadata may be computed before the effective model is resolved.
• OpenAI model with agentRuntime.id "openclaw" appears to switch to OpenAI Codex runtime after first Telegram message #90021: OpenAI model with agentRuntime.id = "openclaw" appears to switch to OpenAI Codex runtime after first message. That may be an actual runtime routing issue; this report appears to be a status metadata mismatch after an OpenRouter session model switch.
• Refactor session model/auth state resolution #87957: broader refactor issue for session model/auth state resolution.

Suspected cause

Source inspection suggests /status may compute runtime/auth/usage/text-verbosity from the raw provider / model params passed into the status builder, while the visible Session selected line is resolved later from sessionEntry via resolveSelectedAndActiveModel(...).

If the caller passes the configured default (openai/gpt-5.5) while the session entry contains a model override (openrouter/minimax/minimax-m3), the status card can render exactly this mixed state:

• selected model from session entry: openrouter/minimax/minimax-m3
• auth/runtime/usage from default provider/model: OpenAI Codex

The fix should make /status resolve one effective selected/active model state first, then derive model label, auth label, runtime label, usage provider, text verbosity, and context window from that same state.

Privacy note

Session IDs, account IDs, and local paths are omitted. The status snippets above are redacted to model/provider/auth-label level only.