Model and effort in Claude Code knowing more vs. trying harder Claude Code 中的模型与工作量：知识深度与努力程度的权衡

Claude Code gives you two settings that both seem to “make the answer better”: the model, and the effort level. But what do these actually do to the output? And how do you know whether to reach for a different model or just change the effort level? It’s easy to assume that choosing a larger model like Fable gives you a smarter output than Sonnet, and that a higher effort level just means Claude thinks longer before it answers. Claude Code 提供了两种似乎都能”让答案更好”的设置：模型和努力程度。但它们实际上对输出结果有什么影响？你该如何判断是应该换个模型还是仅仅调整努力程度？ 人们很容易认为，选择像 Fable 这样更大的模型会比 Sonnet 产生更智能的输出，而更高的努力程度只是意味着 Claude 在回答前思考更长时间。

The first assumption is true. Our largest models are more capable, according to industry-standard benchmarks.第一个假设是正确的。根据行业标准基准测试，我们最大的模型能力更强。

But effort means more than “thinking time.” Effort controls how much work Claude does on your request overall. That includes how long it thinks, but also:但努力程度所代表的含义远不止”思考时间”。努力程度控制着 Claude 对你的请求进行总体工作的投入量。这包括它思考的时间，但也包括：

• how many files it reads; 它读取多少文件；
• how much it verifies; and 验证的程度；以及
• how far it pushes through a multi-step task before checking in with you. 在执行多步骤任务时，在向你确认之前能推进多远。

At higher effort, Claude takes more of those actions (read files, run tests, double-check) before it comes back to you. At lower effort, it would rather ask you for more context than spend tokens figuring something out on its own. 投入更高努力时，Claude 会先采取更多此类操作（如读取文件、运行测试、双重检查），之后再向你汇报。投入较低努力时，它宁愿向你索要更多上下文，也不愿消耗 Tokens 自行推断。

How model selection works 模型选择的工作原理

To understand what the model setting actually controls, it helps to start at the very beginning, from the moment you press enter. 要理解模型设置实际控制什么，不妨从头说起——就从你按下回车键的那一刻开始。

Claude Code assembles your message together with the system prompt, tool definitions, your CLAUDE.md, the conversation history, and any files in context. All of this is sent as one request to the API. Claude Code 将你的消息与系统提示、工具定义、你的 CLAUDE.md 文件、对话历史以及上下文中的任何文件整合在一起。所有这些内容作为一次请求发送到API。

Everything Claude Code has gets packed into one API request. On the server, the text is tokenized before it ever reaches the model. Claude Code 的所有内容都会被打包成一个 API 请求。在服务器端，文本在被送入模型之前就会先进行分词处理。

The model never sees any of that as plain text, though. The first thing that happens on the server is tokenization: the text gets split into pieces, and each piece is mapped to an integer from a fixed vocabulary the model was trained with. `const` might map to 1978, `await` might map to 4293. From here on, your prompt is an array of integers.不过，模型从来不会将这些内容视为纯文本。服务器上发生的第一个步骤是分词：文本被拆分成片段，每个片段映射到模型训练时使用的固定词汇表中的某个整数。比如 `const` 可能映射为 1978，`await` 可能映射为 4293。从这个阶段开始，你的提示语就变成了一个整数数组。

The tokenizer splits your text into pieces and maps each piece to an integer in a fixed vocabulary. Each chunk in the top row becomes its token ID (bottom row); IDs shown are illustrative. 分词器将您的文本拆分成片段，并将每个片段映射至固定词汇表中的整数。顶行的每个分块会转换为对应的词汇 ID（底行所示）；展示的 ID 仅供参考。

The model’s job is to take that array and predict which token comes next. It does this by computing a probability for every token in its vocabulary and picking from the top. After “const x = await”, a well-trained model puts high probability on “fetch” (very likely) and near-zero on “banana” (not likely at all). 模型的任务是接收这个数组，并预测下一个会是哪个词元。它通过计算词汇表中每个词元的概率，然后从最高概率中选取来实现。在 “const x = await” 之后，一个训练有素的模型会对 “fetch” 赋予高概率（非常可能），而对 “banana” 赋予接近零的概率（几乎不可能）。

The model’s prediction is a probability for every token in its vocabulary. The gap between the top guess and an unrelated one is enormous. 模型的预测结果是针对其词汇表中每个词元的概率。最高概率猜测与不相关词元之间的差距是巨大的。

What turns your input tokens into those probabilities is the weights (also called parameters): billions of numbers organized into large matrices. To predict one token, the model runs your input through those matrices (a long chain of matrix multiplications) and reads the probabilities at the end. The weights are where everything the model “knows” lives.将你的输入转化为这些概率的是权重（也称参数）：数十亿个数字排列成大型矩阵。为了预测一个词元，模型会将你的输入通过这些矩阵进行处理（一个长长的矩阵乘法链），并在最后读取概率。模型”知道”的一切都存在于这些权重中。

The weights of each model are set during training, and by the time you’re sending requests they’re read-only. Nothing in your prompt, your CLAUDE.md, or your context changes them. If you’ve run into the word inference, that’s all it means: using the model after training is done, with the weights fixed.每个模型的权重在训练时就被设定，当你发送请求时，它们已是只读状态。你的提示词、CLAUME.md或上下文中的任何内容都不会改变它们。如果你遇到过”推理”这个词，那就是它的全部含义：训练完成后，权重固定不变，直接使用模型。

Your prompt goes in, probabilities come out. The weights in the middle don’t change. 你的提示词进入，概率输出。中间的权重保持不变。

Everything Claude knows about TypeScript, popular frameworks, or any other general programming knowledge was encoded into those weights at training time. Claude 所知道的一切关于 TypeScript、流行框架或其他通用编程知识，都是在训练时被编码进这些权重中的。

Your prompt and context can still steer the prediction. Putting your real code in front of Claude is steering, and it works really well. However, this doesn’t add anything to the weights themselves.你的提示和上下文仍然可以引导预测结果。将实际代码提供给Claude是一种引导方式，而且效果相当不错。不过，这并不会给权重本身增加任何内容。

If a library didn’t exist when the model was trained, it isn’t in the weights. You can put the docs in context and Claude will use them, but that’s steering**, not teaching**. Claude’s response is only influenced for that one request, but the underlying model hasn’t retained anything.如果一个库在模型训练时还不存在，那它就不在权重中。你可以把文档放入上下文，Claude会使用它们，但这是引导，而非教授。Claude的回应仅针对该次请求生效，底层模型并没有保留任何信息。

When Claude confidently calls an API that doesn’t exist (a hallucination), that’s the weights producing a token sequence that looks plausible from training patterns, not a failed lookup.当Claude自信地调用一个不存在的API时（即出现幻觉），这是权重根据训练模式生成了看似合理的token序列，而非查找失败。

So what does changing the model actually do? It swaps which set of frozen weights handles your request.那么，更换模型到底有什么作用？它更换的是处理你请求的那组固定权重。

The model doesn’t generate a whole answer at once. It predicts one token, appends it to the sequence, and runs the whole computation again to get the next one. A 200-token response is 200 separate passes through the weights. This loop is where most of your wait time (and your output cost) comes from. 模型并不是一次性生成整个答案。它每次预测一个令牌，将其追加到序列中，然后重新运行整个计算来获取下一个令牌。一个200令牌的响应意味着200次独立的权重通过过程。这个循环正是你大部分等待时间（以及输出成本）的来源。

The sequence grows by exactly one token per step. The model re-reads the whole array each time to predict what comes next. 序列每一步只增长一个令牌。模型每次都会重新读取整个数组，以预测接下来会出现什么。

The model setting decides which weights handle your request, and it also decides what each output token costs. 模型设置决定了处理你请求时使用哪些权重，也决定了每个输出令牌的成本。

What it doesn’t decide is how many tokens get generated. That number can vary a lot for the same prompt, depending on how much work Claude decides to do.但它并不决定生成多少个令牌。对于相同的提示词，这个数量可能会有很大差异，具体取决于克劳德决定做多少工作。

Which is exactly what effort controls. 这正是努力掌控的内容。

How effort works 努力的工作方式

While Claude Code is working on a task, the tokens it generates fall into a few categories: 当Claude Code在处理任务时，它生成的token可分为几个类别：

• Thinking: the reasoning you see streaming before and between actions.思考：你在操作前后看到的推理过程。
• Tool calls: structured blocks naming a tool like Read or Edit and its arguments, which Claude Code then parses and executes.工具调用：结构化的代码块，命名了诸如 Read 或 Edit 等工具及其参数，Claude Code 随后解析并执行这些调用。
• Text to you: the plan, progress updates, the summary at the end.传递给用户的文本：计划、进度更新、以及最后的总结。

These are all ordinary output tokens from the same loop, billed at the same rate. Thinking tokens, for example, are generated exactly like the other output tokens and stay in context for the rest of that turn. 这些都是在同一循环中生成的普通输出令牌，按相同费率计费。例如，思考令牌的生成方式与其他输出令牌完全相同，并且在该轮次后续过程中会保留在上下文中。

By the time Claude moves on to writing code, its earlier reasoning is part of the input, just like a file it read. 当 Claude 开始编写代码时，它之前的推理已成为输入的一部分，就像它读取过的文件一样。

All of Claude’s output is tokens. Thinking, tool calls, and text to you are all generated from the same loop. 克劳德的所有输出皆为令牌。无论是思考过程、工具调用还是给你的文本回复，都源自同一循环机制。

So how does effort change any of this? The effort level is sent to the model as part of the request, right alongside your prompt. The model was trained to understand how to behave at each effort level, and that learned behavior is baked into the frozen weights.那么”努力程度”如何改变这一点？努力程度作为请求的一部分被发送给模型，与你的提示词并列送达。模型经过训练，能理解在每个努力层级下该如何表现，这种习得行为已固化在冻结的模型权重之中。

When your request arrives, effort is just one more input the model responds to, the same way it responds to your prompt text. It sets how thorough, and how certain, Claude needs to be before it considers the task done. That gets weighed on every turn, and higher confidence takes more tokens to reach.当你的请求抵达时，努力程度不过是模型需要响应的又一个输入项——就像它回应你的提示词文本一样。该参数决定了克劳德在完成任务前需要达到的严谨程度和置信水平。这一标准会在每次交互中被权衡，而达到更高的置信度需要消耗更多令牌。

Same prompt, two effort levels. The high effort path generates roughly 7x more tokens to reach a higher confidence answer. 同一提示词，两种努力程度。高努力路径需要生成约7倍的令牌数量，才能得出置信度更高的答案。

At higher effort levels, Claude often starts by creating a plan, and the effort level influences the depth and breadth of that plan. But the plan isn’t frozen in place. As Claude gets results back from its actions, it updates its picture of how much progress it’s made and how certain it is of the accumulated result. 在较高的努力级别下，Claude 通常从制定计划开始，而努力级别会影响计划的深度和广度。但计划并非一成不变。当 Claude 从执行结果中获取反馈时，它会更新自己对进展程度以及累积结果确定性的认知。

When step 1 of a three-hypothesis debugging plan finds the bug, “investigate hypotheses 2 and 3” may no longer be necessary. Claude will usually say this explicitly (e.g. “the first check found it, so the remaining checks aren’t needed”) and skip ahead. You see this happen in Claude Code when task lists get revised mid-run. 当包含三个假设的调试计划的第一步就找到了错误时，“调查假设2和假设3”可能就不再必要了。Claude 通常会明确说明这一点（例如”第一次检查已发现问题，因此无需进行剩余检查”），并跳转执行。当任务列表在运行过程中被修订时，你会在 Claude Code 中看到这种情况发生。

Higher effort does make Claude more likely to double-check, like verifying the answer it found, or still look into the hypotheses it could have skipped. However, it generally won’t artificially inflate usage on a simple task just because the effort level is turned up. “Overthinking” is something our team specifically watches for during model training as it degrades effectiveness. 更高的努力程度确实会让Claude更倾向于进行双重检查，比如验证已找到的答案，或者继续研究那些本该跳过的假设。不过，即便提升努力等级，对于简单任务一般也不会人为增加使用量。“过度思考”是我们团队在模型训练阶段特别关注的问题，因为这反而会降低效果。

Picking an effort level 选择努力等级

For most tasks, use the model’s default effort level. The default is the level where Claude scales its token usage to what most people would want to spend on a task.对于大多数任务，请使用模型的默认努力等级。默认等级下，Claude会将令牌使用量控制在多数人愿意为任务投入的合理范围内。

Think of effort as a manual override on how hard and how long Claude works. Reach for it deliberately when you have a strong preference for thoroughness or speed based on your domain or the type of work you do, and treat it as a general preference, not a task-by-task decision. 你可以将努力等级视为手动调节Claude工作强度与时长的控制器。当你因自身领域或工作类型而特别注重全面性或追求速度时，可以主动调整该参数——请将其作为通用偏好设置，而非针对每个任务逐一决策。

One practical note following the launch of Opus 4.8: in our testing, the default effort setting on Opus 4.8 produces better results for about the same amount of tokens as the default effort setting on Opus 4.7 on the same task. Opus 4.8 推出后的一点实际反馈：在我们的测试中，对同一任务使用默认努力程度设置时，Opus 4.8 在消耗约等量 token 的情况下，能比 Opus 4.7 产生更优的结果。

What to change when Claude gets it wrong 当 Claude 出错时该如何调整

When Claude gets something wrong, your first instinct shouldn’t be to change a setting. It should be to look at the context you gave it. Is your prompt too vague? Is Claude connected to the right tools? Does it have the right skills? 当 Claude 出错时，你首先想到的不该是调整某个设置，而应审视你提供的上下文。你的提示词是否过于笼统？Claude 是否正确连接了工具？它是否具备所需的技能？

If you’re increasing effort on a task that shouldn’t need it, the fix is usually upstream: in your context, your CLAUDE.md, or how the task is scoped. 如果你在对一个本不需要的任务增加努力程度，问题通常出在上游：你的上下文、你的 CLAUDE.md 文件，或是任务范围的界定方式。

But say you’ve given clear context and Claude still gets it wrong. The question to ask yourself is: did it not try hard enough, or did it not know **enough?**但假设你已提供清晰的上下文，Claude 仍然出错。这时需要问自己：是它不够努力，还是知识储备不足？

Model: the problem was too hard 模型：问题太难

Pick a larger model when the problem is genuinely hard, like subtle bugs, unfamiliar domains, architecture decisions. A larger model is what you want when the smaller model is confidently wrong no matter how much context you give it.当问题确实复杂时——比如微妙的漏洞、陌生领域、架构决策——应选用更大的模型。当不论提供多少上下文，小模型都自信地给出错误答案时，大模型才是你需要的。

Larger models are also better at handling ambiguity. On smaller models, specific instructions that direct the execution are a better recipe for success. 更大的模型也更擅长处理模糊性。对于小型模型，提供明确的操作指令才是更有效的成功之道。

Pick a smaller model when the work is routine: edits you can describe precisely, mechanical changes, questions about code that’s already in context. There’s no reason to pay for capability the task doesn’t need. 选用较小模型的情况：当任务属于常规性工作，例如你能精确描述的各项编辑、机械性修改、或针对已载入上下文中代码的提问。没有必要为这些不需要的功能支付额外费用。

If Claude had all the pertinent context, clearly tried, and still got it wrong; that’s a signal to pick a larger model. And if you’re on the larger model and the work has been routine for a while, dropping down will increase speed and typically reduce cost without impacting the quality of the output. 如果克劳德（Claude）已掌握所有相关上下文，确实尽力尝试后仍未正确完成，这说明应选用更大模型。而当你正使用较大模型且连续处理常规性工作时，降级为较小模型能提升速度，通常也能降低成本，同时不影响输出质量。

Effort: Claude didn’t try hard enough 努力程度：克劳德（Claude）未能足够努力

Pick a higher effort level if Claude did it wrong by not trying hard enough: skipping a file, not running the tests, or not double-checking its work. This is most relevant if you’d selected an effort level below the model’s default. 当克劳德（Claude）因不够努力而导致错误时——例如跳过文件、未运行测试或未复核其工作——则需调高努力级别。这一情形在你当前选择的努力级别低于模型默认值时最为相关。

The specialist, the expert, and the generalist 专家、专才与通才

One way I like to think about the two settings is that Fable is a specialist who can handle problems almost no one else has, Opus is the expert, and Sonnet is a really good generalist. The effort level decides how much time any of them spends on your task. 关于这两种模式的对比，我喜欢将其理解为：Fable是能处理几乎无人能解的难题的专才，Opus是专家，而Sonnet则是非常出色的通才。努力程度决定了他们各自在你任务上投入的时间。

Opus at low effort is like getting five minutes with an expert who has deep experience with problems like yours. They bring knowledge that isn’t anywhere in your codebase; patterns they’ve seen before, gotchas they know to check for, the kind of experience you only get from having solved a lot of similar problems. But five minutes means a quick read of your code, not a careful pass through every file. 低强度模式下的Opus，就像用五分钟咨询一位对你这类问题有深厚经验的专家。他们带来的知识不在你的代码库里——那些是他们曾见过的模式、知道要检查的陷阱，只有解决过大量类似问题才能积累的经验。但五分钟意味着快速浏览你的代码，而非逐文件仔细审查。

Sonnet at high effort is the generalist with the whole afternoon. They’re great at coding, and they’ll read everything, run things, double-check their work, and end up understanding your specific code thoroughly. 高强度模式下的Sonnet，则像拥有整个下午的通才。他们极擅编码，会通读所有内容、运行程序、反复检查自己的工作，最终彻底理解你的具体代码。

Fable is the specialist you call when everyone else is stuck. Even at low effort, they’ll spot the thing no one else would. That recognition is also what you’re paying the most for, so it’s worth saving it for the tasks that need it. Fable 是当其他人都束手无策时，你才会请来的专家。即使投入的精力不多，他们也能发现别人发现不了的问题。这种识别能力也正是你付出最高代价所换取的价值，因此值得将其保留给真正需要的任务。

None of these is universally “better”. The model setting is roughly how capable; the effort setting is roughly how thorough. Most real tasks need some of both.这些设置并无绝对的”优劣之分”。模型设置大致决定了能力水平，而努力程度则大致决定了周全程度。大多数实际任务需要两者兼备。

Effort, model, and token consumption 努力程度、模型选择与 token 消耗

So how do model selection, effort, and token consumption all interact? It depends on the task. 那么模型选择、努力程度和 token 消耗这三者之间是如何相互作用的呢？这取决于具体的任务。

On routine work at the same effort level, both the larger and smaller models generally get it right. The larger model consumes more tokens with extra verification steps, at a higher per-token price. That’s why dropping to the smaller model for routine stretches saves real money at no quality cost. 在日常工作中，当投入相同程度的努力时，较大和较小的模型通常都能正确完成任务。较大的模型会因额外的验证步骤消耗更多标记，且每个标记的价格更高。这就是为什么在日常流程中改用较小模型，能在不牺牲质量的前提下节省实际成本。

Curves are for illustration purposes only, shown for a single task simple enough to be accomplished quickly by both models. They do not represent real benchmark data. 曲线仅供示意，展示了一个足够简单、两个模型都能快速完成的单一任务。它们不代表真实的基准数据。

On harder, multi-step work, the equation flips. The smaller model has to grind toward the limit of its ability, burning iterations, while the larger model reaches the same quality bar in fewer steps. 在更困难、多步骤的任务中，情况则截然相反。较小的模型必须费力地逼近自身能力极限，反复迭代；而较大的模型则能用更少的步骤达到相同的质量标准。

You’re paying more per token for the larger model, but on tasks that genuinely stretch the smaller one, the total cost per task can come out lower. And more importantly: the larger model can finish tasks the smaller one can’t, even at the highest effort settings.虽然较大模型的每个标记价格更高，但在那些真正挑战较小模型能力的任务中，每个任务的总成本反而可能更低。更重要的是：即使将较小模型调至最高的努力程度，它也无法完成某些任务，而较大模型却能胜任。

This is most pronounced with Fable. On long, multi-step work it pulls furthest ahead. In our testing, it finished jobs Opus and Sonnet can’t reach at any effort level. It also costs the most per token, which is the other reason to save it for the work that really needs it. 在Fable上这一点最为明显。在处理需要多步骤的复杂任务时，它遥遥领先。在我们的测试中，它能完成Opus和Sonnet在任何投入程度下都无法完成的任务。同时它的单token成本也是最高的，这也是为何要将其留到真正需要它的任务上。

Curves are for illustration purposes only, shown for a single task hard enough to stretch both models. They do not represent real benchmark data. 曲线仅为示意，展示的是单个足够困难的任务下两种模型的表现。它们并不代表真实的基准数据。

The key point in the graphs above: effort picks how far Claude is willing to travel along the curve. That doesn’t mean Claude will need to go that far to finish the task.以上图表的关键点在于：投入程度决定了Claude愿意沿曲线行进多远。但这并不意味着Claude必须走到那么远才能完成任务。

Lastly, effort shapes token consumption, but it doesn’t limit it. The only hard cap in the system is max_tokens, which truncates a response mid-stream when hit, but it’s a blunt instrument and mostly relevant to API developers. Softer controls like task budgets or asking Claude to keep it brief in your prompt are more helpful. They’re guidance the model is trained to follow (it’ll look to wrap up as it gets near the limit) rather than a wall it runs into.最后，努力程度决定了令牌消耗，但并不限制消耗。系统中唯一的硬上限是 max_tokens，达到时会在生成回复中途截断，但这是一种粗糙的控制手段，主要与 API 开发者相关。更柔性的控制方式（如任务预算或在提示中要求 Claude 保持简洁）更为有效。这些是模型经过训练会遵循的指导原则（模型会在接近上限时尝试收尾），而不是它会撞上的限制。

Effort changes how much work Claude does. The model changes what Claude knows. 努力程度改变 Claude 做多少工作。模型改变 Claude 知道什么。

When you’re unhappy with a result, check the context before you touch either setting: give Claude a clear prompt, the right tools and skills, and a way to verify its own work. 当您对结果不满意时，在调整这两项设置之前先检查上下文：为 Claude 提供清晰的提示、合适的工具和技能，以及验证自身工作的方法。

If Claude still gets it wrong, ask yourself: did it not know enough, or did it not try hard enough? Not knowing enough is a model problem, not trying hard enough is an effort problem.如果 Claude 仍然出错，请问自己：是它了解得不够，还是努力不够？了解不够是模型问题，努力不够是努力程度问题。

This article was written by @lydiahallie, member of technical staff on the Claude Code team.本文由 Claude Code 团队技术成员 @lydiahallie 撰写。