`litellm.BadRequestError` — where LiteLLM raises its 400 class

litellm.BadRequestError: <Provider>Exception - <provider message>

(The error as str(e) gives it when it comes from LiteLLM’s generic raises for OpenAI-style providers, assembled by us from the class prefix and the message form quoted as source below, with our placeholders in angle brackets. Unlike LiteLLM’s 429, 500 and 503 classes, these raises put no second class name inside the message. Other raise sites build a different text after litellm.BadRequestError: .)

In its exception mapper, LiteLLM raises this after the provider call failed: it maps the provider’s exception to its own classes, and the class it picks is BadRequestError when, in the generic branch for OpenAI-style providers, the error text contains invalid_request_error but not Incorrect API key provided, or the provider’s exception carries status code 400 or 422, or the text contains invalid_encrypted_content or could not be verified — each only when no earlier test in that chain matched — and, in a status fallback, for a 4xx status the fallback does not map to another class. LiteLLM also raises it itself, before any provider call, for example when it cannot tell which provider a model belongs to. Several LiteLLM classes are subclasses of it. Every claim about the library below is read off the Python source of BerriAI/litellm at tag v1.104.2, fetched on 10 October 2026, with the line of each quote given; where we draw a conclusion from those lines rather than quote them, we say so.

What it is: class BadRequestError(openai.BadRequestError):, in litellm/exceptions.py — a subclass of the OpenAI SDK’s own BadRequestError. Its constructor prefixes the message with litellm.BadRequestError: and keeps the response it was passed only when that is an httpx.Response with a request attached, else a stand-in with status 400. ContextWindowExceededError, ContentPolicyViolationError, UnsupportedParamsError and four more LiteLLM classes subclass it, so except litellm.BadRequestError catches them too (our reading).

Where: exception_type in litellm_core_utils/exception_mapping_utils.py, which completion() raises from its except block; that file has 48 raise statements for this class, listed below by function; and, in the files we read, get_llm_provider and three sites in main.py.

What to check: the provider’s own text at the end of the message, which says what the provider rejected in the request as sent, and the subclass first: an isinstance test against the subclasses before you treat the error as a plain 400 (our reading).

The generic raises

In litellm/litellm_core_utils/exception_mapping_utils.py, _map_openai_exception (defined at line 275) runs a chain of tests that opens at line 307. The raise on the invalid_request_error phrase is at lines 373–375:

elif "invalid_request_error" in error_str and "Incorrect API key provided" not in error_str: raise BadRequestError( message=f"{exception_provider} - {message}",

It runs only when none of the earlier branches of that chain matched (our reading); among them, at line 317, ExceptionCheckers.is_error_str_context_window_exceeded(error_str) raises ContextWindowExceededError, at line 325 invalid_request_error together with model_not_found raises NotFoundError, and at lines 340–344 invalid_request_error together with content_policy_violation, or two other phrase tests, raise ContentPolicyViolationError. Just before it, line 353, elif "invalid_encrypted_content" in error_str or "could not be verified" in error_str: raises this class at line 365 with a message that starts f"{exception_provider} - {message}\n\n" (line 355) and goes on to say the error occurs when load balancing Responses API across deployments with different API keys, and to suggest an encrypted_content_affinity router check.

When none of the text tests matched, the status test is at lines 422–425:

elif hasattr(original_exception, "status_code"): if original_exception.status_code == 400: raise BadRequestError( message=f"{exception_provider} - {message}",

That elif belongs to the chain that opens at line 307, so this raise runs when the original exception has a status_code attribute equal to 400 and none of the earlier branches (lines 307–421) matched (our reading). In the same block, elif original_exception.status_code == 422: (line 455) raises this class too, at line 456, with the same message form. All four raises pass llm_provider=custom_llm_provider, model=model, response=response, litellm_debug_info=extra_information, and body=getattr(original_exception, "body", None),. There response is what _litellm_proxy_response returns for the original exception (line 285) — its response attribute, rebuilt with the exception’s own headers only for the litellm_proxy provider when the response had none and the exception has some (lines 258–272); message is what get_error_message returns for the original exception, or failing that its message attribute or str() (lines 287–292), with OPENAI and openai.OpenAIError replaced by the upper-cased provider name and by {custom_llm_provider}.{custom_llm_provider}Error when the message is a string (lines 294–301); exception_provider is "OpenAI" + "Exception" for openai and otherwise the provider name with its first letter upper-cased plus Exception (lines 302–305). exception_type (line 2349) sends openai, text-completion-openai, custom_openai, mistral, runwayml and the providers in litellm.openai_compatible_providers to this function (the condition at lines 2458–2465).

The other sites in that file

A grep of the file for raise BadRequestError( finds 48 lines. Besides lines 365, 374, 424 and 456 above, and the two in exception_type described in the next section (2331 and 2653), they sit in the provider functions below. This is a declared scope: we name the function and the line of each raise, and we did not read the conditions of those we do not describe.

_map_anthropic_exception (line 527): 566, 587.
_map_replicate_exception (line 640): 665, 687.
_map_openai_like_exception (line 732): 779, 805, 824.
_map_bedrock_exception (line 872), which exception_type calls for bedrock and bedrock_mantle (line 2505): 906, 913, 920, 980, 1002.
_map_sagemaker_exception (line 1036): 1047, 1054, 1089, 1110.
_map_vertex_exception (line 1143): 1154, 1200, 1281.
_map_cloudflare_exception (line 1366): 1384.
_map_cohere_exception (line 1392): 1410, 1432, 1461.
_map_huggingface_exception (line 1486): 1504, 1526.
_map_ai21_exception (line 1562): 1581, 1602.
_map_nlp_cloud_exception (line 1625): 1644, 1665.
_map_together_ai_exception (line 1716): 1745, 1763, 1777.
_map_aleph_alpha_exception (line 1806): 1824, 1839.
_map_ollama_exception (line 1863): 1878, 1892.
_map_azure_exception (line 1926): 2014, 2023, 2048, 2080. Of these we read two: line 2023, under elif "invalid_request_error" in error_str and getattr(original_exception, "status_code", None) in (None, 400): (line 2022), and line 2080, under elif original_exception.status_code == 422: (line 2079), both with the message f"AzureException BadRequestError - {message}" (lines 2024 and 2081).
_map_openrouter_exception (line 2139): 2151, 2182.

For the litellm_proxy provider, exception_type first calls extract_and_raise_litellm_exception (lines 2448–2457), which finds the first match of litellm\.\w+Error in the error text (lines 232–233), looks the name up with getattr(litellm, exception_name, None) (line 237) and raises it with the whole error text as the message (lines 240–245). When the proxy’s error text names litellm.BadRequestError first, that raises this class (our inference: we did not fetch the package’s __init__.py), and str(e) then carries the prefix twice (our reading).

The fallback and the edge case

In exception_type, after the if model or custom_llm_provider: block (line 2376) that holds the provider-specific mapping — so only when nothing in that block raised (our reading) — line 2649 tests whether str(original_exception) contains "BadRequestError.__init__() missing 1 required positional argument: 'param'", under a comment calling it an edge-case bug in the OpenAI SDK. If it does, line 2653 raises this class with message=f"{exception_provider} BadRequestError : This can happen due to missing AZURE_API_VERSION: {original_exception}", (line 2654), passing model, llm_provider and the original exception’s response attribute (lines 2655–2657) and no body.

The else: of that test, line 2659, sets exception_mapping_worked = True (line 2663) and calls _map_exception_by_status (line 2664). That function (line 2242) returns without raising when the status code is not an int or is below 400, or when status_code_is_synthesized is true (lines 2251–2255); otherwise it builds message: Final = f"{exception_provider} - {error_str}" (line 2256) and matches the status. It has no case 400:; it has cases for 401, 403, 404, 408, 429, 500, 502, 503 and 504, and then, lines 2330–2331:

case _ if status_code < 500: raise BadRequestError(

So any other status from 400 to 499 — 400 itself included — is raised as this class there, with the original exception’s response attribute, litellm_debug_info and no body (lines 2332–2337; our reading). In both raises of this section exception_provider is the provider name with its first letter upper-cased plus Exception when the provider name is a non-empty string, set inside the try: at line 2392 (lines 2402–2403) once that block reaches them, and the provider name as passed otherwise (line 2360).

Every raise in that file happens inside the try: at line 2373 (our reading). Its except Exception as e: (line 2700) re-raises e when exception_mapping_worked is true (lines 2712–2714) and otherwise when e is an instance of a type in litellm.LITELLM_EXCEPTION_TYPES (lines 2716–2719), a list that includes BadRequestError (exceptions.py line 973); both paths first set litellm_response_headers on it. So the class reaches the caller unchanged from every site above (our reading).

Where `completion()` sends it, and where LiteLLM raises it itself

In litellm/main.py, completion (line 5113) ends with, lines 6036–6038:

except Exception as e: ## Map to OpenAI Exception raise exception_type(

passing model, custom_llm_provider and the original exception (lines 6038–6044). acompletion (line 400) does the same at lines 709–717, after setting custom_llm_provider to "openai" when it is empty (line 710). exception_type returns an exception that is already an instance of one of LiteLLM’s types unchanged (lines 2357–2358), so a BadRequestError raised inside completion’s try: (line 5419) reaches you as raised (our reading). Two such raises:

No provider found. completion calls get_llm_provider at line 5452. In litellm_core_utils/get_llm_provider_logic.py, when no provider was found (line 532) it raises litellm.exceptions.BadRequestError — this class itself, not a subclass — with a message beginning LLM Provider NOT provided. Pass in the LLM provider you are trying to call. (line 539), response=None and llm_provider="" (lines 541–546). Its except (line 552) re-raises a BadRequestError as is and wraps any other exception in a new one whose message starts GetLLMProvider Exception - (lines 553–558).
Provider affinity header. When litellm_params has a provider_affinity_header that is not None (line 5686) and adding it raises ValueError, line 5701 raises this class with that error’s text.

main.py also raises it directly in embedding (line 6270), at line 6907, for ollama input that is not all strings, and in speech (line 8197), at line 8298, when voice is missing or not a string for OpenAI-style TTS. We did not trace the Router or the proxy.

The class and its subclasses

In litellm/exceptions.py, class BadRequestError(openai.BadRequestError): is at line 219. Its constructor takes message, model, llm_provider and optional response, litellm_debug_info, max_retries, num_retries and body (lines 220–230), then sets, lines 231–232:

self.status_code = 400 self.message = f"litellm.BadRequestError: {message}"

Lines 233–237 store model, llm_provider, litellm_debug_info, max_retries and num_retries as passed. Lines 240–248 keep response as self.response only when it is not None, is an httpx.Response and has a non-None _request; otherwise self.response is _get_minimal_error_response(), a cached httpx.Response with status 400 and a stub GET request to https://litellm.ai (lines 121–129). Lines 249–251 pass self.message, response=self.response, body=body to the parent. Its __str__ (lines 253–259) and __repr__ (lines 261–267) return self.message, plus LiteLLM Retried: {self.num_retries} times when num_retries is non-zero and , LiteLLM Max Retries: {self.max_retries} when max_retries is non-zero.

A grep of the file for (BadRequestError) finds seven subclasses: ImageFetchError (line 270), VectorStoreSearchError (line 297), ContextWindowExceededError (line 535), RejectedRequestError (line 577), ContentPolicyViolationError (line 619), UnsupportedParamsError (line 945) and LiteLLMUnknownProvider (line 1068). InvalidRequestError (line 1028) subclasses openai.BadRequestError directly, not LiteLLM’s class, so except litellm.BadRequestError does not catch it (our reading).

The parent, in the OpenAI Python SDK at v1.109.1 (the version we read; yours may differ), is class BadRequestError(APIStatusError): in src/openai/_exceptions.py (line 104). APIStatusError.__init__ (lines 87–91) passes the message, response.request and the body up to APIError, then sets self.response, self.status_code from response.status_code and self.request_id from the response’s x-request-id header; APIError.__init__ (lines 54–67) sets request, message and body, and sets code, param and type from the body when it is a dict and to None otherwise. Because that runs after line 231, e.status_code ends up as the status of e.response, not a fixed 400 (our reading, at that SDK version).

What it looks like in the field

In freelawproject/litigant-portal#997, titled Thread description generation fails: fast model rejects the chat completions API on Bedrock Mantle, the reporter quotes: litellm.BadRequestError: BedrockException - {"error":{"code":"validation_error","message":"The model 'anthropic.claude-haiku-4-5' does not support the '/v1/chat/completions' API". The provider’s own text after the label says what it rejected. Bedrock errors are mapped in _map_bedrock_exception, whose conditions we did not read, so we do not say which site raised it.

In Kilo-Org/kilocode#14920, a report from the Kilo VS Code extension, the error reads litellm.BadRequestError: AzureException BadRequestError - Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead. followed by a model-group suffix. The AzureException BadRequestError - label is the message form of lines 2024 and 2081; the rejection of max_tokens came from the provider, under this class, not from LiteLLM’s UnsupportedParamsError (our reading). We did not trace where the suffix is added.

What the caller sees and can read

str(e) and e.message — litellm.BadRequestError: followed by the message the raise passed (line 232); str(e) adds the retry notes when those counts are non-zero (lines 253–259). Subclasses may set their own prefix: ContextWindowExceededError puts litellm.ContextWindowExceededError: in front after the base constructor ran (line 557), and UnsupportedParamsError sets litellm.UnsupportedParamsError: (line 958).
e.response — the response the raise passed, when it is an httpx.Response with a request attached; otherwise the shared stand-in with status 400 (lines 240–248). The get_llm_provider raise and the three main.py raises pass none, so there it is the stand-in (our reading).
e.status_code — the status of e.response (above): the provider’s status when its response was kept — 422 at line 456, any 4xx the fallback handles at line 2331, whatever the provider sent at lines 365 and 374 — and 400 from the stand-in (our reading).
e.body, e.code, e.param, e.type — the original exception’s body at lines 365, 374, 424 and 456, and the three fields from it when it is a dict; None at lines 2331 and 2653, which pass no body (our reading).
e.llm_provider, e.model — what the raise passed (lines 233–234); at the generic and fallback sites the custom_llm_provider and model that completion() passed to exception_type (lines 6039–6040), which get_llm_provider may have reassigned (line 5452); "" as the provider from the “LLM Provider NOT provided” raise.
e.litellm_debug_info — what the raise passed (line 235), else None, the default at line 226. Lines 365, 374, 424, 456 and 2331 pass extra_information; line 2653 does not. exception_type sets extra_information to "" (line 2375) and, inside the try: at line 2392, to f"\nModel: {model}" (line 2400) and extends it with other details.
e.litellm_response_headers — set in the except block above to what _get_response_headers (line 193) found on the original exception: its headers, else its response’s headers, else its own litellm_response_headers (lines 201–206), or None. An error that exception_type returns unchanged (lines 2357–2358), such as the “LLM Provider NOT provided” raise, does not pass through that block, and the class does not define the attribute (our reading).

What to do

Check the subclass first. Test isinstance against ContextWindowExceededError, ContentPolicyViolationError, UnsupportedParamsError and the other subclasses before you handle the base class; an except BadRequestError placed first catches them all (our reading, from the class lines).
Read the provider part of the message. After the prefix comes <Provider>Exception - or the branch’s own label and the provider’s text, which says which field, parameter, model or API it rejected: at the mapped sites, a 400 is the provider rejecting the request as sent (our reading). If the text after the prefix begins LLM Provider NOT provided, no provider was called: fix the model string or pass the provider.
Do not resend the same request. Nothing in the source we read suggests that a resend of an unchanged request would succeed (our reading). completion_with_retries (main.py lines 6047–6070) wraps completion (unless an original_function is passed, line 6061) in tenacity.Retrying with stop_after_attempt(num_retries), num_retries defaulting to 3 (line 6056), and neither Retrying call passes a retry= condition (lines 6062–6069), so it would retry this class too (our reading). Change the request — the parameter, the model, or the input the provider named — and then send it.

from litellm import completion from litellm.exceptions import ( BadRequestError, ContentPolicyViolationError, ContextWindowExceededError, UnsupportedParamsError, ) def call(model: str, messages: list[dict]): # Our sketch: let LiteLLM's 400 subclasses through, then show what the base class carries. try: return completion(model=model, messages=messages) except (ContextWindowExceededError, ContentPolicyViolationError, UnsupportedParamsError): raise except BadRequestError as e: print("provider:", e.llm_provider, "model:", e.model, "status:", e.status_code) print(e.message) raise

(Our sketch, not library code, and not run against your version. It re-raises: what to change in the request depends on what the provider part of the message says.)

What is behind this site

There is a written guide: the step-and-turn arithmetic as a formula you can run against a brief before you launch it, why raising a cap does not finish the job, and batch.py, one standard-library file that collapses a per-item loop into a single pass — fewer turns, which means fewer final calls made from an unfinished transcript when a run hits its cap. It is $19, on a storefront that delivers the files automatically and carries a 30-day money-back guarantee (checked 7 October 2026). One working way to pay today is 19 USDC on Base, and delivery is manual: you email the transaction hash and the files come back as a reply. This page is free, ungated, and sells nothing on its own.

The short version: litellm.BadRequestError is LiteLLM’s subclass of openai.BadRequestError, raised by exception_type — in the generic OpenAI-style branch when the error text contains invalid_request_error but not Incorrect API key provided, or invalid_encrypted_content or could not be verified, or when the provider’s exception has status_code 400 or 422, each when no earlier test matched; at sites in sixteen provider functions; and in the status fallback for a 4xx it does not map elsewhere — and by LiteLLM itself, for example when no provider was found. str(e) starts litellm.BadRequestError: , seven LiteLLM classes subclass it, and e.status_code follows e.response. Check the subclass, read the provider’s text, and change the request before you send it again.

Nearby

ContextWindowExceededError — a subclass of this class (line 535) that the generic branch raises earlier in the same chain, when is_error_str_context_window_exceeded matches the error text (line 317); its str(e) starts litellm.ContextWindowExceededError: .
UnsupportedParamsError — a subclass of this class (line 945) with its own prefix, litellm.UnsupportedParamsError: (line 958); its page traces where LiteLLM raises it, while this page covers parameters the provider itself rejected.
LLM Provider NOT provided — raised as this class itself, not a subclass, by get_llm_provider before any provider is called (lines 539–546), so an isinstance test does not separate it; its message does.

This page counts anonymous readership with one counter, the file at /measure.js, and each of the events below is sent at most once per load. Once the page is ready it sends one view event. With it go the page path, the domain of the page you came from — only the domain, and nothing at all if you came from this site — how long the page has been open, counting only the time it was actually in front of you and not the time it sat in a background tab, whether you have scrolled, and any campaign or outreach code in the link you followed. A second event, which we call a human candidate, is sent only once the page has also received a real input event from you — a mouse movement, a touch, a scroll or a key press — and has been visible in the foreground for ten seconds in all; a program that fetches the page, or opens it and sits there, cannot produce one. A third, “engaged”, is stricter still: it is sent only after the human-candidate event, once the page has been in front of you for ninety seconds in all and you have scrolled far enough to reach a marker we put where the explaining part of this page ends; a reader who stops short of that marker never produces one. The second and third events carry the same fields as the first. If you switch away from the tab or close it, an event that has just become due may be sent as you leave. If this page has a button or a copy control that says it records a click, pressing it sends the name of that event and nothing else. Following a link to buy the guide sends one further event, also at most once per load, carrying that event’s name and a single word for which of the two checkouts you were sent to — the Gumroad listing or the payment page on this site — and nothing else: not the address you followed, not which page you were reading, not how long you had been there. Everything is sent to this site only, with no cookie attached. No cookie is read or written, nothing is put in your browser’s local or session storage, and no identifier is made from your device. Earlier versions of this page kept the campaign codes of your first visit in local storage under the name llab_attr; this page neither reads nor deletes that entry, so if it is there it stays until you clear this site’s data. An outreach code is minted per recipient, which would let us tell one reader from another; it is sent with each event and, unlike on earlier versions of this page, it is no longer removed from the address bar after it is read — if you copy the address, the code goes with it. Earlier versions also asked this domain for Vercel’s analytics script at /_vercel/insights/script.js, which on 26 September 2026 returned HTTP 404 on every host we publish; this page no longer asks for it. Your browser and the network attach things the page does not send: the identification string your browser gives, your IP address and the time of the request. The host that serves this page keeps its own request logs; those are its record and not ours.

litellm.BadRequestError — where LiteLLM raises its 400 class