openclaw - 💡(How to fix) Fix [Feature Request] Show actual model identifier per reply when fallback or model switch occurs [1 comments, 2 participants]

Problem

When a model request fails (rate limit, billing error, timeout, etc.) and OpenClaw silently falls back to another provider/model, the user has no way to know which model actually generated the reply. This is especially problematic when:

• The primary model is down and a much weaker fallback model responds — the user may misjudge the quality of the intended model based on the fallback output.
• Billing or rate-limit errors on the primary cause consistent fallback without visibility, making it hard to diagnose why responses feel "different."
• Multi-model setups (primary + fallback chain) make it essentially impossible to track which model handled which turn without digging through gateway logs.

Currently the only way to discover which model answered is checking gateway logs or /status, which is not practical during a normal conversation.

Suggested Solution

Add a lightweight per-reply indicator that shows which model actually produced the response. A few possible approaches:

1. Inline footer line — Append a small line at the end of the assistant reply, e.g.:

   _↳ openai/gpt-5.5_

   This is the most discoverable option for end users.

2. Reply metadata / reaction — Use a channel-appropriate mechanism (e.g. a Telegram reaction emoji, a Discord embed footer) that doesn't clutter the text but remains inspectable.

3. Message entity tag — Include the model as a structured metadata field in the message payload that UIs and bots can optionally render.

The indicator should appear whenever the actual model differs from the configured primary, or optionally on every message (configurable). This way:

• Users immediately notice fallback events.
• Config misconfigurations (wrong model name, dead API key) surface quickly instead of being masked by a silent fallback.
• It becomes trivial to correlate response quality with the actual model used.

Why This Matters

Silent fallback is a useful reliability feature, but without visibility it becomes a hidden variable that erodes trust. Users who pay for a specific model deserve to know when they are getting a different one. Even in free-tier scenarios, noticing "this feels like model X" without confirmation is a frustrating experience.

The v2026.4.26 release already improves fallback logging (structured fallback-step fields per #71922), which is great for administrators. This request is about surfacing that information to the end user in the conversation itself.

Environment

• OpenClaw 2026.4.15+ (all channels: Telegram, Discord, WebChat, etc.)
• Primary use case: Telegram direct chat

Thank you for considering this!