Summary

In a QQ gateway DM, sending /model status appears to be interpreted as a model switch to a model literally named status. More importantly, after switching back to a valid/default model, later gateway messages/sessions can still auto-use the stale status model override.

This causes the agent to call the configured custom OpenAI-compatible proxy with model: status, receive an upstream error, retry, and then fall back to the fallback model.

Why this is problematic

/model status is easy to type when a user is trying to inspect the current model/status. Even if it is not the intended command, the gateway should not persist an invalid model override that continues to affect later sessions after the user switches back to a normal model.

The confusing part is not only the initial misinterpretation. The stale status model came back automatically later, after the user had already switched back to the normal model.

Observed behavior

A QQ gateway DM received these commands on 2026-05-18:

/model status
/models status
/model status

On 2026-05-19, a new QQ gateway message/session still started with Model: status in the injected system context, despite the main config default model being valid:

model:
  provider: custom
  base_url: http://192.168.1.55:8317/v1
  default: gemini-3.1-pro-preview

Gateway logs from the later session:

Vision auto-detect: using main provider custom (gemini-3.1-pro-preview)
Could not detect context length for model 'status' at http://192.168.1.55:8317/v1
Auxiliary auto-detect: using main provider custom (status)
API call failed (attempt 1/3): InternalServerError [HTTP 502]
Provider: custom  Model: status
Error: HTTP 502: unknown provider for model status
API call failed (attempt 2/3): InternalServerError [HTTP 502]
Provider: custom  Model: status
Error: HTTP 502: unknown provider for model status
API call failed (attempt 3/3): InternalServerError [HTTP 502]
Provider: custom  Model: status
Error: HTTP 502: unknown provider for model status
Max retries (3) exhausted — trying fallback...
Primary model failed — switching to fallback: claude-opus-4-7 via custom
Fallback activated: status → claude-opus-4-7 (custom)

The resulting session metadata showed the session model had fallen back to the fallback model:

{
  "session_id": "20260519_122220_a78a9717",
  "model": "claude-opus-4-7",
  "platform": "qqbot"
}

But the injected session context also showed the stale model was used when starting the conversation:

Conversation started: Tuesday, May 19, 2026 12:22 PM
Model: status
Provider: custom

Expected behavior

One or more of the following would avoid this failure mode:

1. /model status should show current model/status, or at least be treated as an invalid /model argument rather than switching to a literal model named status.
2. /model <name> should validate that <name> resolves to a configured/known model before persisting it as a gateway session override.
3. If a user later switches back to a valid model/default model, the old invalid model override should be cleared and should not be restored in later QQ gateway sessions.
4. New gateway sessions should not inject Model: status when the global config default is a valid model such as gemini-3.1-pro-preview.

Environment

• Hermes Agent Docker image: ghcr.io/zpvel/hermes-agent-ghcr:latest
• Upstream Hermes label: org.opencontainers.image.upstream.version=0.12.0
• Gateway platform: QQ bot DM
• Provider: custom
• API mode: chat_completions
• Base URL: OpenAI-compatible local proxy
• Fallback providers enabled

Notes

The upstream model/proxy itself was healthy. The failure was specifically caused by Hermes sending model: status to the proxy. The same valid model configured in the proxy works normally when requested directly.