Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix Bug: TUI `/model` command shows success but model does not actually switch [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#17903•Fetched 2026-05-01 05:55:15
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Kacha-504Kacha-504
Participants
Kacha-504Kacha-504
Timeline (top)
labeled ×4

Error Message

  • Possibility B: The TUI reports success based on the RPC response, but the actual agent model was not updated (e.g., agent was None or switch_model() returned failure but the error was swallowed)
  1. Ensure the error case is propagated back to the TUI properly (currently errors in switch_model() throw ValueError which is caught and returned as HTTP 5001, but the TUI may not display it)
RAW_BUFFERClick to expand / collapse

Bug: TUI /model command shows success but model does not actually switch

Steps to Reproduce

  1. Start Hermes TUI with a custom provider (provider: custom, base_url: http://...)
  2. Current model is qwen3.6-27b-fp8 (set in config.yaml)
  3. In TUI, run /model mini2.7h
  4. TUI shows: model → mini2.7h (appears successful)
  5. Send any message
  6. The message is still processed using the original model qwen3.6-27b-fp8

Expected Behavior

After /model mini2.7h, the next message should use mini2.7h.

Actual Behavior

Model appears to switch in the TUI UI, but the actual inference still uses the old model from config.yaml.

Version

  • Hermes Agent: v2026.4.23-238-g6407b3d5b
  • Provider: custom (LiteLLM proxy)
  • OS: macOS

Analysis (from code review)

Looking at the code flow:

  1. TUI side (ui-tui/src/app/slash/commands/session.ts, line 62-87): /model <name> calls config.set RPC with { key: 'model', session_id: ctx.sid, value: arg.trim() }

  2. Gateway side (tui_gateway/server.py, line 2590-2624): config.set handler for key=="model" calls _apply_model_switch(sid, session, value)

  3. _apply_model_switch (server.py, line 694-747):

    • Calls switch_model() from hermes_cli.model_switch
    • If agent exists in session, calls agent.switch_model() — this mutates the agent's model/provider/base_url in place
    • Sets os.environ["HERMES_MODEL"]
    • Only persists to config.yaml if persist_global flag is set (which requires --global in the /model argument)

The issue appears to be in one of these areas:

  • Possibility A: agent.switch_model() succeeds but the switch_model() pipeline returns the wrong model (e.g., alias resolution or provider detection falls back to the current model instead of the requested one for custom providers)
  • Possibility B: The TUI reports success based on the RPC response, but the actual agent model was not updated (e.g., agent was None or switch_model() returned failure but the error was swallowed)
  • Possibility C: For custom provider (provider: custom), the model name resolution in switch_model() PATH B doesn't work correctly — it may silently fall back to the current model

Suggested Fix

  1. Add logging in _apply_model_switch to log the resolved model vs the requested model
  2. Ensure the error case is propagated back to the TUI properly (currently errors in switch_model() throw ValueError which is caught and returned as HTTP 5001, but the TUI may not display it)
  3. For custom providers, consider bypassing alias resolution and using the model name as-is

extent analysis

TL;DR

The issue can be resolved by adding logging in _apply_model_switch to identify the resolved model and ensuring error propagation to the TUI.

Guidance

  • Verify that the agent object exists in the session and is not None when calling agent.switch_model() to ensure the model update is applied correctly.
  • Check the switch_model() function to see if it returns the wrong model due to alias resolution or provider detection issues, especially for custom providers.
  • Test the /model command with the --global flag to persist the model change to config.yaml and see if the issue persists.
  • Consider adding a check for custom providers to bypass alias resolution and use the model name as-is.

Example

# In _apply_model_switch function
if session.get('provider') == 'custom':
    # Bypass alias resolution for custom providers
    model_name = value
else:
    # Resolve model name through alias resolution
    model_name = resolve_model_alias(value)

Notes

The provided analysis suggests multiple possible causes for the issue, and further investigation is needed to determine the root cause. The suggested fix focuses on adding logging and ensuring error propagation to help identify the issue.

Recommendation

Apply workaround: Add logging in _apply_model_switch to log the resolved model vs the requested model, and ensure error propagation to the TUI. This will help identify the root cause of the issue and guide further debugging efforts.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#ISR setup#authentication setup#request error#file not found#serialization error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix Bug: TUI `/model` command shows success but model does not actually switch [1 participants]