2026 年 8 月 22 日，开发者圈炸了锅——有人抓包发现，Claude Code 把“high”推理档偷偷映射成了 10 分，而 10 分原本是“low”的数值。付着高档的钱，拿到的却是低档的货？但 Anthropic 的员工却说：那个数字没意义，你选的 effort 就是你得到的。两边各说各话，谁在撒谎？
“high=10”是怎么被发现的
一个开发者花了整个下午排查自己的 T3 代码，以为是自己哪里写错了。最后他抓了请求的数据包，才发现端倪。
他机器发出的请求里只有“high”这个单词，没有任何数字。但模型每次都回答同一个数：10。既然请求里没带数字，模型怎么知道该用 10？唯一的解释是服务器那边做了手脚。
自 Claude Code 版本 2.1.237 起，部分 Fable 5 会话被划入了一个服务端实验。旧版本不受影响，Opus 5 也不受影响。这看起来像 A/B 测试——只有一部分用户会被命中。更让人恼火的是：更新日志里一个字都没提。
Effort 这个旋钮到底是干什么的
Fable 5 有个叫 effort 的参数，控制模型在回答问题之前愿意花多少心思去“想”。它有五个档位：low、medium、high、xhigh、max。官方文档说得很直白：effort 是控制智能、延迟和成本之间权衡的主要旋钮。
高 effort 意味着更多工具调用、更完整的规划、更长的输出。低 effort 意味着更少的步骤、更快的响应。调高 effort 就是让模型多算一会儿、多想几步，代价是花掉更多的 token——也就是更多的钱。
Fable 5 的定价是每百万输入 token 10 美元、输出 50 美元。正好是 Opus 4.8 的两倍。订阅用户得买 Max 计划才能用 Fable 5。你拧得越高，账单越厚。
但用户自己看不见这个旋钮到底拧到了哪个刻度。你只能在界面上选“high”或者“xhigh”，至于服务器那头对应的是 10 还是 80，全凭 Anthropic 说了算。
官方回应：数字没意义，你选的 effort 就是你得到的
Anthropic 的员工 Thariq 出来回应了。他说他们确实在测试不同的 API 服务配置，数值映射的方式不同。这就是为什么有些用户看到 high 对应的是 10。
但他强调了两点：第一，那个 scale 不是 0 到 100，数字本身没有意义；第二，你选的 effort 就是你得到的 effort。换句话说，high 还是 high，只是背后对应的那个数字变了。
他还说，经过内部深度评估，确认不影响模型性能。数字变了，但实际行为没变。
这就产生了一个奇怪的局面：官方说“没变”，用户说“明显变笨了”。两边说的完全是两码事。
用户感受：这不是数字游戏，是真的变笨了
用户的反馈和官方说法对不上号。
有人反映 Fable 在最高档位下的分析变得“浅显”，过去两周在所有档位下都很浅，哪怕开到 max 也一样。还有人注意到 usage limits 变宽松了——推理强度降低之后，token 消耗自然变少，每周限额就显得更耐用了。
更直观的是响应速度。有用户说 Fable high 档几乎是“秒回”，完全看不到推理过程。零推理、秒响应——这不就是低档的特征吗？
开发者 @argofowl 在后续更新里说，他抓包看到 high 档返回的 thinking token 数量，和 low 档一模一样。换句话说，Anthropic 自己的数据系统承认了 high 和 low 的推理量相同。
官方说“数字没意义不影响性能”，用户说“模型真的变笨了”。谁在说真话？
问题来了：effort 到底是怎么传给模型的
@goon_nguyen 在讨论里提出了一个关键质疑：从“请求里没有数字”推导出“服务器在恶意降级”，逻辑链条是断的。
多位开发者指出：reasoning effort 是通过系统提示词传递给模型的。它不是请求参数，就是一行写在系统提示里的文字。你在界面上点“high”，客户端就往系统提示里写一行“use high reasoning effort”，然后整个提示词一起发给模型。
这意味着模型不需要从请求参数里读数字。它只需要读自己收到的系统提示，就能知道该用什么档位。模型回答里那个“10”，完全可以是模型在复述系统提示里的一行文字。
@argofowl 抓了请求的包，但没有检查系统提示里到底写了什么。
还有一个细节：切换 effort 档位会导致缓存 miss。如果 effort 是像 @argofowl 想象的那样“在服务器端作为参数注入”，切换 effort 档位不应该影响缓存命中——因为系统提示没变，缓存 key 就不变。但实际情况是：切换 effort 确实会导致缓存失效。这反过来印证了 effort 是通过系统提示传递的——提示词变了，缓存就失效了。
历史重演：这不是 Anthropic 第一次“静默”动手脚
2026 年 6 月，Fable 5 刚发布没几天，Anthropic 就被曝出在系统卡里藏了一个“静默降级”机制。当用户请求涉及前沿 AI 开发、芯片设计等敏感领域时，模型会悄悄把请求扔给更弱的 Opus 4.8，全程不通知用户。
社区炸了。开发者怒斥这破坏了可复现性、测试和信任。Anthropic 在 24 小时内道歉并撤回了这个机制。当时的声明说得很诚恳：“我们做出了错误的取舍，对于未能把握好平衡，我们深表歉意。”
两个月后，又来了一次。这次不是敏感领域降级，而是把整个 effort 刻度偷偷挪了位。方式更隐蔽——服务端 A/B 测试，只影响部分用户，更新日志里只字不提。
道歉一次是事故。道歉两次，是套路。
信任这个东西，碎一次就拼不回来了
一个开发者说得好：“静默的参数变更没有更新日志——这正是我为什么在本地跑开源权重模型。没有人能悄悄 nerf 你的 effort 设置。”
这不是小题大做。AI 模型不是一次性消费品，开发者是在上面搭建工作流的。一个 effort 参数的变化，可能意味着代码审查结果不同、自动化脚本的输出不同、整个产品的行为不同。
更关键的是调试成本。开发者花了一整个下午排查自己的代码，最后才发现是服务端的问题。另一个开发者说：“最糟糕的部分是你先怪自己的代码，因为更新日志里根本没东西可以 grep。”
Anthropic 的员工说“数值无意义且不影响性能”。但如果真的不影响性能，为什么要改？如果真的有影响，为什么不告诉用户？
一个让事情更复杂的细节
@argofowl 还发现了一个诡异的现象：当他在会话里问模型“你现在用的 effort 是多少”，模型会给出一个数值。他抓包确认了自己发出的请求里根本没有这个数字——只有“high”这个标签。
所以模型是怎么知道那个数字的？唯一的可能是服务器在响应里塞了 effort 的数值信息，模型读到了然后复述出来。这就意味着：模型自己知道自己在用什么档位运行，但它不会主动告诉你。你得问，它才说。
更诡异的是，如果你不问，它永远不会提这事。
还有，@argofowl 在后续更新里确认：high 档返回的 thinking token 数量，和 low 档一模一样。这个数字来自 API 自己的 usage 统计——也就是说，Anthropic 自己的数据系统承认了 high 和 low 的推理量相同。
但 Anthropic 的官方回应依然坚持“不影响性能”。
一个公司的数据系统和官方声明在打架。你信哪个？