Choose Thinking Effort Like An Engineering Budget

You open the model picker in VS Code, Codex, Copilot, or some other AI coding tool, and there it is: Thinking Effort.

None. Low. Medium. High.

It looks like the difficulty slider in a game, except the boss fight is your half-migrated auth middleware and the loot drop is maybe a passing test suite.

The tempting interpretation is simple: high means smarter, low means cheaper, medium means “I am a responsible adult with a calendar.” That is not completely wrong, but it is too fuzzy to be useful. Thinking effort is not a new personality, and it is not just the model printing more steps. It is better understood as a budget for internal deliberation.

That budget can improve hard answers. It can also burn latency and credits on work that did not need a deep think. The trick is learning to spend it like an engineer, not like someone mashing the “make good” button.

The Espresso Shot: What The Setting Actually Changes

A normal language model response is generated from the prompt and context it receives: your message, conversation history, files, tool outputs, custom instructions, and whatever else the tool includes.

Reasoning models add another wrinkle. Before producing the final answer, they may spend internal tokens working through the task. OpenAI’s reasoning-model docs describe these as internal reasoning tokens used before a response. VS Code’s language-model docs call them dedicated thinking tokens, separate from the final output.

That separation matters.

When you choose a higher thinking effort, you are usually giving the model more room to do hidden work: plan, compare approaches, inspect ambiguity, reason through constraints, or decide which tool call comes next. The final answer might still be short. A good high-effort answer to “which migration path should we take?” may be a crisp recommendation with three tradeoffs, not a wall of visible chain-of-thought.

This is where the common “more reasoning means more visible steps” explanation needs an update. Extra visible steps can help in ordinary prompting because writing intermediate work into the context gives the model more structure to continue from. But modern thinking-effort controls often operate below the visible answer. Providers may return a summary of reasoning, omit it, or expose only token accounting.

So the useful mental model is:

Thinking effort controls how much deliberation the model may spend.
Output length controls how much of the result you ask it to show.
They are related, but they are not the same knob.

You can ask for high reasoning and a concise answer. You can also ask for low effort and a long explanation. Only one of those choices gives the model more deliberation budget.

The Three Levels, In Engineering Terms

Different providers and tools implement the labels differently, and some systems also support adaptive reasoning. Still, the practical shape is consistent enough to use.

Low: The Quick Pass

Low effort is for tasks where the path is already obvious. Use it when you want speed more than exploration:

• explain a compiler error you mostly understand
• generate boilerplate
• rename a small helper
• write a short regex with known constraints
• summarize a small file
• convert a simple function from one style to another

Low effort tends to pick a plausible path quickly. That is fine when the cost of being slightly shallow is low. If you ask it to add a missing null check in a two-line function, you do not need an architecture review in a candlelit room.

The failure mode is using low effort when the problem is deceptively connected. “Fix this flaky test” might be quick if the assertion is wrong. It might also involve async timing, stale state, retries, test isolation, and a mock server quietly wearing a fake moustache. Low effort may patch the first visible symptom and miss the system behavior.

Medium, Default, Or Adaptive: The Normal Workbench

Medium is the sane default for most engineering work. In many tools, leave the default or adaptive setting alone until you have evidence it is wrong. VS Code’s docs say it sets recommended effort levels and enables adaptive reasoning where supported, so the model can dynamically decide how much to think based on task complexity.

Use this tier for normal feature implementation, test updates, code review comments, explaining unfamiliar code, moderate refactors, API questions, and small debugging sessions with enough context. It gives the model enough room to avoid the most obvious foot-guns without turning every request into a committee meeting.

It also pairs well with better prompting. “Update this function” is okay. “Update this function, preserve the public API, keep the existing error behavior, and add tests for the new branch” is better. Thinking effort helps the model reason, but it still reasons over the context you give it.

High: The Deep Review

High effort is for tasks where the expensive part is not typing code. It is choosing the right path.

Reach for high when the work has multiple interacting constraints:

• debugging a bug that crosses files, services, or tools
• designing a migration plan
• comparing architecture options
• refactoring a large or interconnected area
• analyzing logs or performance behavior
• reviewing security-sensitive changes
• planning an agent workflow
• deciding whether a model’s answer is likely wrong

High effort gives the model more chance to do the thing you wish a rushed assistant would do: pause, inspect the surrounding constraints, compare theories, and avoid sprinting directly into the nearest plausible answer. It is especially useful when you want a plan before edits, a diagnosis before a patch, or a risk review before merging.

The tradeoff is real. Higher thinking effort can produce more thinking tokens, which VS Code warns can increase AI credit consumption. Anthropic’s docs are explicit at the API level too: internal thinking tokens may be billed even when the thinking content is summarized or omitted. More deliberation also means more latency.

High effort is not “better” in the abstract. It is better when the extra deliberation is cheaper than the cost of a shallow answer.

A Practical Example: The Flaky Integration Test

Imagine you ask an assistant to fix a flaky integration test. At low effort, it may look at the failure, notice a timeout, and increase the timeout. Sometimes that is exactly right. Sometimes it is the programming equivalent of putting tape over the check-engine light.

At medium effort, it is more likely to inspect the setup, the failing assertion, recent changes, and the mocked dependency. It may suggest isolating shared state or waiting on a real readiness signal instead of sleeping longer.

At high effort, you should expect more deliberate behavior: build a theory list, inspect logs, check whether tests pass alone but fail in a suite, look for order dependence, and propose a minimal patch plus verification plan. The final output might be shorter than the work behind it:

Likely cause: shared database state between tests.
Fix: create per-test tenant IDs and clear the queue fixture.
Verification: run this test alone, then the full integration suite twice.
Risk: this does not address the slower CI startup path; keep the timeout unchanged for now.

That is the output you wanted. Not a transcript of every thought. A better engineering answer.

Grounds For Concern: What Thinking Effort Does Not Fix

High thinking is useful, but it is not a universal solvent.

It does not fix missing context. If the model cannot see the failing test, the relevant config, or the production constraint, extra reasoning may just make it more confident about the wrong universe.

It does not guarantee correctness. Reasoning models are still probabilistic systems. They can reason from bad assumptions, miss edge cases, or produce code that looks tidy and fails under the one condition your customer will discover at 4:57 p.m. on Friday.

It does not replace verification. For code, the best companion to high effort is usually a test, a build, a trace, a log, or a small reproduction. If the assistant cannot run verification, ask it to produce the verification plan explicitly.

It does not mean you should expose raw reasoning. Current providers often summarize, hide, or encrypt reasoning artifacts for safety and product reasons. Treat reasoning summaries as helpful observability, not a perfect audit log.

And it definitely does not mean every answer should be longer. If you want a concise result, ask for one:

Use high thinking effort. Return only:
1. the likely root cause
2. the smallest safe fix
3. the commands to verify it
4. any remaining risk

That prompt spends reasoning budget on the hard part and output budget on the useful part.

Barista’s Tip: A Small Decision Frame

Before changing the effort level, ask one question:

Is the hard part execution, or judgment?

If the hard part is execution and the path is clear, use low or the default. You need throughput. If the hard part is normal engineering judgment, stay with medium, default, or adaptive. You need balance. If the hard part is choosing between plausible explanations, preserving constraints, or avoiding costly mistakes, use high. You need deliberation.

Here is the pocket version:

Effort	Use For	Expect	Watch Out For
Low	Simple, known-path work	Fast answers, lower overhead	Shallow fixes on connected problems
Medium/default/adaptive	Everyday development	Balanced speed and quality	Still needs good context
High	Ambiguous, multi-step, high-risk work	Better planning and tradeoff analysis	More latency, more tokens or credits

The setting is a budget. Spend it where reasoning changes the outcome.

The Last Sip

Thinking effort is one of those small UI labels that hides a real engineering tradeoff.

Low is not lazy. High is not magic. Medium is not boring. They are different ways to allocate model deliberation against latency, cost, and task uncertainty. Use low when the path is obvious. Trust default or adaptive settings for most work. Reach for high when the model needs to slow down, inspect alternatives, and reason through consequences before touching the code.

And remember the most useful pairing: high thinking, tight instructions, visible verification. That is where the setting stops being a mysterious slider and starts feeling like a tool.

Sources On The Counter

• OpenAI’s reasoning model docs explain internal reasoning tokens, reasoning.effort, and reasoning summaries for the Responses API.
• Anthropic’s extended thinking docs are useful for understanding thinking budgets, summarized or omitted thinking, and thinking-token accounting.
• VS Code’s thinking effort docs show how the setting appears in the model picker and why higher effort can increase AI credit usage.
• VS Code’s language model concepts explain thinking tokens, context, agent loops, and adaptive reasoning in everyday IDE terms.
• GitHub’s Copilot model comparison gives a practical task-based split between fast help and deep reasoning/debugging work.