| |

用 API易 調用日誌查看 Codex 每輪 token 消耗：5 步算清長對話成本

ByShark
用 API易 調用日誌查看 Codex 每輪 token 消耗：5 步算清長對話成本

作者注：Codex 輸入框看不到上下文用量？入口在 /status。本文用 API易 調用日誌 5 步算出 Codex 每輪 token 消耗和金額，並給出“該壓縮還是該新開”的判斷表。

你用 Codex 接上 API易，在一個對話裏連續幹了幾個小時的活。輸入框下方只顯示權限模式和模型，上下文用了多少卻看不到，你也拿不準該不該新開窗口。

先說結論：不是 Codex 不給看，上下文用量的入口挪到了 /status；能算錢的數據在 API易 / apiyi.com 的調用日誌裏。本文圍繞 用 API易 調用日誌查看 Codex 每輪 token 消耗 這件事，分五步講清楚：看什麼，怎麼合計，什麼時候壓縮或新開。

這不是又一篇概念科普。每一步都寫了界面上會看到什麼、該點哪裏，並附一句驗收標準。

codex-token-usage-per-turn-apiyi-logs-zh-hant-image-0

爲什麼在 Codex 裏看不到每輪 token 消耗

很多人以爲 Codex 去掉了上下文顯示。實際情況是，相關信息分散在三個入口裏，而且每個入口能看到的東西不一樣。

  1. 桌面客戶端 / IDE 插件：輸入框只顯示權限模式和模型。輸入 /status，能看到 chat ID、context usage（上下文已用比例）和 rate limits（速率餘量）。
  2. CLI：/status 顯示當前模型、審批策略、可寫目錄和當前 token 用量。CLI 頁腳原本就有上下文提示。用 /statusline 可以把 context stats（上下文統計）和 token counters（token 計數）加到頁腳，選擇結果會寫回 config.toml 的 tui.status_line。
  3. codex exec --json：非交互執行時，Codex 每次狀態變化都會輸出一行 JSON 事件。其中 turn.completed 事件帶 usage，包含 input_tokens、cached_input_tokens、cache_write_input_tokens、output_tokens、reasoning_output_tokens 五個字段。

另外 /usage 只能看賬號維度的 token 活動，前提是官方登錄態。如果你用的是第三方 Key，這個命令不適用。

Codex token 消耗的三套口徑對比

口徑 覆蓋場景 能看到什麼 看不到什麼
API易 調用日誌 桌面、IDE、CLI 全覆蓋 每次請求的輸入、輸出、緩存讀寫、金額 對話內容；一行只是一次請求，一輪需要自己合計
Codex /status 桌面與 CLI 交互界面 上下文用量、速率餘量、當前 token 用量 金額
codex exec --json 僅非交互執行 每輪的輸入、緩存讀、緩存寫、輸出、思考 token 交互式 TUI 與桌面端的數據

三套口徑裏只有日誌能看到金額。前提是你走的通道本身提供日誌和用量明細，官方訂閱沒有逐次請求的明細可查。

第一步：確定 Codex token 消耗的統計口徑

開始統計前，先記住一點：一次請求不等於一輪對話。

請求指 Codex 向模型發出一次調用。輪指你發一句話、Codex 幹完活回覆你的整個過程。在一輪裏，Codex 會讀文件、跑命令、改代碼，每次工具調用結束後都要把結果連同完整歷史再發給模型一次。所以一輪對話在日誌裏通常對應好幾行，複雜任務可能有幾十行。

還要知道，模型本身不記得之前說過什麼。第 N 輪的輸入 ≈ 前 N-1 輪的全部內容 + 本輪新增內容，這就是長對話越聊越貴的根本原因。

codex-token-usage-per-turn-apiyi-logs-zh-hant-image-1

驗收：看到日誌裏多行請求時，你能判斷它們屬於同一輪，不會把單行當成一輪來算。

第二步：給 Codex 單獨建一把令牌

統計的前提是日誌裏只有 Codex 的請求。如果 Codex 和腳本、其他工具共用一把 Key，後面就沒法按令牌篩選了。

  1. 進入 API易 控制檯的令牌頁面，點「添加令牌」，名字起一個自己能認出來的，例如帶上“codex”字樣。
  2. 打開 Codex 的 config.toml，在 model_providers 下添加一個 provider，base_url = "https://api.apiyi.com/v1"，通過 env_key 指定讀取這把令牌的環境變量。
  3. 把 model_provider 指向這個 provider。桌面、IDE 和 CLI 讀的是同一份配置，改一次就夠了。
  4. 其他工具一律使用別的 Key，不要複用這把。

🎯 技術建議：專用令牌、日誌按令牌篩選、導出，這三項是 API易 / apiyi.com 控制檯提供的統計抓手。官方訂閱看不到單次請求明細，用專用令牌後，Codex 的賬可以單獨算。

驗收：在日誌頁「展開」後的進階篩選裏，「令牌」選中這把 Key，列表裏只剩 Codex 發出的請求。

第三步：在調用日誌裏讀懂單次請求

打開 api.apiyi.com/log，也就是左側菜單的「日誌」。列表裏每一行是一次 API 請求。

頂部默認可以篩時間區間、類型、模型和緩存狀態。緩存狀態的提示語寫着“命中=讀取緩存，未命中=創建緩存”。點「展開」後，還可以按令牌、流式、提示/補全範圍、首字節耗時等條件進一步篩選。

日誌各列的含義

列名 你會看到什麼 怎麼理解
時間 請求完成時間 默認 UTC+0，比北京時間晚 8 小時
模型 例如 gpt-5.6-terra 換了模型，緩存不共享
信息 流式/非流式、首字節耗時、提示/補全 token、金額 一格內看全本次請求概況
提示 / 補全 兩個數字 提示=輸入 tokens，補全=輸出 tokens，思考 token 通常算在補全裏
消費 美元金額 折扣前金額，已含分組倍率
說明 各項倍率、緩存寫入 tokens、緩存讀取 tokens 緩存命中與寫入在這裏單獨列出，不需要猜

帶緩存的請求，「信息」列會同時顯示命中和寫入的數字。不帶緩存明細的行只顯示“非流式 首字節：N秒 提示/補全 金額”這樣的組合。按次計費的圖像、視頻模型也會顯示提示和補全，但它們的金額不是按 token 算的，不要拿來套本文的算法。

codex-token-usage-per-turn-apiyi-logs-zh-hant-image-2

驗收：隨便指着一行，你能說出這次請求的輸入是多少、輸出是多少、緩存命中多少、花了多少錢。

第四步：把多行日誌合成一輪 Codex token 消耗

單行數據只說明一次請求。要看一輪對話的消耗，需要合計。

合計規則：同一令牌、同一模型，你發出指令後約 5 分鐘窗口內的請求全部加起來。時間窗口按自己的實際情況調整。

  1. 頁面上直接看：篩選令牌 + 模型 + 時間區間，逐行看提示和補全。適合偶爾查一次。
  2. 導出復算：點列表右上角「導出」，拉出 Excel 或 CSV，在表格裏按時間分組求和。
  3. 日誌查詢 API：調用 GET /api/log/self，認證用個人訪問令牌（以 nap_ 開頭，用 sk_ 開頭的 API Key 會返回 401）。參數傳 type=2（只看消費）、token_name、start_timestamp 和 end_timestamp（Unix 秒）。注意分頁參數是駝峯寫法 pageSize，寫成 page_size 會被靜默忽略。
  4. 換算金額：接口返回的 quota ÷ 500,000 = 美元。other 字段是 JSON 字符串，需要再解析一次，才能拿到 usage 等明細。

使用查詢接口時，時間窗口一定要傳，跨度建議不超過 1 天。不傳時間窗口，接口會回溯全部歷史，數據量大的賬號容易超時報錯。查詢日誌本身不消耗額度。

用價格算一輪 Codex 花了多少

模型 輸入 緩存讀 輸出 上下文 算例：一輪合計
gpt-5.6-sol $4 $0.4 $20 1,000,000 約 $0.214
gpt-5.6-terra $2 $0.2 $12 1,000,000 約 $0.107
gpt-5.6-luna $0.2 $0.02 $1.2 1,000,000 約 $0.011

單價均爲每百萬 tokens，查於 2026-10-28。單次請求輸入超過 272,000 tokens 後，輸入價翻倍。

💰 價格說明：型號與價格以 API易 / apiyi.com 平臺型號列表爲準。表中算例按一輪累計輸入 120,000、其中命中緩存 96,000、輸出 4,000 計算。以 sol 爲例：未命中 24,000 × $4 + 命中 96,000 × $0.4 + 輸出 4,000 × $20，除以一百萬後合計約 $0.214。

這組數字說明了兩件事。第一，緩存命中的 96,000 只花了約 $0.038，緩存是長對話成本的關鍵。第二，同一輪任務換到 luna，費用接近 sol 的二十分之一。不過 luna 官方頁面註明，256K 以上的超長上下文表現較弱。

codex-token-usage-per-turn-apiyi-logs-zh-hant-image-3

驗收：你能算出“這一輪比上一輪多了多少輸入 token”，並說出多出來的部分裏有多少是緩存命中。

第五步：用 Codex token 數據決定壓縮還是新開

有了每輪數據，判斷就可以基於數字。重點看三個信號：

  • 輸入增速：每輪新增的輸入越來越多，說明工具輸出和歷史在快速堆積。
  • 緩存讀佔比：說明列裏緩存讀取佔輸入的比例明顯下降，說明前綴變了，新輸入大多按全價計費。
  • 單次輸入：接近 272,000 時，下一次請求就會跨過價格階梯。

壓縮與新開窗口判斷表

你在日誌裏看到的 建議動作 原因
單次輸入接近 272,000，任務還沒做完 先手動 /compact 避免跨過階梯後輸入價翻倍
單次輸入接近 272,000，任務已告一段落 新開窗口 壓縮不如重開乾淨
緩存讀佔比連續幾輪下滑 新開窗口，換新話題 緩存已經失效，繼續聊大多按全價
每輪輸入增量突然變大 檢查工具輸出，必要時調低 tool_output_token_limit 大段命令輸出被寫進了歷史
輸入平穩、緩存讀佔比高 繼續當前對話 這時長對話性價比最高
剛壓縮過一次，又快滿了 新開窗口 多次壓縮會讓摘要越來越粗

codex-token-usage-per-turn-apiyi-logs-zh-hant-image-4

Codex 上下文壓縮怎麼配置

壓縮，指把較早的對話輪次替換成一段精簡摘要，從而騰出上下文空間。Codex 支持手動和自動兩種方式。

  1. 手動壓縮：桌面端和 CLI 都可以輸入 /compact。
  2. 自動壓縮：由 model_auto_compact_token_limit 設置觸發閾值，不填則使用模型默認值。
  3. 閾值的計算範圍：model_auto_compact_token_limit_scope 可選 total（按整段活動上下文計算）或 body_after_prefix（只計算攜帶前綴之後新增的部分）。
  4. 使用第三方 base_url 時：模型名不在 Codex 內置表裏，model_context_window 和自動壓縮閾值建議手動填寫。如果想在跨過價格階梯前觸發壓縮，可以把閾值設在 272,000 以下。
  5. remote_compaction 不要隨意開啓：設爲 v2 時，需要上游支持 Responses 側的壓縮協議。保持 unsupported，使用本地壓縮更穩妥。

壓縮的代價

壓縮並不免費。它會改寫歷史前綴，緩存隨即失效，壓縮後的那次請求輸入幾乎按全價計費。所以壓縮完成後，最好直接開始新話題，不要回頭重複舊任務。壓縮也會丟失細節，摘要不能保證保留所有信息。

常見問題 FAQ

Q1：日誌裏查不到某次請求，是漏記了嗎？

日誌只記錄成功計費的調用。網絡、鑑權、參數校驗等環節失敗的請求沒有到達上游，不扣費，也不會出現在日誌裏。反過來，日誌裏有記錄，就說明請求確實產生了消耗。另外要檢查令牌篩選和時間區間是否選對。

Q2：爲什麼金額比我按 token 估算的低？

最常見的原因是緩存。OpenAI 通道使用自動前綴緩存，前綴不少於 1024 tokens 且保持穩定時就會命中，命中部分按輸入價的 1 折計費。在 API易 / apiyi.com 日誌的說明列裏，可以看到緩存讀取的 token 數。另外，日誌顯示的是折扣前金額，實際成本 ≈ 日誌金額 ÷（1 + 加贈比例）。

Q3：日誌時間和我的操作時間對不上？

日誌默認按 UTC+0 顯示，北京時間是 UTC+8，兩者相差 8 小時。按北京時間篩選“下午三點那輪”，看起來會像缺了一段數據。篩選前先把時間換算好即可。

Q4：日誌能保留多久？

建議按“最近約 30 天可查”來安排。實際保留時間可能更長，但平臺不做承諾，清理策略也可能調整。需要長期對賬的話，請定期用「導出」或日誌查詢 API 自行留存。

Q5：日誌能看到 Codex 讀了哪些文件、發了什麼內容嗎？

看不到。日誌只保留計費所需的基礎信息，比如 token 數、金額和倍率，不記錄輸入輸出內容。想知道某一輪做了什麼，需要回到 Codex 對話本身查看。

Q6：想把每輪用量自動記下來，有更省事的辦法嗎？

如果是腳本化執行，可以用 `codex exec –json`，讀取 `turn.completed` 事件裏的 usage。交互式使用時，可以通過日誌查詢 API，按專用令牌和時間窗口定時拉取並聚合。新用戶可以先在 API易 / apiyi.com 領取免費測試額度，跑通整個流程。

Codex 每輪 token 消耗核心要點 Key Takeaways

  • 入口沒有消失：上下文用量在 /status 裏查看，CLI 還可以用 /statusline 放到頁腳。
  • 請求 ≠ 輪：一輪對話包含多次工具調用，在日誌裏對應多行，需要按時間窗口合計。
  • 專用令牌：給 Codex 單獨建一把 Key，日誌才能乾淨地篩出來。
  • 看說明列：緩存讀寫單獨列出，命中部分按 1 折計費。
  • 272K 階梯：單次輸入超過 272,000，輸入價翻倍。
  • 壓縮有代價：壓縮後緩存失效，那次請求輸入幾乎全價，壓縮後適合直接換新話題。

總結

在 Codex 裏看不到上下文用量，原因不是功能被刪，而是入口換了地方。/status 告訴你還剩多少上下文，調用日誌告訴你每輪花了多少錢。把兩者結合起來，“要不要新開窗口”就能按數字判斷。

今天就可以動手：給 Codex 建一把專用令牌，然後打開 API易 / apiyi.com 的日誌頁，挑最近一輪對話，把它的幾行請求加起來算一遍。

📚 參考資料

  1. OpenAI Codex 官方倉庫：CLI 源碼與事件定義
  2. 鏈接：github.com/openai/codex

  3. 說明：codex-rs/exec/src/exec_events.rs 中定義了 turn.completed 的 usage 字段

  4. Codex 官方文檔：斜槓命令與配置參考

  5. 鏈接：developers.openai.com/codex

  6. 說明：/status、/compact、/statusline 以及壓縮相關配置項的說明

  7. API易 幫助文檔：調用日誌、緩存計費、日誌查詢 API

  8. 鏈接：docs.apiyi.com
  9. 說明：日誌字段口徑、緩存 1 折規則、quota 換算方法

作者：API易 技術團隊
技術交流：歡迎在 API易 官網首頁聯繫我們，更多配置說明見文檔中心。

延伸閱讀

Similar Posts