01为什么今天要谈这个

01Why this matters today

2026 年 9 月 1 日,Anthropic 发布 Claude Fable 5.1 与 Mythos 5.1。发布页最值得注意的不是某个基准分数,而是图表的画法:四张性能图全部是「成绩(%)对成本(美元,对数轴)」,每条曲线上标着 low / med / high / xhigh / max 五个点。换句话说,官方不再把模型当成一个固定能力的黑盒来宣传,而是把它当成一条你可以在上面选点的曲线。

On 1 September 2026, Anthropic released Claude Fable 5.1 and Mythos 5.1. The most telling thing on the announcement page is not any single benchmark number — it is how the charts are drawn: all four performance charts plot score (%) against cost (USD, log scale), with five labelled points on each curve: low, med, high, xhigh, max. In other words, the model is no longer marketed as a black box with one fixed capability level. It is marketed as a curve you choose a point on.

同一天还有两件事把这个选择变得更值钱:一是 Fable 5.1 把缓存读取(cache read)单价降了 75%,到 $0.25 / 百万 token,官方称典型负载总成本降约 25%、高度 agentic 负载最多降约 45%;二是 Claude Code v2.1.257 给 /effort 加了「按 s 只改本会话」。前者改变了长会话的成本构成,后者让「按任务选档位」从一句口号变成一个键。

Two things the same day made that choice more valuable. First, Fable 5.1 cut cache-read pricing by 75%, to $0.25 per million tokens; Anthropic reports roughly 25% lower total cost on typical workloads and up to about 45% on highly agentic ones. Second, Claude Code v2.1.257 added a session-only option to /effort (press s). The first changes the cost structure of long sessions; the second turns "pick a level per task" from a slogan into a single keystroke.

02是什么:两个旋钮的分工

02What they are: two knobs, two jobs

effort:一个行为信号,不是 token 上限

effort: a behavioural signal, not a token cap

官方文档对 effort 的定义是「控制 Claude 回应请求时愿意花多少 token」,取值 low / medium / high / xhigh / max,默认 high(显式传 high 与完全不传行为完全一致)。它有两个关键设计:

The docs define effort as controlling "how many tokens Claude spends when responding to requests", with values low / medium / high / xhigh / max and a default of high (passing high explicitly is exactly identical to omitting the parameter). Two design choices matter:

• 不需要开启 thinking 就生效。它不是 thinking 的一个别名——即使 thinking 关闭,effort 依然作用于输出。
• 作用于全部输出 token:文本与解释、工具调用与其参数、以及 thinking(当 thinking 活跃时)。这意味着低档位不只是「少想」,还会合并并减少工具调用。

• It works without thinking enabled. It is not an alias for thinking — with thinking off, effort still shapes the output.
• It affects all output tokens: text and explanations, tool calls and their arguments, and thinking (when active). So a lower level does not merely mean "think less" — it also means fewer, more consolidated tool calls.

文档明确提醒:effort 是行为信号,不是严格的 token 预算。在低档位下,遇到足够难的问题 Claude 仍然会思考,只是比高档位下想得少。

The docs are explicit that effort is a behavioural signal, not a strict token budget. At lower levels Claude will still think on sufficiently hard problems — just less than it would at a higher level on the same problem.

task_budget:一个模型看得见的倒计时

task_budget: a countdown the model can see

Task Budgets 目前是 beta(需要 beta header task-budgets-2026-03-13),做法是告诉 Claude 整个 agentic loop 有多少 token 可用——包含 thinking、工具调用、工具结果和输出。服务端在对话中注入一个倒计时标记,模型据此排优先级并优雅收尾。

Task budgets are currently in beta (beta header task-budgets-2026-03-13). You tell Claude how many tokens the full agentic loop has — including thinking, tool calls, tool results, and output. The server injects a countdown marker into the conversation, and the model uses it to prioritise work and finish gracefully.

03Effort 五档详解与选型

03The five effort levels, and how to pick

注意 xhigh 是较新的档位:有些支持 max 的模型并不支持 xhigh。按官方兼容表,xhigh 可用于 Fable 5、Mythos 5、Opus 5、Opus 4.8、Opus 4.7 与 Sonnet 5;max 的支持面更宽,还包括 Opus 4.6、Sonnet 4.6 与 Mythos Preview。

Note that xhigh is a newer level: some models that support max do not support xhigh. Per the compatibility table, xhigh is available on Fable 5, Mythos 5, Opus 5, Opus 4.8, Opus 4.7, and Sonnet 5; max has wider coverage, additionally including Opus 4.6, Sonnet 4.6, and Mythos Preview.

同一个参数,不同模型的建议起点不一样

Same parameter, different recommended starting points per model

这是最容易被忽略的一点:官方针对不同模型给出的建议起点并不相同,把上一代的 effort 设置直接搬到新模型上是错的。文档明确写着「如果你从更早的模型沿用了 effort 设置,请在你的评测集上重新做一次 effort 扫描,而不是直接复用」。

This is the most commonly missed point: the recommended starting level differs by model, and carrying settings over from a previous generation is a mistake. The docs say plainly: if you carried effort settings over from an earlier model, run a fresh effort sweep on your evals rather than reusing them.

低档位在工具使用上的具体行为差异

How lower effort concretely changes tool use

这一点在做 Agent 时比「思考深度」更有实感。官方列出的差异是:

When building agents this matters more concretely than "thinking depth". The documented differences:

# Python:请求级设置(注意在 output_config 里,不是顶层参数)
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=65536,                    # xhigh/max 时从 64k 起步
    messages=[{"role": "user", "content": "分析微服务与单体架构的取舍"}],
    output_config={"effort": "medium"},  # low / medium / high / xhigh / max
)

# Python: a request-level setting (note it lives inside output_config, not at top level)
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=65536,                    # start at 64k for xhigh/max
    messages=[{"role": "user", "content": "Analyze the trade-offs between microservices and monoliths"}],
    output_config={"effort": "medium"},  # low / medium / high / xhigh / max
)

04Task Budgets:倒计时怎么算

04Task budgets: how the countdown counts

Task Budgets 最反直觉、也最容易用错的一点是:倒计时算的是「Claude 这一轮看到的新内容」,不是你请求体的大小。在 agentic loop 里,你的客户端每轮都会重发整段对话历史,payload 逐轮膨胀;但预算只按这一轮 Claude 新看到的 token 扣减。

The most counter-intuitive — and most misused — property of task budgets is this: the countdown counts what Claude sees this turn, not the size of your request payload. In an agentic loop your client resends the full conversation every turn, so the payload grows turn over turn; the budget only decrements by the tokens Claude newly sees.

三个必须知道的约束

Three constraints you must know

1. 软提示,不是硬上限。Claude 可能会超出预算——当它正处在「中断比完成更具破坏性」的动作中间时。唯一被强制的输出上限仍然是 max_tokens,达到时以 stop_reason: "max_tokens" 截断。两者相互独立:task_budget 跨整个循环(可能很多次请求),max_tokens 管单次请求,所以并不要求前者小于等于后者。
2. 预算太小会引发「拒绝式行为」。当 Claude 看到的预算明显不够完成任务(文档举的例子:给一个数小时的 agentic 编码任务只给 20,000 token),它可能干脆不接这个任务、激进地缩小范围,或者早早停在一个半成品上。如果你在设了预算之后看到莫名的拒绝或提前停止,先把预算调大,再去 debug 其他参数。最小可接受值目前在所有支持模型上都是 20,000 token,低于此返回 400。
3. 响应里读不到剩余预算。usage 对象里没有 task_budget 信息,SDK 也没有对应访问器。要在客户端追踪花费,只能自己把循环里每次请求的 token 用量加起来。

1. Advisory, not enforced. Claude may exceed the budget when it is mid-action and interrupting would be more disruptive than finishing. The only enforced ceiling is still max_tokens, which truncates with stop_reason: "max_tokens". The two are independent: task_budget spans a whole loop (potentially many requests) while max_tokens caps each individual request, so one need not be at or below the other.
2. A budget that is too small causes refusal-like behaviour. When Claude sees a budget clearly insufficient for the work — the docs' example is a 20,000-token budget for a multi-hour agentic coding task — it may decline the task outright, scope it down aggressively, or stop early with a partial result. If you see unexpected refusals or premature stops after setting a budget, raise the budget before debugging anything else. The minimum accepted value is currently 20,000 tokens on every supported model; below that you get a 400.
3. You cannot read the remaining budget from the response. There is no task_budget information in the usage object and no SDK accessor for it. To track spend client-side, sum token usage across the requests in your loop yourself.

# 设置一个任务预算(注意 beta header)
with client.beta.messages.stream(
    model="claude-fable-5-1",
    max_tokens=128000,                 # 硬上限:单次请求
    output_config={
        "effort": "high",              # 深度
        "task_budget": {"type": "tokens", "total": 64000},   # 广度
    },
    messages=[{"role": "user", "content": "通读代码库并提出重构方案"}],
    betas=["task-budgets-2026-03-13"],
) as stream:
    response = stream.get_final_message()

# 跨压缩(compaction)续算:服务端不记得压缩前花了多少,自己传 remaining
tokens_spent_so_far = 45000
output_config = {
    "effort": "high",
    "task_budget": {
        "type": "tokens",
        "total": 128000,
        "remaining": 128000 - tokens_spent_so_far,
    },
}
# ⚠️ 若你每轮都重发完整未压缩历史,就【省略】remaining,让服务端自己算

# Setting a task budget (note the beta header)
with client.beta.messages.stream(
    model="claude-fable-5-1",
    max_tokens=128000,                 # hard cap: per request
    output_config={
        "effort": "high",              # depth
        "task_budget": {"type": "tokens", "total": 64000},   # breadth
    },
    messages=[{"role": "user", "content": "Review the codebase and propose a refactor plan."}],
    betas=["task-budgets-2026-03-13"],
) as stream:
    response = stream.get_final_message()

# Carrying a budget across compaction: the server has no memory of pre-compaction spend
tokens_spent_so_far = 45000
output_config = {
    "effort": "high",
    "task_budget": {
        "type": "tokens",
        "total": 128000,
        "remaining": 128000 - tokens_spent_so_far,
    },
}
# ⚠️ If your loop resends full uncompacted history every turn, OMIT remaining and let the server track it

怎么定这个数

How to choose the number

官方给的方法不是拍脑袋,而是先测量:在不设 task_budget 的情况下跑一批有代表性的任务,记录每个任务的总 token 花费(把循环里每次请求的 usage.output_tokens 加起来,再加上你在请求之间追加的工具结果 token),得到一个分布,从 p99 起步,然后上下调。关键是按你实际的任务长度分布来定,而不是套一个固定默认值。

The documented method is measurement, not guesswork: run a representative sample of tasks without task_budget set and record total tokens per task (sum usage.output_tokens across every request in the loop, plus the tool-result tokens you append between requests). From that distribution, start at the p99 and tune up or down. Size budgets against your actual task-length distribution rather than a fixed default.

05成本结构:缓存降价改变了什么

05Cost structure: what the cache price cut changed

Fable 5.1 的定价变动只有一项:缓存读取(cache read)从 $1 降到 $0.25 每百万 token,降幅 75%。输入 $10 / 输出 $50 每百万 token 保持不变。但 Anthropic 给出的实测口径是:典型负载总成本降约 25%,高度 agentic 负载降约 45%(基于 2026 年 8 月四周的真实使用数据,默认 effort)。

Fable 5.1 changed exactly one price: cache reads dropped from $1 to $0.25 per million tokens, a 75% cut. Input at $10 and output at $50 per million tokens are unchanged. Anthropic's measured figures: roughly 25% lower total cost on typical workloads and about 45% on highly agentic ones, based on four weeks of actual August 2026 usage at default effort.

为什么单改一项能拉动这么多总成本?因为在上下文重、工具重的 agentic 负载里,缓存读取就是账单的大头。官方的成本构成图(以 Fable 5 = 100 为指数)是这么分的:

Why does changing one line item move total cost so much? Because in context-heavy, tool-heavy agentic workloads, cache reads are most of the bill. Anthropic's indexed cost chart (Fable 5 = 100) breaks down as:

Task Budgets 有一个额外的缓存陷阱:倒计时标记是服务端按轮注入的,本身不跨请求匹配缓存。如果你的客户端每轮都自己递减 task_budget.remaining,那个变化的值会让包含它的缓存前缀失效。官方建议:在首次请求上设一次预算,之后让模型对着服务端倒计时自律,不要在客户端不断修改它。

Task budgets add one more caching trap: the countdown marker is injected server-side per turn and does not itself match across requests. If your client decrements task_budget.remaining every turn, that changing value invalidates any cache prefix containing it. The recommendation: set the budget once on the initial request and let the model self-regulate against the server-side countdown rather than mutating it client-side.

06怎么用:分层分配策略

06How to use it: a tiered allocation strategy

把上面的规则拼起来,可以得到一个实际可执行的决策流程。核心思想不是「找到一个最优档位」,而是把不同类型的工作负载分开,各自定档,并在负载内部保持稳定。

Putting the rules together yields a workable decision procedure. The core idea is not to find one optimal level, but to separate workload types, fix a level per type, and hold it constant within each.

在 Claude Code 里落地

Putting it into practice in Claude Code

Claude Code 侧不支持 task_budget,但 effort 是完整可用的,而且 v2.1.257 之后可以按会话覆盖。Fable 5.1 在 Claude Code 里默认 high(在 Cowork 与 claude.ai 上默认 medium)。

Claude Code does not support task budgets, but effort is fully available, and since v2.1.257 it can be overridden per session. Fable 5.1 defaults to high effort in Claude Code (and to medium in Cowork and on claude.ai).

# 会话内:打开选择器,选好档位后按 s → 只对当前会话生效
/effort

# 启动时指定,只影响这一次会话
claude --effort low -p "把 README 的安装步骤同步成最新的 pnpm 命令"

# 常备别名:把「杂活会话」和「硬骨头会话」分开
alias ccq='claude --model claude-fable-5-1 --effort low'
alias ccd='claude --model claude-fable-5-1 --effort xhigh'

# 顺带把 subagent 一律压到低档模型(v2.1.257 新增 FORCE)
CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5-20251001 \
CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 claude

# In session: open the picker, then press s to apply to this session only
/effort

# At launch, for this session only
claude --effort low -p "Update the README install steps to the current pnpm commands"

# Standing aliases: separate the "chores" session from the "hard problem" session
alias ccq='claude --model claude-fable-5-1 --effort low'
alias ccd='claude --model claude-fable-5-1 --effort xhigh'

# And force every subagent onto a cheaper model (FORCE added in v2.1.257)
CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5-20251001 \
CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 claude

07常见坑清单

07Pitfalls checklist

08学术背景:自适应推理算力分配

08Research context: adaptive test-time compute

厂商暴露 effort 这个旋钮,背后是一条已经比较成熟的研究线:自适应 test-time compute 分配。它的出发点是一个经验观察——投入算力与准确率增益之间是凹函数关系(边际收益递减)。既然如此,与其对所有请求均匀投入,不如把算力挪到边际收益最高的地方。

The reason vendors expose an effort knob at all traces back to a fairly mature research line: adaptive test-time compute allocation. It starts from an empirical observation — the relationship between added compute and marginal accuracy gain is concave (diminishing returns). Given that, spending uniformly across all requests is wasteful; the win comes from reallocating compute to where marginal return is highest.

目前的主流做法大致分三类:

Current approaches fall broadly into three families:

代表性工作如 Adaptive Test-Time Compute Allocation for Reasoning LLMs via Constrained Policy Optimization(arXiv:2604.14853)。另有独立测量指出:在 LLM API 上,选一个运行时长两倍的模型,大致能把错误率降低同一个倍数,且这个关系与初始运行时长无关——这为「用延迟换准确率」提供了一个粗略的定价直觉。⚠️ 后一条来自第三方分析(Epoch AI),不是厂商数据,引用前请回溯原文。

A representative paper is Adaptive Test-Time Compute Allocation for Reasoning LLMs via Constrained Policy Optimization (arXiv:2604.14853). Separately, independent measurement suggests that across LLM APIs, choosing a model with roughly 2× longer runtime cuts error by about the same factor, largely independent of the initial runtime — a rough pricing intuition for trading latency against accuracy. ⚠️ That second finding comes from third-party analysis (Epoch AI), not vendor data; check the original before citing.

对工程实践的启示很直接:推理算力应该被当作一类需要策略性分配的一等资源,而不是均匀花掉。产品侧的 effort + task_budget,本质上就是把这条研究结论做成了两个可以直接调的参数——难度感知路由由你(或你的路由层)来做,自我调速由模型对着倒计时来做。

The engineering takeaway is direct: inference compute should be treated as a first-class resource allocated strategically, not spent uniformly. Product-side, effort plus task_budget is essentially that research conclusion turned into two dials you can set — difficulty-aware routing is yours (or your router's) to do, while self-pacing is the model's, against the countdown.

09术语表

09Glossary

10来源

10Sources

1. Effort — Claude Platform Docs · 档位定义、各模型建议、与 thinking 和缓存的交互、最佳实践(本文第 2、3、5 节的主要依据)
2. Task budgets — Claude Platform Docs · 倒计时机制、三轮 worked example、最小值 20,000、支持矩阵(第 4 节)
3. Introducing Claude Fable 5.1 and Claude Mythos 5.1 — Anthropic, 2026-09-01 · 缓存读取降价 75%、指数化成本图、各 effort 档位的成绩-成本曲线、基准表
4. Claude Code changelog · v2.1.257 的 /effort 会话级覆盖、--effort 语义变更、Fable 5.1 默认模型、gateway 别名说明
5. Extended thinking — Claude Platform Docs · thinking 与 effort 的分工、adaptive 模式
6. Prompt caching — Claude Platform Docs · 缓存前缀失效机制
7. Adaptive Test-Time Compute Allocation for Reasoning LLMs via Constrained Policy Optimization · arXiv:2604.14853(第 8 节)
8. LLM providers offer a trade-off between accuracy and speed — Epoch AI · ⚠️ 第三方分析,非厂商数据
9. Stanford CS329A: Self-Improving AI Agents · test-time compute scaling 的课程背景

1. Effort — Claude Platform Docs · Level definitions, per-model guidance, interaction with thinking and caching, best practices (primary basis for sections 2, 3, and 5)
2. Task budgets — Claude Platform Docs · Countdown mechanics, the three-turn worked example, the 20,000 minimum, support matrix (section 4)
3. Introducing Claude Fable 5.1 and Claude Mythos 5.1 — Anthropic, 2026-09-01 · The 75% cache-read price cut, indexed cost chart, score-vs-cost curves per effort level, benchmark table
4. Claude Code changelog · v2.1.257 session-only /effort, the --effort semantics change, Fable 5.1 as default model, gateway alias note
5. Extended thinking — Claude Platform Docs · How thinking and effort divide the work; adaptive mode
6. Prompt caching — Claude Platform Docs · How cache prefixes are invalidated
7. Adaptive Test-Time Compute Allocation for Reasoning LLMs via Constrained Policy Optimization · arXiv:2604.14853 (section 8)
8. LLM providers offer a trade-off between accuracy and speed — Epoch AI · ⚠️ Third-party analysis, not vendor data
9. Stanford CS329A: Self-Improving AI Agents · Course background on test-time compute scaling