OpenRouter passes upstream context-window errors through with status 400 — e.g. OpenAI-style "maximum context length is X tokens" or Anthropic-style "input length exceeds the maximum". For every other provider in `exception_mapping_utils.py`, a 400 whose `error_str` matches the canonical context-window phrases gets raised as `ContextWindowExceededError`. The OpenRouter branch skips that check and always raises plain `BadRequestError`.

Concretely, in `litellm/litellm_core_utils/exception_mapping_utils.py` (line ~2316 on `main`):

```python if custom_llm_provider == "openrouter": if hasattr(original_exception, "status_code"): exception_mapping_worked = True if original_exception.status_code == 400: exception_mapping_worked = True raise BadRequestError(...) # <-- unconditional ```

Other branches (e.g. line ~398) do this first:

```python elif ExceptionCheckers.is_error_str_context_window_exceeded(error_str): raise ContextWindowExceededError(...) ```

The downstream effect: consumers can't distinguish "real bad request" from "context overflow", so SDKs that have a context-window recovery path (auto-compaction, sliding window, fal…