Codex session import ignores cache_write_input_tokens; cache writes priced as ordinary input - cc-switch

Quick fix

Upgrade cc-switch or wait for an official fix: Codex session log import misses cache_write_input_tokens, so cache writes are counted as ordinary input and…

Symptom

Error outputCopy

{"input_tokens":54141,"cached_input_tokens":43323,"cache_write_input_tokens":10815,"output_tokens":313,"reasoning_output_tokens":193,"total_tokens":54454}

Cause

Starting with openai/codex#33454, Codex records cache_write_input_tokens in rollout token_count events (from Responses API usage.input_tokens_details.cache_write_tokens). This field does not overlap with cached_input_tokens; both are part of input_tokens. The cc-switch session import logic (/src/services/session_usage_codex.rs) does not parse this field and hardcodes cache_creation_tokens to 0 when inserting records into the database, retaining the old input accounting. As a result, cache write tokens are treated as new input and billed at the 1.0× input rate. The local proxy path (since f991726f) already records cache writes correctly from usage.input_tokens_details.cache_write_tokens, so the two paths use inconsistent accounting. The built-in pricing table charges cache writes at 1.25× the input rate (for example, gpt-5.6-sol is $5 vs $4 / MTok), so users may be undercharged or overcharged depending on the comparison baseline; relative to the correct accounting, the cache write portion is underestimated.

Fix

1. 1

   Check whether your cc-switch version includes the fix for issue #7634; if you are using 3.20.2 or earlier, upgrade to the latest release.

2. 2

   If you cannot upgrade yet, you can correct historical data locally with SQL: subtract the value corresponding to cache_write_input_tokens from input_tokens in records with the codex_session source, write it to cache_creation_tokens, then recalculate the cost using the model pricing.

Affected Versions

ToolCodex

Version3.20.2（本机观测）；main @ 85caa69e（v3.20.4 之后）代码中问题仍在

PlatformsmacOS

Source Issues

This page is distilled from 1 real issues

• #7634[Bug][Codex] 会话用量导入忽略 cache_write_input_tokens：GPT-5.6+/GPT-6 缓存写入按普通输入计价

FAQ

Why is cache_creation_tokens always 0 after Codex session import?

Because the cc-switch session import parser does not read the cache_write_input_tokens field in rollout logs, and the code hardcodes cache_creation_tokens to 0, with a comment saying “Codex logs have no such data.”

Does this affect the billed amount?

Yes. Cache write tokens are counted as ordinary input and billed at the 1.0× input rate; the correct accounting should use the cache write rate (for example, gpt-5.6-sol at 1.25× the input rate). The issue author replayed 45 rollout files, and the gpt-5.6-sol cost changed from $0.3866 to $0.4314.

Do the local proxy path and session import path use consistent accounting?

No. Since v3.17.0 (commit f991726f), the local proxy has correctly recorded usage.input_tokens_details.cache_write_tokens as cache writes; however, the session import path still ignored this field through 3.20.2, resulting in different cache_creation_tokens counts for the same requests processed through the two paths.

Related problems

[CODEX-SYNC] deferred 4 CodexUpgrade cc-switch to v3.20.3 to fix Windows session files permanently deferred when mtime does not change.1 issues mergedCost always 0: GPT-6 Sol usage statistics in CodexEnable “Model Price Sync” in Settings to synchronize pricing data for gpt-6-sol.1 issues mergedcc-switch Usage Statistics Differ from DeepSeek Official Site / Stop UpdatingUpgrade to v3.19.2 or later, then run “Rebuild Codex Usage” once on the “Usage Statistics” page to correct historical overcounts or missing records.22 issues merged