bump: version 1.96.1 → 1.96.2 (1.96.1 burned by the PyPI storage failure)

[yuneng-berri]

Bumps stable/1.96.x from 1.96.1 → 1.96.2. No code changes — version only.

Why

The v1.96.1 release run exhausted the PyPI project storage quota partway
through the upload, so 1.96.1 is now a permanently incomplete release:

Surface	State
PyPI litellm==1.96.1	4 of 36 files (only cp310 × 4 platforms, uploaded 2026-08-11 02:31–02:32Z) — no sdist, no cp311–cp314
PyPI litellm==1.96.0 (reference)	36 files
DockerHub litellm/litellm:v1.96.1	absent (404)
GHCR ghcr.io/berriai/litellm:v1.96.1	absent
git tag v1.96.1	absent
branch release/v1.96.1	absent

PyPI filenames are immutable — the 4 uploaded files can never be replaced. Strictly
speaking the 32 missing files could still be pushed under 1.96.1 (the publish
steps run skip-existing: true, so a re-run would fill the gaps rather than error),
but that would ship a stable version whose artifacts come from two different builds
days apart, with no guarantee the rebuilt wheels match the four already on the index.
That's not something to do to a stable release. Treating 1.96.1 as burned and
moving to 1.96.2 is the clean call.

Nothing downstream consumed 1.96.1 (no image, no tag, no release branch), so the
bump skips nothing and strands nothing.

What's in here

Same two-commit shape as the 1.96.1 bump on this line:

• bump: version 1.96.1 → 1.96.2 — pyproject.toml only ([project].version +
  [tool.commitizen].version), produced by cz bump --increment PATCH
• chore: refresh uv.lock for 1.96.2 — uv lock run with the line's own uv pin
  (0.11.7, per Dockerfile UV_IMAGE)

Total diff: 4 lines across 2 files. The lock refresh moved only the project's
own entry (litellm 1.96.1 → 1.96.2) plus the rolling exclude-newer timestamp
— no third-party package version moved, and revision = 3 / format fields are
unchanged. No git tag was created (tagging is release.yml's job).

Subpackages: not bumped, and that's correct

litellm-enterprise (0.1.53) and litellm-proxy-extras (0.4.81) are unchanged
on this line and are already fully published on PyPI (2 files each, from
2026-08-03 and 2026-07-29 respectively — i.e. before the failed run, not casualties
of it). The publish workflows use skip-existing: true, so re-publishing them at
1.96.2 is a no-op rather than an error.

Before re-running the release

The storage quota that killed the run is not addressed by this PR. If the PyPI
project limit is still exhausted, 1.96.2 will fail exactly the same way and burn
another version — confirm the quota has been raised before dispatching.

[greptile-apps]

Greptile Summary

This PR advances the LiteLLM release version from 1.96.1 to 1.96.2 after the incomplete 1.96.1 publication.

• Updates both root version declarations in pyproject.toml.
• Refreshes the editable root package version and generated cutoff timestamp in uv.lock.
• Leaves independently versioned workspace packages and all third-party dependency versions unchanged.

Confidence Score: 5/5

The PR appears safe to merge because the release version is consistently updated and the lockfile remains coordinated with the project metadata.

The changed manifests agree on version 1.96.2, independently versioned workspace packages require no coordinated bump, and frozen installations continue using the same pinned third-party dependencies.

Important Files Changed

Filename	Overview
pyproject.toml	Consistently updates the project and Commitizen versions to 1.96.2 without changing dependencies or package behavior.
uv.lock	Updates the editable LiteLLM package to 1.96.2 and refreshes expected lock-generation metadata without moving third-party packages.

_{Reviews (1): Last reviewed commit: "chore: refresh uv.lock for 1.96.2" | Re-trigger Greptile}