429里带rate_limit字样的是限流不是没钱：你单位时间打得太快或令牌吞吐太高，先用退避重试和队列把速度降下来，长期不够再去提等级和限额。
先和额度不足分清
现象：同样是429，有时等一会就好，有时等一天也不好。
原因：限流的错误码写的是请求频率超限，过一分钟配额就回来了；额度不足写的是配额问题，是钱包和上限的事，等多久都不会自愈。
怎么办：先看报错里的类型字样再动手，是限流就按本文降速，是配额就去查余额和绑卡，两件事不要混治。
它同时卡请求数和令牌数
现象：每分钟请求数明明不多，还是被限流。
原因：限額是双指标的，除了每分钟请求数，还有每分钟令牌数，长提示词加长输出，几次调用就能把令牌那条线打满。
怎么办：去限额页面把自己这个模型的两个上限都记下来，估算时用单次平均令牌乘以并发量，两边都留两成余量，不要只盯请求条数。
新账号的上限天生低
现象：刚接接口，稍微并发一点就满屏429。
原因：用量按等级发放，新账号在最低档，每分钟的请求和令牌上限都很小，正常消费和付款记录攒够了才会自动升档。
怎么办：起步阶段按低配设计程序，并发先压到个位数，随着真实消费稳定增长再逐步放开，不要第一天就按成品的量级压测。
没有退避的重试最伤
现象：一次限流之后，报错像雪崩一样越来越多。
原因：很多程序一失败就立刻原速重试，多台机器同时重试等于在限流口上继续加压，还会把刚恢复的配额瞬间打空。
怎么办：改成指数退避加随机抖动，第一次等一两秒，后面成倍拉长，并给重试设总次数上限；优先读响应头里的剩余量和建议等待时间，按它给的节奏来。
给请求排队削峰
现象：业务一到高峰时段就必然触发限流。
原因：流量是尖峰型的，一秒涌进来的量远超每分钟均摊的上限，平均值看着明明没超。
怎么办：在调用前加一层队列和令牌桶，把并发数设成固定值匀速放行，急的请求走实时队列，不急的攒一批延后处理，峰削平了，429自然就少了。
从令牌侧省额度
现象：请求数压下来了，令牌那条还是先到顶。
原因：超长上下文每次全量重发、输出不设上限，令牌消耗比请求数涨得快得多。
怎么办：给输出长度设明确上限，长对话只带必要的摘要，重复的前缀内容用缓存，批量又不急的任务走批处理通道，既慢不了大事，还能把实时额度让给前台请求。
长期不够就提限额
现象：降速和省量都做了，正常业务量还是天天贴着上限跑。
原因：这说明是真不够用，不是程序问题，等级和限额需要靠消费记录和申请往上提。
怎么办：在限额页面确认当前等级，消费达标会自动升档仍不够的，按页面入口提交提额申请，理由写清业务场景和增长量；等审批期间继续用队列顶住，不要硬闯。
常见问答
429会持续多久？
按分钟计算的限额滚动恢复，通常几十秒到一分钟就回血，前提是这期间别继续猛打。
多建几个密钥轮着用能绕吗？
不能，限额按组织和模型算不按密钥算，轮密钥只会把程序搞复杂，官方也可能判定为规避限额。
升档要多久？
看累计消费和付款时长是否达标，以限额页面的等级说明为准，达标后自动生效，不需要人工催。