fix: model picker snaps to wrong model with multi-slash IDs (#3360)

[b3nw]

fix: Model picker snaps to wrong model with multi-slash IDs

Closes #3360

Thinking Path

• Hermes WebUI supports custom/proxy providers that expose models from multiple upstream vendors
• When a proxy advertises models with multi-slash IDs (e.g. vendor_a/deepseek/deepseek-v4-pro, vendor_b/deepseek/deepseek-v4-pro), the dropdown contains entries that share the same base model name under different vendor hierarchies
• The model picker uses normalization to fuzzy-match selected model IDs to dropdown options — and three separate normalization paths all use split('/').pop() (JS) or split('/')[-1] (Python), which discards everything except the last segment
• This causes distinct multi-slash IDs to collide during matching, badge assignment, configured-entry dedup, and label rendering
• This PR replaces all lossy split('/').pop() normalizations with first-segment-only stripping, preserving the vendor hierarchy that distinguishes these models
• The result is that clicking a model always selects exactly that model, badges attach to the correct entry, configured entries don't duplicate, and the composer chip shows a meaningful label

What Changed

Fix 1 — _findModelInDropdown (static/ui.js)

Moved the exact string match (opts.includes(modelId)) before the provider-aware normalized match. Previously, when all models share the same provider ID (common with LLM proxy setups), the normalized match returned whichever colliding option appeared first in DOM order — even when the exact clicked value existed verbatim in the dropdown.

   const opts=options.map(o=>o.value);
+  // 0. Exact match — highest priority, no ambiguity possible (#3360).
+  if(opts.includes(modelId)) return modelId;
   // 1. Normalize: lowercase, strip namespace prefix, replace hyphens→dots.
   const norm=s=>...

Fix 2 — _normalizeConfiguredModelKey (static/ui.js) and _norm_model_id (api/config.py)

Replaced split('/').pop() / split('/')[-1] with first-segment-only stripping:

• Frontend: s.replace(/^[^/]+\//, '') || s
• Backend: s.split("/", 1)[1] (Python split with maxsplit=1 preserves the remainder)

This preserves vendor hierarchy so vendor_a/deepseek-v4-pro normalizes to deepseek.v4.pro while vendor_b/deepseek/deepseek-v4-pro normalizes to deepseek/deepseek.v4.pro — distinct keys that no longer collide.

Additionally, added colon-qualified prefix stripping to the frontend normalizer so that badge-key variants generated by the backend (e.g. custom:llm-proxy/opencode_go/model) merge correctly with bare values (opencode_go/model) during configured-section dedup.

Fix 3 — getModelLabel (static/ui.js) and _get_label_for_model (api/config.py)

Same split('/').pop() → first-segment-strip change in the display label functions. This ensures the composer-bar model chip shows opencode_go/deepseek-v4-pro instead of truncating to just deepseek-v4-pro.

Files changed

File	Lines	Description
static/ui.js	+32/−8	All three frontend fixes
api/config.py	+17/−12	Backend mirror: _norm_model_id + _get_label_for_model
tests/test_issue3360_multi_slash_model_collision.py	+263 (new)	9 regression tests across 3 test classes
tests/test_norm_model_id_trailing_empty_guard.py	+14/−8	Updated assertions for new pattern
CHANGELOG.md	+3	Release note under [Unreleased]

Why It Matters

Any user running a custom LLM proxy (LiteLLM, OpenRouter, or a private gateway) that aggregates models from multiple vendors will hit this bug as soon as two models share the same base name. The symptoms — silent model swapping and misleading configured badges — are particularly dangerous because the user believes they are using one model when the API is actually being called with a different one.

Verification

Automated tests

pytest tests/test_issue3360_multi_slash_model_collision.py \
       tests/test_norm_model_id_trailing_empty_guard.py \
       tests/test_issue1188_fuzzy_match.py \
       -v --timeout=60
# 25 passed

New tests (test_issue3360):

• TestFindModelExactMatchPriority — 3 tests: exact match beats normalized collision (same provider), exact match beats DOM order, single-slash still works
• TestNormalizeConfiguredModelKeyMultiSlash — 5 tests: multi-slash preserves vendor segment, single-slash unchanged, bare model unchanged, @Provider prefix stripped, trailing slash fallback
• TestBackendFrontendNormParity — 1 test: Python _norm_model_id produces identical output to JS _normalizeConfiguredModelKey for all input variants

Existing test updates:

• test_norm_model_id_trailing_empty_guard — updated to assert the new replace(/^[^/]+\//) pattern instead of the old split('/').pop()
• test_issue1188_fuzzy_match — all 11 tests pass unmodified (no regression in the existing fuzzy-match behavior)

Manual verification

Tested against a live deployment with an LLM proxy serving 173 models from multiple upstream vendors (including multiple models sharing the deepseek-v4-pro base name under different vendor prefixes):

1. Clicking a multi-slash model selects exactly that model (no snapping)
2. Configured badge attaches to the correct entry only
3. Single configured entry shown (no duplicates from badge-key variants)
4. Composer chip shows opencode_go/deepseek-v4-pro (not truncated to deepseek-v4-pro)
5. Single-slash models (e.g. openai/gpt-5.5) behave identically to before

Risks / Follow-ups

• Low risk: For single-slash IDs (provider/model), split('/').pop() and first-segment strip produce identical results — behavior is unchanged for the common case.
• Edge case: IDs with trailing slashes (e.g. provider/) now fall back to the original string instead of empty string, which is strictly better.
• Not addressed: The backend _build_configured_model_badges generates badge entries for model, provider/model, and @provider:model variants. This creates phantom configured entries when the provider-qualified variant doesn't exist in the dropdown. The frontend dedup now handles this correctly via the colon-prefix strip, but a cleaner long-term fix would be to avoid emitting badge keys that don't correspond to real model options.

AI Usage Disclosure

• Provider: google antigravity
• Model: Claude Opus 4.6
• Tool: Antigravity IDE (agentic pair-programming)
• Usage: Root cause analysis, implementation of all fixes, test authoring, and live hotpatch verification were done collaboratively. All changes were reviewed and tested by a human before commit.

[nesquena-hermes]

Reviewing this against origin/master and the existing model-picker test suite, I think the consistent shard-0 FAILURE across 3.11/3.12/3.13 (while shards 1 and 2 pass) is caused by Fix 1 — moving the exact match to step 0 of _findModelInDropdown.

The collision with #1228/#1313 provider-aware preference

On origin/master, static/ui.js:1059 orders the lookup so the provider-aware match runs before the bare exact match:

const preferred=String(preferredProviderId||explicitProvider||'').toLowerCase();
if(preferred){
  const providerMatch=options.find(o=>norm(o.value)===target && _getOptionProviderId(o).toLowerCase()===preferred);
  if(providerMatch) return providerMatch.value;
}
// 2. Exact match
if(opts.includes(modelId)) return modelId;

This PR hoists if(opts.includes(modelId)) return modelId; to step 0, above the preferred block. That re-breaks the case tests/test_issue1228_model_picker_duplicate_ids.py pins in TestFrontendPreferredProviderMatch.test_find_model_prefers_matching_provider_for_slash_collision (~line 250):

options: [
  { value: 'google/gemma-4-27b',               provider: 'custom:alpha' },
  { value: '@custom:beta:google/gemma-4-27b',  provider: 'custom:beta' },
]
_findModelInDropdown('google/gemma-4-27b', sel, 'custom:beta')  // expects '@custom:beta:google/gemma-4-27b'

With the reorder, opts.includes('google/gemma-4-27b') is true at step 0, so it returns the bare google/gemma-4-27b (the custom:alpha row) instead of the saved custom:beta sibling. That's a real behavior regression, not a flaky test: when a user has a model saved against a specific provider and a same-normalized bare duplicate exists under a different provider, rehydration now snaps to the wrong provider row.

Suggested fix — guard the step-0 short-circuit

Keep the exact match early (it's the right instinct for the #3360 same-provider proxy case), but don't let it override a cross-provider preference:

// 0. Exact match — but don't override a provider-aware preference (#1228/#1313).
if(opts.includes(modelId)){
  const exactOpt=options.find(o=>o.value===modelId);
  const exactProv=exactOpt?_getOptionProviderId(exactOpt).toLowerCase():'';
  const pref=String(preferredProviderId||'').toLowerCase();
  if(!pref || !exactProv || exactProv===pref) return modelId;
}

This still satisfies all three of your new TestFindModelExactMatchPriority cases — in each the exact option's own provider equals the preferred provider (llm-proxy/proxy/openai), so it short-circuits as intended — while letting the #1228 case fall through to the provider-aware match when the exact option belongs to a different provider.

Verify

Run the two suites together so the interaction is covered:

pytest tests/test_issue1228_model_picker_duplicate_ids.py \
       tests/test_issue3360_multi_slash_model_collision.py -v

The rest of the change (first-segment strip in _normalizeConfiguredModelKey, _norm_model_id, and the label helpers) looks consistent and the backend/frontend parity test is a nice touch. Just the _findModelInDropdown ordering needs the provider guard before this is green.

[b3nw]

@nesquena-hermes lmk if any other feedback

[nesquena-hermes]

Shipped in v0.51.210 (Release GD) — cherry-picked onto fresh master and released as part of stage-batch1. Thank you @b3nw!

The multi-slash model-id collision fix is live: exact-match priority in _findModelInDropdown plus first-segment-only stripping in _normalizeConfiguredModelKey / _norm_model_id now prevent same-base-name collisions across proxy-provider model IDs in selection, badge assignment, and configured-entry dedup.

Verification before merge: full pytest suite green (7267 passed), and our Codex regression gate explicitly confirmed the normalization handles single-slash IDs, @provider:model qualified IDs, custom:proxy/model, Ollama model:tag, and cross-provider same-bare-name collisions (e.g. openai/gpt-4o vs openrouter/gpt-4o) without snapping to the wrong provider's row. Your 263-line node-driven + Python regression test is now part of the suite. Closing as merged.

[pamnard]

Follow-up regression reported in #3429: getModelLabel() first-segment slash strip breaks URI-shaped model ids like gpt://${YANDEX_FOLDER_ID}/deepseek-v4-flash/latest (composer chip shows /${YANDEX_FOLDER_ID}/...).