Codex 用起来确实爽但真正让大部分开发者头疼的从来不是它写代码的能力而是账单。我见过太多人把套餐额度、Usage Credits、Wallet 和 API 这四本账混在一起算最后要么在订阅页看到额度用光要么在账单页看到一笔根本没预期的扣费甚至被401 unauthorized: incorrect api key provided、auth token is unavailable这类报错卡在门口连账都记不上。这篇文章就是帮你把这四本账彻底拆开它们各是什么、一次请求到底扣了哪本账、怎么用一套台账把每一分钱都对得上以及那些高频报错背后对应的是哪本账的问题。我给的方案不依赖任何商业监控工具一个表格加一段脚本就能跑起来。1. 四本账到底是什么它们为什么总被认错先说结论Codex 本身不记账。它是一个 agent 型编程客户端只负责把请求发到配置好的服务端真正决定从哪个桶里扣钱的是服务端那一侧。Codex 能接的身份和通道又特别多于是同一个对话框里可能上一轮走订阅身份下一轮走 API key月底一算自然对不上。1.1 套餐额度订阅里的次数池这是跟着 ChatGPT 订阅账号走的。你登录了 ChatGPT 账号再用 Codex请求就消耗套餐额度。它的特点是按次数算而不是按 token 算有一个滚动时间窗口比如某些档位是每若干小时若干次请求窗口过了额度自动恢复。套餐额度的核心规律是不用白不用但也别指望攒着。它是订阅权益的一部分不会累积、不能折现、也不能转给下个月。很多人以为我买了 Plus/Pro 就等于 API 随便用这是四本账里最常见的第一误解。我之前的做法是在每个滚动窗口快结束时把不紧急的批量任务一次性丢进去跑反正不额外花钱。1.2 Usage Credits平台的一次性赠点Usage Credits 是平台发的一种一次性抵扣点数跟订阅额度是两码事。来源包括新账号赠送、活动奖励、服务补偿有些第三方平台也叫 trial credits。它通常有有效期而且普遍约定先于现金余额消耗。混淆的高发区就在这里很多平台的账单页同时显示 Credits、Balance、Usage 三块新手很容易把 Credits 当成自己充值的钱。实际上 Credits 往往过期作废也不是随时能退款。有一次我在某平台看到 Credits 还剩不少以为能撑几个月结果月底一看过期了一半那部分额度就这样消失了。1.3 WalletAPI 预付费钱包Wallet 是你预充值的现金余额性质跟手机话费一模一样。你往里面充一笔钱每次 API 调用按 token 消耗实时扣减扣的是真金白银。OpenAI API 平台和其他多数模型厂商都是这套逻辑充 $5、$10、$50用完再充。Wallet 的显著特征是扣得飞快。一次把大仓库塞进上下文的请求可能一次就吃掉几万甚至几十万 token单价再一乘数字就非常具体。很多人没有记账习惯等到 Wallet 见底、请求突然开始报错才回头翻账单已经晚了。Wallet 是所有账本里最需要盯紧的一本。1.4 API 通道按量计费的外部账单第四本账是API 通道本身。当你把 Codex 指到第三方模型服务比如 DeepSeek、OpenRouter 或其他兼容接口计费就发生在对方平台上。它跟你有没有 ChatGPT 订阅、跟 OpenAI 的 Wallet 完全无关价格体系也是另一套有的按 token 计价有的按请求计价有的还要在对方平台单独充值。这本地账的特殊性在于它经常被忽略。因为 Codex 界面看起来一模一样很多人没意识到自己在用第三方通道收到对方平台的账单时一脸懵。话说回来接入第三方 API 让 Codex 用其他模型是完全正当的开发操作做四账本系统时把它单独列一本就是为了让它的消费量在总账里显形。1.5 一张表看清四本账账本计费主体计费口径是否过期能否结转在哪查套餐额度订阅账号请求次数/时间窗滚动恢复不能订阅账户用量页Usage Credits平台账号点数/美元额度有有效期通常不能平台 Credits 页Wallet平台账号预充值现金不失效可以平台 Billing 页API 通道第三方厂商按量计费不失效看厂商第三方账单页四本账的区别本质上是两种维度权益型套餐、Credits和资金型Wallet、API 账单。权益型的痛点是过期和不结转资金型的痛点是扣费快和容易漏记。把维度分开看很多账单问题就清楚了一半。2. 账本归属判定怎么知道一次请求扣了哪本账四本账理清楚之后下一个问题是我屏幕上正在跑的这轮对话到底扣了哪本账这个问题的答案不直观但有三条铁律可以帮你快速定位。2.1 三条铁律第一条看身份。Codex 启动时用codex login登录了 ChatGPT 账号请求走订阅服务端消耗套餐额度如果设置了 API key环境变量或--api-key请求走 API 服务端消耗 Wallet 或第三方账本。身份是决定账本归属的第一因素。第二条看配置。~/.codex/config.toml里的model_providers决定请求发给哪个厂商。默认配置发到官方 API/订阅服务端你手动加了第三方的 provider 映射实际的计费方就变成了那家厂商。第三条看报错。会话刚开始如果报401、auth token is unavailable说明认证没通过请求根本没有进入计费环节这时最该查的是密钥和登录态而不是余额。反过来说如果你看到的是402 Payment Required、429 quota reached这类错误才说明账本真的被触动了。2.2 判定规则速查表判断依据归属账本验证方法codex login未配置 API key套餐额度订阅页看用量曲线设置了CODEX_API_KEY/OPENAI_API_KEYWalletAPI 平台看余额变动config 里 model_providers 指向第三方API 通道第三方平台看调用记录平台发放的 Credits 快照Usage CreditsCredits 页看剩余与到期日2.3 边界情况转发链路与多 Provider现实里还有一个灰色地带有人用社区的多 Provider 切换工具来管理多个模型厂商配置。这类工具的本质是帮你批量改 Codex 的 provider 配置再起一个本地转发服务把/responses这类请求导到目标上游。于是你会看到类似cc switch local proxy failed while handling codex endpoint /responses的报错。我直接说结论这个报错不涉及任何账本扣费因为请求在转发这一步就断了根本没到上游计费端。它属于链路没通而不是账没算清。排查优先级是先确认你选中的 Provider 配置是否完整再看上游 endpoint 地址和密钥是否还有效最后看本地转发服务有没有真正启动。注意不同版本的配置字段名可能有差异我通常会把log_level调到 debug 再看一次请求实际发往哪个地址比瞎猜快得多。3. 记录模型与台账设计一次请求一条记录要做四账本系统先别急着写代码把记录模型定下来。模型定对了后面不管用表格还是脚本都顺手。3.1 核心原则一次请求落一条记录每条记录标一个账本台账的最小单位是一次请求。Codex 一轮对话里可能包含很多次内部请求比如工具调用、重试、上下文压缩每一次都会产生 token 消耗。如果你只按会话记账成本归属会非常粗因为一次会话可能跨了身份切换、也可能一个请求失败重试了三次。每条记录必须能回答四个问题什么时候发生的、用的什么模型、属于哪个账本、花了多少钱。回答不了这四个问题的记录对账的时候就是废数据。3.2 字段设计我实际在用的字段表长这样字段说明示例timestamp请求发出时间2025-06-01 14:23:11session_id会话 ID用于回溯0190f...provider实际计费方openai / deepseek / openrouterauth_type认证方式oauth / api_keyledger账本归属套餐额度 / Wallet / ...model模型名gpt-5-codex / deepseek-chatinput_tokens输入 token 数28413output_tokens输出 token 数1877cost_usd_cents成本美分142status_codeHTTP 状态码200 / 429error_msg关键错误信息rate limit reached其中ledger这一列不要手工猜应该按 2.2 的规则自动推导auth_type 和 provider 两个字段组合起来账本归属就是确定的。手工填错列名是台账系统最先崩的地方一定要让代码或下拉列表来约束。3.3 为什么成本要统一成美分这是我从对账失败里总结出的教训。各家平台计价单位不一样有的按每百万 token 美元计价有的按人民币计价还有的按平台自定义点数。如果你在台账里混用美元、人民币、点数月底求和时只能干瞪眼。我的做法是所有成本统一折算成美分USD cents存储。比如某厂商给出每百万 token $3.5那一次 3 万 token 的请求就是 $3.5 × 0.03 $0.105记成 10.5 美分。统一单位后四本账可以直接相加、可以直接做环形图误差也小。换算关系写死在采集脚本里每次单价变动只改一处常量台账不用动。4. 三层落地从手工 Sheet 到自动对账模型定好之后落地可以分三层走。按你自己的技术条件选一层或者组合使用不用一步到位。4.1 第一层一个 Sheet 搞定手工台账最轻量的一层是直接用 Excel 或 Google Sheets 建表。表头就是 3.2 的字段每跑完一轮 Codex 会话手动补一行。听起来原始但对用量不大的个人开发者完全够用。关键是善用公式。比如我想看某天 Wallet 的消耗汇总可以这样写SUMIFS(成本列, 账本列, Wallet, 日期列, DATE(2026,1,1), 日期列, DATE(2026,1,2))再做一张透视表行放账本列放月份值放成本总和四本账每个月花了多少一眼就能看到。手工台账有个副作用是逼你养成每次跑完顺手记一笔的习惯这个习惯本身比工具值钱。4.2 第二层解析 Codex 日志做半自动统计Codex CLI 会在本机留下会话日志通常是~/.codex/sessions下的 JSONL 文件以及~/.codex/log下的运行日志。日志内容因版本而异但一般包含模型名、输入输出 token、时间戳这些核心字段。写个小的解析脚本就能把手工记账变成半自动。一个最小解析思路是逐行读 JSONL过滤出带 usage 字段的记录然后组装成台账行。伪代码如下import json from pathlib import Path sessions_dir Path.home() / .codex / sessions rows [] for f in sessions_dir.glob(*.jsonl): for line in f.read_text(encodingutf-8).splitlines(): if not line.strip(): continue rec json.loads(line) # 字段名按你本机版本实际结构调整常见是 usage 下带 input_tokens/output_tokens usage rec.get(usage) or {} if not usage: continue rows.append({ time: rec.get(timestamp) or rec.get(created_at), model: rec.get(model, ), input_tokens: usage.get(input_tokens, 0), output_tokens: usage.get(output_tokens, 0), status: rec.get(status, ), })注意不同 Codex 版本的日志结构差异很大字段名可能叫prompt_tokens而不是input_tokens也可能嵌套层级不一样。我的经验是先打印一条日志看结构再动手写解析不要盲猜。4.3 第三层Python 自动对账把采集到的台账和平台账单放在一起做对账就是对账脚本的活了。对账逻辑不复杂把平台账单的消费明细按天汇总跟自家台账的对应账本逐日核对差值超过阈值就报警。我常用的脚本框架是这样import json from collections import defaultdict def daily_total(rows, ledger): total defaultdict(float) for r in rows: if r[ledger] ledger: total[r[date]] r[cost_usd_cents] return total # 假设 imported_platform_rows 来自平台导出的账单字段先统一成 date 和 cents platform_total daily_total(imported_platform_rows, Wallet) my_total daily_total(my_log_rows, Wallet) for day in set(platform_total) | set(my_total): diff platform_total.get(day, 0) - my_total.get(day, 0) if abs(diff) 10: # 阈值 10 美分 print(f{day} 对不上差异 {diff:.2f} 美分)差值的常见来源有三个一是 Codex 内部有重试日志记了两次但平台只计一次二是平台账单有延迟入账三是日志解析时漏掉了某些记录。遇到差异先别急着改代码把对应那几天的请求明细拉出来人工扫一眼通常能找到原因。5. 常见报错与对应的账本排查速查四账本系统能不能救命真正体现在排查报错上。这一节把热词里高频出现的几类报错逐个拆开告诉你该先查什么。5.1 401incorrect api key providedunexpected status 401 unauthorized: incorrect api key provided: sk-svcac****这类报错字面意思是密钥不对。它表示认证阶段就被拒了请求根本没进计费环节所以跟账本余额不足没关系。排查顺序先检查是不是复制密钥时多了空格或换行再确认这个 key 在这台机器上有没有被旋转或删除最后看环境变量是不是被别的配置覆盖了。一个常见坑是 shell 的.bashrc里同时导出过OPENAI_API_KEY而 config.toml 里又指定了另一个env_key两边不一致就会报 401。验证 key 是否有效可以直接在请求里带这个 key 打一个最小接口但注意不要在任何截图里暴露完整 key 明文。5.2 auth token is unavailable这个报错通常意味着 Codex 找不到可用的登录凭据。常见场景是你明明执行过codex login但换了终端、换了环境变量或者容器启动时没有挂载~/.codex目录导致 token 文件不存在。它直接影响的是套餐额度这条账本路径因为订阅身份失效了。解法是重新登录一次把~/.codex目录的权限和挂载检查一遍。如果这个报错出现在 Docker 或 CI 环境优先确认宿主机到容器之间的配置卷挂载有没有丢。5.3 转发链路报错本地转发失败热词里那句cc switch local proxy failed while handling codex endpoint /responses刚才在 2.3 已经提过。这里补充一点这类报错经常发生在你刚切换完 Provider、但配置没有完全落盘的时候。它不扣任何账本的钱因为请求都没到上游。修复的关键是让 Provider 配置回到一致状态。我会做三件事先把选择的 Provider 重新执行一次切换并确认输出无报错再检查~/.codex/config.toml里对应 provider 的base_url和env_key是否是有效值最后开 debug 日志看实际请求目标。注意第三方厂商的 endpoint 会随版本变化旧配置里的地址可能已经失效。5.4 限额类报错context、quota 与组织状态400 this models maximum context length is 1048576 tokens是上下文超长不是扣费问题但它对四本账有间接影响上下文越长输入 token 越多成本越高。你手上这本账可能余额充足但一次 100 万 token 的输入直接能把单次成本拉到一个夸张的数字。碰到这种报错先精简上下文把仓库文件切块、用摘要代替全文而不是硬加预算。429 Rate limit reached要分两种情况如果报错明确说 subscription 次数用完说明套餐额度这本账触顶了等滚动窗口恢复即可如果报错带quota exceeded、spend limit之类的字样那就是 Wallet 或 API 账本的钱不够了得去充值或提高上限。400 this organization has been disabled属于组织级状态问题。API key 归属于某个组织组织被管理员停用后这一整本账都不可用。个人开发者遇到得少团队环境里才会碰到。解法是换个人项目或找组织管理员处理跟密钥本身无关。5.5 报错-账本-动作快速对照表报错特征涉及账本先查什么快速解法401 incorrect api key无认证未过密钥、环境变量重新复制有效 keyauth token unavailable套餐额度路径登录态、HOME 目录codex login重新登录转发链路失败无未到计费Provider 配置、endpoint重刷配置、检查地址context 超长所有账本间接上下文大小精简输入、分步任务429 subscription 限流套餐额度滚动窗口用量等待窗口恢复429 quota exceededWallet / API 通道余额与限额充值或调整上限organization disabledWallet / API 通道组织状态联系管理员或换项目6. 跑了一个月之后我的几条实在建议这套四账本方案我实际用了一个多月踩过一些坑也有几个值得保留的小习惯。第一个习惯是每周对一次账而不是月底。Codex 的消费频率高一周的偏差可能已经几十美元一个月后再发现就晚了。我固定每周日晚间跑一次对账脚本把四本账各自的日消耗曲线打印出来扫一眼哪里异常。第二个习惯是给每个项目配独立的 API key。在多 Provider 切换的场景下项目级 key 能让你在第三方平台的账单页直接按项目切分消费回到四账本里做归属判定也简单得多。共用一个 key 等于把两本账焊死在一起排查困难。第三个习惯是日志留档。Codex 的会话日志默认有一定保留期我每月把~/.codex/sessions归档压缩一次这样即使平台账单页只保留短期数据自家台账也能补上历史。这样跨月对比成本趋势时就永远有数据可用。第四个习惯跟成本单位有关。我在踩过浮点误差的坑之后所有成本全部用整数美分落库显示时才换算成美元。别小看这个细节月度累计之后浮点误差会从几分钱滚到几块钱对账脚本经常因为这种差异误报。最后一个小技巧每次切换 Provider 或更换 key 后先跑一个最小测试请求确认返回 200 再开始正式干活。这个请求的日志行就是新账本的第一条记录有了它后续所有归属判定都有参考基准。四账本系统不是一次性搭完就完事的它真正的作用是让跑一次 Codex 花哪本账的钱变成一个可回答的问题。你不需要每次调用都盯着屏幕算账只需要让记录、归属、对账这三件事自动化起来剩下的事交给系统。