# LiteLLM Model-Specific Parameters and Provider Transformations: A Complete Guide

> Master LiteLLM model-specific parameters & provider transformations. This guide explains how LiteLLM unifies LLM providers with a two-layer architecture for seamless API integration.

- Repository: [Berri AI/litellm](https://github.com/BerriAI/litellm)
- Tags: deep-dive
- Published: 2026-03-26

---

**LiteLLM normalizes hundreds of LLM providers into a single OpenAI-compatible API through a two-layer architecture of Config classes (for parameter definitions) and Transformation classes (for request/response adapters), automatically filtering unsupported parameters and converting schemas under the hood.**

LiteLLM bridges the fragmentation across the LLM ecosystem by providing a unified interface to providers like OpenAI, Anthropic, Azure, and Vertex AI. At the heart of this abstraction lies a sophisticated system for handling **LiteLLM model-specific parameters and provider transformations** that ensures only supported arguments reach each backend. This architecture relies on specialized configuration classes and request/response transformers to maintain compatibility without sacrificing provider-specific functionality.

## The Config Hierarchy: From BaseConfig to Provider-Specific Classes

LiteLLM isolates model-specific parameter definitions in lightweight configuration classes that inherit from a common base. This hierarchy determines which arguments are valid for each model and provides the filtering logic used before sending requests to upstream providers.

### BaseConfig – The Foundation

The `BaseConfig` class in [`litellm/llms/base_llm/chat/transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/base_llm/chat/transformation.py) serves as the abstract foundation for all provider configurations. It provides a generic utility for exposing class-level attributes without provider-specific logic.

```python
class BaseConfig(ABC):
    def __init__(self):
        pass

    @classmethod
    def get_config(cls):
        # Returns a dict of *class attributes* that are not private,

        # callable, or None – i.e. the effective parameter set.

        ...

```

According to the LiteLLM source code, `get_config` reflects the class-level attributes set by subclass constructors, enabling dynamic discovery of supported parameters at runtime.

### OpenAIGPTConfig – OpenAI-Style Parameter Handling

The `OpenAIGPTConfig` class in [`litellm/llms/openai/chat/gpt_transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/openai/chat/gpt_transformation.py) extends `BaseConfig` with OpenAI-centric defaults and type definitions. It declares which optional arguments a provider supports—such as `max_tokens`, `temperature`, and `response_format`—and exposes a convenient Python constructor.

```python
class OpenAIGPTConfig(BaseLLMModelInfo, BaseConfig):
    # Model-specific defaults and typing

    frequency_penalty: Optional[int] = None
    function_call: Optional[Union[str, dict]] = None
    ...
    def __init__(self, *, frequency_penalty=None, function_call=None, ...):
        # Populate class attributes only for values that are not None

        for key, value in locals().items():
            if key != "self" and value is not None:
                setattr(self.__class__, key, value)
        self.__class__._is_base_class = False

```

This class implements three critical methods for parameter management:

- **`get_supported_openai_params`**: Returns the union of core parameters (e.g., `temperature`, `max_tokens`) plus model-specific extras (such as `response_format` for all models except `gpt-4`).
- **`_map_openai_params`**: Filters user-provided `non_default_params` dictionaries, retaining only keys that appear in the supported list for the target model.
- **`map_openai_params`**: Public wrapper that forwards to the internal filtering logic.

By leveraging these methods, LiteLLM ensures **only parameters the model understands are sent** to the provider, silently dropping unsupported keys to prevent API errors.

### Provider-Specific Configurations

Most providers subclass `OpenAIGPTConfig` and add extra fields required by their native APIs. The following table highlights notable implementations:

| Provider | Config Class | Notable Extra Fields |
|----------|--------------|----------------------|
| **WatsonX** | `IBMWatsonXChatConfig` ([`litellm/llms/watsonx/chat/transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/watsonx/chat/transformation.py)) | `project_id`, `region`, `space_id` |
| **Vertex AI – Anthropic** | `VertexAIAnthropicConfig` ([`litellm/llms/vertex_ai/vertex_ai_partner_models/anthropic/transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/vertex_ai/vertex_ai_partner_models/anthropic/transformation.py)) | Forces `anthropic_version = "vertex-2023-10-16"` |
| **Azure AI – Anthropic** | `AzureAnthropicConfig` ([`litellm/llms/azure_ai/anthropic/transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/azure_ai/anthropic/transformation.py)) | Injects Azure auth headers while re-using Anthropic logic |

These subclasses inherit the parameter-filtering logic from `OpenAIGPTConfig` and simply expose additional attributes required by the underlying service, maintaining consistency across the abstraction layer.

## The Transformation Pipeline: Mapping Requests and Responses

While Config classes define *what* parameters are valid, **Transformation classes** handle *how* those parameters are formatted for each provider's native schema. Each provider lives under `litellm/llms/<provider>/…/transformation.py` and shares standardized method signatures.

### Parameter Mapping and Filtering

Before a request leaves LiteLLM, the system executes a three-step transformation pipeline:

1. **Parameter mapping**: `OpenAIGPTConfig.map_openai_params` (or a provider-specific override) strips unsupported keys using the logic defined in `_map_openai_params`.
2. **Message conversion**: Provider-specific `transform_request` methods rewrite messages, tools, images, and PDFs into the native format. For example, `OpenAIGPTConfig._transform_messages` normalizes `image_url` objects, while PDF URLs are converted to base64 via `contains_pdf_url` and `_handle_pdf_url` in [`litellm/llms/openai/chat/gpt_transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/openai/chat/gpt_transformation.py).
3. **Response translation**: `transform_response` builds a `ModelResponse` object that mimics OpenAI's JSON schema, mapping provider-specific fields (e.g., Anthropic's `reasoning` to OpenAI's `reasoning_content`).

### Message and Tool Transformation

The `transform_request` method in [`litellm/llms/openai/chat/gpt_transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/openai/chat/gpt_transformation.py) demonstrates the internal flow:

```python
def transform_request(self, model, messages, optional_params, litellm_params, headers):
    messages = self._transform_messages(messages=messages, model=model)
    messages, tools = self.remove_cache_control_flag_from_messages_and_tools(
        model=model, messages=messages, tools=optional_params.get("tools", [])
    )
    if tools:
        optional_params["tools"] = tools
    optional_params.pop("max_retries", None)
    return {"model": model, "messages": messages, **optional_params}

```

All transformation classes implement the same method signatures (`transform_request`, `async_transform_request`, `transform_response`), enabling the router to call them polymorphically regardless of the target provider.

### Response Normalization

When processing responses, transformation classes convert provider-native output back to OpenAI-compatible `ChatCompletion` formats. This includes handling differences in content block structures, token usage reporting, and reasoning fields across vendors like Anthropic, Cohere, and Google.

## Implementation Examples

### Simple OpenAI Calls with Custom Parameters

You can pass any supported OpenAI-style parameter; unsupported ones are automatically ignored by the Config class:

```python
import litellm

# Pass any supported OpenAI-style param; unsupported ones are ignored.

resp = litellm.completion(
    model="gpt-4",                         # model name

    messages=[{"role": "user", "content": "Tell me a joke."}],
    temperature=0.4,                       # supported

    response_format={"type": "json_object"},  # only for < gpt-4

    unknown_param=123                      # silently dropped

)
print(resp.choices[0].message.content)

```

Under the hood, `litellm.completion` creates an `OpenAIGPTConfig` instance, calls `map_openai_params` to retain valid parameters like `temperature` while removing `unknown_param`, and builds the final payload for the OpenAI endpoint.

### Routing to Non-OpenAI Providers

When targeting providers like Anthropic via Vertex AI, LiteLLM automatically selects the appropriate Config and Transformation classes:

```python
import litellm

resp = litellm.completion(
    model="vertex/anthropic.claude-3-sonnet@001",
    messages=[{"role": "user", "content": "Summarise the paragraph."}],
    max_tokens=512,
    temperature=0.7,
    # provider-specific flags (e.g., anthropic_version) are injected automatically

)

print(resp.choices[0].message.content)

```

The internal flow follows these steps:

1. The `model` string matches the **Vertex AI Anthropic** regex in [`litellm/router_utils/model_info.py`](https://github.com/BerriAI/litellm/blob/main/litellm/router_utils/model_info.py), selecting `VertexAIAnthropicConfig`.
2. The config adds the required header `anthropic-version: vertex-2023-10-16`.
3. `transform_request` rewrites messages to Anthropic's "messages" schema.
4. The response, containing Anthropic-style `content` blocks, is converted back to OpenAI-compatible `Message` objects.

### Adding Custom Provider Support

To support a new LLM service in LiteLLM, implement three components:

1. **Create a Config subclass** (e.g., `MyLLMConfig(BaseConfig)`) exposing any extra fields required by the provider's API.
2. **Implement a transformation file** at [`my_llm/transformation.py`](https://github.com/BerriAI/litellm/blob/main/my_llm/transformation.py) with `transform_request` and `transform_response` methods handling the specific schema conversions.
3. **Register the provider** in [`litellm/router_utils/model_info.py`](https://github.com/BerriAI/litellm/blob/main/litellm/router_utils/model_info.py) by mapping model name patterns (regex) to your config class.

No changes are required in higher-level routing code; the system automatically discovers and utilizes the new classes through the registry.

## Key Source Files and Architecture

The following files define the core infrastructure for LiteLLM model-specific parameters and provider transformations:

| Area | File | Role |
|------|------|------|
| **Core config base** | [`litellm/llms/base_llm/chat/transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/base_llm/chat/transformation.py) | `BaseConfig` definition and generic attribute extraction |
| **OpenAI-style config** | [`litellm/llms/openai/chat/gpt_transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/openai/chat/gpt_transformation.py) | `OpenAIGPTConfig`, parameter mapping (`_map_openai_params`), message handling (`_transform_messages`), and PDF URL conversion |
| **WatsonX implementation** | [`litellm/llms/watsonx/chat/transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/watsonx/chat/transformation.py) | `IBMWatsonXChatConfig` with project/region fields |
| **Vertex AI Anthropic** | [`litellm/llms/vertex_ai/vertex_ai_partner_models/anthropic/transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/vertex_ai/vertex_ai_partner_models/anthropic/transformation.py) | `VertexAIAnthropicConfig` forcing `anthropic_version` headers |
| **Utility functions** | [`litellm/litellm_core_utils/prompt_templates/common_utils.py`](https://github.com/BerriAI/litellm/blob/main/litellm/litellm_core_utils/prompt_templates/common_utils.py) | Helper functions like `map_developer_role_to_system_role` used across configs |
| **Routing metadata** | [`litellm/router_utils/model_info.py`](https://github.com/BerriAI/litellm/blob/main/litellm/router_utils/model_info.py) | Associates regex patterns to config classes (e.g., `vertex/anthropic.*` → `VertexAIAnthropicConfig`) |

## Summary

- **LiteLLM isolates model-specific parameters** in lightweight `Config` classes that inherit from `BaseConfig` and specialize via `OpenAIGPTConfig`.
- **Parameter filtering** occurs through `get_supported_openai_params` and `_map_openai_params`, ensuring only valid arguments reach the provider.
- **Provider-specific subclasses** like `IBMWatsonXChatConfig` and `VertexAIAnthropicConfig` add required fields (e.g., `project_id`, `anthropic_version`) without duplicating filtering logic.
- **Transformation modules** in `litellm/llms/<provider>/transformation.py` convert OpenAI-style requests to native schemas and back, handling messages, tools, images, and PDFs.
- **Polymorphic method signatures** (`transform_request`, `transform_response`) allow the router to treat all providers uniformly while preserving backend-specific requirements.

## Frequently Asked Questions

### How does LiteLLM handle unsupported parameters for specific models?

LiteLLM uses the `_map_openai_params` method in `OpenAIGPTConfig` (located in [`litellm/llms/openai/chat/gpt_transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/openai/chat/gpt_transformation.py)) to filter user inputs against the list returned by `get_supported_openai_params`. Unsupported keys are silently removed from the request payload before transmission to the provider, preventing 400 Bad Request errors from APIs that reject unknown fields.

### Can I use OpenAI-specific features like `response_format` with non-OpenAI providers?

Yes, but only if the target provider's Config class explicitly supports it. The `OpenAIGPTConfig.get_supported_openai_params` method returns `response_format` for compatible models, while provider-specific configs like `VertexAIAnthropicConfig` may inject additional headers (e.g., `anthropic-version`) required to enable JSON mode on Anthropic models hosted via Vertex AI. Always check the specific transformation file for your provider to verify compatibility.

### What is the difference between `BaseConfig` and `OpenAIGPTConfig`?

`BaseConfig` in [`litellm/llms/base_llm/chat/transformation.py`](https://github.com/BerriAI/litellm/blob/main/litellm/llms/base_llm/chat/transformation.py) provides generic attribute extraction via `get_config` and serves as the abstract base for all providers. `OpenAIGPTConfig` extends this with OpenAI-centric logic, including the parameter filtering methods (`_map_openai_params`) and default value handling for standard OpenAI chat parameters like `temperature` and `max_tokens`. Most modern providers inherit from `OpenAIGPTConfig` rather than `BaseConfig` directly to reuse this OpenAI-compatible filtering logic.

### How do I add support for a new LLM provider that isn't in LiteLLM yet?

To add a new provider, create a Config subclass (inheriting from `BaseConfig` or `OpenAIGPTConfig`) that declares any extra parameters your provider requires. Then implement a transformation file with `transform_request` and `transform_response` methods to handle schema conversion. Finally, register the provider in [`litellm/router_utils/model_info.py`](https://github.com/BerriAI/litellm/blob/main/litellm/router_utils/model_info.py) by mapping a regex pattern (e.g., `myprovider/.*`) to your Config class. LiteLLM's router will automatically instantiate your classes when matching models are requested.