摘要 10 月 24 日，一位 Claude Max 用户第一次用第三方编程工具 T3 Code，约 30 分钟就撞上了 5 小时额度上限。第二天，T3 Code 创始人 Theo 说他排查了一天，确认是 Anthropic 那边的 bug：经 Agent SDK 的用量消耗 5 小时额度比直接用 Claude Code 更快，周额度不受影响，已上报。要注意两点：说“不是我们工具的问题”的正是工具方本人；但早在 9 月 25 日，就有无关用户在 Anthropic 官方仓库报过同样的问题，此后 5 组与 T3 Code 无关的用户对照测量，加上 T3 Code 自己的一组，结论方向一致，消耗速度约是交互式使用的 1.3 到 2.9 倍。截至 10 月 25 日，Anthropic 尚未公开确认。
很多人默认，同一个 Claude 模型、同一份订阅，在官方 Claude Code 里用还是在第三方工具里用，消耗应该一样。这两天的一场讨论说明，事情可能没这么简单。（文中日期均为北京时间。）
发生了什么：30 分钟撞上 5 小时上限
10 月 24 日，一位开发者在 X 上求助：他刚下载 T3 Code，第一次在 Claude Max 套餐上撞到 5 小时额度上限。他说只开了一个会话，让它修项目里几个和支付有关的 bug，结果约 30 分钟就把整整 5 小时的额度用完了，而他的提示方式和平时在 Claude Code 命令行里一样。
T3 Code 是一款第三方 AI 编程工具，底层通过 Anthropic 的 Claude Agent SDK 调用 Claude。Agent SDK 是 Anthropic 提供给开发者的工具包，别的应用可以借它像 Claude Code 一样让 Claude 读代码、跑命令、改文件；按官方帮助文档，Agent SDK、claude -p（Claude Code 的非交互命令行模式）和第三方应用的用量，都从你的订阅额度里扣。
不过从他贴出的截图看，这个“会话”里同时派出了多个子 agent（被拆出来并行干活的小任务），分别在处理询价、导入、公开页面、登录、支付等问题，实际工作量比“修几个 bug”大。工作量大本身就会更快用光额度，所以单看这一例，还不能说明是计量出了错。
Theo 的结论，以及他的身份
10 月 25 日，T3 Code 的创始人 Theo（知名技术博主）发帖说，他花了一天排查，“确认这是 Anthropic 那边的真实 bug”：所有经 Agent SDK 的用量（他推文里写作 agents SDK），消耗 5 小时额度都比直接用 Claude Code 更快；周额度不受影响；他已经报给 Anthropic，希望尽快修复。他还在 T3 Code 的代码仓库里贴出了测试：同一个 Max 账号，测试开始时 5 小时额度和周额度都是 0%，之后用同样的工作量依次交替跑交互式 Claude Code、T3 Code 和 claude -p，第二组顺序反过来。
交互式 Claude Code 两次各让 5 小时额度涨 7%，T3 Code 两次分别涨 13% 和 16%，claude -p 涨 9%；而周额度每轮都只涨 2%。他据此估计，同样的 token，经 SDK 消耗的 5 小时额度约是交互式 Claude Code 的 1.6 到 1.7 倍；也就是说，用 T3 Code 把 5 小时额度用满时，只用掉了周额度的约 14%，直接用交互式 Claude Code 时则是约 29%。
要点明的是，这是利益相关的说法：用户撞上限用的是 T3 Code，说“不是工具的问题，是 Anthropic 的 bug”的，正是 T3 Code 的创始人。他的测试也只有一个账号、少数几轮。至于原因，Theo 的说法是“我怀疑”与 9 月 23 日官方提高 5 小时额度有关，可能这次上调没对 Agent SDK 生效；他在问题单里（那条评论注明由 AI 代他发出）还补了一句自己“大概 95% 确定”。再笃定也只是猜测，官方没有证实。
工具方之外：一个月前就有人报过
让这件事更可信的，不是 Theo 的表态，而是 Anthropic 自己的代码仓库。早在 9 月 25 日，一位与 T3 Code 无关的用户就在 Claude Code 的官方仓库提交了问题单：同样的工作量，用 claude -p 跑比在交互界面里跑，消耗的 5 小时额度约是交互界面的 1.8 倍，而 token 用量相同。
此后一个月里，又有几位用户在同一个问题单下贴出各自的测试，套餐、对比对象和测法都不一样：
这 6 组对照测量里，5 组来自与 T3 Code 无关的用户，1 组是 T3 Code 自己的。方向一致，都是经 SDK 或 claude -p 的用量消耗 5 小时额度更快，但幅度差别很大，约是交互式使用的 1.3 到 2.9 倍。另有两位用户贴出了非受控的观测，差距更大（一位估算约 3 到 4 倍，另一位手动对比是 4 个百分点对 1 个百分点），但任务不同、测法粗糙，没有计入。所以比较稳妥的说法是：问题大概率存在，具体快多少，没有一个可以当定论的数字。截至 10 月 25 日，这个问题单有 18 条评论，没有一条来自 Anthropic 员工；问题单上的“bug”“has repro”等标签是机器人自动加的，不代表官方确认。
科普：为什么周额度没事，5 小时额度先爆
Claude 的 Pro 和 Max 订阅，其实有两块表在同时计数。按官方帮助文档，两种套餐都有一个 5 小时额度（five-hour session limit，按 5 小时一段计算的会话额度，用完要等它重置）和一个周额度（一周的总用量上限），Max 套餐还另有一个单独的 Fable 模型周额度。网页、App、Claude Code、IDE 插件里的用量都算进同一份额度，Agent SDK、claude -p 和第三方工具也一样。
两块表各管各的：任何一块先到顶，你都会被拦下。这次的反常之处在于，同样的工作量，经 SDK 时周额度涨得和平时一样，5 小时额度却涨得更多。结果就是周额度看着还很宽裕，5 小时额度却先爆了，很容易让人以为是自己提示词写太长、任务派太多。
修复之前，普通开发者能做什么
先看是哪块表在掉。 如果你在用第三方工具或自己写的 Agent，发现周额度正常、5 小时额度掉得特别快，先别急着怀疑自己用错了，很可能就是这个问题。
重活放回终端里的交互式 Claude Code。 目前的报告里，在终端里直接交互使用的 Claude Code 没有出现这种多扣；桌面端经 Remote Control（远程控制）运行的会话，有用户报告同样受影响；VS Code 扩展的结论还待确认。长任务、要并行派很多子 agent 的活，修复前可以先放在这里跑。
Max 用户可以考虑每月送的 API 额度。 从 10 月 7 日起，Max 和 Team 套餐每月附带 Claude 开放平台的 API 额度（Max 5x 每月 100 美元，Max 20x 每月 200 美元），官方说明它覆盖 Agent SDK 和 claude -p，前提是用关联的开放平台组织生成的 API key 来调用，而不是用订阅账号登录，所以第三方工具得支持填 API key。领取条件是订阅满 7 天，并先在 claude.ai 的账单设置里关联一个开放平台（Console）组织。这样就不占订阅的 5 小时额度，但按 API 价格计费；额度当月不结转，用完后请求会停下，除非自己买额度或打开自动充值。
别用改请求头的绕法。 网上有人提到，某些代理工具会给请求加上“交互界面”的标识，因此不受影响。这类做法本质是伪装请求来源，可能违反使用条款，不建议用。
第三方工具和订阅之间的灰色地带
这一节是编辑判断。这件事暴露的不只是一个可能的 bug，还有订阅制 AI 工具的一个灰色地带：用户付的是同一份订阅，但额度怎么计、不同入口是否同价，官方文档写得并不细。帮助文档只说 SDK 和第三方应用“从订阅额度里扣”，没说会不会按入口加权；而第一位报告者在问题单里提的诉求正是：如果是有意为之，请写进文档。
在官方回应之前，对 Theo 的结论最好打个折扣，对“一个月前就有人复现”的事实则可以多给一点分量。真正需要的，是 Anthropic 说清楚：这是 bug 还是规则；如果是 bug，多扣的额度怎么算。