很多人把 DeepSeek 的 Key 配进 Claude Code 能跑起来，但一到月底对账就懵：钱是按官方价扣的、还是按中转站倍率扣的？长上下文和跑 Agent 循环时用量为什么突然翻倍？这篇不给你一个死数字，而是给一套判断口径：先分清三种计费来源，再按自己的使用姿势估月成本，最后用一次真实请求把账对平。适合已经能跑通、但不确定花得对不对的开发者。
很多人把 DeepSeek 的 Key 配进 Claude Code，能跑起来就以为万事大吉，一到月底对账就懵：钱到底是按官方价扣的，还是按中转站倍率扣的？长上下文和多轮 Agent 循环为什么让用量突然翻倍？这篇不给死数字，只给一套判断口径——先分清钱付给了谁，再按自己的使用姿势估月成本，最后用一次真实请求把账对平。适合已经跑通、但不确定花得对不对的开发者。
核心就三件事：来源、放大、对账。来源搞不清就别谈贵不贵；放大因素不看，估算会差一个量级；不对账，你永远不知道账单上的模型和渠道是不是你以为的那个。下面按这三件事拆开讲，每节都给能直接做的动作。
先分清钱是付给谁的：三种计费来源
同一句请求，打到官方直连、中转站转发、还是用 Claude Code 的套餐额度，计费逻辑是三套东西。第一步不是比价，是确认你的请求究竟落到哪个域名、Key 是谁发的。这个搞不清楚，后面所有估算都是空转。
- 官方直连
- 按 DeepSeek 官方按量单价扣费，计费单位和口径到 /official-api/providers/deepseek 核对当时的说明。
- 中转站转发
- 在中转站自己的倍率上再叠一层，同一模型不同站差异可能很大，去 /rankings 和站内检测页横向对照。
- 订阅套餐替代
- 如果你用的是 Claude Code 套餐额度而不是 API Key，折算逻辑完全不同，去 /coding-plans 看额度怎么算。
- 先看配置文件里的 base_url 和 Key 前缀，判断请求落到哪个域名、由谁签发。
- 再看账单明细里的结算主体，和你以为的渠道逐项核对，别只看总额。
- 中转站要额外看它的倍率和可信度检测结论，别只看首页标价。
- 判断标准：能一句话说清「这笔钱付给谁、按什么单位算」才算来源清楚；说不清就先别优化成本。
用量被什么放大：Claude Code 的四个耗钱习惯
Claude Code 这类编程 Agent 的账单，很少是「问一句付一句」的线性关系。同一段上下文会被反复重发、重算，轮次一多，成本曲线就往上翘。理解这几个放大点，比背单价有用得多。
| 耗钱习惯 | 为什么放大 | 能做的动作 |
|---|---|---|
| 上下文反复重发 | 每轮都带上历史，轮次越多单次请求越重 | 长会话定期开新会话，旧对话别无限续 |
| 读大文件与命令输出 | 文件内容和命令回显都会进上下文 | 读之前先截断，只取需要的片段 |
| Agent 循环与失败重试 | 同一段上下文被多步循环算好几遍 | 给循环设步数上限，失败别无限重投 |
| 模型混用 | 不同模型单价口径不同 | 按任务分配模型，别用一个单价乘全部请求 |
Token 到底怎么算、系统提示和工具输出各占多少，可以到 /ai-dict/category/basics 补一下基础口径，再回头看自己的请求结构。不适用情况：如果你只是偶尔问几句、不读大文件、也不跑长循环，上面这些放大效应基本可以忽略，按次数粗估就够。
估月成本的四步做法
估算的目标不是精确到分，而是把误差控制在一个量级内，能支撑「走按量还是走套餐」这个决策。做法上先取真实样本，再换算，最后和套餐比。
- 抽一天真实用量记下请求数、平均输入输出 Token、用到的模型，从实际日志里取，别凭感觉拍。
- 换成日成本用 /tools/token-price-calculator 和 /tools/model-cost-calculator 把单价代入，再去 /price-watch 确认价格有没有变动。
- 乘出月区间用日成本乘工作日数得到区间，并留一层余量给重试和长文件读取。
- 和套餐比一比拿月区间对照 /coding-plans 里的编程套餐额度，判断按量划算还是套餐更稳。
判断标准：估算和实际账单差在一个量级内就算过关，可以用来做决策；如果差出几倍，先别继续算，回头查是不是走了不同渠道或混了模型，而不是把估算公式再精修一遍。
对账与止损：发现花超了按这个顺序查
账单对不上时，最怕的是边猜边改。按固定顺序排查，能快速定位是渠道问题、客户端问题还是上下文问题。下面这个顺序从便宜到贵，先做前面的。
- 查账单明细：按哪个模型、哪个渠道结算，和你的配置逐项核对。
- 查客户端行为：是否有后台悄悄重试、反复请求，用 /tools/verify 的思路发一次最小请求验证。
- 查上下文膨胀：大文件、旧对话、工具输出有没有该截断而没截断的。
- 做止损动作：换通道、限制单次上下文、给循环设步数上限，这套和 /guides/agent-runaway-guardrails 配套使用。
不适用情况：如果用量本身没错、任务确实需要长上下文，那问题不在渠道而在任务设计，先考虑把任务拆小、分段处理，别急着换更便宜的站——便宜的通道配上失控的循环，账单一样会上去。
什么情况下这套判断不适用
这套口径建立在「单人、单 Key、用量相对稳定」的前提上。以下几种情况直接套会失真，需要换算法或换数据源。
- 团队多人共用一把 Key：人均成本要按人拆，不能照单人估算。
- 业务波动大：估算只能给区间，真实曲线去 /usage 看实际记录。
- 用免费额度或试用通道：价格口径和正式计费不同，别拿它做长期预算。
常见问题
DeepSeek 接进 Claude Code 后，是扣 DeepSeek 的钱还是 Claude 的钱？
看你把请求打到哪个地址、用谁的 Key。用 DeepSeek 的 Key 就是 DeepSeek 的计费口径，用中转站就是中转站自己的倍率；Claude Code 只是客户端，本身不决定扣谁的钱。先确认域名和 Key 归属再谈费用。
为什么我估算的月成本跟账单差很多？
常见三类原因：一是走了不同渠道，单价口径不一样；二是上下文被大文件和旧对话撑大，实际 Token 远超估算；三是客户端后台重试或 Agent 循环把同一段内容算了好几遍。先按渠道、上下文、重试三个方向逐个排。
是不是越便宜的中转站越划算？
不一定。便宜可能来自倍率低，也可能来自模型路由到别的版本或限流更严，跑起来重试一多反而更贵。先看站内检测结论和排行榜口径，再用一两个真实任务实测成本，别只看标价。
