Skip to content

fix(web): preserve custom: provider slugs in main model assignment - #45069

Closed
Hung2124 wants to merge 1 commit into
NousResearch:mainfrom
Hung2124:fix/custom-provider-slugs
Closed

fix(web): preserve custom: provider slugs in main model assignment#45069
Hung2124 wants to merge 1 commit into
NousResearch:mainfrom
Hung2124:fix/custom-provider-slugs

Conversation

@Hung2124

Copy link
Copy Markdown

What

_normalize_main_model_assignment() now returns early for custom:<name> provider slugs.

Why

User-defined providers from config.yaml are valid as-is, and their model namespaces routinely contain / (e.g. kr/claude-opus-4.8 on a local router). Without the early return, the vendor-prefix fallback misreads the / as an openrouter-style vendor prefix and silently rewrites the assignment onto openrouter — breaking the user's explicit provider choice.

Testing

Verified with a custom: provider whose model ids contain /: assignment is preserved verbatim; openrouter-style slugs still normalize exactly as before (early return only triggers on the custom: prefix).

custom:<name> providers from config.yaml are valid as-is and their model namespaces routinely contain '/' (e.g. kr/claude-opus-4.8 on a local router). Return early for them so the vendor-prefix fallback never silently rewrites the assignment onto openrouter.
@alt-glitch alt-glitch added type/bug Something isn't working comp/gateway Gateway runner, session dispatch, delivery P3 Low — cosmetic, nice to have labels Jun 12, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related: #45075 (later same-day twin with the identical fix).

Copy link
Copy Markdown

Thanks for working on this fix. I am preparing a YouTube video for release around June 15 that demonstrates Hermes Desktop with custom OpenAI-compatible LLM providers such as Polza.ai. In the current Desktop build, viewers following the UI setup will end up with openrouter persisted and a non-working Gateway, even though the custom provider credentials and endpoint are valid.

I have reproduced the issue consistently, verified the provider API itself returns HTTP 200, and verified this patch fixes the persistence path locally. Would it be possible to prioritize review and include this in the next Desktop/backend update? Even an indication of whether it is likely to land soon would help me give viewers accurate instructions. Thank you.

@Hung2124

Copy link
Copy Markdown
Author

Thanks for the detailed repro and for confirming the patch fixes it on your end — that's really helpful.

The PR is small (+8 lines, single file) and just preserves the custom: provider slug instead of rewriting it onto openrouter during main-model assignment. It's ready and mergeable; I'm waiting on a maintainer to review/merge since I'm only the author here.

I've pinged the team to flag it. I can't promise a timeline for the next Desktop build, but I'll keep this PR up to date if any changes are requested. Hopefully it lands before your video — fingers crossed.

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the focused custom-provider fix. This is already implemented on current main through a broader consolidation.

  • Automated hermes-sweeper review verified hermes_cli/web_server.py:1047-1054 resolves declared custom providers before the vendor-prefix fallback and preserves their model IDs.
  • Commit 9a15fad0d6c370ba09bf87af92144f46ccd2bc4a (fix(web): preserve declared providers in model writes (#63058)) added this behavior.
  • tests/hermes_cli/test_main_model_custom_provider_normalization.py:22-33 covers the custom:<name> plus vendor/model case.

Closing as implemented on main.

@teknium1 teknium1 closed this Jul 14, 2026
@teknium1 teknium1 added sweeper:implemented-on-main Sweeper: behavior already present on current main sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jul 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/dashboard Web dashboard / control panel UI (dashboard/, landing) P3 Low — cosmetic, nice to have sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:implemented-on-main Sweeper: behavior already present on current main sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants