你让AI接着修项目，也能看到Token统计。于是想再加一道限制：额度用完就停。这时最需要弄清楚的是，系统只会在事后提醒，还是能在下一次请求发出前把它拦下来？
10月29日晚到30日凌晨，我核对了自己使用的Codex／DSH混合调用链。本次结论是：没有足够证据证明这些入口已经统一接入逐请求的预算控制，因此不能承诺严格不超额。这是当前环境的核查结果，不能推成“这些产品都没有预算功能”。
这次具体查了什么？
这轮做的是只读能力核查：查命令帮助、当前配置、运行进程和官方接口资料，没有拿真实模型请求测试额度能否拦住。下面是实际检查及它们各自能说明的事情。
1. 命令行入口：确认能怎样启动，尚未验证预算拦截
核查运行了Codex的--version、--help、exec --help和app-server --help。当时版本输出为codex-cli 0.165.0-alpha.1.2，帮助中可以确认exec和app-server入口。
这些输出证明入口可用，不证明它们已接入同一个预算控制器。核查还查看了协议Schema生成命令的帮助，但没有生成Schema或据此完成接口测试；也不能因为帮助里没找到某个参数，就断言整个产品不存在相应能力。
2. 当前配置与运行程序：找到多个入口，未查明统一控制
核查只读解析了Codex配置中的控制项和已有连接，并用系统进程清单确认DSH Desktop与DeepSeek Harness都在运行。当前所查配置中，未发现已接入、可验证的DSH请求前预算接口。
这里的边界很重要：程序在运行，不等于已追踪到它的每一次模型请求。本次没有抓取请求流量，也没实测从另一个入口绕过控制。因此，准确说法是“尚未证明已经统一纳管”，而不是“已经证明所有入口都能绕过”。
3. 官方接口资料：有预算和停止能力，但仍需核对覆盖范围
对照App Server文档，可以找到线程用量更新和回合中断接口；Goal说明也确实提供tokenBudget，用于线程目标的预算与续跑控制。
这些能力不能被忽略。本次尚未证明的是，它们能否覆盖当前混合链中的每次请求，并满足逐请求预留、跨线程共享额度的要求。hooks文档还说明，部分工具路径不经过本地hook，不能把工具hook直接当作完整的强制执行边界。
额度不足是否拒绝调用、并发时会不会重复占用余额、超时后怎样结算，以及一次请求包含重试后最多消耗多少，本轮都没有实测。本次没有安装软件、改变调用配置或发起付费模型测试，原业务任务继续暂停。
为什么看见用量，仍不等于管住预算？
这有点像消费短信和刷卡前的余额检查：短信告诉你已经花了多少；余额检查决定下一笔能不能付。即使用量通知很及时，等它到达时，请求也可能已经发出。
判断自己的工具时，可以先追问一句：余额不足时，究竟是谁在模型请求发出前拒绝它？回答如果只是提醒或中断，还需要继续验证实际覆盖范围。
真要验证，下一步应测哪些环节？
对于能够自行控制每次调用的程序，OpenAI的Responses API预算控制示例提供了参考顺序：先预留，再请求，最后按实际用量结算。落到自己的环境里，可以围绕四件事设计测试：
- 检查实际入口。每次请求是否先核验任务授权和预算？其他入口能否绕过？
- 确定并预留本次上限。完整输入、最大输出和重试规则是否可界定？两个执行者同时申请时，能否避免都把同一份余额当作可用？
- 按实际用量结算。收到结果后释放未用的预留，同一响应不能重复扣除。
- 对未知消耗保持占用并停下。客户端超时不代表服务端没有执行；费用没查明前退回全部额度再重试，可能掩盖重复消耗。
这份示例只覆盖特定条件下的同步、非流式模型Token费用，额外工具费等不在其中。Token用量也不能直接当成金额：模型、输入输出和缓存等计费差异仍需另行核对。它适合作为测试设计参考，不能直接放到桌面程序外面就视为接管了内部请求。
这次停在哪里？
这次核查给出的建议，是先停止沿当前桌面混合链继续叠加硬预算机制。下一步若仍要求严格上限，应先选定实际承载全部请求的入口，再验证上述环节；入口和单次消耗上界都没弄清，增加日志或管理文件无法补足保证。
如果能接受软限额，可以另行考虑减少并发、缩小任务窗口、监测用量并设置停止条件，但需要接受停止可能滞后。这只是可选择的方向，本次没有改用软限额执行，也没有得到预算拦截成功的测试结果。
发表回复