有用户挂了一夜自动任务，六小时后发现周额度少了 20%，随即引发「额度是不是被砍了」的讨论。本文区分 token 消耗与额度百分比两套计量口径，分析无人值守长任务为何格外费额度，给出可复现的量化方法与省额度清单，并说明「模型变差」这类感受该如何验证。
问题：任务跑了一夜，额度少了两成
有人睡前挂了一个自动执行的目标任务，六小时后回来一看：产出并不多，周额度却掉了 20%。类似的反馈还有几种：同样的工作量在早些时候很耐用，如今撑不到原来的一半；用客户端自带的统计对照，前六天消耗约 6 亿 token 用掉周额度 80%，最后一天只消耗 1800 万 token 却又扣了 20%；还有人干脆认为模型本身退化了，连标点符号用错都不承认。
这些说法混在一起，很容易直接得出「额度被偷偷砍掉」的结论。但把 token 数和额度百分比当成同一件事，往往是误解的起点。下面按「先弄清计量口径 — 再量化验证 — 最后落到省额度的操作」来拆解。
额度不是 token 计数器
订阅制里的周额度、短窗口额度，通常是服务方内部的一套加权计量，而不是公开的 token 账单。几个关键差异：
- 模型权重不同：同一段对话用高配模型和轻量模型跑，计入额度的比例可能差好几倍。
- 上下文越长越贵：多轮对话每一轮都要把历史重新送进去，上下文膨胀后单轮成本线性上升。
- 工具与子代理计入：工具定义常驻上下文，子代理、思考过程、缓存写入都可能参与计量。
- 百分比是粗粒度数字：界面上的百分比经过取整，一个大任务跨过某个计费步长、跳个 5%～20% 并不罕见。
- 规则会动态调整：高峰期限流、灰度放量、套餐倍率的调整都可能发生，历史经验未必适用。
所以「6 小时掉 20%」既可能是真的烧得多，也可能是一个失控的长任务再加上计量步长造成的观感放大。
为什么无人值守的长任务特别费
夜间任务没有人盯着，浪费会被自动放大：
- 上下文滚动膨胀：任务每推进一轮，历史记录都在变长，后半夜的单轮成本远高于开头。
- 失败重试与死循环：报错、重试、再报错，模型不断尝试同一个错误路径。
- 子代理与并行调用：一次派发多个子任务，消耗成倍增加。
- 常驻工具定义：装了用不上的插件或工具服务，每次请求都带着它们的定义。
- 网络中断或机器休眠：连接断开后重连重跑，同一段上下文被反复计费。
先量化，再下结论
在抱怨额度之前，先做一轮可复现的记录，避免把「感觉」当证据。
| 检查项 | 具体做法 | 目的 |
|---|---|---|
| 固定基线 | 清空上下文，同一模型、同一提示跑一次，记录前后额度百分比 | 得到单次任务的真实成本 |
| 统计口径 | 以官方用量页面为准，第三方统计只作参考 | 避免延迟与口径差异误导 |
| 区分额度池 | 周额度与短窗口额度分开记录 | 防止把限流当成额度耗尽 |
| 记录时间段 | 高峰期、低峰期各测一次 | 判断是否受限流或动态调整影响 |
| 记录任务结构 | 轮次、工具调用次数、上下文峰值，而不只是总 token | 找出真正的成本来源 |
如果固定基线的消耗与一两周前相比没有明显变化，那么「额度缩水」更可能是任务结构变重了；如果基线本身成倍变差，再把怀疑指向计量规则，并到官方文档与状态页确认。
把额度省下来的具体手段
- 治理上下文：任务切换时清空会话；长会话定期压缩；大文件按需读取而不是整份塞入；常驻说明文件保持精简。
- 给工具瘦身：关掉当前任务用不到的插件和工具服务，它们的定义会一直占着上下文。
- 模型分级：搜索、改名、格式化这类机械活交给轻量模型，只有难推理才上高配模型。
- 给自动循环加刹车：设定最大轮次、连续失败若干次即退出、每 N 轮把中间结果落盘再开新会话。
- 拆任务：夜间只跑确定性强的批处理，需要判断的步骤留到白天人工介入。
- 能用脚本就别用模型：批量重命名、文件搬运、格式转换交给 shell 脚本，避免模型一轮轮试错。
- 加监控：用一层包装脚本记录每轮耗时与用量，跑完输出汇总，便于下次判断值不值。
长任务放本地还是放常开机器
夜间长跑最怕两件事：本地机器休眠断网，以及网络抖动导致请求失败重试。笔记本合盖、Wi-Fi 掉线、代理切换都可能让任务停在半路，重连后同一段上下文被重新计费。
如果无人值守任务变成常态，可以考虑把执行环境挪到一台常开的机器上。例如整机放在新加坡机房的独享远程 Mac，按月租用、远程连接使用，不随本地设备休眠，网络环境相对稳定，适合挂着 Claude Code 跑整夜的任务。需要说清楚的是：它只解决稳定性和设备常开的问题，额度仍由同一账号的订阅规则决定，不能用来规避任何限额。
关于「模型变差」的抱怨
标点用错、不肯承认错误这类现象确实会让人怀疑模型被换了。但单次体验很难作为证据：上下文太长、提示含糊、工具返回异常，都会让输出质量突然下滑。相对靠谱的做法是建一个小型回归集：
- 准备 10～20 条有明确预期结果的提示，覆盖代码、中文排版、逻辑推理；
- 每隔一段时间用相同参数跑一遍，记录通过率；
- 对照官方更新日志与状态页，看是否有模型版本或路由变化；
- 只有在多条用例同时退化时，才把原因归到模型本身。
同时也要接受一个现实：服务方对模型路由、限流和额度的调整通常不会逐条公告，网上流传的各种倍率传闻和检测技巧大多无法验证，只可当作参考。
风险与合规提醒
额度紧张时容易出现的几类捷径都不建议碰：购买或共享他人账号、使用来路不明的「无限额度」中转、用非常规手段规避地区限制。风险包括账号封禁、付款信息与代码内容暴露给第三方、服务随时中断。更稳妥的替代路径是：按实际用量选择合适的订阅档位；把可预期的高强度任务改用按量计费的接口；把批量工作拆到不同时段或团队内分摊。
小结
- 额度百分比不等于 token 数，模型权重、上下文长度、工具调用和重试都会影响计量。
- 记录前后百分比并同时记录任务结构，才能判断是真消耗还是计量步长。
- 长任务的关键是控制上下文、限制循环、设置检查点，而不是一味延长运行时间。
- 无人值守场景优先解决稳定性，必要时使用常开的远程环境，但它不改变额度规则。
- 具体倍率与计费规则变化频繁，请以官方最新说明为准，别把几个月前的经验当作基准。