Codex 額度用太快？用一段指令找出消耗原因

你請 Codex 改幾段文字、整理一張表，工作還沒做多少，Codex 額度卻掉了一大截。回頭看聊天，它好像一直在讀檔、檢查、重試，卻很難說出哪一步花得最多。這時可以先讓 Codex 分析自己的工作紀錄，找出值得調整的地方。

我會先把「帳號還剩多少可用量」與「哪些工作做得多」分開看，再給你一段可以直接貼進自己 Codex 的完整指令。你不用先寫程式；分析完成後，重點是看懂有證據的原因，選一個動作改善，下次用相近工作驗證。

先看官方用量頁，再查工作紀錄

Codex 額度是訂閱方案在指定期間提供的工作用量，剩餘比例與重置時間可以從官方用量頁查看。每次任務處理多少資料、採用什麼模型及執行方式，都會影響用量；因此，光看你輸入的那一句話有多短，很難解釋整件工作的消耗。OpenAI 用量與定價說明

例如，同樣是「幫我改這份報告」，一次只改指定段落，另一次卻重新找資料、改全文、重做圖片，再檢查整份成果，實際工作就差很多。分析 Codex 額度時，值得追的是後面發生了哪些事。

記下目前可用的 Codex 額度

先登入自己的Codex 官方用量頁，記下畫面顯示的剩餘比例、下次重置時間，以及截圖或記錄的時間。使用 Codex CLI 的人，也可以在該終端機工作階段輸入 /status 查看狀態。OpenAI CLI 指令說明

這份記錄回答的是「我現在還能用多少」。如果你已經碰到限制，今天急著把工作做完，可以先看Codex 額度用完的處理方式；下面的分析則幫你找出之後要調整哪一種工作習慣。

工作紀錄用來找出哪件事做得多

Codex 處理文字時，會以 token 作為讀寫資訊的計量單位。除了你的提問，檔案內容、聊天歷史、工具回傳及模型回答也可能構成工作量。本機可讀紀錄中的 token，適合拿來找出需要進一步查看的任務；帳號可用比例則由官方用量頁確認。OpenAI 對 tokens 與用量的說明

例如，報告顯示某次整理資料的可見 token 明顯較多，你就能請 Codex 回看那個任務：是否讀了整批原始檔？同一份長表格是否回傳多次？這些線索能定位工作發生在哪裡，本機 token 不能直接換算成訂閱額度百分比或 API 帳單。

分析時也要寫明實際讀到了哪些紀錄。你在另一台電腦或雲端做的工作，以及已刪除、未留存的聊天，都可能形成缺口。報告中的 unknown 就是「這一欄資料未知」，保留它才能看清分析涵蓋的範圍。

網路上常見的 Codex 額度檢查做法，怎麼選？

先看剩餘用量，再找工作量集中的任務，最後回看事件解釋原因，這三件事需要的資料各有用途。官方介面看帳戶額度；本機統計看保留下來的工作；聊天中的執行事件，則用來判斷哪些動作值得改善。

例如，你想知道今晚還能不能繼續做簡報，就先開官方用量頁；想找昨天哪個任務讀寫資訊最多，就查本機統計；想知道為何同一份簡報重做三次，再回看那個任務的事件。接下來三種方法，可以依這個順序選。

官方介面：確認還剩多少 Codex 額度

只想開始診斷，就用前面的官方用量頁配合下方完整指令。若目前環境已有可讀的官方帳戶用量工具，也可以沿用；先請 Codex 說明讀到的是帳戶剩餘額度，還是聊天的 token 計數。兩者的用途，分別對應「還能用多少」與「這份紀錄處理多少資訊」。OpenAI 帳戶用量介面說明

ccusage：把本機紀錄整理成每日與任務統計

ccusage 是讀取本機工作紀錄、整理用量報表的工具。它的 Codex 資料來源會查 CODEX_HOME 指定的資料根目錄，預設為 ~/.codex，並讀取其中的 sessions 與 archived_sessions。報表涵蓋已保留且格式可讀的紀錄，缺少的設備或雲端工作另列未知。ccusage 的 Codex 資料說明

已安裝 ccusage、也會用終端機的人，可以先執行以下兩行，查看本機版本是否支援本文使用的選項。下方命令依 2026 年 11 月 7 日專案文件整理，本文未安裝或實跑這些工具；版本不符時，回到完整指令，讓 Codex 用現有可讀資料分析。

ccusage codex daily --help
ccusage codex session --help

若本機說明有列出這些選項，以下以台北時區示範：在 2026 年 11 月 7 日查看，最近七個完整日是 10 月 31 日至 11 月 6 日。請把兩行中的日期與 Asia/Taipei 換成自己的範圍和時區；起訖日期都包含當日。

ccusage codex daily --since 2026-10-31 --until 2026-11-06 --timezone Asia/Taipei --offline --json --no-cost
ccusage codex session --since 2026-10-31 --until 2026-11-06 --timezone Asia/Taipei --offline --json --no-cost

daily 用來看哪天較多，session 用來找要回看的工作階段。--offline 採離線模式，--json 讓 Codex 方便整理欄位，--no-cost 移除估算費用。這裡明列日期，是因為 --last 7 會包含今天。ccusage 日期與輸出選項

CodexBar：經常需要一眼查看剩餘用量

CodexBar 適合想常駐查看額度的人，專案提供 macOS、Linux 與 CLI 相關版本，Windows 使用者可先沿用官方介面。選用時，把畫面上的帳戶額度與本機估算費用分開讀；原因診斷仍交給任務紀錄與事件證據。CodexBar 專案、帳戶額度與本機統計的範圍

對多數只是想找出 Codex 額度消耗原因的讀者，我建議先貼下一節的指令。已有 ccusage 就沿用統計；需要長期提醒，再評估 CodexBar。先取得自己任務的證據，會比同時準備多套工具更快進入問題。

複製這段指令，分析最近七天的 Codex 額度問題

打開你平常使用的 Codex，將下面整段指令貼進一則新聊天。指令會先找目前有權限讀取的資料，整理可見工作量，再挑最多五個高耗用任務查看相關片段。第一次執行先維持七天，讓分析停留在一個可以看完的範圍。

這次只分析並提出建議，原本的設定與工作檔案保留。如果 Codex 讀不到官方用量頁，就依報告列出的欄位補上剩餘比例、重置時間與截圖時間；它仍可以先分析已取得的本機紀錄。

請幫我分析「Codex 額度為什麼用得太快」，這次只做小範圍唯讀診斷，最後給我看得懂的報告。請直接開始，不要先重跑我原本的工作。

【範圍】
1. 分析最近 7 個完整日，以我電腦的當地時區計算，先寫出時區、起訖日期與時間。今天尚未結束的資料另列，不混入主比較。
2. 資料入口依序使用：目前有權限讀取的官方用量頁／官方帳戶工具、既有本機統計工具、本機工作紀錄。先交代每項是帳戶額度、token 統計或事件資料。具備本機檔案能力時，確認實際 CODEX_HOME 與其中 sessions、archived_sessions 的存在和可讀期間；未設定時才查預設 ~/.codex。找不到就標 unknown，不讀認證檔，也不把資料根目錄或 daily/session 統計當作官方帳戶額度。
3. 已有 ccusage 時，先查本機 daily/session 的 help 與版本；支援日期、時區及 --offline --json --no-cost 才用這些選項取資料，寫出實際命令與工具版本。沒有相容工具就用現有本機腳本抽取必要欄位，不自動下載或安裝。先抽取日期、任務／session ID、模型、速度或推理設定、token 計數、工具類型、失敗與重試次數、完成狀態；不先全文掃描所有聊天。
4. 不讀金鑰、密碼、認證檔或無關個資。先用現有工具或本機腳本彙總，只回傳必要統計與去識別片段供本次對話判讀；不另外上傳整份原始紀錄至第三方服務。不改設定、AGENTS.md、skills 或原任務檔案，不安裝工具、不新增代理、不另行呼叫需付費的 API、不重跑原任務。可用現有已授權的唯讀工具及本機腳本分析；只可另建本次新報告檔。無檔案寫入能力就在聊天交付。

【先交代資料能看見多少】
5. 列出實際找到的來源、可讀期間及缺漏。雲端任務、其他設備、已刪除或未留存紀錄分開標示。可見率有可靠分母才算百分比；沒有完整清單就寫「無法計算」，說明已看見的範圍。
6. 訂閱剩餘比例與重置時間，只引用實際可讀的官方用量頁或介面；若工具看不到，標 unknown，具體告訴我需要補「用量頁上的剩餘比例、重置時間及截圖時間」。不要猜百分比，也不要登入不明帳戶。

【計數方式】
7. 先確認紀錄欄位的定義與計數方式。累積 total 快照用相鄰有效值的增量，時間窗只計窗內增量；不要把每筆累積值相加，也不要把 last 與 total 混加。依 session、事件 ID／時間與內容識別重複紀錄，交代去重規則。跨時間邊界缺前值、計數重設或格式不明時標 unknown，別用整段累積值補入。
8. cached input 若是 input 的子集就只列拆分，不再加一次；reasoning 若已含在 output 就不重複計。缺失欄位保持 unknown，不補成 0；不同計數定義分開列。任務或模型無法歸屬就另列 unknown，保留已知部分。
9. 本機 token 只用來觀察可見工作量與找出需檢查的任務。不要折算成訂閱額度百分比、可做次數、官方帳單或 API 金額；模型、速度、工具與快取差異須分開說明。

【再看可能的原因】
10. 先按任務、模型與日期列出可比的工作量排行，附資料完整性及完成狀態。再針對最多 5 個高耗用任務，只讀與問題相關的片段，找出可定位的證據：重複讀同一檔案、輸入與條件未變卻重測、工具回傳過長、沒有新診斷的失敗重試、超出原要求的範圍擴張，或多代理重複做同一工作。
11. 另查固定 AGENTS.md、skills、MCP 工具描述或回傳是否形成與當次任務無關的上下文。只在事件有跡象時讀必要規則與相關片段，列出來源、何時讀入、與本次任務的關係及可避免的動作。檔案長度或已啟用工具數量不能單獨證明浪費；無法確認實際注入量就明說無法量化。只提調整建議，不停用 MCP、不刪安全規則。
12. 上述都只是待驗假設。請交代每次重做是否由檔案變動、失敗、新證據或必要品質要求觸發，保留必要修復、測試與獨立審查。工具呼叫多、token 高或任務時間長，本身不足以判定浪費。

【報告】
請依序提供：
A. 三句摘要：可確認什麼、最值得先改什麼、還缺什麼。
B. 資料範圍與限制，以及官方額度資訊和本機工作量的分開呈現。
C. 任務、模型與日期排行；每項標單位、計數方式、已知／unknown 及完成狀態。
D. 最多三個有事件證據的主要原因，附任務／時間、相關片段或事件位置、判斷理由與其他可能解釋。證據不足就少列，勿湊三項。
E. 對應的前三個具體改法：指出下一次哪類任務、哪個動作要調整，以及必須保留的品質檢查。先給建議，這次不代為改設定或規則。
F. unknown 清單與補件方式。即使資料不完整，也先完成已知部分。
G. 下一次如何驗證：使用相同長度的時間窗、相近任務類型與成果要求，比較實際完成成果、品質、可見工作量及同時記錄的官方用量變化；不要承諾固定節省百分比。

送出後，你應該拿到資料範圍、排行、事件證據、具體改法與未知項目。若回覆只有「少用大型模型、把問題問清楚」，可以接著要求：「請指出是哪個任務、哪個時間發生了什麼，讓你得到這個建議。」這樣才能把泛泛的省用量建議，拉回自己的工作。

若你連工作資料夾與聊天的關係都還不熟悉，可以先看Codex 入門教學，再回來執行這次診斷。

工商時間

如果你想要更系統化、更輕鬆的學好 SEO 與 AI SEO，歡迎參考我與知識衛星合作的 SEO 線上課程：《SEO 排名攻略學》、《AI SEO 流量變革》。

透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗。
再搭配《AI SEO 流量變革》看懂 AI 搜尋趨勢，搶佔 AI 搜尋紅利。

收到報告後，先看資料範圍與前三個原因

Codex 額度分析的第一個重點，是報告到底看到了什麼。接著才看哪個任務工作量高，以及高的原因。照這個順序讀，你比較容易分辨資料缺漏、計數方式有問題，還是真的發現一次可以省下的重做。

先看缺了哪一段，再看排行

先找報告的起訖時間、時區、資料來源及缺漏清單。最近七個完整日，是從七天前的當地午夜，到今天午夜之前；今天尚未結束的使用情形另列。這樣每次比較的日數才一致。

如果只讀到本機五天紀錄，就用這五天回答可回答的問題，另外兩天保留未知。要計算「看見了全部工作的幾成」，還需要可信的完整任務清單作為分母；缺少分母時，報告應列出可見範圍。

例如，你明知週三在另一台電腦做了簡報，本機紀錄卻沒有這個任務，週三就應註記缺少來源。寫成 0，會讓你誤以為當天沒做事，也容易把其他日子的 Codex 額度下降看成異常。

數字是否把同一份工作重複加進去

工作紀錄可能用「這次新增多少」或「到目前累積多少」呈現計數。累積數需要先算前後增量，再加總選定期間的工作；同一事件重複出現在不同紀錄時，也要先去重。跨日邊界缺少前一筆數值，或計數中途重設，就保留未知部分。

假設同一個工作階段先記錄累積 10,000，後來變成 13,000，兩筆之間新增的是 3,000。若把 10,000 與 13,000 相加成 23,000，排行就會被放大。這是計數示例，實際分析要先確認那個欄位確實是累積值。

另一種重複來自欄位之間的包含關係。若 cached input（快取輸入）已包含在 input 內，它只是輸入的一部分；若 reasoning（推理）已含在 output 內，也採相同方式呈現拆分。欄位定義決定怎麼算，缺值則保留 unknown。

例如，某筆紀錄的 input 是 10,000，其中 cached input 是 8,000，整筆輸入仍是 10,000，快取部分占其中 8,000。把兩者加成 18,000，就把同一批資訊算了兩次。指令裡的計數要求，正是要先處理這些會影響診斷的差異。

高耗用任務，要追到實際事件

高工作量可以幫你選出優先查看的任務。判斷有沒有浪費，則要追到具體事件：Codex 為什麼再次讀檔、再次測試或再次研究？觸發原因可能是檔案剛改過、前一次失敗、出現新證據，或原本就要求獨立審查。

例如，同一張表測了三次：第一次找到公式錯誤，修好後第二次確認數字，第三次檢查使用者剛新增的一列。這三次都有工作上的理由。若表格與環境都沒變、前次也已通過，又完整重測一次，才值得請 Codex 解釋那次重測要解決什麼問題。

另一個值得查的方向，是每次工作帶入的固定規則與工具資訊。AGENTS.md 是給 Codex 的工作規則，skills 是處理特定工作的指引，MCP 則讓它連接外部工具；如果內容與當次工作無關，也可能增加要處理的資訊。OpenAI 節省用量建議

例如，只修改一段文案，事件卻顯示它重新讀完另一個專案的長規則，並取得整份無關工具結果，就值得把這兩個動作列入診斷。報告要指出實際來源與用途；看不到注入量時，寫明無法量化，再建議下次讓規則與資料範圍貼近任務，這次先保留設定。

因此，報告最好寫成「任務、時間、事件、原因」的對照，並交代其他可能解釋。你要找的是有機會刪掉的重複動作，同時保留讓成果正確的修復、測試與獨立審查。只為了讓 Codex 額度下降慢一點，就拿掉必要驗收，後面出錯返工反而更麻煩。

工商時間

如果你想要更系統化、更輕鬆的學好 SEO 與 AI SEO，歡迎參考我與知識衛星合作的 SEO 線上課程：《SEO 排名攻略學》、《AI SEO 流量變革》。

透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗。
再搭配《AI SEO 流量變革》看懂 AI 搜尋趨勢，搶佔 AI 搜尋紅利。

依證據調整工作，再用同類任務驗證

看完報告，先選一個證據最清楚的原因處理。如果問題是重複讀檔，下一次就指定要讀哪份、哪一段；如果問題是無變更重測，就要求沿用前次有效結果，列出這次真正受影響的檢查。讓改法對準已發生的動作，比一次改掉所有使用習慣更容易看出效果。

• 同一份長檔反覆讀：交代「先沿用本次已讀內容，只讀我剛改的第二節；發現檔案版本不同再重讀」。檔案位置容易混淆時，先用Codex 檔案結構與備份方式整理出這次的正式來源。
• 工具每次回傳整張大表：交代「完整原始結果留在本機，聊天只回傳總筆數、異常列及需要我判斷的差異」。遇到錯誤再查看相關行，讓後續閱讀集中在真正有用的資料。
• 小改動被做成整份重寫：交代「這次只修第三段的數字與來源，保留其他正文、圖片和已通過的檢查」。可以搭配Codex 新手交辦技巧練習把修改位置與完成條件說清楚。

模型、推理設定與速度也值得列入報告，尤其是相近任務用了不同設定時。你可以選一類格式整理或資料摘錄工作，試用能完成相同要求的設定；複雜判斷與高風險任務則保留所需能力。具體分工可以接著看Codex 任務與模型分流。

下一輪用同樣長度的時間窗，挑任務類型、資料量與成果要求相近的工作比較。除了可見 token，也記錄完成幾件、需要返工幾次、必要檢查有沒有通過，並在相近時間記下官方 Codex 額度變化。若這週只改短文、上週做整個網站，兩週的總量就應分開解讀。

先找出一次可避免的重做

現在可以把完整指令貼進自己的 Codex，先分析最近七個完整日。拿到報告後，選一個有任務與事件證據的原因，例如同一份長表被反覆回傳，或小修改引起整篇重寫，再把下一次的範圍交代得更精確。

真正有用的 Codex 額度分析，最後會讓你知道哪個動作值得改、哪些檢查應保留，以及還缺哪份資料。先完成一次診斷與一次可比的驗證，之後安排工作與用量，就有自己的紀錄可以依據。