[Bug]: Router context-window checks are silently skipped for all Responses API calls

快速结论：此问题发生在使用 LiteLLM Proxy 的 Router 模块，通过 Responses API（/v1/responses）发送请求时，上下文窗口（context-window）检查被静默跳过。优先检查你是否在使用 Responses API 且期望 Router 根据 max_input_tokens 限制路由请求；该问题已在 PR #32510 中修复，等待发布。

问题场景

用户在 LiteLLM Proxy 中配置了模型组（model group），其中某个部署（deployment）设置了 max_input_tokens 限制（通过静态覆盖或模型成本映射），并通过 /v1/responses 端点发送请求。期望 Router 能在预检查阶段识别请求超出上下文窗口限制并返回错误，但实际请求被正常路由，没有任何上下文窗口错误被触发。

报错原文

(none - this is a silent skip, not an exception)

注意：这是一个静默跳过，不会产生任何异常输出。用户只有在观察到请求被路由到不符合上下文限制的部署时，才会意识到此问题。

原因分析

Router 的 _pre_call_checks() 方法负责在调用前检查请求是否符合 max_input_tokens 限制，但该方法的实现中只检查 kwargs["messages"] 字段。Responses API 请求的参数使用 input 字段而非 messages，因此上下文窗口验证对于所有 Responses API 调用都静默跳过，无论模型组的上下文限制是如何配置的（静态覆盖或从 litellm 模型成本映射派生）。这可能导致超出部署上下文窗口的请求被路由到该部署，且不显示任何上下文窗口错误。

此外，_pre_call_checks() 每次调用都会读取 RPM 缓存，即使模型组中没有部署配置 rpm，也造成不必要的缓存流量。

环境排查

确认 LiteLLM 版本：v1.91.0 或更早版本（问题在 PR #32510 中修复，尚未合入主分支）
确认是否使用 Proxy 模式（Router 功能）
确认是否通过 Responses API 端点（/v1/responses）发送请求
确认模型组中是否有部署配置了 max_input_tokens 限制

解决步骤

确认你使用的是 Responses API（/v1/responses）而非 Chat Completions API（/v1/chat/completions）；如果是 Chat Completions API，此问题不适用。
等待 PR #32510 合入并发布新版本，通常在 .rc 版本中可用（Issue 评论提到“fixed – will be live in today’s .rc”）。
如急需修复，可尝试手动应用 PR #32510 的更改到你的 LiteLLM 安装中（从 PR #32510 获取 diff）。
临时工作区：在 Responses API 请求前手动检查 input 长度，或改为通过 Chat Completions API 发送请求（如果可能）。

验证方法

修复后，发送一个 /v1/responses 请求，其中 input 明显超过模型组的 max_input_tokens 限制，应该会收到上下文窗口错误，而不是静默路由请求。同时，对于没有配置 rpm 的模型组，_pre_call_checks() 不再读取 RPM 缓存，减少不必要的缓存流量。