Chain-of-Thought Is Built In Now: How to Use AI Reasoning Modes Instead

A few years ago, adding "let's think step by step" to a prompt felt like a secret password. It reliably boosted accuracy on math problems, logic puzzles, and multi-part questions. That trick still works — but it's no longer doing what you think it's doing. Most frontier models now reason internally by default, and the smartest prompters have shifted from tricking the model into thinking to directing how and when it thinks. That shift is what extended thinking mode is all about.

If you're still sprinkling magic phrases into every prompt hoping for a reasoning boost, you're optimizing for a model behavior that's already been absorbed into the architecture. Here's what changed, why it matters, and how to actually use extended thinking mode to get better output.

The Technique That Got Built In

Chain-of-thought (CoT) prompting was a genuine breakthrough. Researchers found that asking a model to show its work — rather than jumping straight to an answer — dramatically improved performance on reasoning-heavy tasks. The prompt pattern was simple: describe the problem, then add a phrase like "think through this step by step before answering."

That pattern worked because early models defaulted to fast, pattern-matched responses. Forcing them to slow down and reason explicitly gave them room to catch their own mistakes.

Today's leading models don't need the nudge. Reasoning is often a built-in capability — sometimes visible as a distinct "thinking" or "reasoning" phase before the final answer, sometimes happening automatically depending on task complexity. The scaffolding you used to build with clever phrasing is now part of the foundation.

This is the core idea behind extended thinking mode: instead of prompting the model to pretend to reason, you're now selecting how much real reasoning budget to allocate to a task — often through a setting, a mode toggle, or a specific model variant built for deeper reasoning.

The Magic Phrase, Retired

Here's the practical problem: many people are still writing prompts as if chain-of-thought needs to be manually triggered with language. At best, this is redundant. At worst, it adds noise that competes with your actual instructions.

Old habit (redundant): "Analyze this quarterly report. Let's think step by step. First, consider revenue trends. Then think about margins. Then think about risks. Take your time and reason carefully before giving a final answer."

Better with extended thinking mode: "Analyze this quarterly report for revenue trends, margin changes, and risk factors. Flag anything that contradicts the executive summary." (Extended thinking mode enabled in settings.)

The second prompt is shorter, clearer, and trusts the model's native reasoning process rather than trying to script it turn by turn. When extended thinking mode is active, the model already allocates internal steps to work through revenue, margins, and risk — your job shifts from forcing the reasoning to directing it toward the right questions.

This is a meaningful mindset shift for anyone who learned prompting a year or two ago. Less time engineering pseudo-reasoning language, more time engineering the actual task definition.

When to Turn On Deep Reasoning

Extended thinking mode isn't free — it usually costs more time, more tokens, or both. So the real skill isn't knowing that the mode exists; it's knowing when it earns its keep.

Turn on extended thinking mode when:
- The task involves multiple interdependent steps (financial modeling, multi-file code changes, legal reasoning)
- There's a real risk of a subtle logical error that would be expensive to miss
- You're asking the model to weigh trade-offs or evaluate competing options
- The output needs to survive scrutiny — a report, a recommendation, production code

Skip it when:
- The task is a simple lookup, rewrite, or formatting job
- You need a fast draft and plan to iterate anyway
- The prompt is short and low-stakes (a tagline, a quick summary, a Slack message)

A useful heuristic we teach in our Prompt Engineering course: if you'd double-check the answer yourself before using it, the task probably deserves extended thinking mode. If you'd accept the first draft as-is, it probably doesn't.

Directing Reasoning with the R-C-T-O Framework

Even with reasoning built in, structure still matters — arguably more than ever, because a model that's actually reasoning will follow well-defined direction more faithfully than one guessing at your intent. This is where the R-C-T-O framework (Role, Context, Task, Output format) does heavy lifting.

When you pair R-C-T-O with extended thinking mode, you're not asking the model to think harder — you're telling it what to think about and what shape the answer should take once it's done reasoning.

Example: Research analysis, before and after

Before (vague, relies on old CoT tricks):
"Look at this competitor analysis and think carefully step by step about what it means for our pricing strategy."

After (R-C-T-O + extended thinking mode):
"Role: You are a pricing strategist advising a B2B SaaS company. Context: Here is our competitor pricing data for the last four quarters [data]. Task: Identify pricing patterns, evaluate whether our current tier structure is under- or over-priced relative to competitors, and play devil's advocate against our current strategy. Output format: A three-part memo — Findings, Risks, Recommendation — under 400 words."

The second version doesn't tell the model how to think. It defines the role, gives it real context, specifies the task precisely (including a built-in devil's advocate check, a technique worth using anytime you want the model to stress-test its own conclusion), and constrains the output. Extended thinking mode handles the reasoning; your prompt handles the direction.

Example: Debugging code

Before: "This function is broken, think step by step and fix it."

After: "Role: Senior backend engineer reviewing a teammate's PR. Context: [paste function + error log + relevant file via @-file reference]. Task: Identify the root cause of the null pointer exception, propose a fix, and note any edge cases the current tests don't cover. Output format: Explanation first, then a diff-style code block."

With extended thinking mode enabled and a properly scoped context, the model can trace through the logic on its own — no need to narrate the reasoning process yourself. Your prompt's job is giving it the right inputs and a precise task, the same discipline we cover in-depth in our Prompt Engineering for Code curriculum around context management and the SPEC prompt pattern.

A Quick Debugging Note

If output still feels shallow even with extended thinking mode on, the problem is rarely the reasoning depth — it's usually the task definition. Run through a quick checklist before assuming the model "isn't reasoning":

• Is the task actually well-specified, or is it vague enough that any answer looks "reasoned"?
• Did you provide enough context for the model to reason about the right things?
• Are you asking for one clear output, or several conflicting ones at once?

More often than not, tightening the Task and Context sections of your prompt fixes what looks like a reasoning problem.

Key Takeaways

• Chain-of-thought prompting isn't dead — it's built in. Most modern models reason internally without needing phrases like "think step by step."
• Extended thinking mode lets you control reasoning depth directly, rather than simulating it through prompt language.
• Use extended thinking mode for multi-step, high-stakes, or trade-off-heavy tasks; skip it for quick, low-stakes requests.
• Pair extended thinking mode with the R-C-T-O framework — the model handles how to reason, your prompt defines what to reason about and what shape the answer takes.
• If output still feels weak with extended thinking mode on, revisit your Context and Task before assuming reasoning is the bottleneck.