feat(ui): deployment affinity toggle for the auto-router

[tin-berri]

TLDR

Problem this solves:

• The auto-router's deployment_affinity flag shipped in feat(router): independent, default-on deployment affinity for the auto-router #36146 default-on with no dashboard control, so opting a router out was config-file or raw API only
• Session affinity sat alone in its own Advanced panel while the two affinity knobs are one concept operators reason about together

How it solves it:

• Renames the panel to Advanced: Affinity and puts both switches in it, deployment affinity first (default on) with session affinity below it
• Both payload builders always write deployment_affinity, matching the session_affinity contract; the edit modal hydrates the stored value and manages the key, so a stored false survives an untouched save
• Presets and the routing-test modal flow through the same single builder, so they inherit the default with no per-preset edits

User Flow

Before: an operator who wants one auto-router load-balanced across a group's deployments has no way to do it from the dashboard

1. They open http://localhost:4000/ui/?page=llm-playground, then Models & Endpoints, Add Model, Auto Router
2. They expand Detailed Configuration and every Advanced panel: no deployment affinity control exists anywhere
3. Their router pins sessions to deployments (the backend default) and the only opt-out is hand-editing deployment_affinity: false into the config YAML

After: the toggle is in the form, prefilled with what the router will actually do

1. They open the same Add Model, Auto Router flow and expand Detailed Configuration, then Advanced: Affinity
2. The panel shows "Pin a session to one deployment per model group" already on, and "Pin a session to its first model" off, mirroring both backend defaults
3. They switch deployment affinity off and create the router; the stored config carries deployment_affinity: false
4. Editing that router later shows the switch off, and saving without touching it keeps false

Relevant issues

• Dashboard follow-up to feat(router): independent, default-on deployment affinity for the auto-router #36146, which added the backend flag and its default
• One shared component serves both the add tab and the edit modal, so the section renders identically in both flows

Linear ticket

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)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

UI change, so screenshots to follow this ordered list (proxy on :4000, dashboard dev server on :3000 via npm run dev in ui/litellm-dashboard)

1. Models & Endpoints, Add Model, select Auto Router, expand Detailed Configuration, open Advanced: Affinity: deployment switch on, session switch off
2. Toggle deployment affinity off, create the router, then confirm on the model's raw config that complexity_router_config.deployment_affinity is false
3. Open Edit Auto Router on that router: the deployment switch renders off; click Save Changes without touching anything, re-open, still off
4. Create a second router from the Claude Code preset without touching the panel and confirm its config carries deployment_affinity: true

Type

🆕 New Feature

Changes

• ComplexityRouterConfig.tsx: panel renamed Advanced: Affinity, deployment switch added above the session switch, DEFAULT_DEPLOYMENT_AFFINITY = true exported as the single default owner
• Both payload builders write the key unconditionally; the builder param is non-optional so the compiler forces every call site
• Edit modal: deployment_affinity added to the managed keys and hydrated in initializeForm, the pair that keeps a stored false from being silently rewritten to the default on an untouched save
• buildPresetPrefill hydrates the key so a future preset can express a non-default; the preset JSON is unchanged and inherits the default
• Tests: builder four-case matrices in both builders' suites, untouched-save regression in the modal, default-carry and toggle-off-carry in the add tab, and the shared component's first affinity panel tests. The hydration mutation is killed by the untouched-save test

QA runbook

1. npm run dev in ui/litellm-dashboard against a proxy running the current staging build
2. Walk the four screenshot steps above
3. npx vitest run src/components/add_model/ src/components/edit_auto_router/ src/lib/autorouter_presets.test.ts inside ui/litellm-dashboard: 350 tests

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

Low Risk
Dashboard-only wiring for an existing router flag; behavior changes only when an operator toggles the new control or saves configs through the updated builders.

Overview
Adds dashboard control for deployment_affinity on complexity auto-routers (backend default on), which previously had no UI.

The Advanced: Affinity panel (renamed from Session Affinity) now has two switches: pin a session to one deployment per model group (default on) above pin a session to its first model (default off). Create and edit flows always persist deployment_affinity in complexity_router_config, with hydration and managed-key handling so stored false survives an untouched save.

Bundled Anthropic/OpenAI presets set deployment_affinity: true explicitly; preset prefill uses the same default when the key is omitted.

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

[tin-berri]

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

[tin-berri]

bugbot run

[greptile-apps]

Score: 4.5/5

What's done well:

• The change is tightly scoped — one new flag, one shared constant, consistent propagation through both the add and edit flows
• DEFAULT_DEPLOYMENT_AFFINITY is the single source of truth; every consumer imports it rather than inlining true
• The "untouched save preserves false" regression test directly kills the hydration/default-override bug that would have been easy to miss
• MANAGED_COMPLEXITY_ROUTER_KEYS is updated, so the edit modal won't silently strip the key on round-trip
• Test matrix is thorough: both builders, both UI flows, and the shared component's first affinity panel tests

Minor issues that keep it from 5/5:

1. Indentation inconsistency in test fixtures — in edit_auto_router_modal.test.ts the two new deployment_affinity: true lines are indented with 6 spaces while the surrounding object uses 2-space indentation. Won't break anything but it's a formatting inconsistency in committed test code.

2. Third buildUpdatedComplexityRouterConfig deployment affinity test is slightly misleading — the description says "re-asserts the backend's on-by-default when the form value is absent, rather than dropping the key", but what actually happens is the form value is absent so the ?? DEFAULT_DEPLOYMENT_AFFINITY fallback fires, overwriting the stored false with true. That's the intended behavior but the test name doesn't make the "form wins over stored" semantic explicit, which could confuse a future reader.

3. Session affinity copy update may be inaccurate — the updated description says "Always pins the deployment too, even with the deployment toggle off." If the backend from feat(router): independent, default-on deployment affinity for the auto-router #36146 actually ignores deployment_affinity when session_affinity: true regardless of what the client sends, that copy is correct. But if that's not the backend behavior, the UI is documenting a false constraint. Worth a quick sanity check against the backend implementation.

[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 c1fc6bf. Configure here.}

[greptile-apps]

Greptile Summary

Adds dashboard controls for auto-router deployment affinity and groups both affinity settings in one advanced panel

• Carries deployment affinity through create, preset, routing-test, and edit payload flows
• Hydrates stored values while matching the backend's default-on behavior
• Adds component, builder, create-flow, and untouched-edit regression tests

Confidence Score: 5/5

The PR appears safe to merge, with deployment affinity consistently represented across the dashboard's create, preset, test, and edit flows

Stored false values survive hydration and untouched saves, omitted values match the backend default, and all shared builder callers propagate the setting without stripping or overriding it

Important Files Changed

Filename	Overview
ui/litellm-dashboard/src/components/add_model/ComplexityRouterConfig.tsx	Adds the deployment-affinity switch with backend-aligned defaults and accurately describes its interaction with session affinity
ui/litellm-dashboard/src/components/add_model/add_auto_router_tab.tsx	Propagates the form value or backend-aligned default into the shared create and routing-test configuration
ui/litellm-dashboard/src/components/add_model/build_complexity_router_config.ts	Makes deployment affinity a required builder input and writes it unconditionally into generated payloads
ui/litellm-dashboard/src/components/edit_auto_router/edit_auto_router_modal.tsx	Hydrates, manages, and persists deployment affinity while correctly preserving stored false values
ui/litellm-dashboard/src/lib/autorouter_presets.ts	Carries explicit preset values and applies the backend default when presets omit deployment affinity
ui/litellm-dashboard/src/components/edit_auto_router/edit_auto_router_modal.test.tsx	Covers default hydration, stored-false preservation, and toggle-off persistence through the modal save flow

_{Reviews (1): Last reviewed commit: "feat(ui): deployment affinity toggle for..." | Re-trigger Greptile}

[tin-berri]

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

[tin-berri]

bugbot run

[greptile-apps]

Score: 4.8/5

This is a well-executed, focused PR. Here's the breakdown:

What's strong:

• Correctness is solid. Both payload builders emit deployment_affinity unconditionally (same contract as session_affinity), the edit modal hydrates and adds the key to MANAGED_COMPLEXITY_ROUTER_KEYS, and initializeForm uses a type-checked boolean guard — all three together close the "stored false silently rewritten to default on untouched save" regression.
• Test coverage is thorough. The four-case matrix for both builders, the untouched-save regression test, the shared component render tests, and the add-tab integration tests are exactly what this change warrants. The test descriptions are precise and map directly to real customer scenarios.
• Single source of truth. DEFAULT_DEPLOYMENT_AFFINITY = true exported from ComplexityRouterConfig.tsx and consumed everywhere else means the backend default is declared exactly once.
• Scope discipline. Dashboard-only; no auth, routing, or backend logic touched.

Minor deductions:

• The third test in buildUpdatedComplexityRouterConfig deployment affinity is named "re-asserts the backend's on-by-default when the form value is absent, rather than dropping the key" but it's actually testing a case where FORM_VALUE has no deployment_affinity key and a stored false gets overwritten by the default. This is intentional behavior (form drives the payload), but an operator who edits an unrelated field could silently lose their false if the UI failed to hydrate correctly — the test name should clarify it's a "form wins" contract, not a pure default-fill. This is mitigated by the edit modal's correct hydration, but the description is misleading.
• build_complexity_router_config.test.ts adds deploymentAffinity: true to baseParams but doesn't add a false case the way the session affinity suite does — minor coverage gap, not a blocker.

[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 6503853. Configure here.}

[tin-berri]

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

[tin-berri]

bugbot run

[greptile-apps]

Score: 5/5

This is a clean, well-scoped dashboard feature with no issues worth blocking on.

Why 5:

• Correctness: The deployment_affinity key is always written unconditionally (non-optional in the builder param), matching the session_affinity contract. The ?? fallback in both the create and edit paths uses the exported DEFAULT_DEPLOYMENT_AFFINITY = true, so the backend default is the single source of truth in one place.

• Regression safety: The untouched-save test in EditAutoRouterModal directly exercises the case where deployment_affinity: false survives a round-trip without being clobbered by the default — the exact footgun this kind of hydration is prone to.

• MANAGED_COMPLEXITY_ROUTER_KEYS: deployment_affinity is added to the set in edit_auto_router_modal.tsx, which is what prevents the key from being silently dropped during a partial save. That's the right place for it.

• Test coverage: Four-case matrices in both builder suites, three-case modal suite for the new toggle, add-tab default/toggle-off cases, and the shared component's first affinity panel tests. The edge cases (stored false survives untouched save, absent key hydrates to default) are explicitly covered.

• Scope: Purely dashboard plumbing; no backend changes, no SDK surface touched, no migration concerns.

[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 a29c6d1. Configure here.}