Bug Report: System prompt "Model:" / "Provider:" header is stale after mid-session model switches

Summary

The system prompt's Model: <name> and Provider: <name> lines (visible in the system identity block at the top of every Hermes conversation) reflect the model the AIAgent instance was originally constructed with. They do not update when the model is changed mid-session — via hermes model, a config.yaml edit, a gateway restart that resumes a session, or a session auto-resume.

This causes user confusion: the header claims a different model than the one actually serving API calls. In our case the header said "Model: MiniMax-M2.7-highspeed" while the agent.log clearly showed every API call was using model=MiniMax-M3 provider=minimax base_url=https://api.minimax.io/v1.

Reproduction

1. Configure model.default: <model-A> in ~/.hermes/config.yaml and start a session. Header reads Model: <model-A>.
2. Edit config.yaml to model.default: <model-B> and run systemctl --user restart hermes-gateway.service.
3. Resume the original session (gateway auto-resumes after restart).
4. Header now shows Model: <model-A> (stale), but agent.log shows API calls using <model-B> (current).

Expected

The Model: and Provider: lines in the system prompt should reflect the model currently serving the session. After a config change + restart, the header should say <model-B>, matching the actual API calls.

Actual

Header is frozen at session-start values. The agent instance is reused (or its model / provider attributes are not refreshed from current config) even when the runtime picks a new model.

Source Location

/root/hermes-agent/agent/system_prompt.py, around lines 334-337:

if agent.model:
    timestamp_line += f"\nModel: {agent.model}"
if agent.provider:
    timestamp_line += f"\nProvider: {agent.provider}"

agent.model and agent.provider are set when the AIAgent instance is constructed (see AIAgent.__init__ signature in run_agent.py). They are instance attributes — not dynamically resolved at system-prompt build time.

The "fresh-agent gateway turns" path referenced in the surrounding comment (line 327) suggests the agent should be rebuilt fresh on gateway turns, but in practice agent.model is still the value from when the AIAgent was first built for the session.

Workaround (not a fix)

Either:

• Run /reset in-session to force a full rebuild of the AIAgent
• Restart the gateway AND have the session be created fresh (not resumed)
• Read agent.log to see the actual serving model — but this requires shell access and isn't visible to the user inside the chat

Impact

• High user confusion. Users believe they are getting a cheaper/smaller model than they are actually getting, OR vice versa — they believe they have the latest model when they actually got rolled back to a default. Both directions are problematic for billing, capability, and trust.
• The discrepancy is not visible from the conversation itself; only cross-referencing with agent.log reveals the truth.

Suggested Fix

Resolve the model and provider at system-prompt build time instead of caching on the AIAgent instance. Read from config.yaml's model.default

• model.provider (or from the runtime provider resolution path) when building the volatile system-prompt block, so the header always reflects the model the next API call will actually use.

The relevant helper is already defined:

• gateway/run.py::_resolve_gateway_model(config) — reads model.default from config.yaml
• hermes_cli/runtime_provider.py::resolve_runtime_provider() — resolves the current provider credentials

build_volatile_system_prompt() could call _resolve_gateway_model() and read the active provider from runtime state instead of the AIAgent's frozen self.model / self.provider.

Environment

• Hermes Agent v0.14.0 (2026.5.16)
• Gateway running on Hetzner VPS, headless
• MiniMax-M3 (the locked canonical model) on minimax provider
• Triggered by: systemctl --user restart hermes-gateway.service after model.default was changed in config.yaml