Claude Code 更新梳理：模型切换与用量优化

Claude Code 这轮更新的重点，是让长任务更容易跑完：大任务有新模型，云端环境能辅助配置，额度和磁盘也有了更直接的清理入口。对日常使用 AI 编程的开发者，减少等待、重复配置和上下文开销，可能比换模型更有感。

原文汇总的是 2026 年 11 月 10 日的更新，涉及十五项以上变化。下面的产品能力、速度和试用期限均按原文转述；其中有团队测试数据，也有作者自行构造的使用示例，两者需要分开看。

大任务换 Fable，日常修代码仍从 Opus 开始

按原文说法，Fable 5.2 的输出生成速度比 Fable 5.1 最多快 30%，但 Claude Code 团队仍建议多数日常编程任务从 Opus 5.5 开始。修登录页 bug 属于后者，规划并实现整套离线同步系统，才是 Fable 更适合的开放任务。

输出生成更快，不等于整个任务完成得更快。

原文没有给出代码质量、成功率或端到端耗时的对照数据。「最多快 30%」不能直接理解为项目交付提速三成。

切换模型使用下面的命令，要求 Claude Code v2.1.321 或更高版本：

/model claude-fable-5-2

注意这里指定的是 claude-fable-5-2；安装版本也要满足要求。

Pro 和 Team Standard 用户在 11 月 16 日前，可用最多 50% 的每周额度体验 Fable；之后，若开启 usage credits，Fable 会消耗这些额度。原文还提到，11 月 9 日上午 10:00 PT 前已付费的订阅者，可能获得一次 Fable 额度重置，可在网页或桌面端的 Settings > Usage 查看。不过，各套餐的领取截止时间并未列出。

遇到难题，还有一个比切换整场会话设置更轻的入口：在消息里写入 ultrathink，仅当前这一轮使用 xhigh effort，之后恢复会话原有设置。它适合卡住的并发迁移、死锁等问题，团队也明确说，多数任务用不上。

额度消耗和磁盘占用，终于能顺手处理了

终端里的 /usage 以前主要负责展示额度去向，现在按 f，Claude Code 会自行发送提示，尝试修复它能处理的问题。作者举的是超长对话消耗额度的例子，但没有说明具体修复动作，也没有给出节省比例，不能理解为按一下就能解决所有超额问题。

另一项变化是空闲对话自动压缩。长对话闲置约一小时、缓存即将过期时，Claude Code 会把历史内容整理成摘要。否则，缓存失效后继续聊天，可能需要重新处理完整上下文，再次消耗额度。

压缩发生时会出现横幅，也能在 /config 关闭。VS Code 和桌面端 Code 标签页中，超过 200K tokens 的对话同样适用。摘要能保留主要进度，但原文没有评估它会遗漏多少细节；复杂任务仍应把验收条件写进可持久保存的文档。

长对话还有两处优化：多数用户的请求现在只发送新增消息；切换到容量更小的模型前，由当前模型先做摘要。前者减少重复传输，后者让切换更顺畅，都不代表历史上下文可以无限增长。

磁盘方面，桌面端的 /storage 或 Settings 可以查看会话与 worktree 的占用，清理长期不用的工作副本和不活跃任务。worktree 就是同一仓库的一份独立工作目录，适合隔离并行改动，也容易越积越多。清理后，会话、聊天记录和分支会保留。

删除 worktree 前先提交代码，未提交的改动会一起删除。

原文还提到，Anthropic 在 Pro 和 Max 上的测试中，使用后台子代理的会话额度消耗约减少 5%。这是团队测试结果，但缺少样本规模和任务构成，不能据此推算自己的账单。

云端更省配置，自动执行仍要看权限边界

云端会话让 Claude 在 Anthropic 的服务器上工作，任务可以在后台继续。过去依赖、网络访问和 API key 都要用户准备，现在 Pro、Max、Ultra 用户可以让 Claude 辅助配置：缺什么就指出来，再展示待批准的修改。

作者用 React Native 测试缺依赖和 Firebase API key 举例。这是说明场景，并非作者完成了一次实测。按原文，密钥通过表单提交，Claude 看不到密钥本身；配置会保存供后续会话复用。

云端同时增加了 No repository 选项，初始化脚本失败也不再阻止会话启动；创建或编辑云端 routine 时，模型选择器可以设置 effort。能启动只解决入口问题，依赖脚本失败后的任务是否能跑通，还得继续检查。

自动执行的变化则集中在信任范围。Auto mode 默认只信任当前工作目录和仓库自身的 remotes。前端、后端分仓时，即使都属于自己，跨仓推送也可能被拦住。运行 /auto-mode-setup，工具会根据项目和近期命令，拟出可信仓库、域名及云存储清单，接受后写入 ~/.claude/settings.json。

另一个设置 permissions.blockWritesOutsideWorkingDirectories，会在各权限模式下限制 Write、Edit、NotebookEdit 向工作目录之外写入，部分 Claude Code 自身文件除外。它不限制 shell 命令、MCP 工具和 hooks，所以不能当作完整沙箱。

桌面端和 VS Code 默认启用 fork subagents，子代理继承完整对话；桌面本地会话的排队消息也能在重启后恢复。IDE 扩展则不再自动安装，需要从编辑器扩展页处理，或在外部终端运行 /ide。这些改动分别减少重新交代任务、丢失队列和安装路径不清的问题。

我的判断

我更看好这次对任务连续性的改进。自动配置环境、压缩空闲对话、保留排队消息，针对的都是日常协作里具体的中断点。但原文既没有新旧版本完成同类任务的对照，也没有模型质量评测，模型分工建议仍应视为团队经验。

两条来自 Anthropic 工程师的提示，也值得分开使用。第一条是提前授权模型自行决定可逆事项，稍后汇报决定；分享者称，它解开了一个大型代理团队频繁等待确认的问题。这属于经验反馈，不是普遍有效的实验结论，而且提示授权不能替代工具权限。

第二条更容易验证设计：在独立 worktree 里，试做一个将来可能新增的功能，用实现暴露阻力。

In a separate worktree, do a throwaway build of [a feature we might add later] on top of this design. Don't polish it, just tell me where the design got in the way.

注意 Don't polish it：目标是找出设计哪里碍事，避免把一次架构探路做成正式交付。与反复讨论「是否足够灵活」相比，它能留下可检查的代码证据；代价是仍要审查试做过程，不能把模型碰到的困难全部归咎于设计。

团队还分享了让 Claude 在人工介入前审查多数改动的做法。不过，原文没提供漏报、误报或缺陷减少的数据，适合当作流程参考，不能直接证明审查效果。

能拿来做什么

• 先运行 /usage 查看实际消耗，再尝试按 f 处理；长任务把目标、约束和验收条件留在项目文档中，方便压缩后核对。
• 修页面或处理普通 bug 时继续从 Opus 5.5 开始；需要规划离线同步等开放任务时，再按原文的版本和额度条件试用 Fable 5.2。
• 前后端分仓时，用 /auto-mode-setup 检查拟信任的目标；清理 /storage 前，逐个确认 worktree 中的改动已经提交。
• 评审数据层设计时，在独立 worktree 试做离线模式，只记录接口、状态管理和数据同步受阻的位置，再据此决定是否调整设计。