Claude Code Effort: Choose a Level That Fits the Task

Claude Code can apply different levels of reasoning to a task. A lower effort level produces faster responses with less thorough analysis; a higher effort level applies more thinking time and typically catches more edge cases, but takes longer and costs more to run. Choosing the right level means matching the task's actual complexity to the appropriate depth of analysis.

The criteria for what good output looks like and the lessons you draw from comparing effort levels are worth saving beyond any single session. Tools like fenbs keep those criteria and lessons in the project record, so future sessions can apply the same standard without having to rediscover it.

What do effort levels actually change?

Effort in Claude Code relates to the thinking budget available to the underlying model. At lower effort, the model responds more quickly because it spends less time on internal reasoning steps before producing output. At higher effort, the model works through more of the problem before answering, which can surface dependencies, edge cases, and tradeoffs that a quicker pass would miss.

Claude Code documents its current effort and reasoning settings in Anthropic's Claude Code documentation↗ (opens in a new tab). Check the current options there, because the available levels and how they are configured can change between releases. The underlying principle — that more reasoning time trades off against speed and cost — is stable.

When should you use a lower effort level?

Lower effort is a reasonable choice for tasks where the correct answer is well-defined and the consequences of a missed edge case are easy to catch. Simple changes with clear acceptance criteria, mechanical refactoring with automated tests, and quick questions about the codebase are all good candidates.

• Renaming a variable or function across a well-tested codebase.
• Generating boilerplate code you will review and adapt before use.
• Asking Claude Code to summarize what a file does before you read it yourself.
• Running a batch of similar, low-risk edits where you are reviewing every change.

When should you use a higher effort level?

Higher effort matters when the problem has hidden dependencies, competing requirements, or significant consequences for a wrong answer. Use it when a quicker pass has already missed something, or when the cost of an incorrect solution is high enough that spending more on the initial analysis is clearly worthwhile.

• Designing a change to a shared data model or API that other code depends on.
• Debugging a concurrency issue or a failure that appears inconsistently.
• Writing a migration that must be correct the first time because it is difficult to reverse.
• Producing an implementation plan for a multi-step feature with unclear dependencies.

How do you compare results across effort levels?

The clearest comparison is to run the same concrete task at two different effort levels and evaluate both results against the same criteria. Use the Claude Code fork workflow to try both from an identical starting point. The criteria should be specific: does it pass the same test suite, does it handle the named edge cases, does it change any file outside the stated scope.

Avoid relying on how confident Claude Code sounds. A lower-effort response can be expressed with equal confidence to a higher-effort one. Judge the output against your stated criteria, not against how the response is framed.

How do you record what worked?

The useful output of an effort comparison is a project-specific rule about when to use each level. That rule is not obvious from the task itself; it comes from observing what the lower-effort pass missed and the higher-effort pass caught. Once you have that observation, it is a lesson worth saving.

A lesson in fenbs records what happened, what you learned, and what to do differently. "Higher effort caught two missing null checks in the data layer that lower effort missed; use higher effort for data access changes in this project" is more useful than a general recommendation.

How to do this with fenbs

1. Create a free account and open the project you are testing effort levels on.
2. Write the task criteria in the fenbs task plan before running the comparison. Both effort levels should be measured against the same standard.
3. Connect Claude Code to fenbs from Integrations. Run the task at each effort level and note which criteria each level met or missed.
4. Record the comparison result as a fenbs lesson: what the lower-effort pass missed, what the higher-effort pass added, and what that means for similar tasks in this project.
5. If the lesson produces a project-wide rule — "always use higher effort for schema changes" — add it to Decisions and rules so it applies automatically to future sessions.

fenbs does not control Claude Code's effort setting. It keeps the criteria and lessons that inform how you choose. For understanding how Claude Code plans before acting, the Ultraplan guide covers the extended planning mode. For saving a checkpoint before a high-effort run so you can compare without losing work, the checkpoints guide explains the save and restore flow.