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

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 serves as the abstract foundation for all provider configurations. It provides a generic utility for exposing class-level attributes without provider-specific logic.

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 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.

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)	project_id, region, space_id
Vertex AI – Anthropic	VertexAIAnthropicConfig (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)	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.
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 demonstrates the internal flow:

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:

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:

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, 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 with transform_request and transform_response methods handling the specific schema conversions.
3. Register the provider in 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	BaseConfig definition and generic attribute extraction
OpenAI-style config	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	IBMWatsonXChatConfig with project/region fields
Vertex AI Anthropic	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	Helper functions like map_developer_role_to_system_role used across configs
Routing metadata	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) 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 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}