先确认这次计费变了什么
DeepSeek 官方说明，V4 API 从 2026-08-16 16:00 UTC 起采用峰时和谷时价格，谷时价格为峰时的一半。计费项仍然分为缓存命中、缓存未命中和输出 token；deepseek-v4-pro 与 deepseek-v4-flash 的价格不能用旧表格估算。
这不是简单的“模型涨价”。Agent 会反复发送相同的系统提示、仓库摘要和工具结果，缓存命中率越高，长任务的账单结构越需要单独计算。
长任务的账单要拆成三层
先从 Agent 或网关日志中记录四个字段：
- 模型名：
deepseek-v4-pro或deepseek-v4-flash - 输入 token：缓存命中与未命中分开记录
- 输出 token：包含 thinking 产生的输出
- 请求时间：用于判断峰时还是谷时
一个公开审计案例重算了 650 个请求，缓存命中率为 98.09%，在新价格下账单约为原来的 2.7 倍。这是单个工作负载的实测，不代表所有账号都会涨同样比例，但它说明“缓存命中很多”并不等于新价格下成本一定低。
先用最小请求确认路由和 effort
不要直接让一条长任务验证计费。先用同一个 Key 发一条短请求，确认 API 入口、模型名和 Responses API 路由都正确。
$body = '{"model":"deepseek-v4-flash","input":"返回 OK","reasoning":{"effort":"low"}}'
Invoke-RestMethod -Uri "https://api.deepseek.com/v1/responses" -Method Post -Headers @{ Authorization = "Bearer $env:DEEPSEEK_API_KEY" } -ContentType "application/json" -Body $body成功标准是响应中的模型名正确、请求没有回落到旧别名、输出包含 OK，并且网关日志能看到一次 Responses API 请求。不要把完整 Key 打进日志。
Codex 和 Agent 怎么降低长任务成本
先给任务分级，再决定模型和 effort：
| 任务 | 默认选择 | 需要记录的成本信号 |
|---|---|---|
| 小范围改名、格式化、单测修复 | V4-Flash + low | 未命中输入、输出 token |
| 日常多文件 Agent 任务 | V4-Flash + high | 每轮上下文大小、重试次数 |
| 复杂迁移和审查 | V4-Pro + high/max | 峰谷时段、缓存命中率、总轮数 |
不要把 max 设成所有任务的默认值。也不要在缓存即将过期时盲目恢复一个很大的会话；先记录当前上下文大小，再决定压缩或新建会话。
用账单反证配置是否生效
跑完一次隔离任务后，按下面顺序核对：
- 网关日志里的模型和 effort 是否与配置一致。
- 输入 token 是否拆成 cache hit / miss，而不是只有总数。
- 请求时间是否落在预期峰/谷时段。
- 供应商用量导出中的 token 数是否能和本地日志对上。
- 同一任务在新会话和旧会话之间是否出现明显的上下文成本差异。
如果只看“任务完成了”，无法判断成本控制是否成功。真正的成功标准是模型路由、effort、时段和账单四项都能互相解释。
价格变化后应该更新什么
现有的通用计费文章可以继续解释预算、返工和模型选择；DeepSeek V4 的峰谷价格、缓存字段和 Codex Responses API 则属于供应商特有的验证路径。价格再次变化时，优先重新打开官方价格页和 Change Log，不要沿用旧截图或旧费率。