Matching Thinking Depth to the Task

Thinking isn't free — the deeper it goes, the more tokens it burns, which turns into cost and latency. But apply one depth to every task and you overpay on easy ones while underthinking the hard ones. This is as much about raising depth as lowering it.

Problem

An instruction to fix one typo and an instruction to decide an architectural fork both get thought through at the same depth. The default thinking amount is fixed at a single tier. But task difficulty isn't a single thing.

On the easy side, the excess turns into cost and latency (the official docs state plainly that raising depth increases thinking tokens, and that both credit consumption and latency rise — Official, VS Code, see in Practice). On the hard side, the shortfall remains as a flawed design. Both are losses, but they hurt differently.

Overpaying shows up on the invoice, so it gets noticed eventually even if left alone. Underthinking just returns a wrong answer with a straight face, with no cue at all to notice.

Context

Applies when:

• Task difficulty varies widely — the same repository, the same day, mixes chores and hard spots
• Cost or latency is actually a concern — depth is spending, and if spending isn't a concern there's no motive to adjust it
• A hard spot is visibly underthought — this is the condition for the "raise it" side. This pattern isn't only about lowering

Does not apply when:

• ⚠ The default is already sufficient. The official docs state plainly, in two separate documents, "For most use cases, the defaults work well" and "For most tasks, the defaults are sufficient" (Official, VS Code, see in Practice). This pattern isn't "always adjust." If you can't state a reason to move the default, don't move it
• Territory the tool's automatic judgment already reaches. Even at defaults, some surfaces automatically scale how much to think based on the complexity of the move right in front of them (Official, VS Code, see in Practice). Manually intervening there either matches the same result or makes it worse
• There's no dial to begin with. Without a reasoning model, the UI for choosing depth doesn't even appear on some surfaces (Official, VS Code, see in Practice)

Boundary with neighboring patterns:

• Keeping the Prefix Stable — ⚠ the dial this pattern turns is exactly what that pattern names as "lock in before you start." The official caching advice states verbatim that switching reasoning effort mid-session rebuilds the cache (Official, VS Code, see in Practice)
• The Break-Even Point of Delegation — that pattern is the price tag for who does it; this pattern is the price tag for how much to make it think. They intersect at specifying a tier per subagent (see in Practice)
• Preemptive Plan Review — that pattern is the type that verifies a plan before execution. From this pattern's view, that's the phase corresponding to one of the two situations the official docs name as fine to raise depth for (architectural planning) (Official, VS Code, see in Practice)
• Read-and-Discard Isolation — where to read is that pattern; how much to think there is this pattern. The depth inside an isolated context can be set separately from the main one (see in Practice)

Solution

Why this works. Thinking depth is spending, not a setting. Turning the dial up a notch isn't changing a configuration — it's increasing what you pay on every request. The official docs write the causality in only this direction — raise depth and thinking tokens increase, and credit consumption and latency both go up (Official, VS Code, see in Practice).

Being spending, fixing it to a single value is the most costly choice. The diagonal in the diagram is the line where the two "match." The harder the task, the higher the depth worth paying for. Yet the default is a single vertical line — depth doesn't move even as difficulty does. A vertical line and the diagonal cross at exactly one point, meaning a fixed default only lands for a task of precisely that difficulty. Everything else sits off the diagonal.

There are two ways to miss, and the pain is asymmetric. Lower right (easy, yet deep) wastes cost and latency. Upper left (hard, yet shallow) is a quality loss. This pattern gets misread as "a savings technique" precisely because only the lower-right loss shows up on the invoice. The upper-left loss takes the shape of a wrong answer returned with a straight face, with no way to measure it. Optimize by looking only at measurable loss, and you drift toward the loss you can't measure.

If it stopped here, the story would be "choose by hand, per task." But the tool is already doing part of this. Even at defaults, how much to think gets scaled somewhat automatically to the complexity of the move right in front of it, and the official docs state plainly, "the defaults work well for most use cases" (Official, VS Code, see in Practice). Writing "always optimize by hand" collides head-on with this official statement. This pattern's jurisdiction doesn't extend that far.

What's left is what automatic judgment structurally doesn't see. What the official docs say automatic judgment sees is the complexity of the move right in front of it. What it doesn't see:

• Phase — whether this is planning or implementation isn't written into any single move. An error in planning ripples through everything downstream, but that ripple doesn't show up in the complexity of the request in front of you
• Stakes — "rename this function everywhere" is a simple request, and the damage if you get it wrong is large. Complexity and severity are different quantities
• Structure — hand the same tier to dozens of subagents, and the difference per tier multiplies by that count. A per-move judgment doesn't see that multiplication

So this pattern is about deciding depth at a unit larger than one move. What it matches to isn't "this request" — it's phase, stakes, and structure. That's exactly where automatic judgment doesn't reach, and at the same time, exactly where only a human has the information.

Trade-offs

Advantages

• Thinking can be concentrated on hard spots. Stop spreading it thin across everything, and the same spend can go thicker where it's hard. The official docs name exactly two situations where it's fine to raise it — architectural planning and multi-step debugging (Official, VS Code, see in Practice) — and both are the names of phases, not moves.
• Easy work skips paying cost and latency. Depth affects not just cost but latency too (Official, VS Code, see in Practice). The speed of routine work returns directly to how it feels, apart from the balance sheet.

Costs

• Switching breaks the preamble. The official caching advice names switching reasoning effort mid-session as something that rebuilds the cache (Official, VS Code, see in Practice). This pattern's dial is, from the cache's point of view, near the top of the list of "things to lock in before you start." Flip it up and down often, and you can lose what you saved to recomputing the preamble.
• The cost increase is certain; the improvement is conditional. Within what this catalogue could source, the Official docs write the cost side causally (depth ↑ → thinking tokens ↑ → credit consumption ↑). Quality, on the other hand, stays at a conditional recommendation — "raise it only for genuinely complex tasks." It isn't written as a causal claim that raising it makes things better. Decide to raise it knowing this asymmetry.

GitHub Copilot in Practice

Copilot isn't a single product. The thinking-depth dial exists on both VS Code and Copilot CLI, but the name, where you set it, and the ceiling tier all differ by surface.

VS Code — chosen from the model picker

Source: Language models (retrieved 2026-07-16) Official:

Some models support configurable thinking effort, which controls how much reasoning the model applies to each request.

By default, VS Code sets recommended effort levels and has adaptive reasoning enabled, where the model dynamically determines how much to think based on the complexity of each request. For most use cases, the defaults work well.

Higher thinking effort produces more thinking tokens, which increases AI credit consumption. Only increase thinking effort for genuinely complex tasks.

Non-reasoning models, such as GPT-4.1 and GPT-4o, do not show the thinking effort submenu.

VS Code calls this thinking effort, set from the Thinking Effort submenu in the model picker (the original text describes the setting item as deprecated and directs you to set it directly from the model picker). Without a reasoning model, the submenu itself doesn't appear.

By default, adaptive reasoning is on, and the model decides how much to think based on the complexity of each request. This is the automatic judgment described in Solution — what the official docs write as "sees and decides" is the complexity of each request, the move right in front of it, not the phase and not the stakes. Cost is written causally (depth ↑ → thinking tokens ↑ → AI credit consumption ↑), while quality stays a conditional recommendation — "raise it only for genuinely complex tasks." Trade-offs handles this asymmetry.

VS Code — where it hits cost, and where it's fine to raise it

Source: Language models (Agents concepts) (retrieved 2026-07-16) Official:

Different models consume AI credits at different rates, based on the model and the number of tokens processed. More capable models cost more per token, while lighter models extend your usage further.

Other factors also affect credit consumption, such as thinking effort (higher effort produces more thinking tokens), context window size, and tool usage. Prompt caching lowers the effective cost of a request by reusing tokens from a previous one.

The bulk of cost is model price × tokens processed, and thinking effort is one factor among others that affects it (other factors ... such as). Context length and tool usage sit in the same list. Depth alone doesn't determine cost — lower it, and if context has ballooned, cost doesn't come down. Don't read the cost story as closed by this pattern alone.

Source: Optimize your AI usage (retrieved 2026-07-16) Official:

Higher effort levels produce more thinking tokens, which increases both latency and credit consumption. VS Code sets default effort levels based on evaluations and has adaptive reasoning enabled ... For most tasks, the defaults are sufficient. Only increase thinking effort for genuinely complex problems like architectural planning or multi-step debugging.

Depth affects both cost and latency. "The defaults are usually sufficient" appears a second time, in a separate document from the one above. And the situations named as fine to raise it for are architectural planning and multi-step debugging — both are the names of phases, not a single move. The official advice itself points to a unit larger than one move.

VS Code — the same dial, seen from the cache side

Source: Cache Explorer (retrieved 2026-07-16) Official:

• Lock in settings before you start: Switching the model, reasoning effort, context size, or the enabled tools and MCP servers during a session rebuilds the cache. Choose them upfront, or use auto model selection, which switches models only at cache boundaries.

The dial this pattern turns is named verbatim (Switching the model, reasoning effort, ...). Switch it mid-session and the cache gets rebuilt. The official advice is "choose upfront" (Choose them upfront). "Adjust to fit the task" and "lock in before you start" don't coexist within the same session.

Copilot CLI — the flag goes up to max, the config key up to xhigh

Source: CLI command reference (retrieved 2026-07-16) Official:

| --effort=LEVEL, --reasoning-effort=LEVEL | Set the reasoning effort level (low, medium, high, xhigh, max). max is the highest-depth tier for Anthropic models. |

Against that, the config key (source: CLI config dir reference, retrieved 2026-07-16) Official:

| effortLevel | string | "medium" | Reasoning effort level for extended thinking: "low", "medium", "high", or "xhigh". Higher levels use more compute. |

The CLI calls this reasoning effort. Within the same product, the startup flag lists five tiers and accepts max, while the config key lists only four (default "medium"). Note that the CLI surface phrases cost as "Higher levels use more compute," a different phrasing from VS Code's thinking-tokens-and-credit causality.

The AI credits explanation also changes across surfaces (source: Running tasks in parallel with the /fleet command, retrieved 2026-07-16) Official:

GitHub AI Credits usage: When you submit a prompt in the CLI and Copilot interacts with the selected large language model (LLM) to generate a response, this consumes GitHub AI Credits. More interactions with the LLM result in a higher consumption of GitHub AI Credits.

On the CLI surface, the official route to consumption named is the number of interactions with the LLM; on the VS Code surface it's thinking tokens. This isn't a contradiction — this catalogue reads it as the same "more processed tokens" path described from two different angles. But generalizing across surfaces to "AI credits track thinking tokens" matches neither original text. That depth moves cost is, as far as confirmed, written for the VS Code surface.

Compared with Claude Code — similar, but not identical

Placed here as a cross-tool comparison, with tool names and sources named explicitly. Claude Code uses the same config key name, effortLevel, as Copilot CLI (source: Model configuration, retrieved 2026-07-16) Official:

Settings: set effortLevel to low, medium, high, or xhigh in your settings file. max and ultracode are session-only and are not accepted here

The config key's name matches, the set of tiers matches, even that the top tier can't go in the settings file matches. A different vendor's different product looks this similar. But bundling this as "the same structure" becomes inaccurate about Claude Code Official:

max provides the deepest reasoning with no constraint on token spending and applies to the current session only, except when set through the CLAUDE_CODE_EFFORT_LEVEL environment variable.

What's common is only "the settings file can't hold the top tier"

Copilot CLI's config key enumerates four tiers, low through xhigh; Claude Code's config key names and excludes max (are not accepted here). Both land at the same ceiling. This much can be written as a shared fact.

Past that, they diverge. Claude Code's max has an explicit exception to "session-only" — set via the CLAUDE_CODE_EFFORT_LEVEL environment variable, and it's no longer session-only. So writing "the top tier is runtime-only" for both tools together becomes wrong about Claude Code.

Even two products sharing the same config key name differ in how the ceiling gets lifted. Between "similar" and "the same" sits the distance of one sentence of original text.

Differences across surfaces

Surface	Official name	Where the tier is chosen
VS Code	thinking effort (reasoning effort in the caching material)	Thinking Effort submenu in the model picker. The submenu doesn't appear without a reasoning model
Copilot CLI	reasoning effort	Startup flag (accepts up to max) / config key effortLevel (up to xhigh, default medium)
Claude Code (cross-tool comparison)	effortLevel / effort	Settings file (up to xhigh) / environment variable (exception for max) / skill and subagent frontmatter

The mechanism — "choose a thinking amount by tier" — is the same, yet the name, where you set it, and the ceiling tier all differ. A blanket statement like "Copilot supports setting effort" erases every one of these differences.

Changing tiers per subagent

Solution's claim — "decide depth at a unit larger than one move" — has separate mechanisms in two different tools. Copilot CLI (same config dir reference above) Official:

| subagents.agents | object | {} | Per-agent model configuration, keyed by agent name. Each value is an object with optional model (string), effortLevel (string), and contextTier ("default", "long_context", or "inherit") fields. Set any field to "inherit" to use the parent session's value at dispatch time. … |

Claude Code (model-config above) Official:

Skill and subagent frontmatter: set effort in a skill or subagent markdown file to override the effort level when that skill or subagent runs

This is a shape where depth isn't held once per session but per role. A research agent can stay shallow while an agent handed design work goes deep. Not a single tool's trick — the same shape holds across two products from two separate vendors.

Also Known As

Name	Source
Reasoning effort	Primary — Copilot CLI's official name (flag --reasoning-effort, config key effortLevel). VS Code's caching material also uses this term (source: in Practice section above)
Thinking effort	Primary — VS Code's official name (Thinking Effort submenu in the model picker) (source: in Practice section above)
Adaptive reasoning	Primary — VS Code's official name. ⚠ But this is the name of what the tool does automatically, not this pattern's name (below) (source: in Practice section above)
Matching Thinking Depth to the Task	Descriptive — this catalogue's descriptive name; no primary source uses it

The same concept carries a different primary name per surface. Copilot CLI calls it reasoning effort; VS Code calls it thinking effort. ⚠ But the split isn't even clean across surfaces — VS Code's own docs write thinking effort in the model material and reasoning effort in the caching material (both in Practice). The practical takeaway for readers is one thing: don't lock in a single search term.

Adaptive reasoning isn't made an alias of this pattern. That's the name of the tool automatically scaling the tier, and the official docs state it's on by default (see in Practice). This pattern is the practice of a human deciding the tier at a unit larger than one move. The two don't compete — automatic judgment looks at the move right in front of it; this pattern looks at phase, stakes, and structure. Mixing the names invites the misreading that "adaptive reasoning is on, so this practice is already done."

For the same reason, the official docs give a name only to the dial (thinking effort / reasoning effort). For the practice of choosing that dial to match phase and stakes, no established name could be confirmed. Repurposing the dial's name for the practice invites the misreading "effort can be configured, therefore this practice is being done." Even left at the default, fixed to one tier, the dial is still set.

Related

• Keeping the Prefix Stable — the dial this pattern turns is what that pattern says to "lock in before you start." The official caching advice names reasoning effort specifically as a factor that rebuilds the cache (see in Practice). A direct tension, and this catalogue doesn't resolve it
• The Break-Even Point of Delegation — that pattern is the price tag for who does it; this pattern is the price tag for how much to make it think. They intersect at specifying a tier per subagent, and two tools have mechanisms for it (see in Practice)
• Preemptive Plan Review — that pattern is the type that verifies a plan before execution. From this pattern's view, that's the phase corresponding to one of the two situations the official docs name as fine to raise depth for (architectural planning) (see in Practice)
• Read-and-Discard Isolation — where to read is that pattern; how much to think there is this pattern. The depth inside an isolated context can be set separately from the main one, and two tools have the mechanism for it (see in Practice)
• If reading just one more next: The Break-Even Point of Delegation — having seen the price tag on thinking, it's next to look at the price tag on delegation