Choosing Model Reasoning Levels: Run Low First, Escalate Failed Tasks to High

Many teams working with large language models on code generation, bug fixing, or repository-level development have the same instinct: set every task to the highest reasoning level to maximize success. This looks safer, but it often means many simple tasks pay unnecessary compute costs, and the final results are not necessarily better.

A developer-oriented guide to model selection reached a notable conclusion. On the same batch of software engineering tasks, running tasks at a low reasoning level first and retrying failed tasks at a high level reached an overall pass rate of about 97%, with an average cost of about $0.17 per task. Running every task at the high level from the start reached an overall pass rate of about 95.3%, with an average cost of about $0.29 per task.

The core lesson is not that a low level is always better than a high level. Model capability should be allocated according to task difficulty. Simple tasks do not need complex reasoning, and harder tasks justify more compute. The reasoning level should not be a fixed setting for an entire project. It should be a scheduling decision made for each task.

1. What the Low-First Approach Actually Saves

Suppose a batch has 100 tasks, all run first at the low level. If some of them fail, those failed tasks are sent back at the high level. Total cost can then be approximated as:

Total cost = low-level cost for all tasks + high-level retry cost for failed tasks

Running every task at the high level costs:

Total cost = high-level cost for all tasks

When the low level costs significantly less than the high level and solves most simple tasks, the tiered approach gives a clear cost advantage. In the source data, the tiered approach cost about $0.17 per task, compared with about $0.29 for running everything at the high level. That is a reduction of roughly 41%.

More importantly, the tiered approach does not simply replace the high level with the low level. It gives harder tasks a second chance:

1. Run all tasks at the low level.
2. Use automated checks to identify failed tasks.
3. Raise the reasoning level only for the failed tasks.
4. Rerun tests, builds, or validation.
5. Send tasks that still fail to manual analysis or a higher-level process.

This strategy filters cheaply first, then concentrates resources where they are needed. Its goal is not simply the lowest price.

2. Why the Tiered Approach Can Have a Higher Pass Rate

At first glance, running everything at the high level seems more reliable. But the two approaches make different numbers of attempts.

Running everything at the high level usually means each task runs once. If a task fails because of chance, a misread context, or an incomplete change, it gets no automatic second attempt.

The tiered approach works differently. A task that fails at the low level goes to the high level, so some tasks effectively get two attempts. If a meaningful share of the failed tasks can be fixed at the high level, the overall pass rate can exceed that of the single-run, all-high approach.

This does not mean the high level is weaker. It shows that single-attempt capability and end-to-end workflow success are different things:

• Single-attempt capability measures whether one run completes the task.
• Workflow success also depends on retries, how failures are detected, and whether the strategy changes after a failure.

When you design an AI coding workflow, do not compare reasoning levels only by single-run scores. Compare how they perform across the full workflow.

3. The Key Prerequisite: Results Must Be Checked Automatically

The most important requirement for “escalate after failure” is that the system can tell whether a task succeeded.

Tasks suited to this strategy usually have clear, executable acceptance criteria, such as:

• All unit tests pass.
• The project compiles or builds.
• Static checks report no blocking errors.
• API calls return the expected status.
• The output matches a reference answer.
• Data processing jobs produce files that meet the format requirements.
• Regression tests introduce no new failures.

The task execution flow can be abstracted as:

Generate changes
    ↓
Run verification commands
    ↓
Read exit status and test results
    ↓
Success: record the result and finish
Failure: raise the reasoning level and retry

If a task can only be judged by reading the code, such as “Is the code style elegant enough?”, “Is the interaction more natural?”, or “Does the architecture support long-term evolution?”, automatic escalation loses its foundation. The system cannot reliably tell “done” from “still needs improvement.” The model cost saved at the low level may then be offset by manual review time.

Before implementing this approach, answer three questions:

1. Are the success criteria clear?
2. Is there a stable, repeatable verification process?
3. Does the verification process cover the most common error types?

If all three answers are yes, the tiered reasoning strategy is usually easier to adopt.

4. Cost and Benefit Across Reasoning Levels

Within the same high-tier model, several reasoning intensities are usually available. Using the high level as the baseline, one set of test data showed the following relative performance:

Reasoning level	Effectiveness relative to high	Cost relative to high
Low	About 8 percentage points lower	About one third
Medium	About 2.5 percentage points lower	About 70%
High	Baseline	Baseline
Extra-high	About 1.4 percentage points higher	About 2.5 times

The data shows a typical pattern of diminishing returns.

Moving from low to medium gives a noticeable gain without a large increase in cost. Moving from medium to high is often an important boundary for complex tasks. Moving from high to extra-high, however, sharply increases cost for a relatively small improvement.

So higher is not always better. A more useful measure is the incremental return:

Incremental return = gain in pass rate / increase in cost

If moving from high to extra-high costs 2.5 times as much for about 1.4 percentage points of improvement, the decision depends on task value:

• For one-off, high-value tasks where failure is not acceptable, extra-high may be justified.
• For batch, repetitive tasks that can be retried automatically, it is usually not cost-effective.
• For tasks with strict deadlines, compare the value of extra reasoning time with the value of reduced manual intervention.
• For low-risk tasks, prefer the low or medium level.

5. Assign Levels per Task, Not per Project

A project usually contains tasks of varying difficulty, for example:

• Changing a simple configuration value.
• Adding an interface field that follows an existing pattern.
• Fixing a clearly defined null pointer issue.
• Locating a data flow error across multiple modules.
• Refactoring complex business logic.
• Analyzing and fixing concurrency, caching, or transaction issues.

If the whole project is set to the high level, simple tasks get over-computed. If it is set to the low level, complex tasks may fail repeatedly. A better approach is to define routing rules at the task level.

Consider the following strategy:

1. Low-risk tasks with clear boundaries

Examples include formatting changes, simple field changes, and local test fixes. Start these at the low level. They have a narrow context and clear verification, and they are easy to retry after a failure.

2. Medium-complexity tasks

Tasks that touch several files and require understanding of a local business process, but still have full test coverage, can start at the medium level. The medium level often balances cost and success rate well.

3. High-complexity tasks

Tasks involving cross-module dependencies, implicit business rules, concurrency control, or large-scale refactoring can go directly to the high level. This avoids wasting context on repeated low-level failures.

4. High-risk tasks that cannot be verified automatically

These tasks are not suited to fully automated retries. Use manual confirmation, staged changes, and review processes. The model’s reasoning level is only a supporting factor and cannot replace an acceptance process.

6. Escalation Order When the Current Setup Is Not Enough

When the current configuration cannot complete tasks reliably, do not immediately set every parameter to the maximum. A safer order is:

Step 1: Check the task input

Confirm that the requirements are complete, error logs are not truncated, relevant files are provided, and constraints are clear. Many failures come from incomplete context, not from model limits.

Step 2: Improve the verification and execution flow

Check whether the tests actually cover the target behavior, whether the build commands are correct, whether the environment variables are complete, and whether failure logs are fed back to the model. A flow without useful feedback can repeat the same mistakes even with a stronger model.

Step 3: Raise the reasoning level

Increase reasoning intensity only after the task description and verification flow are sound. This confirms that the extra compute solves the problem rather than h