上周三我在 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 设置了更严格的速率限制，RPM（Requests Per Minute）和 TPM（Tokens 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-requests（RPM 上限）和x-ratelimit-limit-tokens（TPM 上限）。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 触发场景的区分方法

以下是判断逻辑：

怎么确认撞的是哪条？看 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 RPM，gpt-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_url：

from openai import OpenAI client = OpenAI( api_key="your-key", base_url="https://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 速率限制差异

以上数据为个人实测，不同 tier 差异很大，仅供参考。OpenAI 的限速策略随时在调，当前数字可能已有变化，建议以实际 header 返回值为准。

常见问题 FAQ

Q: 我是 Tier 4 / Tier 5 账户，gpt-5.5 也会被限流吗？

会。Tier 越高阈值越高，但 gpt-5.5 相对于同 tier 的 gpt-5.4-pro 仍然更低。有 Tier 5 用户反馈 gpt-5.5 RPM 约 1500（gpt-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告诉你什么时候恢复。

最终配置小结

目前稳定跑的方案：

1. base_url 指向聚合网关（让平台帮排队）
2. 客户端仍然保留指数退避（兜底）
3. 并发硬限制 3（p-limit）
4. 每 100 个请求打印一次x-ratelimit-remaining-*，监控水位

gpt-5.5 的输出质量确实比 gpt-5.4-pro 好一截，但这个限流策略让批量场景的吞吐量明显下降。希望 OpenAI 后续把 Tier 3 的额度往上调调，不然批量 pipeline 场景的体验会比较受限。