Relevant issues

N/A

Linear ticket

Pre-Submission checklist

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

• I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

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

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Screenshots / Proof of Fix

Verification against a proxy with two teams (team A with 3 virtual keys, team B with 0):

```

1. /v2/team/list?team_id=<team_a> (single-team filter)
   {
   "team_id": "f2eabc73-ac0b-4885-8871-4b30226a2336",
   "team_alias": "verify-keys-count-A-...",
   "members_count": 1,
   "keys_count": 3
   }

2. /v2/team/list (full page, both teams visible)
   {
   "team_id": "2419f752-...",
   "team_alias": "verify-keys-count-B-...",
   "keys_count": 0
   }
   {
   "team_id": "f2eabc73-...",
   "team_alias": "verify-keys-count-A-...",
   "keys_count": 3
   }
   ```

Before this change, `/v2/team/list` did not expose any per-team key count, so the Teams page Resources badge (which fell back to `team.keys.length`) always rendered `0 Keys` — even on teams that owned virtual keys (the per-team detail Virtual Keys tab was unaffected since it uses `/key/list?team_id=…`).

Type

🐛 Bug Fix

Changes

• Add `keys_count: int = 0` to `TeamListItem` so the paginated team-list response carries an authoritative per-team key count.
• Populate `keys_count` in `list_team_v2` via a single batched Prisma `group_by` against `LiteLLM_VerificationToken` for the current page's team IDs. The `IN` clause is bounded by `page_size` and uses the existing `@@index([team_id])`, so this is one DB round-trip per page (cheaper than the legacy `/team/list`'s per-team N+1 `find_many`).
• Thread an optional `keys_count_by_team` map through `_convert_teams_to_response_models`; the existing caller's behavior is unchanged (default empty → `0` for all teams). The deleted-table branch is skipped — `LiteLLM_DeletedTeamTable` does not carry `keys_count`.
• UI (Teams list): read `keys_count` from the v2 payload for the Resources column's keys badge, with a `keys.length` fallback for backwards compatibility. Touches `OldTeams.tsx`, `TeamsView.tsx`, `TeamsTable.tsx`, and the shared `Team` interface in `key_list.tsx`.
• UI (delete-team modal): switch the "Warning: this team has N keys" banner and the resource-information row to read `keys_count`, restoring the keys-warning variant that was no longer firing after the v2 migration.
• Tests:
  • `tests/test_litellm/proxy/management_endpoints/test_team_endpoints.py` — 3 new async tests covering the happy path (`keys_count` populated from the batched group_by), the empty-page short-circuit (no group_by issued), and the deleted-status branch (no group_by issued). Existing `list_team_v2` tests get a `litellm_verificationtoken.group_by` stub so they don't trip on the new call.
  • `ui/litellm-dashboard/src/components/OldTeams.test.tsx` — 2 new render tests asserting the Resources badge picks up `keys_count` from the v2 payload and falls back to `keys.length` when absent.