先把当时的情况摆出来。用推理模型做分类，返回的 content 只有一行结论，completion_tokens 里却包含大段 reasoning_tokens，月度费用是预估的三倍，接口返回里看不到推理过程。
排查方向其实有限，先把可能性排一排。推理 token 按输出价计费但不返回正文。还有一种是开放式提问触发长推理链。
还有一种情况，reasoning effort 用了默认的高档位。另外，请求记录里没有单独统计推理开销。
先打印 completion 的明细字段
python -c "import json;print(json.load(open('r.json'))['usage']['completion_tokens_details'])"然后把 reasoning effort 调低做对照
python ask.py --reasoning-effort low --cases cls.jsonl给单请求设置 completion 上限
python patch_client.py --max-completion-tokens 512等前面都确认过，再按业务类型分别统计推理开销
python cost_split.py --by task_type --out reason.csv同样的操作我在测试机上先走了一遍，线上只做验证过的部分。
这台环境是别人交接的，不少默认值被动过，只能一项项核。
怎么算真的好了，看的是同一批现象。同类任务的 completion_tokens 降到原来的三分之一，抽检答案质量没有下降。
提醒一点。看不见的输出也在计费，做预算时必须把推理 token 单列一行。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。