编程 Agent 的额度，其实是一种 SLA
先说结论
编程 Agent 的额度，我越来越倾向于把它当成一种 SLA，而不是订阅页面上的赠品。
因为聊天产品被限流时，用户通常只是晚一点得到一个回答；编程 Agent 被限流时，可能正好停在：
- 已经改了几个文件，但还没跑完测试
- 子 Agent 已经启动，但主任务还没有汇总
- 上下文压缩刚做完，下一步还没执行
- 一次部署正在等待最后一个检查
这时候额度变化不是“少聊几句”，而是直接影响任务的连续性和恢复成本。
最近 OKP 记录了 Anthropic 和 OpenAI 编程产品在同一时间窗口里的额度讨论：Anthropic 侧的公开信息涉及 Claude Code 周额度从临时增加调整为较小的永久增加；OpenAI 侧则出现了“重置付费用量、优化 token 消耗”的公开公告和社区解读。社区把它概括成“额度暗砍”和“重置更耐用”，讨论热度很高。
这里必须区分三层事实：
- 厂商正式公布的政策
- 社区根据账户体感做出的观察
- 用户自己在某个模型、套餐和时间窗口里的实测
这三层不能混成一句“某家把额度砍了”。但它们共同说明了一个问题：Agent 的容量边界已经是产品契约的一部分。
价格和额度不是一回事
很多产品页面只展示月费和模型名称，用户却真正受到下面这些变量影响：
| 维度 | 价格回答什么 | 额度/SLA 要回答什么 |
|---|---|---|
| 订阅费 | 每月付多少钱 | 这一档能持续做多少工作 |
| token 价格 | 每次调用多少钱 | 一项任务会消耗多少可用容量 |
| reset 周期 | 什么时候结算 | 什么时候恢复可用额度 |
| 并发 | 单次请求成本 | 同时跑几个任务不会互相拖垮 |
| 模型可用性 | 能不能选某个模型 | 该模型在高峰期是否稳定可用 |
| 失败处理 | 请求失败是否收费 | 失败后任务能否继续、是否重复扣费 |
| 历史恢复 | 是否保存聊天记录 | 中断后能否从原位置恢复工作 |
一个“很便宜但经常在长任务中途停下”的 Agent，实际成本可能高于一个单价更高、但一次能完成任务的 Agent。
为什么编程任务特别依赖连续性
编程 Agent 不是只返回一段文字。它通常维护一条执行链：
理解需求 → 定位代码 → 制定计划 → 修改文件 → 运行测试 → 读取错误 → 修复 → 再测试 → 汇总结果每一步都可能触发新的模型请求和工具调用。额度在这条链中间耗尽，会留下一个不完整但已经产生副作用的现场。
从用户角度看，真正关心的不是“今天还能发送多少条消息”，而是：
- 这个任务还能不能完成
- 被打断后恢复要不要重新解释
- 已经改动的文件是否能安全保留
- 额度恢复前我能不能继续做别的任务
- 有没有明确的剩余容量提示
所以编程 Agent 的用量指标应该更接近任务维度，而不是消息维度。
我会定义哪些容量指标
1. 可用请求预算
不是总 token 数，而是当前时间窗口还能发起多少次有效模型请求。工具调用、重试和子 Agent 都应该计入。
2. 上下文预算
同样一个模型，在短会话和长会话中的成本完全不同。需要区分：
- 当前输入 token
- 输出 token
- cache hit / miss
- 压缩或历史重建产生的额外输入
- 子 Agent 是否重复携带上下文
Claude Code 官方文档已经提供 /usage、prompt cache、团队 spend limit 和 OpenTelemetry 等用量观察手段。这个方向是对的：用户至少要能知道容量花在哪里。
3. 时间窗口
“每周额度”太粗了。实际产品至少应该说明：
- 五小时窗口如何计算
- 周窗口何时重置
- 多设备是否共享
- 聊天、Cowork 和 Code 是否共享
- 失败请求是否占用额度
- 重置是否立即生效
4. 连续任务保证
这是最容易被忽略的指标。一个任务如果已经开始执行，额度不足时产品应该有明确策略：
继续当前任务 或切换备用模型 或保存 checkpoint 后暂停 或请求用户补充额度直接返回一个模糊的“达到限制”并丢掉上下文，是最差的处理方式。
5. 资源归属
如果一个主 Agent 开了三个子 Agent，额度应该能回答：
主任务用了多少子任务 A 用了多少重试用了多少哪个工具产生了最多上下文否则用户看到的总数无法指导下一次决策。
额度变化为什么会伤信任
价格调整至少是一个容易理解的数字：每月从 20 变成 25。额度调整更难，因为用户要通过长时间使用才能发现变化。
最伤信任的不是额度少，而是这几种不确定：
- 页面写着“无限”，但长任务会在不透明的地方停下
- 同一个任务今天能完成，明天突然只做到一半
- 额度条跳动，但没有解释是输入、输出、重试还是并发造成的
- 重置时间和用户看到的时间不一致
- 失败请求是否扣费没有说明
编程 Agent 的用户本身就在把真实工作交给系统。他们会容忍模型偶尔犯错，但很难接受容量边界不可预测。
如果是我来做 Agent 产品
我会把额度设计成一个可观察、可恢复的状态机，而不是一个藏在后端的计数器：
┌──────────────┐ │ task running │ └──────┬───────┘ │ budget low ┌──────▼───────┐ │ warn user │ └──┬─────┬─────┘ │ │ ┌────────▼┐ ┌─▼──────────┐ │ fallback │ │ checkpoint │ │ model │ │ and pause │ └────┬─────┘ └─────┬──────┘ │ │ └──────┬───────┘ ▼ task continues具体做法是：
- 任务开始时估算一个区间，不假装精确
- 接近阈值时提前提醒，而不是等请求失败
- 保留最近一次可恢复 checkpoint
- 把备用模型和备用 provider 当成正式路径
- 记录每次 fallback 的原因和额外成本
- 额度耗尽时保留任务状态、已改文件和待办步骤
- 让用户能看到 reset 时间和当前任务的预计消耗
这和我们在做 Pi/cohub 时关注的事情是一致的：Agent 不是一次回答，而是一段可能持续很久的工作。工作系统必须知道自己何时应该继续，何时应该停下来等人。
用户自己能做什么
在服务商策略无法改变时，我会采用几条保守策略：
把长任务拆成可恢复阶段
不要让一个会话同时负责分析、实现、测试和部署。每个阶段写出明确产物，下一阶段从文件和 checkpoint 接着走。
给强模型留预算
机械搜索、格式修改、简单测试可以用便宜模型；设计方案、跨文件重构和最终审查留给强模型。关键不是永远用最强模型，而是不要在低价值步骤把预算消耗完。
记录自己的任务成本
我会记录：
任务名称开始/结束时间模型请求次数是否发生压缩是否发生重试最终是否完成一两周之后，才能知道自己真正买的不是“多少 token”，而是多少个完成的任务。
预留故障转移路径
如果一个模型或 provider 是唯一入口，额度一变，整个工作流就会被带走。能接 OpenAI 兼容接口、能保留 transcript、能切换模型的 Agent，抗波动能力会更好。
本地模型也有额度
本地部署看起来没有服务商 quota，但它有自己的容量边界：
- 显存和系统内存
- 磁盘吞吐
- 并发 slot
- 温度和功耗
- 长上下文的速度衰减
- 模型加载和切换时间
我上一篇写 Qwen3.8-Flash-Next 时就提到过：模型“能加载”不等于“能生产”。本地 Agent 的内存和吞吐其实也是一种 SLA，只是承诺方从云服务商变成了自己的机器和推理后端。
最后
编程 Agent 的额度不是一个抽象的套餐数字。它决定了一个正在修改真实代码的系统能不能把事情做完。
所以我希望未来的 Agent 产品页面少写一点“无限”，多写几件更有用的事：
- 一个任务大概能跑多久
- 额度在什么情况下会消耗
- 接近上限时会怎么处理
- 中断后能不能恢复
- 备用路径是什么
SLA 的核心不是承诺永远不出问题，而是出问题时边界清楚、状态保留、用户知道下一步该怎么办。
这对编程 Agent 尤其重要。