feat(ui): match auto-router preset models against deployments' underlying model IDs

[tin-berri]

TLDR

Problem this solves:

• The auto-router template presets only light up when the admin's public model names literally match the preset's hardcoded names (modulo dot/dash), and model_name is admin-arbitrary, so on a proxy with renamed deployments (my-claude-fast, bedrock-opus) both presets stay greyed out with "Missing: claude-haiku-4-5, ..." even though the whole Claude family is deployed

How it solves it:

• Preset models now also resolve against each deployment's underlying provider model ID (litellm_params.model, plus model_info.base_model where set) from /v2/model/info, joined on a normalized ID; the prefill always writes the admin's registered model_group spelling, never the preset's literal string

Relevant issues

• Presets from feat(ui): reorder Add Auto Router into name + template, with a collapsible detailed config #35746 become usable on proxies whose model names share no spelling with the preset's canonical model names
• Resolution is a three-arm chain: exact group name, dot/dash-normalized group name (both pre-existing), then the new normalized underlying-ID index
• A preset that resolved through deployments shows a "Matches your deployments" hint, sorts ahead of unavailable presets, and keeps the detailed configuration open after apply so the admin sees what got mapped

Linear ticket

Resolves LIT-5225

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Screenshots / Proof of Fix

Live rig: proxy on localhost:4000 with a dedicated Postgres and a config whose deployments are all renamed, so no model_group shares a spelling with a preset model

model_list:
  - model_name: my-claude-fast
    litellm_params: {model: anthropic/claude-haiku-4-5}
  - model_name: my-claude-mid
    litellm_params: {model: anthropic/claude-sonnet-5}
  - model_name: my-claude-frontier
    litellm_params: {model: anthropic/claude-fable-5}
  - model_name: bedrock-opus
    litellm_params: {model: bedrock/us.anthropic.claude-opus-5-v1:0}
  - model_name: team-gpt
    litellm_params: {model: openai/gpt-5.4}
  - model_name: team-gpt-mini
    litellm_params: {model: openai/gpt-5.4-mini}
  - model_name: team-gpt-nano
    litellm_params: {model: openai/gpt-5.4-nano}
  - model_name: my-o3
    litellm_params: {model: openai/o3}
  - model_name: openai-wild
    litellm_params: {model: openai/*}

Before (bundle built from the merge base, same rig): both preset options disabled; Anthropic Family shows "Missing: claude-fable-5, claude-haiku-4-5, claude-opus-5, claude-sonnet-5" and OpenAI Family shows "Missing: gpt-5.4, gpt-5.4-mini, gpt-5.4-nano, o3" in red

After (bundle built from this branch, same rig, same deployments): both presets enabled with a green "Matches your deployments" hint; applying Anthropic Family keeps the detailed configuration open and prefills Simple=my-claude-fast, Medium=my-claude-mid, Complex=bedrock-opus, Reasoning=my-claude-frontier; the created router stores only registered group names

$ curl -s http://localhost:4000/v2/model/info -H "Authorization: Bearer sk-1234" | jq '<the auto_router row>'
model_name: claude-family-router
model: auto_router/complexity_router
default: my-claude-mid
tiers: {"MEDIUM": ["my-claude-mid"], "SIMPLE": ["my-claude-fast"], "COMPLEX": ["bedrock-opus"], "REASONING": ["my-claude-frontier"]}
classifier: heuristic

Screenshots to be posted below

Type

🆕 New Feature

Changes

• lib/autorouter_presets.ts: ModelAvailability (group set + normalized underlying-ID index) replaces the bare Set<string> in every resolver signature; new buildModelAvailability, deploymentRefsFromModelInfo, and a normalization pipeline (provider prefix, vertex @ tag, region/vendor namespaces, bedrock -vN:M and throughput suffixes, date stamps, dot->dash, lowercase) with whole-name equality only
• add_auto_router_tab.tsx: the deployment list is fetched under the same autoRouterListKey cache entry AutoRoutersPanel already uses, so opening the dialog reuses the panel's data instead of a second paginated fan-out and writer invalidations reach it; a fetch failure degrades softly to group-name matching; preset options are memoized, sort available-first and label deployment matches; a deployment-resolved prefill keeps the details section expanded
• Submit-side validation (getReferencedModelsError) still checks group names only, byte-identical to before, so nothing new can pass validation that the router could not route
• useModels.ts: exports fetchAllModelDeployments, adds base_model to the deployment model_info type
• Tests: resolver matrix (bedrock/vertex/azure spellings, gpt-5.4 vs gpt-5.4-mini boundary in both directions, wildcard exclusion, deterministic tie-break, group-name precedence) plus component tests for the renamed-deployment flow, all with fixtures derived from the bundled preset JSON

What does not change: the edit modal (it has no preset flow), group-name matching semantics, wildcard deployments still satisfy nothing, and no backend endpoints are touched

QA runbook

1. cd ui/litellm-dashboard && npm run build, then rm -rf ../../litellm/proxy/_experimental/out && cp -R out ../../litellm/proxy/_experimental/out
2. Start a proxy with the config above (any renamed deployments covering one preset family work) and master_key: sk-1234, plus a dedicated DATABASE_URL
3. Log in at http://localhost:4000/ui/ (admin / sk-1234), go to Models + Endpoints, open the Auto-Routers tab, click Add Auto Router
4. Open the Template dropdown: both family presets should be enabled with a green "Matches your deployments" line; on the merge-base bundle they are greyed out with red "Missing:" lines
5. Pick Anthropic Family: the detailed configuration stays open and every tier shows your renamed group names, not the preset's canonical model names
6. Name it and click Add Auto Router, then confirm the created row's "Routes to" chips are your group names

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

---

Note

Medium Risk
New fuzzy matching on deployment IDs could mis-map similar model names if normalization is wrong, but submit still gates on registered group names and wildcards are excluded; scope is dashboard preset UX only with no backend changes.

Overview
Auto-router template presets can light up when the proxy only has renamed model_group names, by resolving preset model IDs against each deployment’s underlying provider model (litellm_params.model, base_model) from /v2/model/info, not only literal group-name matches.

In autorouter_presets, availability moves from a bare group Set to ModelAvailability (groups plus a normalized underlying-ID index). buildPresetPrefill writes the admin’s registered group names into tiers. Wildcard deployments are excluded from matching.

AddAutoRouterTab loads deployments via fetchAllModelDeployments under the same autoRouterListKey as the Auto Routers panel (shared React Query cache). Presets show “Matches your deployments”, sort available first, and keep detailed configuration expanded when mapping came from deployments. If the deployment fetch fails, preset checks fall back to group-name matching only; submit validation still requires tier models to exist as registered groups (unchanged routing semantics).

useModels exports fetchAllModelDeployments / autoRouterListKey and types model_info.base_model. AutoRoutersPanel passes userId into the add flow. Unit and component tests cover resolver edge cases and the renamed-deployment UX.

^{Reviewed by Cursor Bugbot for commit 842bb8e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[tin-berri]

bugbot run

[tin-berri]

@greptileai can you reply here with a score and why that score?

[greptile-apps]

Score: 4/5

The implementation is well-structured, thoroughly tested, and solves a real UX problem cleanly. Here's the breakdown:

What's strong:

• The normalization pipeline (normalizeUnderlyingModel) handles the full breadth of real-world spellings (bedrock regions, vertex @ tags, :0 revision suffixes, date stamps, [1m] context labels) without over-matching — whole-name equality only after stripping, which the gpt-5.4 vs gpt-5.4-mini boundary tests verify explicitly.
• The three-arm resolution chain is correctly ordered: exact group → normalized group → underlying index. Group name always wins, so a preset whose canonical name literally matches an admin's group name is unaffected.
• getReferencedModelsError and submit-side validation intentionally use groupsOnlyAvailability, not the full index. This is the right call — it means a deployment-matched prefill that passes initial validation can still fail if the underlying deployment disappears and the admin types in a canonical name that isn't a registered group.
• Wildcard exclusion is tested explicitly and the includes("*") guard is in normalizeUnderlyingModel rather than at the call site, so it can't be bypassed.
• Tie-breaking is deterministic (alphabetical) with a test. Without this, preset prefill could flicker between renders if the Map iteration order changed.

One concern worth noting:

In add_auto_router_tab.tsx, the sort on the preset options list calls presetAvailability twice per preset per render (once in the sort comparator, once in the map body). presetAvailability is a useCallback-memoized function but the sort itself isn't memoized — on every render the [...presets] slice is re-sorted, invoking the callback 2× per preset. With only two family presets this is negligible, but it's a minor inconsistency with the care taken elsewhere. A useMemo on the sorted list would be cleaner. That said, this is cosmetic given the preset count.

The real substance of the PR — the normalization logic, the resolution chain, the prefill semantics, and the test coverage — is solid. Nothing here blocks merge.

[greptile-apps]

Greptile Summary

This PR extends auto-router preset resolution so canonical preset model names can map to renamed deployment groups through underlying provider model IDs.

• Fetches deployment metadata alongside available model groups.
• Normalizes provider-specific underlying IDs and deterministically resolves them back to registered group names.
• Updates preset ordering, hints, prefill behavior, types, and focused component/library tests.

Confidence Score: 4/5

The deployment-fetch failure regression should be fixed before merging so the new optional matching path cannot disable presets that remain resolvable from model groups.

The core resolution logic is well tested, but coupling two independently fallible endpoints means an unavailable deployment metadata request now removes established group-name preset functionality; the added test comments also violate a repository requirement.

Files Needing Attention: ui/litellm-dashboard/src/components/add_model/add_auto_router_tab.tsx and the changed preset test files

Important Files Changed

Filename	Overview
ui/litellm-dashboard/src/components/add_model/add_auto_router_tab.tsx	Integrates deployment-backed preset availability and UI hints, but makes pre-existing group-only matching unavailable whenever the additional deployment request fails.
ui/litellm-dashboard/src/lib/autorouter_presets.ts	Adds normalized underlying-model indexing and registered-group resolution with wildcard exclusion and deterministic tie-breaking.
ui/litellm-dashboard/src/app/(dashboard)/hooks/models/useModels.ts	Exports the existing paginated deployment fetcher and extends its deployment metadata type with base_model.
ui/litellm-dashboard/src/components/add_model/add_auto_router_tab.test.tsx	Adds renamed-deployment integration coverage, but does not cover graceful fallback when only deployment metadata fails and adds comments contrary to repository policy.
ui/litellm-dashboard/src/lib/autorouter_presets.test.ts	Thoroughly exercises normalization and resolution boundaries, while adding several comments contrary to repository policy.

_{Reviews (1): Last reviewed commit: "feat(ui): match auto-router preset model..." | Re-trigger Greptile}

[tin-berri]

bugbot run

[tin-berri]

@greptileai can you reply here with a score and why that score?

[greptile-apps]

Score: 4/5

The implementation is logically sound and well-isolated. Here's the breakdown:

What's solid:

• The ModelAvailability abstraction cleanly replaces the bare Set<string> without breaking any existing interface
• Submit validation deliberately uses groupsOnlyAvailability — only registered group names can pass, never underlying provider model IDs. This is the correct security boundary
• Group-name match always wins over the deployment index (resolveAvailableModel checks exact → normalized → underlying, in that order)
• Wildcards are excluded at the normalization layer (model.includes("*") return null), not as an afterthought
• The .catch(() => []) fail-soft on deployment fetch means group-name matching always survives a deployment fetch failure — tested explicitly
• Normalization pipeline is correct across all documented spellings (Bedrock region+revision+:0, date stamps like -20250805, Vertex @tag, dotted versions, [1m] context labels)
• presets is a module-level constant so sortedPresetOptions doesn't create a new array reference on every render unnecessarily

What's worth flagging:

fetchAllModelDeployments(accessToken, "", userRole) passes an empty string for userId. Every other call site in the codebase (useAutoRouterModelGroups, useAutoRouters) passes the real userId! from useAuthorized(). The component doesn't receive userId as a prop, so the empty string is consistent with the existing fetchModelAccessGroups pattern in this same file — but if modelInfoCall uses userId for backend filtering, this call could return a different (or empty) result set than authenticated calls. The .catch(() => []) prevents a hard failure, but the deployment index could be silently empty even when deployments exist, making the feature a no-op for some configurations. The fix is straightforward: the component's AddAutoRouterTabProps should accept an optional userId prop, or the component should call useAuthorized() directly for the deployment fetch.

The normalization date-strip regex -20\d{6}$ is also somewhat brittle — 20 is hardcoded as a century prefix, so any future model name that coincidentally ends in a 6-digit number starting with 20 would be incorrectly stripped. Low practical risk but worth documenting.

Overall: UI-only, no backend changes, correct security boundary on submit, comprehensive test coverage of edge cases. The empty userId is the one concrete bug risk.

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 12440f0. Configure here.}

[tin-berri]

Addressed both flags from the last review in 1dbae33: userId is now threaded from AutoRoutersPanel into the deployment fetch, and the date-strip regex only matches real calendar dates with a boundary test pinning that. Also rebased onto latest litellm_internal_staging to clear the conflict with #35960, keeping its extracted getSubmitBlockedReason shape

[tin-berri]

bugbot run

[tin-berri]

@greptileai can you reply here with a score and why that score?

[greptile-apps]

Score: 4/5

Here's why:

What's done well:

1. Critical safety boundary is correct. Submit validation and getSubmitBlockedReason always use groupsOnlyAvailability — only registered group names can pass form validation. Deployment resolution only affects preset selection and prefill, which writes the admin's actual group names (e.g., my-claude-fast), not the preset's canonical strings. So nothing new can be submitted that the router couldn't route.

2. Soft failure on deployment fetch. fetchAllModelDeployments(...).catch(() => []) ensures group-name matching survives a deployment endpoint failure, not breaking existing behavior.

3. Wildcard and orphan guards. model.includes("*") return null in normalizeUnderlyingModel and the .filter(d => groups.has(d.modelGroup)) guard in buildModelAvailability are both correct.

4. Test coverage is strong. The normalization matrix (bedrock region+namespace+revision, date stamp, vertex @tag, 1m context label, dotted version), tie-breaking, group-name precedence over deployment index, and the full preset matrix test are all present and correct.

What brings it down from 5:

1. Variable name shadowing. The component-level const availability: ModelAvailability (~line 196) is shadowed inside the render map by sortedPresetOptions.map(({ preset, availability }) => ...) where the inner availability is a PresetAvailability. Different types, same name in adjacent scopes. Not a bug (both are used correctly), but will trip up future editors.

2. normalizeUnderlyingModel called on bare preset model names. In resolveAvailableModel, normalizeUnderlyingModel(requiredModel) is called on strings like claude-haiku-4-5 that have no provider prefix. The function handles it correctly (no-op path), but it was designed for provider-qualified strings — minor semantic mismatch.

3. buildModelAvailability index build is O(n²). The Array.from(keys, key => entries.filter(e => e.key === key)...) re-scans all entries for each unique key. Proxy configs are small so it won't matter in practice, but a single-pass Map accumulation would be cleaner.

None of these are blockers — the PR is well-reasoned and the safety properties are sound.

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 1dbae33. Configure here.}

[tin-berri]

Took both cleanups in b9688ea: the render map binds presetState so the ModelAvailability name is no longer shadowed, and buildModelAvailability now builds the index in a single pass. On the normalizer running over bare preset names, that is deliberate: both sides of the join go through one pipeline so the two spellings can never diverge, and the bare-name path is a no-op by construction

[tin-berri]

bugbot run

[tin-berri]

@greptileai can you reply here with a score and why that score?

[greptile-apps]

Score: 4/5

The implementation is solid and the design decisions are well-considered. Here's the breakdown:

---

What's good:

• Safety is preserved. Submit validation (getReferencedModelsError) still uses groupsOnlyAvailability — preset resolution through deployment IDs can unlock the UI, but the actual submitted config still must reference registered model groups. This is the right call.
• Graceful degradation. fetchAllModelDeployments failure is caught and reduces to [], so existing group-name matching continues working if the deployment fetch fails.
• Normalization logic is sound. The regex chain in normalizeUnderlyingModel handles Bedrock region/namespace/revision suffixes, Vertex @ tags, provider prefixes, date stamps, and version suffixes correctly. I traced the bedrock date-stamp case (us.anthropic.claude-opus-4-1-20250805-v1:0) through the pipeline and it resolves to claude-opus-4-1 as expected.
• Boundary tests for similar names. The gpt-5.4 vs gpt-5.4-mini and o3 vs o3-mini cases are explicitly tested, which is critical — over-stripping suffixes would cause false positive matches here.
• Test coverage is comprehensive. Provider prefix, Bedrock, Vertex, Azure, wildcard exclusion, deterministic tie-break, group-name precedence, full-preset-through-renamed-deployments — all covered.

---

What gives me pause (deductions):

1. Query key doesn't include userId or userRole — the query key is ["availableModels", "autoRouter", accessToken], but the query function now also calls fetchAllModelDeployments(accessToken, userId ?? "", userRole). If userId or userRole change without accessToken changing, React Query will serve stale deployment data. In practice this is stable per session, but it's a latent correctness gap.

2. The userId ?? "" fallback — passing an empty string as userId to fetchAllModelDeployments when userId is absent is a bit odd. It likely causes a failed fetch that's silently swallowed by .catch(() => []), which is fine functionally but obscures the intent. A comment or early-return guard when userId is falsy would be cleaner.

3. Normalization pipeline complexity — the regex chain in normalizeUnderlyingModel works for current model naming conventions, but it's fragile against new provider naming patterns (e.g., a future suffix that happens to match the date-stamp regex, or a namespace with more than two dots). The test matrix covers current known patterns well, but this will need to be extended as new model families are added.

---

The core feature is implemented correctly, the safety invariant is maintained, and the test suite is genuinely thorough. The minor issues above are low-risk but worth addressing before merge.

[tin-berri]

1f3df7a adds userId and userRole to the query key so the fetch can never serve stale data across an identity change. On the userId fallback: modelInfoCall accepts userID but never sends it (networking.tsx builds the query string from page, size and filters only), so an empty string cannot cause a failed fetch; the value is threaded for future-proofing, not correctness. On normalization fragility: the pipeline is whole-name equality after stripping, the tests derive from the bundled preset JSON, and a new family that needs another suffix rule fails visibly as a greyed-out preset rather than a wrong match

[tin-berri]

bugbot run

[tin-berri]

@greptileai can you reply here with a score and why that score?

[greptile-apps]

Score: 4/5

The implementation is solid. Here's the breakdown:

What's well done:

• The ModelAvailability abstraction cleanly separates group-name matching from deployment-index matching; the three-arm resolution chain (exact → normalized → underlying-ID index) is the right order.
• Security boundary is preserved: getReferencedModelsError and on-submit validation both use groupsOnlyAvailability (no deployment index). A false-positive preset match in the UI → user applies it → all tier models must still be registered group names for submit to succeed. The worst case is a confusing UX, not a routing error.
• Wildcard deployments are correctly excluded from the index.
• Tie-breaking via alphabetical sort is deterministic.
• Soft-fail on deployment fetch preserves group-name matching — correct failure mode.
• Test coverage is thorough: the it.each matrix over bedrock/vertex/azure spellings and the near-miss boundary tests (gpt-5.4 vs gpt-5.4-mini, o3 vs o3-mini) are exactly what this kind of normalization code needs.

What keeps it from 5/5:

1. Double-fetch of deployment data. The availableModels query now bundles a fetchAllModelDeployments call under a separate key (["availableModels", "autoRouter", accessToken, userId, userRole]), while useAutoRouters / AutoRoutersPanel also calls fetchAllModelDeployments under autoRouterListKey. The two cache entries are disjoint, so the dialog always fires a fresh paginated fan-out even if the parent panel already loaded the same data. For a large proxy this is a non-trivial waterfall of parallel modelInfoCalls. Reusing the autoRouterListKey namespace (or passing the already-loaded list down via props) would avoid this.

2. Date-stamp regex could over-strip unusual model names. -20\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])$ is tight enough for today's naming patterns, but it's a heuristic anchored at a hard-coded century prefix (20). A model like some-model-20991399 (a contrived future name) would be silently stripped. Since this only affects preset enablement (not routing correctness), the blast radius is small — but the comment explaining the tradeoff would be valuable here.

3. userId flows in as userId?: string | null through AddAutoRouterTabProps, then passed as userId ?? "" to fetchAllModelDeployments. An empty string is a valid userId value to modelInfoCall. Depending on how the backend interprets an empty userId, this could return an unexpectedly narrow or broad set of deployments. The soft-catch means a 4xx would be swallowed silently, so if the userId is truly missing the deployment index just stays empty — probably fine, but worth an explicit note.

Net: the logic is correct, the safety invariants are intact, and the test suite covers the right edge cases. The deduplication gap and the heuristic's implicit assumptions are the two things worth addressing before merge.

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

1 issue from previous review remains unresolved.

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 1f3df7a. Configure here.}

[tin-berri]

Closing out the last review's three points without further pushes since none changes the code. The 20991399 example is already a pinned negative test: "never lets some-model be satisfied by a deployment of prov/some-model-20991399" passes because the regex rejects month 13; nothing over-strips. The empty userId cannot narrow or broaden results because modelInfoCall never sends userID; its query string carries only page, size and filters. The dialog's fetch does duplicate the panel's deployment list; it is one paginated call per 1000 deployments on dialog open, and unifying the cache namespaces is a reasonable follow-up rather than a blocker

[devin-ai-integration]

QA: presets resolve against renamed deployments ✅

Tested the full Auto-Router preset flow on a proxy where every deployment is renamed so no model_name shares a spelling with any preset's canonical model names (my-claude-fast->anthropic/claude-haiku-4-5, bedrock-opus->bedrock/us.anthropic.claude-opus-5-v1:0, etc.). Before this PR both presets would grey out with red "Missing:" hints; now they light up and prefill the admin's registered group names.

The recording below opens on the renamed model list, adds a deployment through the Add Model UI (my-claude-fast -> claude-haiku-4-5) so the renamed names are visible first, then walks the preset flow through router creation.

Presets enabled + tiers prefilled with renamed groups

Both family presets show a green "Matches your deployments" line and are selectable:

Anthropic Family prefills the renamed groups, incl. bedrock-opus into Complex (resolved via underlying ...claude-opus-5-v1:0):

Created router's "Routes to" chips are the renamed groups:

Backend cross-check (/v2/model/info)

"complexity_router_config": {
  "tiers": {
    "SIMPLE": ["my-claude-fast"], "MEDIUM": ["my-claude-mid"],
    "COMPLEX": ["bedrock-opus"], "REASONING": ["my-claude-frontier"]
  }
},
"complexity_router_default_model": "my-claude-mid",
"model": "auto_router/complexity_router"

[tin-berri]

842bb8e batches two changes: the deployment fetch now shares AutoRoutersPanel's autoRouterListKey cache entry, so opening the dialog reuses already-loaded data and writer invalidations reach it, with the fail-soft moved out of the queryFn so an error cannot poison the shared entry; and deploymentRefsFromModelInfo reads base_model from litellm_params as well as model_info (LiteLLM_Params declares it and utils.py resolves it from there)

[tin-berri]

bugbot run

[tin-berri]

@greptileai can you reply here with a score and why that score?

[greptile-apps]

Score: 4/5

---

What's strong here:

• Pure UI change, no backend. No auth changes, no DB changes, no new endpoints — blast radius is confined to the Add Auto Router dialog.
• Security boundary is preserved correctly. The submit-side validation (getReferencedModelsError, getSubmitBlockedReason) uses groupsOnlyAvailability (group names only), not availability. This means deployment-matched names only get you into the prefill — the router always stores registered group names, and validation checks those same names. The routing semantics are unchanged.
• Soft failure path is correct. If the deployment fetch fails, deployments stays undefined, deploymentRefsFromModelInfo([]) returns [], and buildModelAvailability builds from group names only — pre-existing behavior.
• Normalization pipeline is tested well. The bedrock region+namespace+revision, date stamps, Vertex @tag, bracket labels, and the gpt-5.4 vs gpt-5.4-mini boundary tests all look correct. Whole-name equality (no substring matching) keeps false positives out.
• Cache reuse is smart. Using autoRouterListKey shares the cache entry AutoRoutersPanel already populated — no redundant fan-out in the happy path.
• Test coverage is comprehensive — resolver matrix, component flow with renamed deployments, soft-failure fallback, wildcard exclusion, tie-breaking, ordering.

---

Minor concerns holding it from 5/5:

1. userId ?? "" — AddAutoRouterTab receives userId as an optional prop and falls back to "". If the parent ever omits it, the cache key won't match the one built by useAutoRouters (which uses useAuthorized() context), so the "reuse panel data" optimization silently degrades to a second fetch. It won't break, but the intended optimization is fragile.

2. modelsLoading = groupsLoading || deploymentsLoading — fetchAllModelDeployments does a multi-page fan-out (up to totalPages concurrent requests). For an uncached first open the dialog blocks on all of that. In the common case (page already rendered AutoRoutersPanel and warmed the cache) this is fine, but cold opens with large model lists could feel slower than before.

3. Normalization pipeline complexity — the regex chain is correct for documented cases (and tests cover them), but it's narrow: only one strip of each suffix type per pass. A hypothetical model-name-20250805-v1:0-v2:0 would leave -v2:0 behind. Unlikely in practice given current naming conventions, but worth a comment acknowledging the single-pass assumption.

None of these are blockers — the implementation is solid and the right design choices were made throughout.

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 842bb8e. Configure here.}

[tin-berri]

Standing pat on these three since none changes behavior. The only mount site (AutoRoutersPanel) passes userId, and an omitted userId degrades to one extra fetch rather than breakage. The cold-open wait matches what the dialog always did before the cache sharing; the warm path is now strictly faster. The double-suffix example does not occur in any provider's naming today and the failure mode is a greyed-out preset, never a wrong match