安装 @deepseek-ai/dsh-subagent-codex 后，很多用户会遇到一个问题：主代理明明使用 DeepSeek，为什么任务里出现了 Codex？这些请求到底算在 DeepSeek 账号、Codex 使用额度，还是 API 中转站余额里？
判断费用归属，不能只看界面上显示的主模型名称。
你需要确认主代理和子代理各自使用什么模型、请求发送到哪里，以及哪个账号实际承担调用。把这条链路理清，才能判断某次任务为什么变贵、为什么中转站没有日志，以及哪些费用能够统一核对。
本文围绕 dsh 子代理的费用归属和实际排查展开，不重复安装教程。
先明确：主代理使用 DeepSeek，不代表子代理也使用 DeepSeek
主代理负责理解需求、分配任务和汇总结果。
当它调用 Codex 子代理时，会启动另一套执行过程。当前 @deepseek-ai/dsh-subagent-codex 官方说明强调，原生 Codex 的配置与认证仍然具有决定作用。主代理的模型选择，不能直接证明子代理使用相同的模型或账号。
因此，可能出现以下情况：
| 调用部分 | 可能使用的连接 | 应到哪里核对 |
|---|---|---|
| 主代理请求 | DeepSeek 官方接口 | 对应服务商的用量与账单 |
| 主代理请求 | TreeRouter 等 API 中转站 | 中转站对应账号的调用记录 |
| Codex 子代理 | Codex 当前原生认证与配置 | 该认证方式对应的额度或账单 |
| Codex 子代理 | 已正确配置且兼容的 API 通道 | 实际承接请求的提供商或中转站 |
这张表描述的是排查方向。具体费用归属，必须以本次运行的实际配置为准。
第一步：给一次测试任务建立记录
不要直接拿一整天的余额变化判断某个子代理用了多少钱。
先选择一个范围较小的任务，例如：
“让一个 Codex 子代理检查指定函数的输入验证逻辑，返回问题列表，不修改文件。”
开始前记录：
- 主代理使用的模型和提供商。
- 子代理的认证方式与模型配置。
- 开始时间。
- 任务说明。
- 允许读取的文件范围。
- 相关账号的可用用量记录。
任务完成后再记录结束时间、是否成功、是否发生重试，以及子代理结果是否被主代理重新整理。
为了减少其他请求干扰，可以在测试期间使用专用项目密钥；如果当前平台不支持按项目区分，则至少使用明确的测试时间窗口。
不要把真实密钥写进共享表格。记录密钥名称、用途或允许展示的标识即可。
第二步：确认子代理是否真的被调用
启用插件，不等于已经发生子代理执行。
当前官方文档说明，启用相关 Bundle 会注册工具，但原生子代理进程要等到实际委派任务时才启动。具体行为可以查阅 Codex 子代理官方说明。
因此，检查费用之前，先确认：
- 本次任务是否出现了真实委派。
- 子代理是否成功启动。
- 是否完成了模型请求。
- 是否因错误被重新委派。
如果插件启用了，但主代理自己完成了任务，就不能把所有费用归为“Codex 子代理费用”。
反过来，如果主代理连续分配了三次相近任务，也不能只按照一次子代理执行估算。
第三步：核对子代理的实际配置
这是最容易出现误判的地方。
在主代理配置中填入中转站地址，并不自动证明 Codex 子代理也走同一个地址。
当前插件文档指出，传入的模型名称不会替你自动选择提供商或建立回退配置；子进程环境中的凭证传递也有专门规则。因此，需要按照当前版本文档核对原生 Codex 配置及子进程所需凭证。
实际检查时，重点确认：
- 子代理最终选择的提供商。
- 配置中的模型 ID 是否真实可用。
- 使用哪一种认证方式。
- 请求协议是否被目标通道支持。
- 运行环境是否拿到了所需凭证。
尤其不要把“支持 OpenAI 兼容聊天接口”直接理解为“完整支持当前 Codex 工作流”。不同工具可能需要不同端点、流式事件或工具能力。
如果准备使用 API 中转站，可以先阅读 TreeRouter API 接入说明，再核对目标工具实际需要的协议。基础文本请求成功，只能作为第一步验证。
第四步：把任务费用拆成几部分
一次带子代理的任务，可能包含以下费用：
任务总 API 费用 = 主代理请求费用 + 子代理请求费用 + 后续汇总费用 + 其他已计费请求
其他已计费请求可能来自重试或工作流中的辅助环节，是否产生费用取决于实际执行情况。
下面是纯计算示例，不代表任何模型价格：
- 主代理规划：0.02 元。
- 第一次子代理执行：0.06 元。
- 重新执行：0.04 元。
- 主代理整理结果：0.01 元。
这次任务合计为 0.13 元，而不是只看第一次子代理执行的 0.06 元。
如果其中一部分使用订阅额度，而另一部分使用 API 按量计费，应分别记录使用量和现金支出。没有明确计费规则时，不要把所有订阅使用量硬换算成某个 Token 单价。
第五步：为什么中转站没有看到子代理日志
常见原因是子代理根本没有通过该中转站发送请求。
也可能是子代理尚未成功启动、在鉴权前失败、使用了另一个项目密钥，或者你正在查看错误的账号和时间范围。
建议按下面的顺序排查：
- 确认真实发生了子代理委派。
- 查看子代理启动和请求是否成功。
- 核对提供商与认证配置。
- 核对中转站账号及密钥归属。
- 检查时间范围和日志展示延迟。
- 用可获得的请求标识进一步核对。
不要因为主代理已经连接 TreeRouter，就认定全部下游调用都会出现在 TreeRouter 的账单里。
同样，中转站出现一条主代理请求，也不能证明子代理请求已经经过相同通道。
第六步：为什么限制并发，费用仍然会上升
限制同时运行的子代理数量，有助于控制瞬时负载，但不能直接限制整个会话的累计 Token。
DeepSeek Harness 的子代理服务文档明确区分了活动子代理数量与累计用量；并发容量设置不约束整个会话的 Token 消耗。可以参考 子代理服务官方文档。
即使每次只运行一个子代理，如果主代理连续委派十次，累计费用仍然可能上升。
要控制成本，需要同时控制任务范围和执行次数：
- 限定需要检查的文件。
- 定义什么时候算完成。
- 避免重复提交相同背景。
- 对失败后的再次执行设置明确规则。
- 使用实际可用的预算限制或额度提醒。
不要把“最多同时运行一个子代理”误写成“最多只产生一次调用费用”。
第七步：优化任务说明，比盲目换低价模型更有效
下面这样的任务容易不断扩展：
“全面检查项目，发现问题就继续深入，直到没有任何问题。”
因为没有明确终点，Agent 可能持续读取文件、扩大检查范围或反复验证。
可以改成：
> 检查 payment_validation.py 中金额和币种校验的实现，只阅读该文件及直接相关测试。最多返回五项有代码依据的问题。不要修改代码，不继续检查其他模块。如果证据不足，说明缺少什么，并结束本次任务。
这种任务描述让结果更容易验收，也便于比较不同模型的表现。
比较模型时，应看“完成一次合格任务的费用”，而不只是输入 Token 的标价。低价模型如果反复失败、重复读取或需要多次重做，未必更省。
第八步：什么情况下适合通过 API 中转站管理调用
当多个项目需要访问不同大模型，而你希望统一查看部分 API 调用时，中转站可以成为一个接入选项。
前提是目标模型和工具协议确实兼容，并且请求实际经过该通道。
可以在 TreeRouter 模型列表中确认模型，再用一个小任务测试连接。验证时同时查看任务结果与调用记录，而不是仅检查是否出现成功提示。
如果主代理走中转站、子代理走其他认证方式，就应保留两套核对来源。这比强行假设“一把 Key 管理所有费用”更准确。
常见问题
安装 dsh-subagent-codex 就会持续消耗 Token 吗？
不能这样判断。需要区分插件启用、子代理执行和实际模型请求。其他运行中的主代理或辅助任务，也可能独立产生用量。
主代理使用 DeepSeek，子代理就一定更便宜吗？
不一定。子代理的模型、认证方式、执行次数和任务上下文，都需要单独核对。
修改子代理模型名称，就能切换到中转站吗？
不能只改名称。还要核对提供商配置、协议、地址、凭证和当前工具的支持情况。
并发限制能代替预算限制吗？
不能。并发限制约束同时活动的任务数量，预算控制关注累计费用。
怎样判断配置是否真正生效？
使用一个可重复的小任务，对照实际模型配置、执行记录和服务商账单。仅凭界面上显示的名称不足以确认。
从一条可核对的调用链开始
先把“谁发起请求、请求去了哪里、哪个账号承担费用”解释清楚，再决定是否增加子代理数量或扩大任务范围。
如果计划将兼容的模型请求接入 TreeRouter，可以注册账号，核对当前模型与接口支持情况，完成一次小任务测试，并确认实际请求记录。这样得到的成本判断，才适合用于后续选型和规模化使用。
