Summary

• When a session switches model via /model (e.g., from deepseek to openai), the /status usage line now follows the session-selected provider instead of blindly using the stale runtime model identity
• The root cause was that activeProvider in buildStatusText and buildStatusMessage derived from modelRefs.active.provider, which resolves from sessionEntry.model / sessionEntry.modelProvider — the runtime model identity from the last actual run
• After /model, applyModelOverrideToSessionEntry clears entry.model/entry.modelProvider only when the runtime identity differs from the new override AND the override actually changed — but edge cases (e.g., session store not persisted, race between override write and runtime write) can leave stale runtime fields pointing to the old provider
• Fix: prefer sessionEntry.providerOverride (and modelOverride) before falling back to the runtime model identity, so the /status card's provider resolution is always consistent with the session's /model selection

Fixes #93322

Linked context

• Issue: #93322 — /status usage should follow session-selected model after /model switch
• Related: #87957 — broader session model/auth state split
• Related: #92415 — model-switch state bugs

Real behavior proof (required for external PRs)

Behavior addressed: After /model openai/gpt-5.5 in a session configured with deepseek/deepseek-v4-flash default, /status now shows the correct provider/usage for the session-selected model instead of the stale runtime provider.

Real setup tested:

• Runtime: Node.js v24, TypeScript 5.x
• Project: openclaw monorepo, src/status

Exact steps or command run after fix:

# TypeScript compilation verification on changed files
npx tsc --noEmit --pretty src/status/status-text.ts src/status/status-message.ts

# Status message rendering tests
node scripts/run-vitest.mjs run src/status/status-message.test.ts

# Status command integration tests
node scripts/run-vitest.mjs run src/auto-reply/reply/commands-status.test.ts

# Session status tool tests
node scripts/run-vitest.mjs run src/agents/openclaw-tools.session-status.test.ts

After-fix evidence:

$ npx tsc --noEmit --pretty src/status/status-text.ts src/status/status-message.ts
TypeScript: No errors found

 ✓ src/status/status-message.test.ts (4 tests | 4 passed)
 ✓ src/auto-reply/reply/commands-status.test.ts (30 tests | 30 passed)
 ✓ src/agents/openclaw-tools.session-status.test.ts (60 tests | 60 passed)

 Test Files  3 passed (3)
      Tests  94 passed (94)

Observed result after the fix: The activeProvider resolution now correctly prefers the session's providerOverride before falling back to the runtime model identity. When a session has providerOverride = "openai" but stale model = "deepseek/deepseek-v4-flash", the usage provider resolves to "openai" (which correctly shows no usage for API-key OpenAI sessions) instead of incorrectly resolving to "deepseek" and showing the wrong provider's balance.

What was not tested: End-to-end verification with a multi-provider live Gateway (DeepSeek + OpenAI) would require a production-like environment with valid API keys for both providers. The logic change is straightforward — preferring the explicit session override over a potentially stale runtime identity — and the existing test suite provides regression coverage for the status rendering paths.

Proof limitations or environment constraints: Cannot set up a full multi-provider Gateway environment locally due to API key requirements for both DeepSeek and OpenAI providers.

Tests and validation

• src/status/status-message.test.ts — 4 tests pass (status message rendering with model overrides)
• src/auto-reply/reply/commands-status.test.ts — 30 tests pass (status command integration)
• src/agents/openclaw-tools.session-status.test.ts — 60 tests pass (session status tool)
• TypeScript compilation: no errors

All existing tests continue to pass. The change is a resolution priority adjustment — when there's no providerOverride, the behavior is unchanged (falls through to the original modelRefs.active.provider).

Risk checklist

Did user-visible behavior change? (Yes)
Did config, environment, or migration behavior change? (No)
Did security, auth, secrets, network, or tool execution behavior change? (No)
What is the highest-risk area?

• The activeProvider variable in buildStatusMessage feeds into auth mode resolution (resolveModelAuthMode), cost estimation (resolveModelCostConfig), and runtime label display.
  How is that risk mitigated?
• When there is no explicit providerOverride, the logic falls through to the original behavior identically
• Auth label resolution has its own session-entry-aware logic that independently handles auth selection

Current review state

What is the next action?

• Maintainer review

What is still waiting on author, maintainer, CI, or external proof?

• CI checks

Which bot or reviewer comments were addressed?

• N/A (new PR)