Effort Parameter Guide for Claude Code
The key insight is that effort is essentially verification intensity: it polishes a chosen approach but cannot rescue a wrong one, and detailed task specs shrink the gap between effort levels. Practitioners should use high effort for security, code review and hardware tasks with hidden edge cases, and low or medium effort when staying in the loop. The no-prompt-cache-break detail makes it practical to adjust per task in Claude Code.
Claude Code developer @trq212 published a guide on using the Effort parameter, based on official evaluations and hands-on experiments.
Effort acts as a compute budget signal: high effort leads to more autonomous verification, while low effort produces a quick, iterable draft.
Analysis of Terminal-Bench 3.0 failures shows that raising effort mainly fixes failures from missed edge cases, not failures from wrong approaches.
In an HTML sanitisation task, Fable 5.1 improved from 1/5 at low effort to 5/5 at ultra-high effort, with runtimes going from about 2 minutes to 33 minutes.
Switching effort in Claude Code does not break prompt caching on newer models like Fable 5.1 and Opus 5.
5.
'Effort' 参数到底应该怎么用？ Claude Code 开发者 @trq212 基于官方评测和亲手实验得出 “Effort 参数使用指南”。 首先看看 effort 到底是什么？ Effort 是告诉模型“你希望它为这个任务投入多少计算量”的信号。Thariq 给了一个很精准的类比：同样是做一个任务，别人给你 12 小时，你会理解为“尽全力做好”；只给你 1 小时，你会先交付一个满足要求的版本，等对方反馈再迭代。Effort 就是这个“时间预算”：高 effort 意味着模型会做更多自主判断、更多验证；低 effort 意味着快速给一个可迭代的起点。 一个重要背景：新一代模型 (Fable 5.1、Opus 5.5) 的 effort 曲线是迄今最好的，且在 Claude Code 中切换 effort 不会破坏 prompt 缓存，这正是这个功能真正可用的前提。 关键发现一：effort 的本质是“验证强度” Thariq 通过分析 Terminal-Bench 3.0 (社区共建的终端任务基准) 的失败数据得出核心结论： 提高 effort 主要减少“遗漏边界情况”导致的失败，但无法修复“方向/思路错误”导致的失败。 换句话说，effort 不会让一个想错了方案的模型变对，它只会让模型把同一个方案打磨得更严密。这个区分是全文最有洞察力的一点。 典型证据：HTML 检查任务 (要求封堵所有向页面走私 JavaScript 的方式)，Fable 5.1 从低 effort 的 1/5 提升到超高 effort 的 5/5。低 effort 下模型一遍写完、只用手写页面测一下(约 2 分钟)；高 effort 下(约 33 分钟)它会对抗性审查自己的初稿、读解析器源码找 bug、跑标准 XSS 测试套件、甚至写随机文档模糊测试器。类似的还有存储引擎 bug 修复(0/5→4/5)、线性规划求解器(0/5→5/5)、蛋白质组学分析(0/5→4/5)。 关键发现二：effort 的收益因领域而异 高 effort 受益大的领域：硬件、代码审查、安全，共性是“隐藏边界情况多、验证本身很有价值”。 低/中 effort 更合适的场景：快速出活、需要人保持在决策回路里(brainstorm、打草稿、简单改动)。值得注意的是 gsea-proteomics 那个例子：如果有用户在旁边，模型本可以直接问“数据预处理用哪种方式”；无人值守时，高 effort 才能替代这种追问。 另一个反直觉发现：任务规格(spec)写得越详细，不同 effort 的产出差异越小。规格模糊时，高 effort 意味着模型替你做更多假设和决定，这未必是你想要的。 Thariq 的实际工作流 1. 给 Claude 一份规格，让它反过来访谈我，补齐缺失细节； 2. 低 effort 实现； 3. 人工审查是否抓住要点，需要时继续低 effort 迭代； 4. 高 effort 做验证和测试。 这个模式把“人擅长判断方向”和“模型擅长穷举验证”分别放在了合适的环节。 Effort 档位速查 Low - 快速响应、人在回路，比如头脑风暴、草图、简单修改 Medium - 日常开发主力档，比如新功能实现 High - 验证重要、边界情况多，比如老代码库修 bug Max - 完全自主解决难题，比如端到端构建并验证应用、安全漏洞挖掘 Thariq @trq212 What is effort really? When do you change it it and why not just use max effort for everything? I dove deep into this problem, looking into evals and doing my own tests and I was quite surprised by the results. x.com/i/article/2103… 🔗 View Quoted Tweet📊 3 ⚡
This report is categorized under AITOP's "How-to" desk, focusing on US frontier AI labs and Silicon Valley technology leaders. Within our cross-regional analytical framework, it directly maps to AI developer toolchains, coding agents, and engineering workflows and US-China foundation model benchmarks and commercialization comparison and AI regulation, compliance frameworks, and sovereign compute policy. Key entities and technical topics under continuous tracking include Claude Code, Anthropic, Fable 5.1, prompt engineering.
Source attribution: curated from shao__meng (@shao__meng).
