上周三我在 Cline 里跑一个批量代码脚本模型从openai/gpt-5.4-pro切到openai/gpt-5.5之后三分钟内吃了十几个 429。同样的 prompt、同样的并发数、同样的 Key——gpt-5.4-pro 一个错都没报。结论先给gpt-5.5 的 429 不是你额度用完了是它有两套独立的并发限速规则RPM TPM阈值比 gpt-5.4-pro 低很多两条线任何一条触发都会返回 429。解决方案要么降并发 加指数退避要么走聚合网关让平台侧帮你做请求队列调度。为什么会出现这个问题gpt-5.5 上线首周掘金和 GitHub 上大量开发者反馈同一个现象付费账户、余额充足、gpt-5.4-pro 正常跑换 gpt-5.5 就 429。原因是 OpenAI 对 gpt-5.5 设置了更严格的速率限制RPMRequests Per Minute和 TPMTokens Per Minute是两条独立的限制线——跟之前 gpt-5.4-pro 的宽松 RPM 宽松 TPM体验完全不同。限速触发时收到的报错长这样openai.RateLimitError: 429 Rate limit reached for gpt-5.5 headers: { retry-after: 20, x-ratelimit-limit-requests: 500 }注意 response header 里有两个关键字段x-ratelimit-limit-requestsRPM 上限和x-ratelimit-limit-tokensTPM 上限。gpt-5.5 这两个值都比 gpt-5.4-pro 低但报错信息都是 429不告诉你到底撞的是哪条线。补充说明OpenAI 的 429 实际上对应两种不同情况——速率限制Rate limit reached和账户配额耗尽You exceeded your current quota。本文讨论的是前者即 RPM/TPM 触顶与账户余额无关。两种情况的错误 message 文本不同可以通过 header 中x-ratelimit-remaining-requests是否为 0 来辅助判断。graph TD A[你的请求] -- B{检查 RPM} B --|未超限| C{检查 TPM} B --|超限| D[返回 429 retry-after] C --|未超限| E[正常响应] C --|超限| D两种 429 触发场景的区分方法以下是判断逻辑触发类型典型症状response header 线索常见场景RPM 限速短 prompt 高并发时秒触发x-ratelimit-remaining-requests: 0批量调用、for 循环不加 sleepTPM 限速长上下文/大输出时触发x-ratelimit-remaining-tokens: 0RAG 场景塞满 context、streaming 长回复怎么确认撞的是哪条看 429 响应的 headers// 在 catch 块里打印 headers console.log(e.headers[x-ratelimit-remaining-requests]); console.log(e.headers[x-ratelimit-remaining-tokens]);哪个是 0 就是哪条线触发的。实测下来gpt-5.5 的 RPM 上限大概是 gpt-5.4-pro 的 40%–60%具体数字 OpenAI 官方未公布统一文档不同 tier 不同Tier 3 账户实测 gpt-5.5 大约 500 RPMgpt-5.4-pro 同账户约 1000 RPM比值约 50%仅供参考。方案一客户端指数退避最基础openai-node v6.45.0 内置了自动重试但默认只重试 2 次、退避时间太短。自己包一层async function callWithBackoff(prompt: string, retries 5) { for (let i 0; i retries; i) { try { return await client.chat.completions.create( { model: gpt-5.5, messages: [{ role: user, content: prompt }] } ); } catch (e: any) { if (e?.status ! 429) throw e; const wait Math.min(2 ** i * 1000, 30000); await new Promise(r setTimeout(r, wait)); } } }关键点retry-afterheader 里的秒数要读别自己瞎算。OpenAI 返回retry-after: 20就等足 20 秒比自己用2^i算出来的更准。方案二降并发 令牌桶限流如果你是批量场景比如一次 50 个文件与其事后退避不如事前限流import pLimit from p-limit; const limit pLimit(3); // gpt-5.5 并发不超过 3 const results await Promise.all( files.map(f limit(() callWithBackoff(f.content))) );gpt-5.4-pro 开 10 并发没问题gpt-5.5 开到 5 就开始出现 429。目前稳定跑的配置是并发 3 指数退避基本不触发了。方案三走聚合网关的请求队列方案一二都是治标——代码里要到处加重试逻辑换个模型又得调参数。另一种做法是把请求走聚合 API 网关OpenRouter、ofox.io 这类让网关侧帮你做队列调度和限流平滑。改动量就一行 base_urlfrom openai import OpenAI client OpenAI( api_keyyour-key, base_urlhttps://api.ofox.io/v1 )网关的好处是它在服务端维护了多个上游通道的 RPM/TPM 水位你的请求打过去它会自动排队而不是直接返回 429。OpenRouter 和 ofox.io 都支持 gpt-5.5两者的费率结构和队列调度策略建议使用前自行查阅官方文档确认以实际公布为准。切过去之后 429 的频率从每分钟 3–4 次降到了一天偶尔 1 次。gpt-5.5 vs gpt-5.4-pro 速率限制差异维度gpt-5.4-proTier 3 实测gpt-5.5Tier 3 实测备注RPM~1000~500OpenAI 官方未公布统一数字以 header 返回为准TPM~150K~80K同上retry-after 典型值5–10s15–30sgpt-5.5 退避要求更长并发安全线经验值8–103–4超过就开始出现 429以上数据为个人实测不同 tier 差异很大仅供参考。OpenAI 的限速策略随时在调当前数字可能已有变化建议以实际 header 返回值为准。常见问题 FAQQ: 我是 Tier 4 / Tier 5 账户gpt-5.5 也会被限流吗会。Tier 越高阈值越高但 gpt-5.5 相对于同 tier 的 gpt-5.4-pro 仍然更低。有 Tier 5 用户反馈 gpt-5.5 RPM 约 1500gpt-5.4-pro 同 tier 约 3500但该数据来源为社区讨论未经官方确认仅供量级参考。Q: 429 报错里的retry-after到底要不要信要信。这是服务端算出来的最短等待时间比自己2^i * 1000更准。读法parseInt(e.headers[retry-after])单位是秒。Q: 用 Cline 这类工具调 gpt-5.5 怎么配退避Cline 的settings.json中与重试相关的字段名称建议以 Cline 官方文档 为准社区流传的字段名存在版本差异。如果工具本身不支持自定义退避参数可以通过将 base_url 指向带队列功能的网关来间接解决。Q: 我怎么知道我当前的 RPM/TPM 剩余额度每个成功响应的 header 里都有x-ratelimit-remaining-requests: 487 x-ratelimit-remaining-tokens: 72340在代码里打印这两个值低于 10% 就主动 sleep别等 429 了再退避。Q: 切到聚合网关之后还会收到 429 吗偶尔会但频率极低。网关帮你平滑了请求峰值但如果上游 OpenAI 本身全局限流比如模型刚上线负载爆了网关也扛不住。这时候 header 里会带x-ratelimit-reset-requests告诉你什么时候恢复。最终配置小结目前稳定跑的方案base_url 指向聚合网关让平台帮排队客户端仍然保留指数退避兜底并发硬限制 3p-limit每 100 个请求打印一次x-ratelimit-remaining-*监控水位gpt-5.5 的输出质量确实比 gpt-5.4-pro 好一截但这个限流策略让批量场景的吞吐量明显下降。希望 OpenAI 后续把 Tier 3 的额度往上调调不然批量 pipeline 场景的体验会比较受限。