如果你也习惯在 Codex 里来回切模型大概率想过这个问题我切到另一个模型再切回来5 小时那个额度是不是就当无事发生重新计算了说真的我第一次冒这个念头时还挺激动要是真能这样等于把硬上限变成软上限。但实测下来想多了。Codex 的 5 小时限额和 Weekly Limit 是挂在账号维度上的计数器切换模型改的是请求里的 model 字段两个东西根本不在同一层。这篇文章就把 Codex 的额度体系是怎么记录的、切换模型到底碰不碰得到计数器、哪些情况会让你误以为额度被重置以及不同入口订阅版、CLI、第三方模型的额度差异一次性讲清楚适合所有在用 Codex 写代码、又总担心额度突然见底的人。1. Codex 的额度体系5小时与Weekly Limit是怎么被记录的1.1 5小时限制是滚动窗口不是固定时间段先说最容易误解的一点ChatGPT 订阅里的5 小时限制并不是每天某个固定 5 小时时段内只能用这么多而是一个滚动时间窗口。你每发出一条消息、每产生一次 Codex 调用这条记录就会被放进一个基于当前时间向前推 5 小时的计数窗口里。窗口里的记录数超过上限系统就拒绝新的请求直到最早那条记录滑出窗口。这个设计有点像地铁站的限流闸机不是说你一天总共只能进站多少次而是说在任意一个过去 5 小时的连续时间段里进站人数不能超过某个值。人走了闸机自然就松了。你 14:00 用的额度到了 19:01 就彻底从窗口里消失不占用 19:00 之后的任何空间。所以很多人的体验是明明感觉限额了睡一觉又好了不是有人在后台给你重置而是窗口自己滑过去了。1.2 Weekly Limit以7天为周期的滚动配额Weekly Limit 的思路和 5 小时窗口一样只是把时间尺度拉长到 7 天。它统计的是过去 168 小时内的累计使用量用来限制那些每天都没超限、但天天高强度用的重度用户。单独看 5 小时你可能觉得还好但叠加周维度后系统能更准确地判断一个账号的长期负载。这里有个关键点5 小时窗口和 Weekly Limit 是两套独立记录但你的一次调用会同时写进两套计数器。也就是说你发一条消息既影响小时窗口里的记录数也累加到周累计量里。任何绕过其中一套的做法另一套也会照样记账不存在钻空子的空间。1.3 限额统计的是消息数、用量点还是Token这可能是整个额度问题里最容易产生误会的部分。ChatGPT 订阅版的限额本质上按消息数 模型消耗倍率来算不是单纯数 token。比如你用一个高智能模型一条消息可能被折算成 2 条甚至 3 条普通消息的用量而 Codex 在会话里的一次次补全、报错重试同样会被折算进这个体系。API 那边则完全不一样按 RPM每分钟请求数和 TPM每分钟 token 数来做速率限制外加账户维度的 daily/weekly 用量上限。也就是说你人在网页版和 CLI 里感受到的限额根本是两套计算逻辑后面第 5 节我会专门展开。明白了这几点你再看切换模型会不会重置额度这个问题思路就清晰了一半既然都是账号服务端在记账那切换模型是否影响取决于它改的是不是服务端那本账。2. 切换模型后额度会不会重置底层判定逻辑2.1 额度计数器挂在账号维度不挂在模型维度我一开始也天真地以为每换一个模型服务端就单独开一本新账。实际上不是。Codex 的额度计数器挂在你的登录账号订阅版或 API KeyAPI/CLI 版上所有模型共用同一套记录。你在同一个账号里切 GPT-5.2、切 o3、切自定义模型发的每一条请求都会写进同一本账。打个比方额度是一张总银行卡模型是你在不同商户刷卡。你在 A 商户刷了 60% 的额度换到 B 商户继续刷B 商户看到的是同一张卡的余额而不是换了商户就重新给你充 100%。2.2 模型参数只是请求体里的一行字段理解这一点你就彻底不会再抱幻想了。你每次在 Codex 里发消息客户端往服务端发的是一个请求这个请求体里带有一堆字段其中有一个叫 model。你切换模型本质只是把请求体里的 model 字段值从gpt-5改成o3其他什么都没变。服务端收到请求后按流程处理先验证账号再查额度计数器最后才把 model 字段拿去路由到具体模型服务。也就是说model 字段是最后一个被用到的信息它根本不会触发额度窗口的创建或重置。计数器只会因为这个账号在这个时间窗口内消耗了多少而变化和这个账号用的是哪个模型无关。2.3 不重置是刻意的设计不是技术做不到有朋友可能会问技术上能不能做到按模型分开算额度能很多别的产品确实这么干比如有些平台套餐明确写着每种模型分开计算额度。但 Codex 在订阅版里刻意选择不这么做原因有两层第一防套利。如果切换模型就能重置额度那所有人都会在额度见底前疯狂切模型等于把订阅制变成无限额度这在成本上不可控。第二统一成本控制。OpenAI 要控制的是每个账号能给服务端带来多大负载而不是某个模型有多大负载。既然 5 小时窗口和 Weekly Limit 都是用来卡总体负载的那自然必须放在账号维度统一统计。所以结论很直接切换模型不会重置 5 小时窗口也不会重置 Weekly Limit。你切一万次模型该剩多少额度还是多少额度。3. 实测观察切换模型前后额度的真实变化3.1 我自己的测试方法光说不练没意思。我拿了一个接近限额的账号做了一轮实测方法是这样的在 ChatGPT 网页版打开 Codex用到一个额度明显变少的状态面板显示大概剩 15%然后在同一个会话里把模型从默认切到另一个模型再切回来间隔 1 分钟内连续操作。每次切换后立刻刷新用量面板记录剩余额度数字。我还额外做了一组对照切换模型的同时另开一个新会话对比新旧会话的额度显示是否一致排除会话状态影响额度的干扰因素。3.2 观察到的结果实测下来结果非常一致切模型前后面板显示的剩余额度百分比几乎没有变化偶尔出现一两个数字的波动也都是同一时刻并行请求产生的正常增量不是模型切换触发的重置。值得说明的是我在切换后确实见过一次剩余额度从 14% 跳到 16% 的情况。刚看到时愣了一下以为是切换模型后额度被回了一点。但紧接着刷新了一次又变回 14% 左右。这就是典型的界面显示抖动后面我会详细解释这类干扰因素。3.3 真正会让额度重新计算的场景那么哪些操作能让额度真正重置实测能触发的大概有三种一是切换账号。你从一个 ChatGPT 账号切到另一个账号服务端认的是新账号的用户 ID老账号的计数器自然不再起作用新账号有自己独立的一套 5 小时窗口和周累计量。二是切换 API Key。在 Codex CLI 里如果你从 Key A 换成 Key B两边各自拥有独立的速率限制账户额度互不影响。三是从订阅版切到自己的 API Key。订阅版的限额跟着登录态走API Key 的限额跟着 Key 走两套系统完全不同源。很多人感觉用 CLI 后额度变多了其实就是切到了另一套额度体系不是同一本账被充值。4. 那些让你误以为额度变了的干扰因素4.1 不同模型的用量倍率不同这是最大的干扰源。Codex 切换模型后你感觉额度变化了很多时候不是额度重置而是消耗速度变了。不同模型在订阅版里对应的用量倍率不一样普通模型发一条可能算 1 条旗舰模型发一条可能折算 2 到 3 条。你从高倍率模型切回低倍率模型同样的剩余额度用起来明显耐用了但从计数器角度讲额度一分钱都没多。反过来说你从低倍率模型切到高倍率模型会发现额度掉得飞快这是正常的不是系统在扣你旧账。很多用户抱怨我什么都没干额度没了大概率是切到高倍率模型后不知不觉多发了几条长消息。4.2 界面刷新延迟与服务端计数不同步ChatGPT 网页端的用量面板不是实时同步的它通常是定时刷新或者在你切页面时才拉取一次快照。你切换模型时客户端会重新请求使用量数据拉取到的可能是几十秒甚至几分钟前的缓存值。这就会造成切换后额度跳了一下的假象。你可以在切换后隔 10 秒再刷新一次页面对比如果数字又跳回切换前的水平那就说明第一次看到的只是缓存快照不是服务端真实状态。别被 UI 骗了判断额度变化要以多次刷新后的稳定值为准。4.3 多端登录和并发会话叠加消耗另一个隐蔽的干扰因素是多端同时使用。比如电脑上开着一个 Codex 会话没关手机上又开了一个两边同时在跑任务额度被两边同时消耗。你以为我就切了下模型怎么额度少了 10%其实是另一个端口的请求一直在扣账。我在实测时就踩过这个坑iPad 上的 ChatGPT 后台还在生成一个长回复我在电脑上切模型看额度数字掉了 3%。一开始以为是切换模型导致的后来把 iPad 那个会话停了再看额度不再变化才意识到是并发请求的叠加消耗。4.4 客户端切换模型时的会话状态异常顺带提一个和额度无关但容易引发误会的现象用第三方增强工具或客户端脚本切换模型时偶尔会出现原对话不停跳闪请求报错的情况。这类问题通常是客户端工具处理会话状态时出的 bug和额度统计没有任何关系但很多人会把它和切换模型影响额度联系在一起白白浪费排查时间。我建议遇到这类问题时先把工具升级到最新版再看服务端状态页面有没有异常公告。如果两者都正常那大概率是本地缓存或状态同步问题重启客户端基本能解决。5. 不同使用入口的额度差异订阅版、CLI与第三方模型5.1 ChatGPT 订阅版跟着登录账号走最常用的是 ChatGPT 网页版和桌面应用里的 Codex。这套入口的额度全部跟着你的订阅账号走5 小时窗口、周限额、用量倍率全部由 OpenAI 服务端在账号维度统一计算。你在这个入口切换模型改变不了任何计数逻辑。5.2 Codex CLI跟着 API Key 走如果你用 Codex CLI额度逻辑就完全不同了。CLI 属于开发者工具你可以把它配置成使用 ChatGPT 账号登录也可以配置成使用自己的 OpenAI API Key。用 API Key 时额度就是 API 账户的速率限制体系每分钟请求数、每分钟 token 数、账户总用量上限。这里同样不会因为切换模型而改变因为计数器挂在 Key 维度上不挂在模型上。需要注意API 的限额对单独一个 Key 和一个组织是分开的。如果你有多个 Key每个 Key 是独立计数的这和订阅版的一个账号统一计数是两回事。所以有些人的额度变多了其实是开了多个 Key 分摊了负载。5.3 接入第三方模型 API换了一套全新的额度体系这是最容易被混淆的场景。Codex CLI 本身支持配置自定义模型服务地址很多人会把它接到 DeepSeek、本地模型或其他兼容 API 上。这种情况下你虽然还在用 Codex 的客户端界面但服务端已经不是你登录的那个 OpenAI 账号了额度自然也不是那 5 小时和 Weekly Limit而是第三方服务的账户余额和速率限制。换句话说你在这种切换里感受到的额度变化是彻底换了本账本和标题里问的5 小时和 Weekly Limit 会不会变化根本不是一回事。如果你用的是第三方 API请直接去对应服务商的控制台看用量不要盯着 OpenAI 面板上的数字那已经和你无关了。6. 额度吃紧时的高效使用思路6.1 动手前先看剩余额度和模型倍率既然切换模型不能重置额度那你真正能优化的就只剩怎么让剩余额度更耐用这个方向。我的建议是开始任务前先花 10 秒看一眼用量面板评估当前剩下的额度够不够跑完整个任务。如果明显不够先把任务拆分而不是硬着头皮发起长会话然后在中途撞上 5 小时上限。另外要养成主动关注模型倍率的习惯。简单验证类、补全类的任务用低倍率模型就够了只有架构设计、复杂重构这类任务才值得上旗舰模型。省着用不是抠门而是理性分配。6.2 长任务拆分成短会话减少累计消耗5 小时窗口计的是消息数不是会话数但长会话里反复的上下文重传、报错重试、长回复生成都会快速增加消息消耗。把一个大任务拆成多个小会话每段聚焦一个明确目标既能降低单次会话的无效往返又方便你在中途看到额度走向及时调整策略。我自己常用的做法是先让 Codex 输出实现方案方案确认后再让它分文件落地最后再单独开一个会话做 review。这样每一个会话的输入输出都更精简额度消耗比一个会话死磕到底省很多。6.3 遇到限额后最该做的事如果你真的撞上了 5 小时上限最正确的做法是切到日常不常用的低优先级任务或者干脆停几分钟等窗口滑动而不是反复切换模型试探。切换模型对额度没有任何影响这个操作除了浪费时间没有意义。如果反复在短时间内撞上限那说明你当前的使用强度已经超出订阅套餐的正常范围。这时候合理的做法是考虑升级套餐、在 API 侧使用多个 Key 分流或者接入第三方模型把一部分负载迁移出去而不是找所谓的重置技巧。最后再分享一点个人经验我踩过最深的坑是把界面刷新延迟当成额度被重置又花了半小时去反复切换模型验证最后发现纯属白忙。现在我的习惯是任何额度判断都以服务端面板为准切换完模型先等 10 秒再刷新一次多刷新两轮确认数字稳定再下结论。额度这东西本质上就是服务端的一本账你在这个账号里做的所有操作都会被记进去。与其花心思找重置的旁门左道不如把精力放在更聪明的用量分配上这才是真正划算的玩法。