Your Best Coding Model Should Be Idle Most of the Day

Introduction

Your coding agent finishes a small dependency update, but the usage report looks like it rebuilt half the application. It searched the repository, reread the same files, attempted multiple edits, ran tests, analyzed failures, and asked your most expensive model to supervise every step.

The problem is not that the model costs too much per token. The problem is that you assigned a premium reasoning engine to work that often needed a fast searcher, a competent editor, or a deterministic test runner.

You are about to learn how to route coding agent tasks by risk and measure whether your strongest model is producing enough accepted changes to justify its workload.

One Model, Endless Meter

Most teams begin with a deceptively simple policy: choose the model that performs best and use it everywhere. That feels responsible because coding mistakes are expensive, while the difference between model prices can look small beside an engineer’s salary.

Agent workflows break that comparison. A single request can trigger repository searches, file reads, tool calls, retries, test runs, and self review before producing one proposed change. Developers have described this compounding behavior in a Claude Community Discussion from August 13, 2026, where the concern is not one costly completion but the accumulated expense of autonomous loops.

The visible token price is therefore only one component of AI coding costs. You also pay for failed attempts, duplicated context, orchestration, infrastructure, and the engineer who must inspect an uncertain result. The paper ACEM: A Cost Estimation Model for Agentic Software Engineering formalizes this broader view by including token consumption, orchestration infrastructure, and human oversight in agentic software cost estimation.

This is why a cheaper model is not automatically economical. If it retries five times and still produces an unusable patch, it may cost more than one deliberate pass from a stronger model. The reverse is also true: assigning a frontier model to locate a symbol, rename a field, or summarize test output spends scarce reasoning on routine operations.

Aggregate usage makes this inefficiency difficult to see. You receive a large bill, but you cannot tell whether premium tokens were spent resolving architectural ambiguity or repeatedly reading package.json.

That visibility gap is starting to close. The GitHub Changelog from August 11, 2026 documents per model token breakdowns in usage reports, allowing organizations to attribute consumption to individual models rather than only aggregate credits. Once model consumption becomes attributable, an all purpose model policy becomes measurable rather than merely convenient.

Route Decisions, Not Prompts

LLM model routing means selecting a model and reasoning level for each stage of a workflow instead of selecting one model for the entire agent. The useful routing unit is not the user’s initial prompt. It is the decision the agent is currently making.

Consider a request to add pagination to an API endpoint. The workflow contains several different kinds of work:

Stage	Typical risk	Suggested tier
Locate handlers, schemas, and tests	Low	Fast search model
Identify compatibility constraints	High	Frontier planning model
Implement a bounded patch	Medium	General coding model
Run tests and classify failures	Low to medium	Tooling plus fast model
Review authorization and API behavior	High	Frontier review model

The frontier model is valuable at two narrow points. It can create a plan when the task has architectural ambiguity, and it can review a completed patch when an error would have serious consequences. It does not need to perform every file read or narrate every test command.

This resembles workload placement in infrastructure. You would not schedule every Kubernetes pod on your largest node simply because that node is the most capable. You match resources to workload requirements, preserve expensive capacity for demanding jobs, and escalate when the cheaper path cannot meet the service objective.

Reasoning intensity belongs in the same control plane. According to the GitHub Changelog from August 3, 2026, Copilot cloud agent users can select reasoning intensity, with deeper reasoning consuming additional tokens and credits. That turns reasoning depth into an explicit economic choice.

The key metric should be cost per accepted change, not cost per token or cost per agent session. A cheap session that produces no mergeable work has little value. A costly session can be justified when it safely completes a difficult migration that your team accepts.

For your first version, define the metric as:

cost_per_accepted_change =
  (model_cost + orchestration_cost + human_review_cost)
  / accepted_changes

You decide what “accepted” means. A practical definition might require the change to pass CI, receive human approval, merge, and avoid rollback for seven days. The exact window matters less than applying one definition consistently.

Build the Routing Loop

Step 1: Classify the Work

Start with a small task taxonomy. Avoid routing from vague labels such as “easy” or “hard” because two engineers will interpret them differently.

Use observable characteristics instead:

1. How many subsystems can the change affect?
2. Does it touch authentication, authorization, payments, data deletion, or migrations?
3. Is the requested behavior specified clearly?
4. Can deterministic tests validate the result?
5. Has a lower tier already failed?

These questions produce a risk class that your gateway can evaluate. Repository search might default to low risk, while an authorization change should enter a higher review tier even if the patch is only five lines.

Step 2: Assign Stage Policies

Write the first routing policy as configuration so teams can inspect and revise it. Do not bury coding agent model selection inside individual prompts.

routes:
  search:
    model: fast
    reasoning: low

  plan:
    model: general
    reasoning: medium
    escalate_when:
      ambiguity_score: 0.6
      affected_subsystems: 3

  implement:
    model: general
    reasoning: medium
    max_attempts: 2

  test_triage:
    model: fast
    reasoning: low

  security_review:
    model: frontier
    reasoning: high

  final_review:
    model: general
    reasoning: medium
    escalate_when:
      risk: high
      lower_tier_failed: true

The model names should resolve through your gateway rather than appear throughout agent code. That lets you replace a provider or test a new model without rewriting the workflow.

Place limits beside routes. max_attempts, context budgets, and escalation conditions prevent a low cost model from silently becoming expensive through repetition.

Step 3: Capture a Trace

Record one trace for every agent task. At minimum, capture the task identifier, workflow stage, selected model, reasoning level, input and output tokens, tool calls, retries, elapsed time, and final outcome.

Connect that trace to delivery data. You need to know whether the patch was rejected, revised by a human, merged, reverted, or followed by a defect. Without an outcome, you are measuring consumption rather than value.

Human review time also belongs in the record. If a cheaper model saves one dollar but requires twenty additional minutes of inspection, the routing decision probably moved cost rather than reduced it.

Step 4: Run a Controlled Canary

Choose one narrow class of work, such as dependency updates or isolated test fixes. Route a portion through the new policy while leaving the rest on your current default model.

Compare both groups using:

• Cost per accepted change
• Acceptance rate
• Human review minutes
• Retry count
• Time to merge
• Rollback or follow up rate

Do not optimize only for the lowest bill. Your goal is the least expensive route that maintains your quality threshold.

Step 5: Escalate With Evidence

An escalation should carry forward the lower tier’s useful work. Include the files found, tests run, attempted patches, error messages, and the exact reason for escalation.

This prevents the frontier model from restarting discovery and paying again for context you already purchased. It also gives you diagnostic data. If the same route escalates repeatedly, you can adjust its default tier or improve its tools.

Review the policy on a regular cadence. Model quality, prices, context behavior, and tool integrations will change, so static routing rules will eventually become stale.

Routing Traps Cost More

The first trap is using task size as a proxy for risk. A one line permission change can be more dangerous than a hundred line internal refactor. Route according to consequence, ambiguity, and validation strength rather than lines changed.

The second trap is allowing unlimited cheap retries. A fast model that loops six times is not a cheap route. Set a retry budget, then escalate with the accumulated trace instead of letting the agent continue indefinitely.

The third trap is treating frontier review as ceremonial. If the premium reviewer receives an enormous transcript instead of a focused diff, requirements, and test evidence, you spend extra tokens without creating a sharper decision. Give the reviewer the smallest complete evidence package and ask for a specific verdict.

Make Routing Adaptive

Once your basic policy is stable, move from fixed stage rules to outcome informed routing. You can estimate task risk from repository ownership, changed paths, historical review effort, test coverage, and previous escalation patterns, then propose a tier before the agent starts.

You can also introduce model gateways that enforce budgets, redact sensitive context, cache repeated reads, and compare providers behind a common interface. Keep human overrides available and log them. An engineer who repeatedly upgrades one task class may be identifying a routing flaw before your aggregate metrics expose it.

Keep the Giant Resting

That surprising usage report was not evidence that coding agents are inherently uneconomical. It was evidence that one oversized model had been assigned every job in the workflow.

Your strongest model should handle the decisions where additional reasoning changes the outcome, especially ambiguous planning and consequential review. Everything else should use the least expensive tier that can meet a defined quality bar. When you measure cost per accepted change instead of cost per token, an idle frontier model stops looking wasteful and starts looking like a well managed resource.