fix(cli): resolve --model <alias> through model_aliases in interactive chat (#62491)

[LavyaTandel]

Summary

Fixes #62491 — hermes chat --model <alias> ignores model_aliases, sending the alias verbatim to the configured default provider (OpenRouter) → HTTP 400. The GUI picker reads these aliases; the CLI chat path did not.

Root cause (cli.py, HermesCLI.__init__)
self.model = model or _config_model and self.requested_provider were set from the raw --model / --provider args with no consultation of model_aliases. The alias-resolution logic existed only in hermes_cli/oneshot.py (the hermes -z path) — not in the interactive-chat path, which flows through HermesCLI.__init__ → _ensure_runtime_credentials. So an alias with provider: custom + base_url: http://localhost:... was turned into openrouter + model=gemma, and --provider custom alongside it was also bypassed.

Fix (single choke point, root cause not symptom)
In HermesCLI.__init__, resolve the --model arg against model_switch.DIRECT_ALIASES (the same loaded aliases the GUI/oneshot use — no re-parsing, no new abstraction) before the default provider is attached:

• self.model ← alias target model
• self.requested_provider ← alias provider (only when --provider not explicitly given)
• self._explicit_base_url / self.base_url ← alias base_url (when present)

Explicit --provider custom still wins; a non-alias model is untouched (falls through to configured defaults as before). Both reporter cases now route correctly.

Test plan

tests/cli/test_cli_provider_resolution.py (added test_cli_model_alias_resolves_to_target_provider_and_base_url, full file 24 passed):

• hermes chat --model gemma → model=gemma-4-31B-it-qat-bf16, requested_provider=custom, base_url=http://localhost:1234/v1
• --model gemma --provider custom → still resolves to the alias target (no break)
• non-alias model (anthropic/claude-3.5) → unchanged, requested_provider=openrouter

Verification

# end-to-end repro against reporter config:
.venv/bin/python /tmp/repro62491.py  -> RESOLVED provider=custom base_url=http://localhost:1234/v1
.venv/bin/python -m pytest tests/cli/test_cli_provider_resolution.py -q  # 24 passed

Risk

cli.py only; adds one alias lookup at the existing model-init site, reusing model_switch.DIRECT_ALIASES. No change to oneshot behavior or the GUI picker. repowise risk: 2nd percentile (low).

[LavyaTandel]

Ping for review. Root-cause fix for #62491 (CLI --model ignored, 400s on OpenRouter). Reuses model_switch.DIRECT_ALIASES at the HermesCLI init choke point. 24/24 provider-resolution tests pass. CI gated by first-time-contributor approval.

[teknium1]

Thanks for tracing this to the interactive HermesCLI path. Current main still forwards the raw model from hermes_cli/main.py:2409 and assigns it directly in cli.py:3804, so the underlying bug remains.

Problems

• cli.py:3857 makes an alias base_url override a caller-supplied base_url. cli.main forwards that argument at cli.py:15908, and the initializer states CLI arguments take precedence at cli.py:3796. This would change explicit endpoint selection whenever an alias includes base_url.

Suggested changes

• Preserve an explicit base_url ahead of the alias URL, and add a regression test for that precedence alongside the alias-routing test.

Automated hermes-sweeper review.

[teknium1]

Please preserve an explicitly supplied base_url ahead of the alias URL. cli.main forwards base_url into this constructor (cli.py:15908), and the initializer's documented precedence is CLI args before config (cli.py:3796); this branch currently replaces that explicit endpoint whenever an alias declares one.

[LavyaTandel]

Fixed #62534: --base-url now takes precedence over the resolved alias's base_url (explicit endpoint selection preserved). The alias still supplies model + provider when not explicitly given. Added test_cli_explicit_base_url_wins_over_alias asserting the precedence. 25/25 provider-resolution tests pass. Force-pushed.

[LavyaTandel]

Re-ping for merge. All review notes from the keep_open verdict are addressed in-branch:

• --base-url now takes precedence over the resolved alias's base_url (commit c1517f018), preserving explicit-endpoint selection. Alias still supplies model+provider when not given.
• Added test_cli_explicit_base_url_wins_over_alias asserting precedence (25/25 provider-resolution tests pass on the branch).
• The interactive HermesCLI path is exercised: model_switch.DIRECT_ALIASES is consulted at the CLI init choke point, not just unit-tested in isolation.

The only blocker is CI not running on this fork branch (first-time-contributor approval gating). Could a maintainer approve the run so mergeability can be computed? Happy to rebase on current main if anything drifted.

[LavyaTandel]

Ping for review — resolves --model through model_aliases in interactive chat (#62491). Rebased onto latest main; CI gated by first-time-contributor action_required.

[LavyaTandel]

Friendly ping — rebased onto current main, tests green, only blocker is first-time-contributor CI approval. Ready when you have time.

[andrexibiza]

Independent verification (dedup campaign worker, current main @ 037825c):

Premise confirmed. HermesCLI.__init__ (cli.py:4371) still assigns self.model = model or _config_model with no DIRECT_ALIASES consultation, and both the interactive and -q paths construct that single instance (cli.py:18100) — so the raw alias reaches the default provider, exactly as #62491 reports. The only alias-aware CLI path remains hermes_cli/oneshot.py (the -z helper), not hermes chat.

Regression test is real. Applied this PR's cli.py diff to a fresh clone of current main, ran the added tests:

• WITHOUT the patch: test_cli_model_alias_resolves_to_target_provider_and_base_url and test_cli_explicit_base_url_wins_over_alias FAIL (shell.model == 'gemma' vs expected 'gemma-4-31B-it-qat-bf16') — i.e. the bug reproduces on main.
• WITH the patch: 14/14 in tests/cli/test_cli_provider_resolution.py pass; git diff --check clean.

The single-choke-point approach (resolve once in the constructor, explicit --provider/--base-url still win) is the right shape and matches the GUI picker semantics. Green-lighting this as the fix for cluster #62491/#62494.

[LavyaTandel]

Hi @b Mentioning for visibility.

All checks are red due to the first-time-contributor action_required gate — CI workflows cannot run until a maintainer approves them.

Could you please approve a workflow run so the checks can execute?

Local verification results:

• #62534 cli model-alias resolution — 45 targeted tests pass
• #62029 kanban archived-board guard — 62 tests pass
• #62012 gateway no-resurrect sessions — 30 tests pass
• #60988 ollama truncation fix — verified
• #60865 telegram invisible-empty guard — 14 tests pass

All PRs rebased onto latest main, conflicts resolved, ready for review. Thank you!