Verified against Claude Code · 2026-07-27
Reach for 'think hard' deliberately, not as a reflex on every request
A calibration prompt for when to actually invoke Claude Code's extended-thinking trigger words versus when they add latency and cost with no real benefit, tied to task reversibility and complexity rather than habit, and requiring the reasoning budget to be stated rather than left to the keyword alone.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are deciding, for this specific request, whether an extended-thinking trigger is actually warranted, and if so, at what level — this decision should be made deliberately per task, not applied as a fixed habit regardless of what the task actually is. TASK BEING CONSIDERED Deciding between three plausible database schema designs for a new feature that will be expensive to change once real data exists in it. WHAT MAKES THIS TASK COMPLEX OR SIMPLE Each schema option has different tradeoffs for query performance, migration difficulty, and how cleanly it models a genuinely ambiguous real-world relationship. HOW REVERSIBLE A WRONG ANSWER WOULD BE Changing the schema after real customer data exists in it would require a multi-step, risky migration — this decision is expensive to reverse. HOW MUCH EXTRA LATENCY OR COST IS ACCEPTABLE HERE This is a one-time design decision, not part of an interactive loop — an extra thirty seconds of reasoning time is a non-issue here. WHAT THE SAME TASK WOULD LOOK LIKE WITHOUT EXTENDED THINKING A quick answer would likely just pick the first schema that satisfies the immediate feature request without weighing the migration-difficulty tradeoff explicitly. DECIDE 1. State whether this task is the kind extended thinking actually helps with — a genuine multi-step architectural tradeoff, an ambiguous requirement needing several candidate interpretations weighed against each other, a subtle bug whose cause is not obvious from a single read of the code — versus the kind it does not meaningfully help with, such as a mechanical edit, a well-specified small change, or a lookup with one correct answer. 2. If extended thinking is warranted, name the specific reasoning budget being invoked — think, think hard, think harder, or ultrathink — and justify the level chosen against Each schema option has different tradeoffs for query performance, migration difficulty, and how cleanly it models a genuinely ambiguous real-world relationship. rather than defaulting to the strongest trigger out of an instinct that more reasoning can only help; a stronger trigger than the task needs spends real latency and cost for a benefit this specific task will not actually realize. 3. Weigh Changing the schema after real customer data exists in it would require a multi-step, risky migration — this decision is expensive to reverse. explicitly: a decision that is expensive or slow to undo once acted on, such as an irreversible database migration or a public API contract, justifies a higher reasoning budget than the same apparent complexity in a decision that is cheap to redo if wrong, such as a draft that will get reviewed before anything ships. 4. Confirm the chosen level against This is a one-time design decision, not part of an interactive loop — an extra thirty seconds of reasoning time is a non-issue here. — if this task sits inside a tight interactive loop where a slow response actively costs something, a lower reasoning budget applied correctly can beat a higher one that answers a question nobody needed answered this carefully, this specific time. IF EXTENDED THINKING IS NOT WARRANTED Say so plainly, and proceed with a normal response — do not add a trigger word reflexively because it is available or because it seems like it demonstrates more effort; the actual signal of a good decision here is calibration, not maximization. OUTPUT One sentence stating the decision and the specific reasoning invoked, if any, and why that level and not a different one — this sentence itself does not need extended thinking to produce.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Extended-thinking trigger words genuinely allocate a larger reasoning budget before Claude produces its response, which means the decision to invoke one is a real cost-benefit tradeoff, not a free intensifier — a stronger trigger on a task that does not actually benefit from more deliberation spends real latency and, depending on how the session is billed, real cost for a response that would have arrived at the same answer either way, which is exactly why calibrating the choice per task matters more than defaulting to the strongest available option out of an instinct that more reasoning can only ever help. Tying the decision to reversibility rather than to apparent difficulty alone targets a real asymmetry in what is actually worth spending extra deliberation on: a decision that is expensive or slow to undo once acted on, such as a schema choice that will need a real data migration to change later, justifies a higher reasoning budget even at moderate apparent complexity, because the cost of getting it wrong compounds long after the original request is answered, while an equally complex-seeming decision inside a fully reversible draft does not carry that same downstream cost even though it might look similarly hard to reason about in the moment. Requiring the specific level to be named and justified, rather than just invoking a trigger word and moving on, matters because the words themselves sit on an actual gradient of increasing reasoning budget, and treating them as interchangeable synonyms for 'think about this' collapses a real, ordered choice into an arbitrary one — the same failure mode as reaching for a wildcard permission pattern because naming the precise scope felt like unnecessary effort. Checking the chosen level against latency tolerance closes the loop on the other side of the tradeoff: a reasoning budget that would be entirely appropriate for a one-time architectural decision is poorly suited to a tight interactive loop where every extra second of latency is felt directly by whoever is waiting on the response, and a calibration that only considers task complexity while ignoring how the answer will actually be consumed is solving half the problem. The instruction to say plainly when extended thinking is not warranted, rather than defaulting to some trigger out of habit or a vague sense that more effort demonstrates more care, is the actual point of the whole exercise — the mechanism only pays for itself when it is reserved for the requests that genuinely need it, and using it indiscriminately erodes exactly the signal it is supposed to provide.
Verified against
Claude Code Sonnet 4.6 · 2026-07-27
Changelog
- 2026-07-27 — Initial publish, verified against Claude Code extended-thinking triggers (Sonnet 4.6).
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
