Ask Claude to think before it answers

Let Claude reason step by step before answering when the task needs multi-step logic: a tricky bug, an architecture decision, a math or counting problem, a plan that touches several files. For everything else, a direct answer is faster and costs less. In the current Claude Code CLI you rarely toggle a switch for this. Thinking is on by default, and you steer how much of it happens with plain language in your prompt and with the effort level.

What is extended thinking in Claude?

Extended thinkingA mode where the model produces internal reasoning tokens before its final answer gives Claude room to work a problem out before it commits to a reply. The model writes out reasoning, considers approaches, checks edge cases, and only then produces the answer you read. It is the same model either way. Thinking does not swap in a different brain; it lets the one model spend more effort before speaking.

This matters because a language model writes one token at a time. Without thinking, the first words of the answer are committed before the model has worked through the hard part. With thinking, the hard part happens first, in a separate reasoning pass, so the answer is built on top of it. For the underlying mechanism, see how LLMs predict the next word.

When should I use extended thinking?

Thinking adds latency and costs tokens. Use it when reasoning quality matters more than speed. Skip it when the task is a lookup or a small mechanical edit.

A useful test: if you would want a colleague to pause and think before answering, ask Claude to do the same. If you would expect an instant reply from anyone competent, do not pay for a reasoning pass.

How do I ask Claude to think first?

The most direct lever is your own words. Adaptive thinking reads your prompt and decides whether to think, and a clear instruction tips that decision. Anthropic documents two phrasings as reliable nudges.

To push Claude toward reasoning on a hard task, end the message with a request to think:

To pull Claude away from a slow reasoning pass on something simple, ask for a direct reply:

These nudges work on a single message. Steering is sensitive to wording. If one phrasing does not change the behaviour you see, try a more direct variant. State the kind of effort you want plainly: "consider the edge cases first," "list the trade-offs before you choose," or "just give me the command."Common gotchaPiling superlatives onto the nudge ("think hard, deeply consider everything") does not buy deeper reasoning.Adaptive thinking reads it as the same single instruction to reason, so the extra words only inflate the prompt, and since ultrathink is retired there is no magic word hiding in there. To turn the depth dial up, raise the session effort level instead.

The effort level is the broader dial

Per-message phrasing tunes one turn. The effort level sets the default posture for the whole session. It is soft guidance for how much Claude reasons, and at higher levels Claude thinks more often and more deeply.

The default is high, so out of the box Claude already thinks on most non-trivial tasks. Lower the effort when you are doing a run of small, obvious edits and want speed and a smaller bill. Raise it for a gnarly architecture session. The effort level and your per-message phrasing stack: you can run at medium for a quick session and still say "think hard" on the one message that needs it. For how effort trades speed and cost against depth in coding specifically, see effort levels.

Does ultrathink still work?

No. As of January 2026 the ultrathink keyword is deprecated and thinking is enabled by default for the models Claude Code uses. If you have seen older advice telling you to type ultrathink or think harder as magic words, that approach is retired. You do not need a special token to unlock reasoning. Plain instructions and the effort level replace it. Writing "think carefully" still helps, not because it is a keyword but because it is a clear instruction the adaptive logic responds to.

Thinking between tool calls

In an agent loop Claude reads files, runs commands, and reads the output before its next move. Adaptive thinking turns on interleaved thinkingReasoning that happens between a model's tool calls, not only before the first answer, which lets Claude reason between those steps rather than only at the start. After a failing test it can think about why before editing, instead of guessing.

This is why thinking pays off most in long, multi-step work. A plan-then-build flow is the natural fit: break the task into steps, ask for the plan first, read it, then let Claude execute with reasoning between each tool call.Common gotchaAsking Claude to "think first" on a multi-file change does not stop it from editing as it reasons, so the code is already rewritten before you can check the logic.Add "do not edit yet, propose a plan" so you get to approve the reasoning before any file changes.

Where the reasoning goes

You will see Claude work through a problem and then answer. The reasoning you see is a summary of a longer internal pass, not the raw tokens. On the newest models the readable summary is off by default and the answer streams sooner; you opt in if you want the summary text. Either way the thinking happened.

One cost detail worth knowing: you pay for the full thinking tokens the model generated, not for the shorter summary you read. So thinking is a real cost, which is the whole reason to reserve it for tasks that earn it. To see what your session is spending, watch the token count in the footer or run /cost.

/cost

For the full picture of what drives the bill, see token usage and cost.

How do I make Claude think by default?

If a repo is full of subtle work, a payments service or a concurrency-heavy module, you can bias toward thinking by writing it into the project's rules file so it applies every session without re-typing. Keep the instruction short and specific about when to reason.

## Reasoning
 
This codebase has subtle money-rounding and timezone logic.
Before editing files under src/billing or src/scheduling,
reason through the edge cases first, then make the change.
For one-line edits elsewhere, answer directly.

The opposite also works. In a repo of mostly mechanical changes, a rule that says "answer directly unless the task spans more than one file" keeps the session quick. For more on durable project instructions, see rules and memory files.

A short workflow

1. Judge the task. Hard reasoning, or a lookup?
2. For hard tasks, ask Claude to reason first, or run at a higher effort level.
3. For a multi-file change, request a plan before edits and read it.
4. For simple edits, say "answer directly" and keep effort low to stay fast and cheap.
5. Watch /cost on long sessions so the reasoning is buying you something.

Common mistakes

• Thinking on everything. Reasoning on a rename or a syntax lookup wastes time and tokens. Match the effort to the task.
• Expecting magic keywords. ultrathink is gone. Use plain instructions and the effort level.
• Asking to think but not to plan. On multi-file work, pair "think first" with "do not edit yet, propose a plan." You get to check the reasoning before any code changes.
• Ignoring the bill. Thinking tokens are billed in full even though you read a short summary. On a long session, check /cost.
• Vague nudges. "Be careful" is weaker than "list the edge cases before you choose." State the reasoning you want.

Checklist

• Does this task need multi-step reasoning, or is it a lookup or mechanical edit?
• If it needs reasoning, did you ask Claude to think first or raise the effort level?
• On multi-file work, did you ask for a plan before edits?
• On simple work, did you ask for a direct answer and keep effort low?
• Are you watching cost on long sessions so the thinking is earning its place?

Reasoning before answering is a tool, not a default setting to leave maxed out. Spend it on the problems that reward it, and ask for speed on the ones that do not.