Claude Fable 5 的免费额度为什么消耗得很快？

Claude Fable 5 的免费额度或 usage credits 消耗很快，通常不是因为最后一句提示词本身很长，而是请求带上了整个对话历史、项目文件、工具定义与结果，并可能触发多轮代理执行和大量思考 token。要找出原因，应查看 Usage 页面或 API 响应中的实际用量，而不能只按屏幕上输入的几个字判断。

短问题也可能携带很长的上下文

在持续对话中发送“当前状态是什么”之类的短问题，模型仍需要读取前面的消息、代码、附件和工具结果。对话越长，每个新回合重新处理的输入通常越多。

如果此前运行的是大型代码库分析或长时间代理任务，最后一句状态查询可能继续推动任务执行，而不只是生成一句摘要。界面上的短输入因此不能代表完整请求大小。

项目文件和附件会进入处理范围

Claude 项目中的文档、上传文件、图片和代码在被对话引用时会占用上下文。文件数量多、单个文件大，或每轮都需要重新访问相关材料时，输入消耗会明显增加。

项目缓存可以降低部分重复内容的消耗，但缓存并不意味着所有文件永远免费。内容变化、前缀变化、缓存失效或不同工作流都可能导致重新处理。

Claude Code 一次操作可能包含多轮请求

Claude Code 会读取文件、搜索代码、运行命令、检查结果并继续修改。用户只发送一条指令，背后可能产生多次模型调用和工具往返，每一轮都会增加输入与输出用量。

状态询问若让代理继续恢复工作，还可能读取任务进度、终端输出和修改后的文件。计算成本时应按整个代理运行汇总，而不是只统计最后一条可见回复。

Research 和网页搜索消耗更快

Research 模式可能执行多次搜索、打开多个页面并综合长篇内容。搜索结果会作为上下文交给模型，既产生工具费用，也增加输入 token。

不需要外部资料的任务应关闭 Research、网页搜索和非必要连接器。需要检索时则缩小问题范围，并在获得足够证据后停止继续搜索。

工具定义本身也占输入

启用浏览器、代码执行、连接器或大量 MCP 工具时，系统需要把工具说明和参数结构提供给模型。即使某个工具最终没有被调用，其定义也可能增加请求输入。

官方定价文档指出，仅默认浏览器工具集定义就可能增加约 6,600 个输入 token，具体数量以实际 usage 为准。工具返回的页面文本、截图和控制台信息还会继续增加上下文。

思考 token 按输出计费

Fable 使用自适应思考，模型会根据任务复杂度决定推理量。思考 token 属于输出 token 并按输出价格计费，即使完整思考过程没有显示在最终回答中。

因此，可见回答只有几行并不代表输出成本很低。高 effort、复杂规划、反复验证和长代理循环都可能增加不可见的推理消耗。

Fable 的 token 计数可能高于旧模型

Fable 5 使用较新的 tokenizer。官方说明，同一文本相较 Claude Opus 4.7 之前的模型，可能产生大约 30% 更多 token，实际差异取决于内容和工作负载。

从旧模型迁移时，不能直接沿用原来的 token 估算。API 用户应使用 token counting 接口并指定实际 Fable 模型，对完整请求重新计数。

输入和输出价格差异会放大长回答

Fable 5 的标准 API 参考价是输入每百万 token 10 美元、输出每百万 token 50 美元。输出单价为输入的五倍，长篇生成、思考和多次重试都可能快速消耗余额。

订阅中的免费额度不是直接显示为固定美元数，但底层处理量仍会影响额度消耗速度。Usage 页面比“发送了多少条消息”更适合作为判断依据。

缓存失效会让重复上下文重新计费

提示缓存要求前缀稳定且在有效期内再次使用。修改早期系统指令、工具列表、项目内容或消息顺序，都可能破坏缓存前缀，使大段内容重新写入缓存或按普通输入处理。

长代理任务应保持可缓存前缀稳定，把频繁变化的内容放在后部，并检查 cache_creation_input_tokens 与 cache_read_input_tokens。只有看到真实命中数据，才能确认缓存正在节省成本。

失败、超时和重试也可能产生用量

客户端断线或超时不一定表示服务端没有处理请求。自动重试、用户手动重发和代理恢复都可能产生新的调用。看到界面卡住时，不应连续多次点击发送。

排查时记录请求时间、会话、模型、重试次数和最终状态，并与 Usage 页面时间段对应。没有这些证据，无法仅凭余额变化断定是重复扣费。

如何定位一次异常消耗

1. 暂停当前长任务和自动充值，避免继续扩大消耗。
2. 在 Settings > Usage 查看余额变化、时间和使用入口。
3. 确认当时使用 Claude、Claude Code、Cowork 还是 API。
4. 检查对话长度、项目文件、Research、连接器和工具调用。
5. API 用户保存 response usage，区分输入、输出、缓存写入和缓存读取。
6. 检查是否存在超时、自动重试、并行代理或后台任务。
7. 证据仍无法解释时，将时间、记录和会话信息提交官方支持。

如何降低后续消耗

为新主题创建新对话，定期压缩长任务状态，移除不再需要的文件和工具。普通任务优先使用更低成本模型，只在较低模型达不到验收标准时升级到 Fable。

降低不必要的 effort，要求简洁输出，为代理设置任务预算、最大步骤数和停止条件。长任务分阶段验收，发现方向错误时立即暂停，不让错误路径继续累积 token。

免费额度和付费余额要分别理解

Max 和高级席位的 Fable 用量来自每周计划额度中的最多 50%，并不是固定金额的免费浅包。Pro 和标准席位则从第一次 Fable 使用起消耗 usage credits。

一次性赠送 credit、预付余额和计划内额度的显示方式可能不同。排查前先确认余额来源，不要把“额度很快用完”自动解释为同一种计费机制。

FAQ

只问一句状态为什么可能花很多？

这句提示可能携带很长的历史和文件，并让代理继续执行多轮工具任务。费用来自完整运行，而不是单独几个字。

可见回答很短是否能证明扣费异常？

不能。不可见思考、输入上下文、工具结果和重试都可能产生用量，需要查看 Usage 或 API usage 数据。

删除旧消息就一定能省额度吗？

减少无关上下文通常有帮助，但应保留完成任务必需的状态。更稳妥的方法是把关键进度压缩成短摘要，再从新对话继续。

总结

Fable 5 额度消耗速度由完整上下文和整个任务过程决定，而不是由最后一句提示词长度决定。长会话、文件、工具、Research、思考 token、缓存失效和重试都可能放大用量。先用 Usage 或响应数据定位，再通过新对话、工具精简、较低 effort、任务预算和模型分流控制成本。