Low vs high reasoning: which setting fits each coding-agent task?

Keeping a coding agent on high or max reasoning is a poor default. For a small change with cheap verification, it may only add latency and token use. Put an uncertain production bug on low, though, and the agent may commit to the wrong path before it has mapped the problem. This is not a benchmark. It turns the current OpenAI, Anthropic, and Google documentation into a task-based selection guide.

Short answer: use low for bounded, reversible work; medium for ordinary development that spans several files and needs a plan; high for ambiguous root-cause analysis, architecture, or risky migrations. Reserve xhigh or max for long jobs where errors are expensive and a lower setting has already fallen short. Start with task risk, not the model badge.

The labels do not mean the same thing across vendors

OpenAI documents a model-dependent subset of none, minimal, low, medium, high, xhigh, and max for reasoning.effort. It associates lower effort with speed and lower token use, and higher effort with more complete reasoning and higher-quality responses. GPT-5.6 defaults to medium in both standard and pro mode. Those are OpenAI product claims, not a promise that every repository will show the same quality gap. [1]

Anthropic’s effort control affects the whole response, including text and tool calls, rather than internal thinking alone. Its documentation says Claude defaults to high; low may make fewer tool calls, medium targets a speed-cost-performance balance, and xhigh is aimed at long coding and agent jobs. Anthropic also describes effort as a behavioral signal rather than a strict token budget. [2]

Google’s available thinking_level values and defaults vary by Gemini model. Some support minimal, low, medium, and high, while others expose a narrower set. Google recommends minimal or low thinking for simple work, the default for moderate comparisons, and maximum thinking for advanced coding or multi-step planning. Matching vendors by label alone is therefore unreliable. [3]

Low: when verification is cheap

Low is a sensible start when the boundary and acceptance criteria are already clear. The work does not have to be trivial. The important part is that a test, lint run, or short diff review can expose a wrong result quickly.

• A rename, copy edit, or small configuration change in one file.

• Adding a unit test that follows an existing pattern.

• Finding references to a symbol and explaining a short code path.

• Fixing a specific error reported by the linter.

Keep a low-effort prompt narrow: “add this test in this file, change only the related code, then run this command.” If the agent starts expanding scope, tighten the task before raising reasoning effort.

Medium: the everyday agent default

Medium is the better starting point for much of a solo builder’s production work. OpenAI describes it as a balanced setting for planning, complex reasoning, and judgment, and GPT-5.6 uses it by default. That is still a vendor recommendation, but it makes a useful routing baseline. [1]

• Fitting a feature into the repository’s existing architecture and test style.

• A reversible refactor that spans several files.

• Updating types, tests, and documentation after an API change.

• Comparing two or three possible root causes from logs and error messages.

Ask for a plan first, then a small change set, then tests. A checkpoint between stages can improve the result more than taking the same oversized task straight to high.

High: when ambiguity or failure cost rises

Use high because the decision tree is wide, not because you want a longer answer. OpenAI positions it for hard reasoning, complex debugging, and deep planning. Anthropic points to difficult coding and agent work where quality matters more than speed. These are the vendors’ own recommendations. [1][2]

• A production failure with an unknown root cause across several services.

• A schema or storage migration with data-loss risk.

• Code review that changes authorization, payments, or a security boundary.

• An architecture choice with several viable options and a high reversal cost.

High does not grant automatic approval. Require the agent to state its assumptions, target files, and verification plan before it acts. Production writes, deletion, and access changes still need separate human approval.

xhigh and max: escalation, not habit

OpenAI recommends xhigh for long-running agent jobs, security or code review, and difficult coding workflows, adding that evals should show a benefit worth the extra latency and cost. Anthropic associates xhigh with coding and agent work lasting more than 30 minutes and potentially consuming millions of tokens. Both vendors reserve max for the hardest work at the top of the capability range. [1][2]

Do not switch to xhigh or max until you can say why the medium or high plan failed. More reasoning does not repair missing requirements. If the agent has the wrong repository, vague acceptance criteria, or a broken test environment, the expensive setting may just produce the same mistake at greater length.

A four-step routing rule

• Classify the task: is it reversible, how many files or systems can it touch, and what does a wrong decision cost?

• Start at the lowest sensible level: low for small bounded work, medium for ordinary multi-step work, high for ambiguous or risky work.

• Look for escalation signals: did the plan miss a dependency, did tool use stop too early, or did two attempts fail in the same place?

• Verify independently of reasoning effort with a diff, tests, lint, build, and any required security or production checks.

If you still need to choose the model tier, use the GPT-5.6 Sol–Terra–Luna pillar guide for the depth, speed, and cost split.

For the terminal surface and permission model, continue with the Codex CLI vs Claude Code vs Gemini CLI task guide. A stronger reasoning setting cannot repair a poor permission boundary.

Once the agent says it is done, run the seven-step output verification checklist.

Singrey note

My default recipe is deliberately boring: try small work on low, carry daily development on medium, and save high for ambiguity and risk. xhigh or max earns its place only when it removes a measurable bottleneck. Expensive reasoning is not trust. Trust starts when you can check the result independently.