# How I cut coding agent costs with model and harness routing > Source: > Published: 2026-09-08 16:00:57+00:00 *Author’s note: Model’s change, and by the time you’re reading this, you’ll probably be experimenting with the next one (like Astra or Fable 5.1). But the lessons in here are relevant regardless of what model you choose.* I am a software engineering intern on Arize’s experimentation team, so I spend a lot of time testing [coding-agent harnesses](https://arize.com/blog/what-is-an-agent-harness/) such as Claude Code, Codex, Cursor, OpenCode, Pi etc. I started these experiments with a practical question: how much useful engineering work can I get from the same AI budget? One of our recurring workflows was a daily Slack bot that searched for a critical bug and opened a pull request. Running Opus 5 from end to end cost about $100 per attempt. After I moved the main loop to Kimi K3 Max, delegated supporting work to lower-cost models, and kept Opus 5 available as an advisor, the same workflow cost about $15 to $20 per run. Although it is hard to measure the quality of findings compared to the previous method, we continued merging pull requests from it. That experiment made me more curious about [coding-agent economics](https://arize.com/blog/how-cheap-models-changed-multi-agent-economics/). A run contains several kinds of work, and each one places different demands on the model. Planning an unfamiliar change may require frontier-level judgment. Finding relevant files, summarizing test output, or making a straightforward edit may not. My current rule is to spend frontier tokens on judgment, then measure whether the complete workflow still produces an acceptable result. ## **Coding agent cost depends on the whole run** The starting equation is simple: ``` total model cost = per-token price × token usage ``` [Price tables only describe part of the bill](https://arize.com/blog/why-ai-token-costs-dont-tell-you-if-your-ai-is-working/). Input, cached-input, and output tokens may have different rates. Long contexts can enter another pricing tier. A single request may also trigger many model calls while the harness reads files, invokes tools, delegates work, retries failures, and reviews the result. [The harness matters](https://arize.com/resources/agent-harness-evaluation-tracing/) because it controls how the model is used. It decides how much repository context to send, whether tool output is summarized, how many subagents can run, when to retry, and when the task is complete. Composio ran [an evaluation on the same model across four harnesses on 30 agentic tasks](https://x.com/composio/status/2085330847951970801?s=20). The pass count ranged from 14 to 17, while cost per successful task varied by 2.7 times. I treat that as a directional result rather than a universal ranking, but it shows why model price alone is an incomplete comparison. The metric I care about is [cost per accepted task](https://arize.com/blog/cost-per-successful-task-ai-model-benchmark): ``` cost per accepted task = total cost of attempts, retries, reviews, and human validation ÷ number of tasks that meet the acceptance criteria ``` For a coding agent, acceptance might mean that the tests pass, the change matches the specification, and a reviewer is willing to merge the pull request. For a security workflow, it might mean that a human confirms the finding. ## **Two model-routing patterns that worked for me** A typical coding-agent run includes planning, repository exploration, implementation, verification, and review. Routing becomes useful when those stages have different reasoning requirements. ### **Pattern 1: Frontier orchestrator with lower-cost subagents** In this pattern, a frontier model owns the plan and coordinates the run. Lower-cost subagents handle token-heavy work such as locating files, inspecting code, summarizing existing behavior, and making routine changes. One version of this architecture used GPT-5.6 Sol as the orchestrator with Terra subagents. A simplified instruction looked like this: ``` Keep planning and architectural decisions in the parent agent. Delegate: - repository exploration - file discovery - summaries of existing behavior - straightforward implementation Review subagent output before producing the final patch. ``` This is a conceptual example rather than the exact production prompt. Delegation syntax and subagent behavior vary by harness. I use this approach when a weak initial plan would make all downstream work more expensive. The orchestrator receives the task, decides how to divide it, and evaluates the returned work. ### **Pattern 2: Lower-cost orchestrator with a frontier advisor** In the second pattern, a capable lower-cost model drives the main loop. A frontier model reviews plans, resolves uncertainty, or checks the proposed change at defined checkpoints. One implementation used Kimi K3 Max as the driver (5.6 Sol is a good contender for this task as well), GLM 5.2 Max, Composer 2.5, and 5.6 Terra for supporting work, and Opus 5 as the advisor. This works best when the workflow has a clear structure, the advisor can be called after the initial plan, after repeated test failures, before a high-risk architectural change, or before the pull request is opened. Giving the frontier model a narrow review task also reduces the context it needs. Reviewing a plan or patch usually costs less than independently exploring the codebase and implementing the entire change. ## **What happened in two real workflows** | **Workflow** | **Routed architecture** | **Result** | **Limitation** | |---|---|---|---| | Daily critical-bug-finder Slack bot | Kimi K3 Max drove the run, lower-cost models performed supporting work, and Opus 5 advised | Cost fell from about $100 to $15-$20 per run. The team continued merging some generated PRs. | We did not run repeated, matched trials that established equal recall, precision, or severity. | | Full-codebase security scan | Lower-cost orchestrator, roughly 50-60 subagents, and a frontier advisor | The scan cost about $100 and surfaced more than 20 candidate high-severity findings. Running it fully on Fable 5 was estimated at $1,000-$2,000. | The higher figure was an estimate, and every finding still required human validation. | The first result gave me confidence that the routing pattern was operationally useful. It did not give me enough evidence to claim that the cheaper system matched the frontier-only system on every quality dimension. The security scan has a similar limitation. A model-generated “high severity” label does not confirm a vulnerability. For that workflow, I would track cost per confirmed finding, false-positive rate, duplicate rate, agreement with a human reviewer on severity, and the time required to validate each issue. ## **Measure cost per accepted outcome** My early experiments measured cost better than quality because token counts are explicit while engineering quality has to be defined. A better comparison starts before the agent runs: 1. **Build a fixed task set.** Include routine tasks, ambiguous cases, and known failure modes from the real workflow. 2. **Define acceptance criteria.** Decide what counts as success before seeing the output. Examples include passing required tests, matching a written specification, receiving reviewer approval, or producing a confirmed security finding. 3. **Run each configuration several times.** Coding agents are non-deterministic, so one run can misrepresent both cost and quality. 4. [**Trace the whole harness**](https://arize.com/blog/open-source-coding-agent-tracing/)**.** Record the model used at each step, input and output tokens, cache usage, tool calls, retries, subagent count, latency, and final outcome. 5. **Compare accepted outcomes.** Include failed attempts, advisor calls, and human review in the final cost. For the bug-finding bot, cost per opened pull request is less useful than cost per merged pull request. The second metric connects spend to an outcome the engineering team valued. Tracing is especially important in a [multi-agent system](https://arize.com/resources/ai-agent-tracing-evaluation/) because the top-level request hides most of the work. A single run may contain repeated repository searches, overlapping branches, or expensive retries that are invisible in the aggregate bill. ## **Reduce context before paying for a stronger model** Routing produced the largest savings in my experiments, but unnecessary context also creates a significant bill. Test runners, Git commands, linters, Docker, and build systems can generate thousands of lines. The agent usually needs the failing assertion, the relevant stack trace, the changed files, and the command status. Progress indicators and repeated success messages rarely help with the next decision. Two tools address this: - [**RTK**](https://github.com/rtk-ai/rtk) filters and compresses command output before it reaches the agent context. The project reports reductions of roughly 60% to 90% for shell output, depending on the command and workflow. - [**Caveman**](https://caveman.so/) is a response-formatting skill for Claude Code and other coding agents that prompts the model to answer in terse, compressed prose while instructing it to leave code, commands, error strings, and symbols unchanged. It promises an average 65% reduction in output tokens across 10 example prompts. Those are project-reported numbers, so I would verify them on the tasks that matter to your team. The same principle can be applied directly in a harness. Request targeted file ranges, summarize successful test output, preserve complete failure details, deduplicate repeated stack traces, cap search results, reuse stable prompt prefixes where caching is available, and stop branches that repeat completed work. Reducing context can improve reasoning as well as cost because the relevant evidence becomes easier for the model to find. ## **A practical rollout for model routing** I would introduce routing one stage at a time: 1. Choose an expensive, repeatable workflow with a clear outcome. 2. Record the current cost, token use, retries, latency, acceptance rate, and human review time. 3. Separate planning, exploration, implementation, verification, and review. 4. Move one high-volume, lower-risk stage to a cheaper model while keeping the existing planner and reviewer. 5. Add escalation rules for repeated failures, conflicting evidence, security-sensitive decisions, or changes to high-risk systems. 6. Compare both configurations on the same task set before routing more work. [A lower-priced model can still create a more expensive run](https://arize.com/blog/how-to-reduce-llm-costs-without-sacrificing-quality/) when it consumes more tokens, retries frequently, or requires extensive repair. A strong benchmark score also cannot guarantee strong performance on a particular repository. [Security and data-handling policies](https://arize.com/blog/how-to-detect-credential-theft-in-ai-agent-harness-traces/) should constrain the model menu from the beginning. The advisor pattern also has limits because a reviewer can only evaluate the context it receives. Missing evidence or weak subagent summaries can still produce a bad decision. ## **Spend frontier tokens where judgment matters** The largest improvement came from treating the coding agent as a routed system. I now reserve frontier models for planning, ambiguous decisions, escalation, and final review. Lower-cost models handle much of the repository exploration, summarization, and routine implementation. Deterministic tools verify whatever they can. The model names will change quickly. That means the question I use to design the workflow has to, by necessity, be more durable: **which parts of this task require expensive judgment, and which parts mainly require tokens?** The routing policy only counts as an improvement when the completed task still passes the checks that mattered before.