如果你也習(xí)慣在 Codex 里來回切模型大概率想過這個(gè)問題我切到另一個(gè)模型再切回來5 小時(shí)那個(gè)額度是不是就當(dāng)無事發(fā)生重新計(jì)算了說真的我第一次冒這個(gè)念頭時(shí)還挺激動(dòng)要是真能這樣等于把硬上限變成軟上限。但實(shí)測下來想多了。Codex 的 5 小時(shí)限額和 Weekly Limit 是掛在賬號(hào)維度上的計(jì)數(shù)器切換模型改的是請(qǐng)求里的 model 字段兩個(gè)東西根本不在同一層。這篇文章就把 Codex 的額度體系是怎么記錄的、切換模型到底碰不碰得到計(jì)數(shù)器、哪些情況會(huì)讓你誤以為額度被重置以及不同入口訂閱版、CLI、第三方模型的額度差異一次性講清楚適合所有在用 Codex 寫代碼、又總擔(dān)心額度突然見底的人。1. Codex 的額度體系5小時(shí)與Weekly Limit是怎么被記錄的1.1 5小時(shí)限制是滾動(dòng)窗口不是固定時(shí)間段先說最容易誤解的一點(diǎn)ChatGPT 訂閱里的5 小時(shí)限制并不是每天某個(gè)固定 5 小時(shí)時(shí)段內(nèi)只能用這么多而是一個(gè)滾動(dòng)時(shí)間窗口。你每發(fā)出一條消息、每產(chǎn)生一次 Codex 調(diào)用這條記錄就會(huì)被放進(jìn)一個(gè)基于當(dāng)前時(shí)間向前推 5 小時(shí)的計(jì)數(shù)窗口里。窗口里的記錄數(shù)超過上限系統(tǒng)就拒絕新的請(qǐng)求直到最早那條記錄滑出窗口。這個(gè)設(shè)計(jì)有點(diǎn)像地鐵站的限流閘機(jī)不是說你一天總共只能進(jìn)站多少次而是說在任意一個(gè)過去 5 小時(shí)的連續(xù)時(shí)間段里進(jìn)站人數(shù)不能超過某個(gè)值。人走了閘機(jī)自然就松了。你 14:00 用的額度到了 19:01 就徹底從窗口里消失不占用 19:00 之后的任何空間。所以很多人的體驗(yàn)是明明感覺限額了睡一覺又好了不是有人在后臺(tái)給你重置而是窗口自己滑過去了。1.2 Weekly Limit以7天為周期的滾動(dòng)配額Weekly Limit 的思路和 5 小時(shí)窗口一樣只是把時(shí)間尺度拉長到 7 天。它統(tǒng)計(jì)的是過去 168 小時(shí)內(nèi)的累計(jì)使用量用來限制那些每天都沒超限、但天天高強(qiáng)度用的重度用戶。單獨(dú)看 5 小時(shí)你可能覺得還好但疊加周維度后系統(tǒng)能更準(zhǔn)確地判斷一個(gè)賬號(hào)的長期負(fù)載。這里有個(gè)關(guān)鍵點(diǎn)5 小時(shí)窗口和 Weekly Limit 是兩套獨(dú)立記錄但你的一次調(diào)用會(huì)同時(shí)寫進(jìn)兩套計(jì)數(shù)器。也就是說你發(fā)一條消息既影響小時(shí)窗口里的記錄數(shù)也累加到周累計(jì)量里。任何繞過其中一套的做法另一套也會(huì)照樣記賬不存在鉆空子的空間。1.3 限額統(tǒng)計(jì)的是消息數(shù)、用量點(diǎn)還是Token這可能是整個(gè)額度問題里最容易產(chǎn)生誤會(huì)的部分。ChatGPT 訂閱版的限額本質(zhì)上按消息數(shù) 模型消耗倍率來算不是單純數(shù) token。比如你用一個(gè)高智能模型一條消息可能被折算成 2 條甚至 3 條普通消息的用量而 Codex 在會(huì)話里的一次次補(bǔ)全、報(bào)錯(cuò)重試同樣會(huì)被折算進(jìn)這個(gè)體系。API 那邊則完全不一樣按 RPM每分鐘請(qǐng)求數(shù)和 TPM每分鐘 token 數(shù)來做速率限制外加賬戶維度的 daily/weekly 用量上限。也就是說你人在網(wǎng)頁版和 CLI 里感受到的限額根本是兩套計(jì)算邏輯后面第 5 節(jié)我會(huì)專門展開。明白了這幾點(diǎn)你再看切換模型會(huì)不會(huì)重置額度這個(gè)問題思路就清晰了一半既然都是賬號(hào)服務(wù)端在記賬那切換模型是否影響取決于它改的是不是服務(wù)端那本賬。2. 切換模型后額度會(huì)不會(huì)重置底層判定邏輯2.1 額度計(jì)數(shù)器掛在賬號(hào)維度不掛在模型維度我一開始也天真地以為每換一個(gè)模型服務(wù)端就單獨(dú)開一本新賬。實(shí)際上不是。Codex 的額度計(jì)數(shù)器掛在你的登錄賬號(hào)訂閱版或 API KeyAPI/CLI 版上所有模型共用同一套記錄。你在同一個(gè)賬號(hào)里切 GPT-5.2、切 o3、切自定義模型發(fā)的每一條請(qǐng)求都會(huì)寫進(jìn)同一本賬。打個(gè)比方額度是一張總銀行卡模型是你在不同商戶刷卡。你在 A 商戶刷了 60% 的額度換到 B 商戶繼續(xù)刷B 商戶看到的是同一張卡的余額而不是換了商戶就重新給你充 100%。2.2 模型參數(shù)只是請(qǐng)求體里的一行字段理解這一點(diǎn)你就徹底不會(huì)再抱幻想了。你每次在 Codex 里發(fā)消息客戶端往服務(wù)端發(fā)的是一個(gè)請(qǐng)求這個(gè)請(qǐng)求體里帶有一堆字段其中有一個(gè)叫 model。你切換模型本質(zhì)只是把請(qǐng)求體里的 model 字段值從gpt-5改成o3其他什么都沒變。服務(wù)端收到請(qǐng)求后按流程處理先驗(yàn)證賬號(hào)再查額度計(jì)數(shù)器最后才把 model 字段拿去路由到具體模型服務(wù)。也就是說model 字段是最后一個(gè)被用到的信息它根本不會(huì)觸發(fā)額度窗口的創(chuàng)建或重置。計(jì)數(shù)器只會(huì)因?yàn)檫@個(gè)賬號(hào)在這個(gè)時(shí)間窗口內(nèi)消耗了多少而變化和這個(gè)賬號(hào)用的是哪個(gè)模型無關(guān)。2.3 不重置是刻意的設(shè)計(jì)不是技術(shù)做不到有朋友可能會(huì)問技術(shù)上能不能做到按模型分開算額度能很多別的產(chǎn)品確實(shí)這么干比如有些平臺(tái)套餐明確寫著每種模型分開計(jì)算額度。但 Codex 在訂閱版里刻意選擇不這么做原因有兩層第一防套利。如果切換模型就能重置額度那所有人都會(huì)在額度見底前瘋狂切模型等于把訂閱制變成無限額度這在成本上不可控。第二統(tǒng)一成本控制。OpenAI 要控制的是每個(gè)賬號(hào)能給服務(wù)端帶來多大負(fù)載而不是某個(gè)模型有多大負(fù)載。既然 5 小時(shí)窗口和 Weekly Limit 都是用來卡總體負(fù)載的那自然必須放在賬號(hào)維度統(tǒng)一統(tǒng)計(jì)。所以結(jié)論很直接切換模型不會(huì)重置 5 小時(shí)窗口也不會(huì)重置 Weekly Limit。你切一萬次模型該剩多少額度還是多少額度。3. 實(shí)測觀察切換模型前后額度的真實(shí)變化3.1 我自己的測試方法光說不練沒意思。我拿了一個(gè)接近限額的賬號(hào)做了一輪實(shí)測方法是這樣的在 ChatGPT 網(wǎng)頁版打開 Codex用到一個(gè)額度明顯變少的狀態(tài)面板顯示大概剩 15%然后在同一個(gè)會(huì)話里把模型從默認(rèn)切到另一個(gè)模型再切回來間隔 1 分鐘內(nèi)連續(xù)操作。每次切換后立刻刷新用量面板記錄剩余額度數(shù)字。我還額外做了一組對(duì)照切換模型的同時(shí)另開一個(gè)新會(huì)話對(duì)比新舊會(huì)話的額度顯示是否一致排除會(huì)話狀態(tài)影響額度的干擾因素。3.2 觀察到的結(jié)果實(shí)測下來結(jié)果非常一致切模型前后面板顯示的剩余額度百分比幾乎沒有變化偶爾出現(xiàn)一兩個(gè)數(shù)字的波動(dòng)也都是同一時(shí)刻并行請(qǐng)求產(chǎn)生的正常增量不是模型切換觸發(fā)的重置。值得說明的是我在切換后確實(shí)見過一次剩余額度從 14% 跳到 16% 的情況。剛看到時(shí)愣了一下以為是切換模型后額度被回了一點(diǎn)。但緊接著刷新了一次又變回 14% 左右。這就是典型的界面顯示抖動(dòng)后面我會(huì)詳細(xì)解釋這類干擾因素。3.3 真正會(huì)讓額度重新計(jì)算的場景那么哪些操作能讓額度真正重置實(shí)測能觸發(fā)的大概有三種一是切換賬號(hào)。你從一個(gè) ChatGPT 賬號(hào)切到另一個(gè)賬號(hào)服務(wù)端認(rèn)的是新賬號(hào)的用戶 ID老賬號(hào)的計(jì)數(shù)器自然不再起作用新賬號(hào)有自己獨(dú)立的一套 5 小時(shí)窗口和周累計(jì)量。二是切換 API Key。在 Codex CLI 里如果你從 Key A 換成 Key B兩邊各自擁有獨(dú)立的速率限制賬戶額度互不影響。三是從訂閱版切到自己的 API Key。訂閱版的限額跟著登錄態(tài)走API Key 的限額跟著 Key 走兩套系統(tǒng)完全不同源。很多人感覺用 CLI 后額度變多了其實(shí)就是切到了另一套額度體系不是同一本賬被充值。4. 那些讓你誤以為額度變了的干擾因素4.1 不同模型的用量倍率不同這是最大的干擾源。Codex 切換模型后你感覺額度變化了很多時(shí)候不是額度重置而是消耗速度變了。不同模型在訂閱版里對(duì)應(yīng)的用量倍率不一樣普通模型發(fā)一條可能算 1 條旗艦?zāi)Ｐ桶l(fā)一條可能折算 2 到 3 條。你從高倍率模型切回低倍率模型同樣的剩余額度用起來明顯耐用了但從計(jì)數(shù)器角度講額度一分錢都沒多。反過來說你從低倍率模型切到高倍率模型會(huì)發(fā)現(xiàn)額度掉得飛快這是正常的不是系統(tǒng)在扣你舊賬。很多用戶抱怨我什么都沒干額度沒了大概率是切到高倍率模型后不知不覺多發(fā)了幾條長消息。4.2 界面刷新延遲與服務(wù)端計(jì)數(shù)不同步ChatGPT 網(wǎng)頁端的用量面板不是實(shí)時(shí)同步的它通常是定時(shí)刷新或者在你切頁面時(shí)才拉取一次快照。你切換模型時(shí)客戶端會(huì)重新請(qǐng)求使用量數(shù)據(jù)拉取到的可能是幾十秒甚至幾分鐘前的緩存值。這就會(huì)造成切換后額度跳了一下的假象。你可以在切換后隔 10 秒再刷新一次頁面對(duì)比如果數(shù)字又跳回切換前的水平那就說明第一次看到的只是緩存快照不是服務(wù)端真實(shí)狀態(tài)。別被 UI 騙了判斷額度變化要以多次刷新后的穩(wěn)定值為準(zhǔn)。4.3 多端登錄和并發(fā)會(huì)話疊加消耗另一個(gè)隱蔽的干擾因素是多端同時(shí)使用。比如電腦上開著一個(gè) Codex 會(huì)話沒關(guān)手機(jī)上又開了一個(gè)兩邊同時(shí)在跑任務(wù)額度被兩邊同時(shí)消耗。你以為我就切了下模型怎么額度少了 10%其實(shí)是另一個(gè)端口的請(qǐng)求一直在扣賬。我在實(shí)測時(shí)就踩過這個(gè)坑iPad 上的 ChatGPT 后臺(tái)還在生成一個(gè)長回復(fù)我在電腦上切模型看額度數(shù)字掉了 3%。一開始以為是切換模型導(dǎo)致的后來把 iPad 那個(gè)會(huì)話停了再看額度不再變化才意識(shí)到是并發(fā)請(qǐng)求的疊加消耗。4.4 客戶端切換模型時(shí)的會(huì)話狀態(tài)異常順帶提一個(gè)和額度無關(guān)但容易引發(fā)誤會(huì)的現(xiàn)象用第三方增強(qiáng)工具或客戶端腳本切換模型時(shí)偶爾會(huì)出現(xiàn)原對(duì)話不停跳閃請(qǐng)求報(bào)錯(cuò)的情況。這類問題通常是客戶端工具處理會(huì)話狀態(tài)時(shí)出的 bug和額度統(tǒng)計(jì)沒有任何關(guān)系但很多人會(huì)把它和切換模型影響額度聯(lián)系在一起白白浪費(fèi)排查時(shí)間。我建議遇到這類問題時(shí)先把工具升級(jí)到最新版再看服務(wù)端狀態(tài)頁面有沒有異常公告。如果兩者都正常那大概率是本地緩存或狀態(tài)同步問題重啟客戶端基本能解決。5. 不同使用入口的額度差異訂閱版、CLI與第三方模型5.1 ChatGPT 訂閱版跟著登錄賬號(hào)走最常用的是 ChatGPT 網(wǎng)頁版和桌面應(yīng)用里的 Codex。這套入口的額度全部跟著你的訂閱賬號(hào)走5 小時(shí)窗口、周限額、用量倍率全部由 OpenAI 服務(wù)端在賬號(hào)維度統(tǒng)一計(jì)算。你在這個(gè)入口切換模型改變不了任何計(jì)數(shù)邏輯。5.2 Codex CLI跟著 API Key 走如果你用 Codex CLI額度邏輯就完全不同了。CLI 屬于開發(fā)者工具你可以把它配置成使用 ChatGPT 賬號(hào)登錄也可以配置成使用自己的 OpenAI API Key。用 API Key 時(shí)額度就是 API 賬戶的速率限制體系每分鐘請(qǐng)求數(shù)、每分鐘 token 數(shù)、賬戶總用量上限。這里同樣不會(huì)因?yàn)榍袚Q模型而改變因?yàn)橛?jì)數(shù)器掛在 Key 維度上不掛在模型上。需要注意API 的限額對(duì)單獨(dú)一個(gè) Key 和一個(gè)組織是分開的。如果你有多個(gè) Key每個(gè) Key 是獨(dú)立計(jì)數(shù)的這和訂閱版的一個(gè)賬號(hào)統(tǒng)一計(jì)數(shù)是兩回事。所以有些人的額度變多了其實(shí)是開了多個(gè) Key 分?jǐn)偭素?fù)載。5.3 接入第三方模型 API換了一套全新的額度體系這是最容易被混淆的場景。Codex CLI 本身支持配置自定義模型服務(wù)地址很多人會(huì)把它接到 DeepSeek、本地模型或其他兼容 API 上。這種情況下你雖然還在用 Codex 的客戶端界面但服務(wù)端已經(jīng)不是你登錄的那個(gè) OpenAI 賬號(hào)了額度自然也不是那 5 小時(shí)和 Weekly Limit而是第三方服務(wù)的賬戶余額和速率限制。換句話說你在這種切換里感受到的額度變化是徹底換了本賬本和標(biāo)題里問的5 小時(shí)和 Weekly Limit 會(huì)不會(huì)變化根本不是一回事。如果你用的是第三方 API請(qǐng)直接去對(duì)應(yīng)服務(wù)商的控制臺(tái)看用量不要盯著 OpenAI 面板上的數(shù)字那已經(jīng)和你無關(guān)了。6. 額度吃緊時(shí)的高效使用思路6.1 動(dòng)手前先看剩余額度和模型倍率既然切換模型不能重置額度那你真正能優(yōu)化的就只剩怎么讓剩余額度更耐用這個(gè)方向。我的建議是開始任務(wù)前先花 10 秒看一眼用量面板評(píng)估當(dāng)前剩下的額度夠不夠跑完整個(gè)任務(wù)。如果明顯不夠先把任務(wù)拆分而不是硬著頭皮發(fā)起長會(huì)話然后在中途撞上 5 小時(shí)上限。另外要養(yǎng)成主動(dòng)關(guān)注模型倍率的習(xí)慣。簡單驗(yàn)證類、補(bǔ)全類的任務(wù)用低倍率模型就夠了只有架構(gòu)設(shè)計(jì)、復(fù)雜重構(gòu)這類任務(wù)才值得上旗艦?zāi)Ｐ汀Ｊ≈貌皇菗搁T而是理性分配。6.2 長任務(wù)拆分成短會(huì)話減少累計(jì)消耗5 小時(shí)窗口計(jì)的是消息數(shù)不是會(huì)話數(shù)但長會(huì)話里反復(fù)的上下文重傳、報(bào)錯(cuò)重試、長回復(fù)生成都會(huì)快速增加消息消耗。把一個(gè)大任務(wù)拆成多個(gè)小會(huì)話每段聚焦一個(gè)明確目標(biāo)既能降低單次會(huì)話的無效往返又方便你在中途看到額度走向及時(shí)調(diào)整策略。我自己常用的做法是先讓 Codex 輸出實(shí)現(xiàn)方案方案確認(rèn)后再讓它分文件落地最后再單獨(dú)開一個(gè)會(huì)話做 review。這樣每一個(gè)會(huì)話的輸入輸出都更精簡額度消耗比一個(gè)會(huì)話死磕到底省很多。6.3 遇到限額后最該做的事如果你真的撞上了 5 小時(shí)上限最正確的做法是切到日常不常用的低優(yōu)先級(jí)任務(wù)或者干脆停幾分鐘等窗口滑動(dòng)而不是反復(fù)切換模型試探。切換模型對(duì)額度沒有任何影響這個(gè)操作除了浪費(fèi)時(shí)間沒有意義。如果反復(fù)在短時(shí)間內(nèi)撞上限那說明你當(dāng)前的使用強(qiáng)度已經(jīng)超出訂閱套餐的正常范圍。這時(shí)候合理的做法是考慮升級(jí)套餐、在 API 側(cè)使用多個(gè) Key 分流或者接入第三方模型把一部分負(fù)載遷移出去而不是找所謂的重置技巧。最后再分享一點(diǎn)個(gè)人經(jīng)驗(yàn)我踩過最深的坑是把界面刷新延遲當(dāng)成額度被重置又花了半小時(shí)去反復(fù)切換模型驗(yàn)證最后發(fā)現(xiàn)純屬白忙?，F(xiàn)在我的習(xí)慣是任何額度判斷都以服務(wù)端面板為準(zhǔn)切換完模型先等 10 秒再刷新一次多刷新兩輪確認(rèn)數(shù)字穩(wěn)定再下結(jié)論。額度這東西本質(zhì)上就是服務(wù)端的一本賬你在這個(gè)賬號(hào)里做的所有操作都會(huì)被記進(jìn)去。與其花心思找重置的旁門左道不如把精力放在更聰明的用量分配上這才是真正劃算的玩法。