Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

Starting in v1.83.1, litellm pins exact versions (==) for most of its core runtime dependencies in pyproject.toml. This was introduced in PR #24905 "[Infra] Pin All Docker Build Dependencies", merged 2026-04-01.

While the stated intent was to pin Docker build dependencies, the pins were placed in pyproject.toml, which affects every downstream consumer of litellm as a library — not just your own Docker images. This forces aggressive downgrades of common libraries (pydantic, openai, aiohttp, click, jsonschema, python-dotenv, importlib-metadata, etc.) and makes litellm very painful to coexist with in any non-trivial project.

Reproduction

Fresh project, upgrading from 1.83.0 → 1.83.10:

$ uv add 'litellm>=1.83.8'
Uninstalled 10 packages
Installed 10 packages
 - aiohttp==3.13.5            + aiohttp==3.13.3
 - click==8.3.2               + click==8.1.8
 - importlib-metadata==9.0.0  + importlib-metadata==8.5.0
 - jsonschema==4.26.0         + jsonschema==4.23.0
 - litellm==1.83.0            + litellm==1.83.10
 - openai==2.32.0             + openai==2.24.0
 - pydantic==2.13.2           + pydantic==2.12.5
 - pydantic-core==2.46.2      + pydantic-core==2.41.5
 - python-dotenv==1.2.2       + python-dotenv==1.0.1
 - typer==0.24.1              + typer==0.23.1

Every downgraded package matches litellm's pin exactly. pydantic-core follows pydantic, and typer is dragged down by the click==8.1.8 pin.

What changed

v1.82.6 / v1.83.0 (ranges — good):

aiohttp>=3.10
click
openai>=2.8.0
pydantic<3.0.0,>=2.5.0

v1.83.1 onwards (exact pins — problematic):

aiohttp==3.13.5
click==8.1.8
openai==2.30.0
pydantic==2.12.5
...

Also, these pins move every release — e.g. openai==2.30.0 in 1.83.1 has since been rolled back to openai==2.24.0 in 1.83.10 — so each litellm upgrade churns a different set of peer versions.

Why this is a problem

1. Libraries should express compatibility, not lock environments. Exact pins belong in application lockfiles (uv.lock, poetry.lock, requirements.txt) or Docker constraint files — not in a library's pyproject.toml. The standard guidance from both the Python Packaging Authority and Poetry/uv/pip maintainers is that libraries should use ranges.

2. Forces downgrades on any shared dep. Projects using pydantic 2.13, openai 2.32, click 8.3, etc. — all current stable releases — are forced backwards just to use litellm.

3. Creates dependency deadlocks. Any other library that requires something newer than litellm's pin (e.g. pydantic>=2.13) becomes uninstallable alongside litellm. This is already happening — the ecosystem is moving faster than litellm's pin updates.

4. The litellm team is already feeling the pain. The commit log right after #24905 shows:

   • "Fix pyproject.toml pins for Poetry Python 3.9 compatibility"
   • "Merge main and resolve dependency pin conflicts"
   • "Remove unused aioboto3 dependency and botocore conflict workarounds"
   • "Revert cryptography to 43.0.3 in pyproject.toml for Python 3.9.0/3.9.1 compat"

   These are all downstream effects of putting exact pins where they don't belong.

Suggested fix

Move the exact pins out of pyproject.toml and into one of:

• A constraints.txt used by Docker builds (pip install -c constraints.txt ...)
• A Poetry/uv lockfile committed alongside the Dockerfile
• A separate requirements-docker.txt

And restore range-based specs in pyproject.toml, similar to 1.83.0:

pydantic>=2.5,<3
openai>=2.8
aiohttp>=3.10
click>=8
...

This preserves reproducible Docker builds (the original goal of #24905) without breaking every downstream consumer.

Environment

• litellm 1.83.0 → 1.83.10

References

• PR that introduced the pins: #24905
• Version bump PR: #25054 (1.83.0 → 1.83.1)
• PyPA guidance on abstract vs concrete dependencies

Steps to Reproduce

Relevant log output

What part of LiteLLM is this about?

No response

What LiteLLM version are you on ?

1.83.10

Twitter / LinkedIn details

No response