* build: migrate packaging metadata to uv * ci: move automation and local tooling to uv * docker: migrate image builds and runtime setup to uv * docs: update install and deployment guidance for uv * chore: align auxiliary scripts and tests with uv * test: harden test_litellm isolation * fix: keep release and health check images self-contained * build: pin uv tooling and health check deps * test: isolate bedrock image request formatting from suite state * test: cover sandbox executor requirements flow * ci: fix circleci no-op command steps * ci: fix circleci publish workflow parsing * fix: stabilize remaining uv migration CI checks * ci: increase matrix test timeout headroom * fix: restore published docker and license coverage * fix: restore proxy runtime build parity * fix: restore proxy extras parity and venv migrations * ci: persist uv path across circleci steps * fix: keep psycopg binary in default test env * docker: preserve prisma cache across stages * test: run local proxy checks through uv python * build: restore runtime deps moved into ci * build: refresh uv lock after upstream merge * fix: restore module import in test_check_migration after merge The conflict resolution imported only the function but the test body references check_migration as a module throughout. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: revert dependency promotions, remove nodejs-wheel-binaries, fix Docker layer caching - Move google-generativeai, Pillow, tenacity back to ci group (they are lazily imported and bloat the base SDK install needlessly) - Remove nodejs-wheel-binaries from extra_proxy and proxy-dev (redundant in Docker where system Node.js is already installed via apk) - Remove all nodejs-wheel node replacement and venv npm patching blocks from Dockerfiles since the wheel is no longer installed - Add --no-default-groups to CodSpeed benchmark workflow so the benchmark environment matches the old minimal pip install footprint - Apply standard uv two-phase Docker pattern: copy metadata first, install deps (cached layer), then copy source and install project - Replace CircleCI enterprise no-op with proper uv sync command Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: regenerate uv.lock after removing nodejs-wheel-binaries Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(ci): use cache/restore instead of cache to prevent cache poisoning The old workflow used actions/cache/restore (read-only). The uv migration changed it to actions/cache (read-write), which zizmor flags as a cache poisoning risk. Restore the safer read-only variant. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(ci): disable setup-uv built-in cache to silence cache-poisoning alert The setup-uv action enables caching by default, which zizmor flags as a cache poisoning risk. Disable it since we already use a read-only cache/restore step. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(ci): disable setup-uv cache in publish workflow Silences zizmor cache-poisoning alert. Publishing workflow runs infrequently on protected branches so caching adds no real benefit. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(test): remove duplicate verbose_logger mock in test_check_migration The logger was patched twice — first via mocker.patch() then via mocker.patch.object(autospec=True). The second call fails because autospec cannot inspect an already-mocked attribute. Remove the redundant first patch. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(ci): free disk space before Docker build in test-server-root-path The Dockerfile.non_root build ran out of disk on the CI runner. Remove Android SDK, .NET, Boost, and GHC toolchains (~12GB) to free space. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
9.6 KiB
Contributing to LiteLLM
Thank you for your interest in contributing to LiteLLM! We welcome contributions of all kinds - from bug fixes and documentation improvements to new features and integrations.
Checklist before submitting a PR
Here are the core requirements for any PR submitted to LiteLLM:
- Sign the Contributor License Agreement (CLA) - see details
- Keep scope isolated - Your changes should address 1 specific problem at a time
Proxy (Backend) PRs
- Add testing - Adding at least 1 test is a hard requirement - see details
- Ensure your PR passes all checks:
- Unit Tests -
make test-unit - Linting / Formatting -
make lint
- Unit Tests -
UI PRs
- Ensure the UI builds successfully -
npm run build - Ensure all UI unit tests pass -
npm run test - Add tests for new components or logic - If you are adding a new component or new logic, add corresponding tests
Contributor License Agreement (CLA)
Before contributing code to LiteLLM, you must sign our Contributor License Agreement (CLA). This is a legal requirement for all contributions to be merged into the main repository.
Important: We strongly recommend reviewing and signing the CLA before starting work on your contribution to avoid any delays in the PR process.
Quick Start
1. Setup Your Local Development Environment
# Fork the repository on GitHub (click the Fork button at https://github.com/BerriAI/litellm)
# Then clone your fork locally
git clone https://github.com/YOUR_USERNAME/litellm.git
cd litellm
# Create a new branch for your feature
git checkout -b your-feature-branch
# Install development dependencies
make install-dev
# Verify your setup works
make help
That's it! Your local development environment is ready.
2. Development Workflow
Here's the recommended workflow for making changes:
# Make your changes to the code
# ...
# Format your code (auto-fixes formatting issues)
make format
# Run all linting checks (matches CI exactly)
make lint
# Run unit tests to ensure nothing is broken
make test-unit
# Commit your changes
git add .
git commit -m "Your descriptive commit message"
# Push and create a PR
git push origin your-feature-branch
Adding Testing
Adding at least 1 test is a hard requirement for all PRs.
Where to Add Tests
Add your tests to the tests/test_litellm/ directory.
- This directory mirrors the structure of the
litellm/directory - Only add mocked tests - no real LLM API calls in this directory
- For integration tests with real APIs, use the appropriate test directories
File Naming Convention
The tests/test_litellm/ directory follows the same structure as litellm/:
litellm/proxy/caching_routes.py→tests/test_litellm/proxy/test_caching_routes.pylitellm/utils.py→tests/test_litellm/test_utils.py
Example Test
import pytest
from litellm import completion
def test_your_feature():
"""Test your feature with a descriptive docstring."""
# Arrange
messages = [{"role": "user", "content": "Hello"}]
# Act
# Use mocked responses, not real API calls
# Assert
assert expected_result == actual_result
Running Tests and Checks
Running Unit Tests
Run all unit tests (uses parallel execution for speed):
make test-unit
If you're running broader test suites, proxy tests, or anything that touches PostgreSQL-backed fixtures/plugins, install the full local test environment first:
make install-test-deps
This syncs the locked test environment used across the repo, including psycopg v3 plus psycopg-binary (used by pytest-postgresql), psycopg2-binary (used by some proxy E2E tests), and a generated Prisma client for DB-backed proxy tests, so pytest startup matches CI without manual package installs.
Run specific test files:
uv run pytest tests/test_litellm/test_your_file.py -v
Running Linting and Formatting Checks
Run all linting checks (matches CI exactly):
make lint
Individual linting commands:
make format-check # Check Black formatting
make lint-ruff # Run Ruff linting
make lint-mypy # Run MyPy type checking
make check-circular-imports # Check for circular imports
make check-import-safety # Check import safety
Apply formatting (auto-fixes issues):
make format
Black formatting is enforced in CI. All PRs must pass the Black formatting check.
- AI coding agents (Claude Code, Copilot, Cursor, etc.):
AGENTS.mdandCLAUDE.mdinstruct agents to runpoetry run black .before committing.- VS Code users: Install the Black Formatter extension and enable format-on-save:
{ "[python]": { "editor.defaultFormatter": "ms-python.black-formatter", "editor.formatOnSave": true } }
CI Compatibility
To ensure your changes will pass CI, run the exact same checks locally:
# This runs the same checks as the GitHub workflows
make lint
make test-unit
For exact CI compatibility (pins OpenAI version like CI):
make install-dev-ci # Installs exact CI dependencies
Available Make Commands
Run make help to see all available commands:
make help # Show all available commands
make install-dev # Install development dependencies
make install-proxy-dev # Install proxy development dependencies
make install-test-deps # Install the full local test environment
make format # Apply Black code formatting
make format-check # Check Black formatting (matches CI)
make lint # Run all linting checks
make test-unit # Run unit tests
make test-integration # Run integration tests
make test-unit-helm # Run Helm unit tests
Code Quality Standards
LiteLLM follows the Google Python Style Guide.
Our automated quality checks include:
- Black for consistent code formatting
- Ruff for linting and code quality
- MyPy for static type checking
- Circular import detection
- Import safety validation
All checks must pass before your PR can be merged.
Common Issues and Solutions
1. Linting Failures
If make lint fails:
- Formatting issues: Run
make formatto auto-fix - Ruff issues: Check the output and fix manually
- MyPy issues: Add proper type hints
- Circular imports: Refactor import dependencies
- Import safety: Fix any unprotected imports
2. Test Failures
If make test-unit fails:
- Check if you broke existing functionality
- Add tests for your new code
- Ensure tests use mocks, not real API calls
- Check test file naming conventions
3. Common Development Tips
- Use type hints: MyPy requires proper type annotations
- Write descriptive commit messages: Help reviewers understand your changes
- Keep PRs focused: One feature/fix per PR
- Test edge cases: Don't just test the happy path
- Update documentation: If you change APIs, update docs
Building and Running Locally
LiteLLM Proxy Server
To run the proxy server locally:
# Install proxy dependencies
make install-proxy-dev
# Start the proxy server
uv run litellm --config your_config.yaml
Docker Development
If you want to build the Docker image yourself:
# Build using the non-root Dockerfile
docker build -f docker/Dockerfile.non_root -t litellm_dev .
# Run with your config
docker run \
-v $(pwd)/proxy_config.yaml:/app/config.yaml \
-e LITELLM_MASTER_KEY="sk-1234" \
-p 4000:4000 \
litellm_dev \
--config /app/config.yaml --detailed_debug
UI Development
1. Setup Your Local UI Development Environment
# Clone the repo (if you haven't already)
git clone https://github.com/YOUR_USERNAME/litellm.git
cd litellm
# Navigate to the UI dashboard directory
cd ui/litellm-dashboard
# Install dependencies
npm install
# Start the development server
npm run dev
2. Adding UI Tests
If you are adding a new component or new logic, you must add corresponding tests.
3. Running UI Unit Tests
npm run test
4. Building the UI
Ensure the UI builds successfully before submitting your PR:
npm run build
Submitting Your PR
- Push your branch:
git push origin your-feature-branch - Create a PR: Go to GitHub and create a pull request
- Fill out the PR template: Provide clear description of changes
- Wait for review: Maintainers will review and provide feedback
- Address feedback: Make requested changes and push updates
- Merge: Once approved, your PR will be merged!
Getting Help
If you need help:
- 💬 Join our Discord
- 💬 Join our Slack
- 📧 Email us: ishaan@berri.ai / krrish@berri.ai
- 🐛 Create an issue
What to Contribute
Looking for ideas? Check out:
- 🐛 Good first issues
- 🚀 Feature requests
- 📚 Documentation improvements
- 🧪 Test coverage improvements
- 🔌 New LLM provider integrations
Thank you for contributing to LiteLLM! 🚀