From 9b3d371f8e3e3408ce0cc0f30078a7bd853649ab Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Sat, 18 Jul 2026 22:13:47 +0000 Subject: [PATCH] docs(rust): add provider abstraction standards Co-Authored-By: Ishaan Jaffer <155045088+ishaan-berri@users.noreply.github.com> --- litellm-rust/ADDING_A_PROVIDER.md | 19 +++++++++++++++++++ litellm-rust/CLAUDE.md | 19 +++++++++++++++++++ 2 files changed, 38 insertions(+) diff --git a/litellm-rust/ADDING_A_PROVIDER.md b/litellm-rust/ADDING_A_PROVIDER.md index 2fa817986056..5f933ec4fa8a 100644 --- a/litellm-rust/ADDING_A_PROVIDER.md +++ b/litellm-rust/ADDING_A_PROVIDER.md @@ -6,4 +6,23 @@ Three layers, same for every route (see `ocr` and `realtime` as references): 2. **Provider config (pure)** — `crates/providers/src///transformation.rs`: implement that trait as a `const __CONFIG`, mirroring the Python provider tree. Add parity unit tests. 3. **HTTP / transport (the host)** — `crates/providers/src/.rs` (e.g. `ocr.rs`, `realtime.rs`): the callable fn (`run_ocr`, `realtime`). It resolves the key, builds the auth header, builds URL + transforms via the config, then does the network call. This is the only layer allowed to do I/O. +## Coding standards + +Before writing new logic, look for an existing base to extend. When a change is +“the same behavior for one more provider/endpoint/integration”, the codebase +almost always already has a shared abstraction for it (for example, provider +`BaseConfig` transformation classes in `litellm/llms/base_llm/`, shared +helpers in `litellm_core_utils/`, typed request/response models, or factory +functions). Find it first with a search, then add the new variant by inheriting +from or composing that base, overriding only what genuinely differs (model +name, parameter mapping, or auth). + +Never copy an existing implementation and edit it in place, and never hand-roll +a parallel version of logic a base already provides. If you catch yourself +writing a second copy of a pattern that exists twice already, stop and extract a +base instead: put the shared shape in one place and make both call sites thin +variants of it. The test for a good abstraction is that adding the next provider +is a few declarative lines, not a new file of duplicated flow. Only diverge from +the base when behavior is genuinely different, and say so explicitly in the PR. + **Calling:** the host invokes the route fn — the Python bridge calls `run_ocr`; the `ai-gateway` server calls `realtime`. Register new modules in `lib.rs` / `mod.rs`, then run `cargo fmt && cargo clippy --workspace -- -D warnings && cargo test --workspace`. diff --git a/litellm-rust/CLAUDE.md b/litellm-rust/CLAUDE.md index 7c723e570ef2..248c8e84b1a9 100644 --- a/litellm-rust/CLAUDE.md +++ b/litellm-rust/CLAUDE.md @@ -2,6 +2,25 @@ This file defines the rules for Rust work in LiteLLM. +## Provider Coding Standards + +Before writing new logic, look for an existing base to extend. When a change is +“the same behavior for one more provider/endpoint/integration”, the codebase +almost always already has a shared abstraction for it (for example, provider +`BaseConfig` transformation classes in `litellm/llms/base_llm/`, shared +helpers in `litellm_core_utils/`, typed request/response models, or factory +functions). Find it first with a search, then add the new variant by inheriting +from or composing that base, overriding only what genuinely differs (model +name, parameter mapping, or auth). + +Never copy an existing implementation and edit it in place, and never hand-roll +a parallel version of logic a base already provides. If you catch yourself +writing a second copy of a pattern that exists twice already, stop and extract a +base instead: put the shared shape in one place and make both call sites thin +variants of it. The test for a good abstraction is that adding the next provider +is a few declarative lines, not a new file of duplicated flow. Only diverge from +the base when behavior is genuinely different, and say so explicitly in the PR. + ## Crates (exactly three — see AGENTS.md) `litellm-core` describes work; `litellm-ai-gateway` executes it; `litellm-python-bridge`