Pushed a small follow-up fix for the session picker PRIMARY badge issue when duplicate slash-qualified model IDs exist across providers. This makes both the backend badge mapping and the UI badge lookup provider-aware, and adds coverage for the regression.

Thanks for the patch. The two-part approach lines up with how #1313 manifests:

1. dedup at the catalog layer so dropdown values stop colliding
2. provider-aware rehydration so the saved default model snaps back to the right active_provider instead of the first option that happens to share the id

The follow-up commit on the session picker PRIMARY badge is a nice catch — same root cause (badge lookup keyed on bare id) and worth folding into the same PR rather than splitting.

Will review the diff in api/config.py (the _deduplicate_model_ids() extension) and the frontend matchers in panels.js / ui.js against the regression tests in test_issue1228_model_picker_duplicate_ids.py and test_model_picker_badges.py before merging. The @<provider_id>:<id> prefix scheme keeps backward-compat for the first occurrence which is the right call.

One thing worth confirming on review: that the prefixed values round-trip through /api/config save/load so a user who happens to have a colliding model selected today doesn't get their preference dropped. The tests look like they cover the dropdown path; will sanity-check the persistence path too.

Thanks — I also sanity-checked the persistence path locally. Saving a prefixed duplicate still writes the CLI-safe bare/slash model plus the matching model.provider, and the UI rehydrates using default_model + active_provider, so the provider identity is preserved across save/load.

Thanks for the persistence-path sanity check. That confirms the round-trip I was worried about:

• default_model is written as the CLI-safe bare/slash id (no @<provider_id>: prefix in the saved config)
• model.provider is written alongside it, carrying the disambiguation
• on rehydrate, the dropdown matcher prefers the configured active_provider instead of the first option that happens to share the bare id

So a user who has a colliding model selected today won't get their preference dropped after this lands — the prefix is purely a dropdown-value uniqueness mechanism and doesn't bleed into persisted config.

Will move to review. The PRIMARY-badge follow-up commit fits in this PR rather than getting split, since both bugs share the same root cause (lookup keyed on bare id without provider context).

Shipped in v0.50.245 via batch release PR #1334 (merge commit 52e1567). Thanks @Hacker2005! 🙏

Live now at https://github.com/nesquena/hermes-webui/releases/tag/v0.50.245.

Released alongside 9 other contributor fixes — see the v0.50.245 entry in CHANGELOG.md.