Claude Fable 5.1 发布后，进步确实不小。有测试显示，哪怕只开 medium 级别，它的表现也比 opus 5 的高级别更稳。
问题主要出在 opus 5 实在有点拉胯。平时我很少用 Fable，除非遇到 opus 解决不了的问题，或者订阅额度快到期了还剩下不少，这时才会开 Fable 冲一把。
今天就遇到了这种情况：opus 5 跟我绕了半天也没解决，于是切到 Fable 5.1。结果没多长时间，5 小时额度就见底了。
官方说法是 Fable 5.1 能力增强了，缓存价格下降，而且更省 Token。可即便这样，额度还是烧得太快。
不过网友的智慧是无穷的。这里汇总了一些更省 Token、更高效使用 Fable 5.1 的配置方式。
关闭 1M 超长上下文
Fable 5.1 默认开启 1M 上下文。窗口越大，每轮对话重读的历史内容就越多，Token 消耗自然越大。
通过修改全局配置关闭 1M 上下文，可以明显减缓 Token 消耗。编辑 ~/.claude/settings.json，加入如下配置：
{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}
同时配合自动压缩（Auto Compact）策略。关闭 1M 上下文后，窗口到达上限的时间会缩短，自动压缩的作用就更加关键。
保持自动压缩开启：默认就是开启状态，可通过 /status 命令确认。
如果未开启，可以执行 /autocompact auto 打开。
推荐阈值：执行 /autocompact 200k，让系统在 200k 附近自动压缩。如果觉得这个值偏小，也可以适当调整到 300k 或 500k。
推理级别使用
建议默认从 Low / Medium 起步。
Low Effort 在 CursorBench 等基准测试中，已经接近 Fable 5 的 High 水平，成本只有约 1/3。
Medium Effort 基本可以解决绝大多数复杂工程任务。
实在不行再开 xHigh，但 Max 要慎用。思考 Token 输出大约会变成 1.7 倍，额度很快就会被掏空。
Fable 只动脑，不动手
Fable 的核心价值在于架构判断，而不是编写基础代码。可以采用 10% 规划 + 80% 执行 + 10% 验收 的节奏。
- 方案设计： Fable 5.1 输出技术方案 Markdown 文档，不直接修改代码。
- 人工确认： 确认方案可行性与边界。
- 及时压缩： 方案确认后立即执行
/compact，利用尚未过期的 Cache 降低后续开销。
- 任务分发： 将文档交由 Codex（如 GPT-5.6 Sol，effort 设为 xhigh）或 Opus/Sonnet 子代理执行；复杂任务配合
/goal 指令。
- 对齐验收： 将执行结果交回 Fable 5.1 审查是否遗漏或偏离；如有问题，反馈到同一执行会话修复。
可以用下面这段提示词来驱动 Fable 5.1：
注意你的主要任务是分析、编排和验证，具体任务尽可能交给 subagent（Opus 或 Sonnet）去执行。自己只做需求澄清、方案拆解、任务分发和结果验收，实现类工作（读大量代码、写代码、跑测试、批量修改）一律用 Agent 工具派给 subagent 执行。
实际上，这个模式不止适用于 Fable 5.1，任何最强档位的大模型都适用。让大哥去思考，让小弟去干活儿。
听说不止是 Claude 不够用，国内的订阅套餐也经常不够用。你的 Token 够用吗？
发表于 4 天前
|
查看: 7|
回复: 0
