Development and Contribution Guidelines
Relevant source files
The following files were used as context for generating this wiki page:
LiteLLM provides a standardized interface for interacting with over 100 LLM providers. These guidelines ensure that contributions maintain code quality, type safety, and cross-provider compatibility across the core library, the proxy server, and the management dashboard.
The project relies on a robust CI/CD pipeline and automated linting to enforce standards. Developers are expected to follow specific patterns for backend provider implementation and frontend component architecture to keep the codebase maintainable and scalable.
Sources: AGENTS.md:5-12, CLAUDE.md:27-46
Backend Development Standards
Backend development in LiteLLM is primarily focused on the core library (litellm/) and the proxy server (litellm/proxy/). Core library changes usually involve adding or modifying provider-specific implementations, while proxy changes involve authentication, rate limiting, and management endpoints.
Core Architecture and Patterns
New providers must inherit from base classes found in litellm/llms/base.py. These implementations require transformation functions to map OpenAI-standard inputs to provider-specific formats and back again.
The diagram shows the flow of a request from the user through the internal translation layer to a provider API and back to a unified response format.
Sources: AGENTS.md:52-60, CLAUDE.md:27-40
Key Development Commands
Developers use make commands for environment setup, testing, and linting.
| Task | Command | Description |
|---|---|---|
| Setup | make install-dev | Install core development dependencies. |
| Linting | make lint | Runs Ruff, MyPy, Black, and import safety checks. |
| Unit Testing | make test-unit | Runs tests/test_litellm with 4 parallel workers. |
| Formatting | make format | Applies Black code formatting. |
| Proxy Dev | make install-proxy-dev | Installs full feature set for proxy development. |
Sources: CONTRIBUTING.md:104-118, CLAUDE.md:5-20, GEMINI.md:5-20
Coding Standards
- Imports: All imports must be placed at the top of the file (module-level). Avoid inline imports within methods except to resolve circular dependencies.
- Type Safety: Pydantic v2 is used for data validation. Type hints are mandatory for all public APIs.
- Testing: Adding at least one test is a hard requirement for any PR. Tests in
tests/test_litellm/must be mocked and avoid real API calls.
Sources: CONTRIBUTING.md:12-16, CLAUDE.md:53-58, AGENTS.md:139-144
UI Development Guidelines
The LiteLLM UI is built with NextJS and follows a strict directory structure within ui/litellm-dashboard/.
Frontend Architecture
The UI follows a strict pattern where pages are contained in their own folders, and routing is automatically handled. Component files should be kept "dumb," focusing strictly on taking data from hooks or props and rendering it.
The diagram illustrates the hierarchical file structure required for UI features, separating logic into hooks and sub-components.
Sources: ui/litellm-dashboard/src/app/(dashboard)/README.md:12-32
UI Component Rules
- Lines of Code: If a component exceeds 300 lines, it must be broken down into smaller sub-components.
- Library Constraints: Tremor components are deprecated and should not be used in new features, except for the Table component.
- Testing: The project uses Vitest and React Testing Library. All test names must follow the
it("should ...")pattern. - Mocking: External dependencies and networking calls must be mocked to ensure isolated component testing.
Sources: AGENTS.md:73-100, ui/litellm-dashboard/src/app/(dashboard)/README.md:38-44
Release Process and Documentation
Release notes are generated following a strict structure to provide visibility into new models, pricing changes, and bug fixes.
Release Note Structure
Release notes are categorized into sections including "New Providers and Endpoints," "New Models," and "AI Integrations." Developers must update provider_endpoints_support.json when adding new providers.
| Section | Content |
|---|---|
| Key Highlights | 3-5 major features like MCP OAuth 2.0 or scheduled rotations. |
| New Model Support | Table including Provider, Context Window, and Cost (Input/Output). |
| Spend Tracking | Service tier pricing, budgets, and rate limiting improvements. |
| MCP Gateway | MCP configuration, tools, and server management. |
Sources: cookbook/misc/RELEASE_NOTES_GENERATION_INSTRUCTIONS.md:35-86, cookbook/misc/RELEASE_NOTES_GENERATION_INSTRUCTIONS.md:209-225
Model Pricing Analysis
Before a release, developers must analyze changes in model_prices_and_context_window.json to extract context windows and token costs for the release notes.
git diff <previous_commit_hash> HEAD -- model_prices_and_context_window.json
Sources: cookbook/misc/RELEASE_NOTES_GENERATION_INSTRUCTIONS.md:14-19
Conclusion
Adhering to these development and contribution guidelines ensures that LiteLLM remains the industry standard for a unified LLM interface. By following the established transformation patterns for backend providers and the structured component architecture for the frontend, contributors help maintain a high-quality, reliable gateway for AI applications.
Sources: AGENTS.md:5-12, CONTRIBUTING.md:162-170