速读#
以前我对模型额度的理解很简单：套餐够不够用，还能继续问多久。直到开始让 Agent 连续工作数小时甚至数天，我才发现额度并不是一个单独的数字，而是上下文窗口、滚动时段、周额度、缓存、请求频率和任务恢复共同组成的边界。
一次 Claude Max 20x 尝试让我直接碰到了这些限制。同期，本地统计面板记录了 2026 年 6 月 1 日至 7 月 29 日的开发调用：多个模型与来源合计 7,427,014,690 Tokens、50,776 次请求，缓存命中率为 87.8%。
这组数据看起来很大，但它真正说明的不是我生成了多少内容，而是工作方式已经从单轮对话转向持续运行的 Agent：先是 Hermes 带来的跨会话使用，后来是 Loop 对任务的反复执行与验证。额度开始像开发环境的资源上限，而不再只是聊天产品的套餐说明。
从 Max 20x 开始重新看额度#
Claude Max 20x 给我的第一印象是额度很高，但真正使用时，界面里同时存在几条不同的边界。
套餐页首先区分了当前会话和周额度。当时当前会话使用了 61%，Fable 周额度使用了 51%。页面下方还把套餐额度与额外 Usage Credits 分开：不开启额外额度时，触顶后的默认处理是等待额度恢复，而不是继续按量消耗。
进入具体任务后，还会看到上下文窗口和五小时滚动额度。
截图中，上下文已经达到 760.8k / 1.0M，五小时额度使用了 93%，另有按模型计算的周额度。它们分别限制不同层面：
- 上下文窗口决定当前任务还能携带多少代码、日志和历史状态；
- 五小时额度决定短时间内还能维持多高的调用强度；
- 周额度决定某个模型在更长周期内还能使用多少。
所以“20x”并不等于一个可以随意消耗的总池子。一个长任务可能上下文还有空间，却先撞到滚动额度；也可能短期额度恢复了，但周额度仍然紧张。对普通聊天影响不大，对运行中的 Agent 则意味着任务会在中途暂停。
这次 Claude Max 尝试后来因为账号被暂停、订阅退款而结束。通知邮件没有说明具体触发原因，因此这件事只作为使用经过记录，不与额度消耗建立因果关系。
额度不是“还能问多少次”#
在 Coding Agent 里，一次可见任务往往对应很多次模型调用。读仓库、搜索调用关系、修改文件、执行测试、分析失败和再次验证，每一步都可能重新携带已有上下文。
本地统计工具记录到 Claude Code 累计约 27.04 亿 Tokens、13,707 次请求，缓存命中率为 80.7%。
其中缓存命中约 21.76 亿，占据了主要部分。也就是说，屏幕上看到的最终回答只占很小一段，大量 Token 用在重复读取项目上下文和任务状态上。
图中的 $4686.8956 是按照 API 定价折算的等价成本，不是订阅支付金额。它能帮助判断调用规模，却不能直接回答套餐里还剩多少额度，因为本地统计和服务商额度并不是同一套计量规则。
这也是 Agent 场景下最容易混淆的地方：Token 统计、套餐额度和支付金额彼此相关，但不能互相替代。
我的日常开发用量#
同期，我接入统计面板的全部开发调用累计约 74.27 亿 Tokens。这是多个模型与来源的合计，不是 Claude Max 单账号数据。
- 新增输入约 6.58 亿；
- 输出约 2877.4 万；
- 缓存创建约 2.46 亿；
- 缓存命中约 64.95 亿；
- 总请求数 50,776。
缓存命中占据了绝大部分。仓库代码、任务计划、历史修改、工具结果和测试日志会在后续请求中反复使用，同一份上下文经过多轮调用后，累计数字自然会快速放大。
面板显示的 $9367.5821 同样只是 API 等价成本估算。订阅、缓存计价和不同来源的路由方式都会改变最终支出，所以我更愿意把它当作负载指标，而不是账单。
对我来说，这组数据最有价值的地方是把工作量拆开了：输出并不是主要消耗，持续携带上下文和反复验证才是。额度压力往往在任务完成之前出现，而不是在答案变长之后出现。
用量从哪里来：先 Hermes，后 Loop#
这些用量并不是突然出现的，它和我使用 Agent 的方式变化有关。
更早前，我先尝试了 Hermes Agent。当时关注的是跨会话记忆、会话搜索、Skills 和长期运行：Agent 能不能在下一次启动时继续理解项目，而不是每次都从头解释。
Hermes 把使用单位从“一段对话”拉长成“持续存在的 Agent”。这类能力很适合长期维护，但也带来新的额度问题：哪些记忆需要进入当前上下文、Skills 会不会不断膨胀、跨会话状态每轮要重复携带多少。长期记忆降低了重新解释的成本，也可能增加持续注入的上下文。
后来我开始尝试 Loop。一次比较完整的实践，是用 /goal 加 Stop hook 处理 39 篇博客：目标记录进度，任务未完成时继续下一轮，清单和审稿标准负责验证结果。
Loop 解决的不是“记不记得”，而是“下一步做什么”和“什么时候结束”。它会把一个目标拆成多轮读取、执行、验证和回退，也因此更直接地消耗滚动额度。
同样的工作方式后来出现在 Codex 的长目标里。有一次目标连续运行了 1 天 19 小时 48 分钟，当时仍处于第 2/5 步。
长时间运行不等于模型一直输出文字。任务还在搜索代码、执行命令、等待结果、验证修改和继续推进。每一轮都要带回一部分已有状态，这正是请求数、缓存命中和总 Token 持续增长的来源。
Hermes 让任务跨会话延续，Loop 让任务在会话内反复推进。它们并不是文章的主角，而是解释了为什么我的额度消耗已经不能再按“每天问了多少个问题”计算。
我现在更在意怎样的额度#
经历这些任务后，我不再只看套餐名称或总倍数，而会关注额度是否适合长时间工作。
额度是否可观察#
至少要能区分上下文窗口、滚动时段、周额度，以及输入、输出和缓存。只有一个总进度条，很难判断该缩短上下文、等待恢复，还是切换模型。
中断后能否恢复#
额度耗尽不应该等于任务报废。进度、修改结果和验证状态需要保存在对话之外，恢复额度后能从检查点继续，而不是重新读取整个仓库。
是否支持平稳降级#
主模型额度不足时，低风险步骤能否切换到其他模型，关键判断再留给主模型。比起单纯增加额度，这种分层更接近工程使用。
有没有明确的停止条件#
Loop 没有终点时，再高的额度也会被空转消耗。最大迭代次数、连续失败检测、时间上限和预算上限应该在任务开始前确定，而不是额度见底后再补。
在长任务里，可预测的中断和可靠的恢复，比一个看起来很大的额度数字更重要。
最后#
Claude Max 让我开始认真看额度的组成，日常统计让我看清用量的来源，Hermes 和 Loop 则解释了为什么工作流会从几十次对话增长到数万次请求。
当 Agent 开始长时间工作，额度不再只是产品套餐的一部分。它会直接决定任务能否继续、能否恢复，以及自动化是否值得运行。
我现在关心的不是哪个套餐给出的数字最大，而是哪套额度能够被看见、被规划，并在任务中断后继续使用。