## Observed behavior

When a Router is configured with a generic `fallbacks` list and the primary model fails for a non-context reason (rate limit, timeout, server error), the same `messages` payload is forwarded to each fallback model as-is. If a fallback model has a smaller `max_input_tokens` than the primary and the request exceeds the fallback's context window, the fallback raises `ContextWindowExceededError` and the chain ends. No preflight token counting or message trimming happens between fallbacks.

Repro (router config):

```yaml model_list: - model_name: gpt-4-turbo litellm_params: model: gpt-4-turbo api_key: os.environ/OPENAI_API_KEY - model_name: gpt-4 litellm_params: model: gpt-4 api_key: os.environ/OPENAI_API_KEY router_settings: fallbacks: - gpt-4-turbo: [gpt-4] ```

Send a ~10K-token request. If the primary fails on a rate limit (or any non-context error), the fallback `gpt-4` (`max_input_tokens=8192`) receives the same payload and fails with `ContextWindowExceededError`. The user gets a context-window error from the fallback, with no indication that the fallback was a bad choice.

## Why this happens

In `litellm/router_uti…