[Bug]: client.files.list() fails with “api_key client option must be set” on a managed-files proxy

快速结论：在启用了 managed files 的 LiteLLM 代理上，OpenAI SDK 的 client.files.list() 会因为请求中缺少 target_model_names 参数而默认走 OpenAI 直连路径，进而触发 “api_key client option must be set” 报错。优先确认代理进程环境变量中是否真的没有设置 OPENAI_API_KEY，并检查是否使用了包含修复提交的 LiteLLM 版本。

适用环境：BerriAI/litellm 代理（Issue 报告基于 v1.89.1，复现验证使用 litellm==1.94.3），启用 managed files（/v1/files 返回 litellm_proxy;... 统一 ID），数据库后端，模型凭据仅配置在 model_list 部署中。OpenAI SDK（Python）调用 client.files.list() 时触发。未提供操作系统、CUDA、显卡等环境信息。

最快修复方案：升级 LiteLLM 到包含修复提交 17ce2c4 或 PR #37855 的版本（提交在 v1.89.1 之后发布）。如果暂时不能升级，可优先尝试使用带 target_model_names 参数的显式请求（如 GET /v1/files?target_model_names=my-gpt）作为临时绕过。

注意事项：即使升级到修复初步版本（如 17ce2c4），部分批次输出行仍可能返回原始 provider 的 file-* ID，导致后续 files.retrieve / files.content 操作失败；该问题由 #36031 进一步跟踪修复。此外，PR #37855 的修复范围覆盖无作用域请求，显式 provider 和模型路由保持不变。

问题场景

在启用 managed files 的 LiteLLM 代理环境下，任何使用 OpenAI Python SDK 的调用方只要执行普通的 client.files.list()（不带任何 target_model_names、provider 或相关 header）就会触发 500 错误。该问题并非边缘场景，影响所有 SDK 调用者。其他 managed 路径操作（上传、读取、内容、删除、批量生命周期）均正常，只有文件枚举功能失效。此问题发生在 managed 路由上，不涉及 passthrough 模式。

报错原文

The api_key client option must be set either by passing api_key to the client or by setting the OPENAI_API_KEY environment variable

openai.InternalServerError: Error code: 500 - {'error': {'message':
...

原因分析

可能原因：无作用域的 GET /v1/files 请求（不带 target_model_names）在 LiteLLM 代理端默认设置了 custom_llm_provider="openai"，导致请求被直接发送到 OpenAI 官方接口而不是经过 LiteLLM 的 router 进行 managed-files 过滤。由于代理进程环境变量中未设置 OPENAI_API_KEY（凭据仅存在于 model_list 的部署配置中），真实 OpenAI 客户端构造时缺少凭据而报错。该问题的根源在于端点代码的 fallback 链：当调用方未提供 provider 时，最终会落到 "or 'openai'" 的默认值。

环境排查

确认 OPENAI_API_KEY 和 OPENAI_ADMIN_KEY 是否在代理进程环境中被取消设置或不存在（凭据应只在 model_list 中）。
确认 LiteLLM 版本：v1.89.1 及以下版本受影响；v1.94.3 仍可复现（修复未完全覆盖）；包含提交 17ce2c4 或 PR #37855 的版本应修复此问题。
验证是否启用了 general_settings.database_url 和 litellm_settings.enable_preview_features。
检查 model_list 中的模型凭据配置是否正确（例如 api_key: os.environ/MY_DEPLOYMENT_OPENAI_KEY）。

解决步骤

升级 LiteLLM 到包含修复的版本：确认提交 17ce2c4（在 v1.89.1 之后）或 PR #37855 合入的版本，升级后重新测试无作用域的 client.files.list()。
临时绕过方案（可优先尝试）：在无法立即升级时，使用带 target_model_names 参数的显式请求调用文件列表，例如 GET /v1/files?target_model_names=my-gpt，该路径在修复前已被验证可正常工作。
检查返回值 ID 一致性：修复后如果列表返回的是原始 provider 的 file-* ID，需确认这些 ID 能否用于后续 managed 路由操作；如不能，需等待 #36031 的进一步修复，或者考虑在应用层做 ID 映射。
验证修复范围：升级后同时测试显式指定 provider（如 ?provider=openai、?custom_llm_provider=openai、custom-llm-provider header）的请求，确保这些路径也正常。

验证方法

升级或绕过修复后，使用与复现步骤相同的配置（不设置代理进程环境 OPENAI_API_KEY），执行 client.files.list()，确认返回 200 且列表只包含当前调用者的 managed 文件（不含其他用户文件）。同时可以运行上游验证测试（在隔离 venv 中、不加载 p72 代码），检查 afile_list(custom_llm_provider="openai") 不再抛出凭据相关异常。