build: raise requires-python cap to <3.15 so Python 3.14 installs current releases

[ryan-crabbe-berri]

Relevant issues

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

Before (at base commit a643dd0): pip on Python 3.14 silently falls back to litellm 1.83.7, a pre-April release whose old auth flow fails with 400s, because every release since 1.84.0 carries requires-python = ">=3.10, <3.14"

$ python3.14 -m pip install --dry-run litellm
Would install ... litellm-1.83.7 ... openai-2.30.0 ...

After (captured at 2c74553, re-verified at 1923917): the full dependency tree resolves and installs on 3.14

$ uv sync --python 3.14 --no-install-project --no-install-workspace --all-extras
Resolved 420 packages ...
 + websockets==15.0.1
 + werkzeug==3.1.8
 ...

Imports work on 3.14.5, with the rust bridge falling back to pure python as designed:

$ .venv/bin/python3 --version
Python 3.14.5
$ PYTHONPATH=. .venv/bin/python3 -c "
import litellm
print('import litellm OK')
from litellm.rust_bridge import native_bridge_available
print('native bridge available:', native_bridge_available())
import litellm.proxy.proxy_server
print('proxy_server importable')
"
import litellm OK
native bridge available: False
proxy_server importable

Real provider calls (no mocks, real Groq API) succeed on 3.14.5, sync, async, and streaming:

$ PYTHONPATH=. .venv/bin/python3 -c "
import litellm, asyncio
m='groq/llama-3.3-70b-versatile'
r = litellm.completion(model=m, messages=[{'role':'user','content':'Say OK'}], max_tokens=20)
print('response:', r.choices[0].message.content)
r2 = asyncio.run(litellm.acompletion(model=m, messages=[{'role':'user','content':'Say hi'}], max_tokens=20))
print('async response:', r2.choices[0].message.content)
async def stream():
    resp = await litellm.acompletion(model=m, messages=[{'role':'user','content':'Count to 3'}], max_tokens=30, stream=True)
    return ''.join([(c.choices[0].delta.content or '') async for c in resp])
print('stream response:', asyncio.run(stream()))
"
response: OK
async response: Hi! How can I assist you today?
stream response: 1, 2, 3

Unit test suite on 3.14.5 (captured at 2c74553):

$ PYTHONPATH=. .venv/bin/python3 -m pytest tests/test_litellm/litellm_core_utils -q -n 4
1338 passed, 1 skipped, 310 warnings in 13.08s

Type

🐛 Bug Fix
🚄 Infrastructure

Changes

requires-python moves from ">=3.10, <3.14" to ">=3.10, <3.15", admitting Python 3.14 while keeping the window bounded at the newest minor we have verified. The <3.14 cap was added in d9a4602 (April 10) because no deps shipped 3.14 wheels and uv could not resolve the 3.14 split; both reasons are gone. The deps that still lack 3.14 support were already gated behind python_version < '3.14' markers (redisvl, semantic-router, aurelio-sdk, pypdf, openapi-core), and uv lock resolves the widened range in under a second

ddtrace gets a version split in the proxy-runtime extra: the existing >=2.19,<3.0 band below 3.14 (unchanged behavior), and >=4.0,<5.0 on 3.14+ where the 2.x line has no cp314 wheels and its sdist no longer builds. Every ddtrace 4.x release ships cp314 wheels, and the band stays within a single major, matching the convention of the 2.x band

uv.lock is re-locked for the wider python range

Known limitation, split into follow-up work: the pyo3 rust bridge (pyo3 0.23.5) cannot compile against 3.14, so cp314 wheels cannot be published until pyo3 is bumped to at least 0.26 and cp314 is added to the release wheel matrix. This does not affect this PR's CI (all jobs run 3.11-3.13) and does not affect 3.14 users at runtime since litellm/rust_bridge/loader.py falls back to pure python when the native module is absent. Until the wheels exist, a 3.14 pip install builds from sdist and needs a rust toolchain; that is a visible, actionable error instead of today's silent downgrade to 1.83.7

On tests: this is a packaging metadata change with no unit-testable surface; the meaningful check is the real-traffic proof above plus the existing CircleCI installing_litellm_on_python_3_13 style install job, which should gain a 3.14 twin once the pyo3 follow-up lands (today it would fail on the maturin build step)

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

[greptile-apps]

Greptile Summary

This PR widens the requires-python constraint from <3.14 to <3.15, enabling Python 3.14 users to install current litellm releases instead of silently falling back to pre-April 1.83.7 builds. It also adds a version-split for ddtrace in the proxy-runtime extra, keeping 2.x for Python < 3.14 (unchanged) and adding a 4.x band for Python ≥ 3.14 where only 4.x ships cp314 wheels.

• requires-python moves from ">=3.10, <3.14" to ">=3.10, <3.15", the minimum change needed to admit Python 3.14.
• ddtrace gains a PEP 508 environment marker split: >=2.19.0,<3.0; python_version < '3.14' (existing behavior) and >=4.0.0,<5.0; python_version >= '3.14' (new, single-major band matching the 2.x convention), resolving the previous review finding about the range spanning two majors.
• uv.lock is re-resolved for the wider range; deps still lacking 3.14 support (redisvl, pypdf, etc.) were already gated with pre-existing python_version < '3.14' markers.

Confidence Score: 5/5

Safe to merge — a minimal packaging metadata change with real-traffic validation on Python 3.14.5 and no changes to runtime logic.

The only changed files are pyproject.toml (two dependency lines) and the generated uv.lock. The ddtrace 4.x split is narrow, stays within a single major, and the litellm ddtrace integration code uses defensive try/except and getattr patterns that tolerate API drift. The widened requires-python cap was verified with live Groq API calls, streaming, and the existing unit-test suite on 3.14.5. No runtime logic was touched.

No files require special attention.

Important Files Changed

Filename	Overview
pyproject.toml	requires-python widened from <3.14 to <3.15; ddtrace split into a 2.x band for Python <3.14 and a 4.x band for Python >=3.14 with correct PEP 508 markers
uv.lock	Re-locked by uv for the expanded Python range; generated artifact, no manual review needed

_{Reviews (2): Last reviewed commit: "build: cap requires-python at <3.15 and ..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_python_3_14_uncap (1923917) with litellm_internal_staging (f1f33f5)}

[ryan-crabbe-berri]

@greptileai

[mateo-berri]

LGTM; thanks!