Thanks for filing the matching issue + PR with reproduction details — the bug is real and the diagnosis matches what I see in api/config.py.

One concern with the proposed fix that I'd want addressed before merge: split(':')[-1] is too aggressive for model IDs that legitimately contain a colon inside the model name. The most common case is OpenRouter's free-tier suffix:

@openrouter:meta-llama/llama-3.1-405b:free

• Old code (split(':', 1)[1]) → meta-llama/llama-3.1-405b:free → after / split + -→. → llama.3.1.405b:free ✓
• New code (split(':')[-1]) → free → free ✗

That collapses every :free variant to the same normalized key ("free"), which would silently dedupe distinct OpenRouter free models against each other and against any other provider whose model ends in :free. That's a worse failure mode than the duplicate "Default" group this PR is trying to fix — see also #1426 which is specifically about OpenRouter free-tier visibility.

A more conservative shape that handles @custom:provider:model without breaking @provider:model:variant:

if s.startswith("@") and ":" in s:
    parts = s.split(":")
    # @custom:<provider>:<model...> → strip both prefix segments
    if len(parts) >= 3 and parts[0] == "@custom":
        s = ":".join(parts[2:])
    else:
        # @<provider>:<model...> → strip only the @provider segment
        s = parts[1] if len(parts) == 2 else ":".join(parts[1:])

Or, if the intent is "strip every leading @…: segment", anchor on the @ specifically rather than greedy-tail:

while s.startswith("@") and ":" in s:
    s = s.split(":", 1)[1]

That second form handles @custom:jingdong:GLM-5 → jingdong:GLM-5 → (no leading @, loop exits) → still leaves jingdong: in. So the explicit @custom branch above is probably the right intent.

Either way, this PR would benefit from two test cases in tests/test_model_resolver.py (or wherever _norm_model_id is exercised):

1. _norm_model_id("@custom:jingdong:GLM-5") == "glm.5" — the bug being fixed
2. _norm_model_id("@openrouter:meta-llama/llama-3.1-405b:free") == "llama.3.1.405b:free" — regression guard

The claim that "all 20 existing tests pass" is good, but those tests don't appear to cover either of these code paths, so they wouldn't catch the regression I'm describing.

Direction is right, just want to make sure we don't trade one dedup bug for another. cc @nesquena for the merge call.

Thanks @happy5318 — both this fix and the frontend mirror in #1474 shipped in v0.50.267 via release PR #1475. The work landed in master via the stage-267 batch (GitHub's auto-close didn't recognize this PR's commits through the no-ff merge, so closing manually). Thanks for the persistence — the multi-segment provider-prefix bug had been latent for several releases and the trailing-empty edge case got an Opus advisor follow-up that hardened both the backend and frontend helpers symmetrically.

Closes #1453.