# LiteLLM SDK provider normalization > 12 source-anchored research claims on LiteLLM SDK provider normalization, grouped by facet. Original confidence and source-owner limits are retained. Parent: [LiteLLM gateway and SDK engineering](https://llms-explorer.com/tree/litellm-gateway-sdk-engineering/) · 6 facets · 12 facts · page: https://llms-explorer.com/tree/litellm-sdk-provider-normalization/ ## Definitions - Use litellm.completion(model=..., messages=...) as the OpenAI-style chat adapter. LiteLLM translates supported inputs to provider endpoints; a common request shape is an integration boundary, not evidence that every provider supports every option. — [source](https://docs.litellm.ai/) *(confidence high; single-owner LiteLLM evidence · confidence: high)* ## Structure and components - The current output guide documents provider_specific_fields.native_finish_reason when a native stop reason differs from its normalized value. Preserve and inspect this field when a native failure, such as a malformed function call, needs a different agent response. — [source](https://docs.litellm.ai/docs/completion/output) *(confidence low; single-owner LiteLLM evidence; qualify exact deployment · confidence: low)* - A non-streaming completion exposes choices, message, finish_reason and usage in an OpenAI-compatible shape. The SDK supports both attribute and dictionary access; inspect the actual message rather than assuming every successful response contains plain text. — [source](https://docs.litellm.ai/) *(confidence high; single-owner LiteLLM evidence · confidence: high)* ## Parameters and configuration - Provider/model prefixes select the intended adapter, for example openai/... or anthropic/.... Configure that provider's credentials explicitly, such as OPENAI_API_KEY or ANTHROPIC_API_KEY; changing only the model string does not supply credentials. — [source](https://docs.litellm.ai/) *(confidence medium; single-owner LiteLLM evidence · confidence: medium)* - The documented Chat Completions default rejects unsupported OpenAI parameters. drop_params=True changes that behavior by removing them, so enabling it changes request semantics and should not be treated as proof the removed feature works. — [source](https://docs.litellm.ai/docs/completion/input) *(confidence high; single-owner LiteLLM evidence · confidence: high)* - allowed_openai_params opts listed caller-supplied fields into forwarding as-is. Current upstream _apply_openai_param_overrides preserves that behavior; this escape hatch changes validation, not the upstream model's capabilities. — [source](https://docs.litellm.ai/docs/completion/drop_params) *(confidence high; single-owner LiteLLM evidence · confidence: high)* ## How-to and procedures - Catch the mapped authentication, rate-limit and request exceptions while retaining provider context. LiteLLM documents OpenAI-compatible exception classes with llm_provider information; unsupported parameters are a 400 BadRequestError subtype, not a transient transport failure. — [source](https://docs.litellm.ai/docs/exception_mapping) *(confidence high; single-owner LiteLLM evidence · confidence: high)* - Query get_supported_openai_params for the exact model and provider before constructing a shared parameter set. LiteLLM documents model-dependent support within a provider; a provider-level check alone can misclassify tool or sampling options. — [source](https://docs.litellm.ai/docs/completion/input) *(confidence high; single-owner LiteLLM evidence · confidence: high)* - Use completion for synchronous calls and await acompletion for asynchronous calls. With stream=True, consume the returned stream iterator; asynchronous streaming uses async for after awaiting acompletion. — [source](https://docs.litellm.ai/) *(confidence high; single-owner LiteLLM evidence · confidence: high)* ## Problems, failure modes and limitations - LiteLLM's completion-input documentation says unknown non-OpenAI parameters are treated as provider-specific request-body kwargs. drop_params is not a general sanitizer for arbitrary custom fields; verify the target provider's accepted payload. — [source](https://docs.litellm.ai/docs/completion/input) *(confidence low; single-owner LiteLLM evidence; qualify exact deployment · confidence: low)* - Do not assume every LiteLLM exception inherits from OpenAI exceptions. BudgetExceededError directly inherits from Exception in the inspected upstream code and is listed that way in the exception table; catch it explicitly when budgets are in scope. — [source](https://docs.litellm.ai/docs/exception_mapping) *(confidence high; single-owner LiteLLM evidence · confidence: high)* ## Comparisons and alternatives - Normalization does not erase native API differences: Anthropic Messages uses a top-level system field, while Google's current text-generation guide shows Interactions input and system_instruction. Keep native-provider contract checks separate from the SDK's OpenAI-style messages contract. — [source](https://docs.litellm.ai/docs/completion/input) *(confidence medium; native contracts do not independently certify LiteLLM implementation · confidence: medium)*