[Bug]: Sub2API 原生 Grok OAuth 正常，但 OpenAI-compatible bridge 持续返回 429

[linhay]

问题模块

OpenAI API 兼容层（Responses / Chat Completions）与 Grok Build Provider 适配

相关 Provider

Grok Build

版本信息

3.1.4（Docker 镜像，amd64）

部署与运行环境

docker；Sub2API 通过 OpenAI-compatible API 调用 grok2api

问题描述

同一份 Grok OAuth 凭证直接配置到 Sub2API 的原生 Grok OAuth 账号时，请求稳定且不会出现该 429。

将同一份凭证导入 grok2api，并由 Sub2API 通过 OpenAI-compatible API 调用 grok2api 时，频繁出现 429。问题集中发生在 grok_build 路径，并非 OAuth 认证过期或配额耗尽。

复现步骤

1. 准备一份可用的 Grok OAuth 凭证。
2. 在 Sub2API 中配置为原生 platform=grok、OAuth 账号，发送相同模型请求，结果正常。
3. 将同一凭证导入 grok2api 的 Grok Build 账号，并通过 /v1/chat/completions 或 /v1/responses 调用。
4. 观察到请求先出现上游 429/504，随后 grok2api 审计中大量出现 upstream_cooling，attemptCount=0，并快速返回 429。

实际行为

• grok2api 的 /v1/chat/completions 和 /v1/responses 均可能返回 429。
• 失败审计显示 upstream_cooling，而不是每次都真正重新请求上游。
• 账号认证状态仍为 active，配额摘要仍有余量，但账号会进入不可用/冷却状态。

预期行为

• 同一 OAuth 凭证在原生 Grok 路径和 grok2api Grok Build 路径应具有一致的可用性，或明确记录两者所需的不同上游入口、请求头、模型名和客户端身份。
• 上游 429/504 后应按账号冷却并正确返回 Retry-After 或切换其他可用账号，避免冷却状态被放大为连续快速 429。
• 如果 OpenAI-compatible 转换对 Grok Build 有特殊限制，希望在文档中说明受支持的 endpoint、model mapping、streaming 参数和必要 headers。

调查线索

• Sub2API 侧错误均属于 upstream/provider/upstream_http，而非本地用户或配额限制。
• 事件窗口内 grok2api 记录到 241 条 429；其中审计可见 38 条为 upstream_cooling 快速拒绝。
• 另有少量 upstream_stream_incomplete，提示 Responses/Chat Completions 流式转换也可能需要关注。
• 详见相关问题 #902。

提交前检查

• 我已经搜索现有 Issue，确认本问题与 [Bug]: grok4.6 当额度请求完，经常性出现429，就结束了，没有自动切换到可用账号 #902 不完全相同。
• 已删除 Token、Cookie、API Key、账号凭据、请求正文、个人信息和服务器地址。
• 这不是需要私下披露的安全漏洞。