Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix Model aliases not resolved for custom providers [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#18954•Fetched 2026-05-03 04:53:22
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
andszwabeandszwabe
Participants
andszwabeandszwabe
Timeline (top)
labeled ×6

When using model aliases defined in config.yaml under model_aliases:, Hermes sends the alias name to the API instead of resolving it to the actual model name. This causes 400 errors with custom provider endpoints that don't recognize the alias.

Error Message

This works (full model name):

hermes chat --provider custom --model claude-opus-4-6 -q "test"

This fails (alias):

hermes chat -m opus -q "test"

Error: HTTP 400: unknown model "opus"

Root Cause

The alias resolution code exists in hermes_cli/model_switch.py (lines 437-441 in resolve_alias()) and checks DIRECT_ALIASES correctly. However:

  1. CLI path (hermes_cli/oneshot.py line 241): Alias resolution only runs when effective_provider is None, but when using -m opus, the provider gets set from the alias definition, preventing resolution on subsequent checks.

  2. Gateway path (gateway/run.py line 8559): The model name is passed directly from turn_route["model"] without alias resolution.

  3. AIAgent initialization (run_agent.py line 1007): self.model is set directly from the parameter without checking if it's an alias that needs resolution.

Fix Action

Workaround

Use the full model name instead of the alias:

hermes chat --model claude-opus-4-6

Or in Telegram:

/model claude-opus-4-6

Code Example

model_aliases:
  opus:
    provider: custom
    model: claude-opus-4-6
    base_url: https://sfedu02-acb50301.snowflakecomputing.com/api/v2/cortex/v1
    context_length: 200000

---

hermes chat -m opus -q "What model are you?"

---

/model opus

---

HTTP 400: unknown model "opus"

---

hermes chat --model claude-opus-4-6

---

/model claude-opus-4-6

---

# This works (full model name):
hermes chat --provider custom --model claude-opus-4-6 -q "test"

# This fails (alias):
hermes chat -m opus -q "test"
# Error: HTTP 400: unknown model "opus"
RAW_BUFFERClick to expand / collapse

Model aliases not resolved for custom providers

Description

When using model aliases defined in config.yaml under model_aliases:, Hermes sends the alias name to the API instead of resolving it to the actual model name. This causes 400 errors with custom provider endpoints that don't recognize the alias.

Steps to Reproduce

  1. Configure a model alias in ~/.hermes/config.yaml:
model_aliases:
  opus:
    provider: custom
    model: claude-opus-4-6
    base_url: https://sfedu02-acb50301.snowflakecomputing.com/api/v2/cortex/v1
    context_length: 200000
  1. Try to use the alias via CLI:
hermes chat -m opus -q "What model are you?"
  1. Or via Telegram gateway:
/model opus

Expected Behavior

Hermes should resolve the alias opus to claude-opus-4-6 before sending the API request.

Actual Behavior

Hermes sends the literal string "opus" to the custom provider API, which returns:

HTTP 400: unknown model "opus"

Workaround

Use the full model name instead of the alias:

hermes chat --model claude-opus-4-6

Or in Telegram:

/model claude-opus-4-6

Root Cause Analysis

The alias resolution code exists in hermes_cli/model_switch.py (lines 437-441 in resolve_alias()) and checks DIRECT_ALIASES correctly. However:

  1. CLI path (hermes_cli/oneshot.py line 241): Alias resolution only runs when effective_provider is None, but when using -m opus, the provider gets set from the alias definition, preventing resolution on subsequent checks.

  2. Gateway path (gateway/run.py line 8559): The model name is passed directly from turn_route["model"] without alias resolution.

  3. AIAgent initialization (run_agent.py line 1007): self.model is set directly from the parameter without checking if it's an alias that needs resolution.

Environment

  • Hermes version: v0.12.0 (2026.4.30) · upstream 5d3be898
  • OS: Pop!_OS 24.04 (Linux)
  • Provider: Custom (Snowflake Cortex API)

Test Case

# This works (full model name):
hermes chat --provider custom --model claude-opus-4-6 -q "test"

# This fails (alias):
hermes chat -m opus -q "test"
# Error: HTTP 400: unknown model "opus"

Suggested Fix

Add alias resolution in run_agent.py __init__ method before setting self.model, or ensure alias resolution happens consistently in all code paths (CLI, gateway, oneshot) before the model name reaches AIAgent.

extent analysis

TL;DR

Add alias resolution in run_agent.py __init__ method before setting self.model to ensure model aliases are correctly resolved before API requests.

Guidance

  • Review the resolve_alias() function in hermes_cli/model_switch.py to understand the existing alias resolution logic.
  • Modify the __init__ method in run_agent.py to resolve model aliases before setting self.model, ensuring consistency across all code paths (CLI, gateway, oneshot).
  • Verify the fix by testing with both the full model name and the alias, as shown in the provided test case.
  • Consider adding alias resolution checks in other relevant code paths, such as hermes_cli/oneshot.py and gateway/run.py, to ensure consistent behavior.

Example

# In run_agent.py __init__ method
from hermes_cli.model_switch import resolve_alias

self.model = resolve_alias(model_name)

Notes

The suggested fix focuses on adding alias resolution in the run_agent.py __init__ method, but it's essential to review the entire codebase to ensure consistent alias resolution across all paths.

Recommendation

Apply the suggested fix by adding alias resolution in the run_agent.py __init__ method, as this should resolve the issue with model aliases not being correctly resolved before API requests.

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…
#api#embedding generation#cache error#pipeline error#runtime 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