Claude Code Extended Thinking for Client Work: When to Turn It On
- Extended thinking makes Claude reason through a problem in visible steps before answering, instead of going straight to a response. Toggle it mid-session with the Tab key, or turn it on as the default for a project in settings.
- It is sticky. Once you turn it on for a project it stays on across sessions until you turn it back off, so it is worth knowing what state you left a client's project in before you start the next session.
- Reach for it on the handful of decisions where being wrong is expensive, like architecture calls and stubborn bugs, not on routine edits. Leaving it on for everything slows down the exact work where speed is the point.
What Extended Thinking Actually Does
With extended thinking on, Claude works through a problem in visible steps, laying out the reasoning in the transcript, before it writes the final answer. Without it, Claude still reasons, but that intermediate work is not surfaced; you only see the output. The practical difference on client work is that you can watch the reasoning as it happens: which approach it considered and ruled out, which edge case it caught before it caught it in your bug report instead.
That visibility is the actual value, not a novelty. On a routine task, the shortest path to the answer is the answer. On a task where the shortest path is unclear, like an architecture decision that will shape a client's codebase for the rest of the engagement, seeing the reasoning laid out is the difference between trusting an answer and understanding it.
Turning It On, and Why It Stays On
You can toggle extended thinking mid-session with the Tab key, in the desktop app the same way as at the terminal, and it takes effect on your next message. You can also set it as the default for a project so it starts on every time you open that codebase, instead of remembering to toggle it each session.
The setting is sticky: once you turn it on, it stays on for that project across sessions until you deliberately turn it back off. That is worth knowing before you walk away from a client's codebase mid-build, because the next person to open that project, including you a week later, inherits whatever state you left it in.
When It Earns Its Keep on Client Work
| Task | Turn it on? | Why |
|---|---|---|
| Scoping the architecture for a new client build | Yes | The cost of a wrong early decision compounds across the whole engagement; seeing the reasoning lets you catch a bad assumption before it becomes the foundation |
| A bug that resists the obvious fix | Yes | A stubborn bug usually means the obvious explanation is wrong; watching Claude reason through the alternatives surfaces the one you have not tried |
| Estimating a build before you quote it | Often | The reasoning behind a complexity estimate is more useful to you than the number alone, especially the risks it flags along the way |
| Routine CRUD work or a small copy change | No | There is no ambiguity to reason through; the extra step only adds time to work that was already fast |
| A client-facing live session where you are narrating progress | Usually no | A long visible reasoning block competes with the plain-language update you are trying to give the client in real time |
Match the setting to what the task actually needs
The pattern underneath the table: turn it on where the task has real ambiguity and being wrong is expensive, and leave it off where the path is already clear. Most of a client build is the second kind of task. That is exactly why the setting is worth toggling deliberately instead of leaving on by default for everything.
The Client-Facing Tradeoff
Extended thinking makes the transcript longer before it shows the answer, and that has a real cost the moment a client is in the room, whether that is a screen-share or a client-facing recap you send afterward. A client watching a wall of visible reasoning before the actual fix appears reads that as slower, not more thorough, because they are not the audience for the reasoning step.
The fix is not to avoid the setting on client work. It is to keep it on for the parts of a session you do alone, scoping and debugging, and turn it off before you open a session up to a client, or clean the transcript before you share it. That keeps the reasoning working for you without turning your process into the deliverable.
A Habit for Using It on Client Work
- Turn it on the moment you notice a task is a judgment call, not a mechanical one. That is the actual signal, not the size of the task.
- Read the reasoning, do not just skim to the answer. The value is in catching the wrong assumption before it ships, and that only happens if you actually look at the steps.
- Turn it back off once the hard part of the session is done. Riding it into the routine follow-up work afterward slows you down for no benefit.
- Check the setting at the start of a session on a project you have not opened in a while, especially one you inherited mid-build from a past version of yourself or a subcontractor.
Common Mistakes
- Leaving it on for an entire client project by default, so every small edit pays a time cost that only a handful of decisions actually needed.
- Sharing a raw transcript with visible reasoning as a client update instead of translating the outcome into plain language yourself.
- Forgetting the setting is sticky and being surprised a week later that a routine session is running slower than expected.
- Never turning it on at all, and quoting an estimate or shipping an architecture decision on the first answer that came back, on exactly the task where a second look would have caught the issue.
Inside the Claude Code Profit Room, builders compare notes on which settings actually change outcomes on client work versus which ones are just habit. It's $9 a month at https://www.skool.com/claudecodeprofitroom/about, come tell us where extended thinking has saved you from a bad early call.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What does extended thinking do in Claude Code?
It has Claude reason through a problem in visible steps in the transcript before writing its final answer, instead of going straight to the response. You can see which approaches it considered and ruled out, which is most useful on tasks with real ambiguity, like an architecture decision or a stubborn bug.
How do I turn on extended thinking in the Claude Code desktop app?
Toggle it mid-session with the Tab key, the same way whether you are in the desktop app or the terminal. You can also set it as the default for a project in settings so it is on from the start of every session in that codebase.
Does extended thinking stay on between sessions?
Yes. It is sticky: once you turn it on for a project, it stays on across sessions until you deliberately turn it back off, so check the setting when you reopen a client project you have not touched in a while.
Should I use extended thinking on every client task?
No. It is worth the extra time on judgment calls, architecture decisions, stubborn bugs, and complexity estimates, but it slows down routine edits and small changes for no real benefit. Turn it on for the hard part of a session and back off for the rest.
Should I show a client a transcript with extended thinking visible?
Generally no. A long visible reasoning block reads as slower to a client who is not the audience for it. Keep the setting on for the work you do alone and translate the outcome into a plain-language update before you share it, or turn it off before a live client-facing session.
Last reviewed September 1, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
