Agentic Coding: How Task Routing Cut My AI Coding Bill by 90%

Introduction

Large Language Models have made it possible to delegate real chunks of software engineering to automated agents — planning, implementing, testing, reviewing. Most people running these agents point every step at the same frontier model: one model plans the architecture, and the same model also renames variables and writes boilerplate tests. That's expensive, and it's wasteful, because not every step in a coding task needs frontier-level reasoning.

Agentic coding, in the sense I mean here, is the practice of routing each subtask to the cheapest model capable of doing it well — reserving expensive, high-reasoning models for architecture and judgment calls, and pushing execution work (edits, tests, log parsing) to smaller, far cheaper models. The orchestration layer, not the model, becomes the thing doing the "thinking" about cost.

This article is a case study from a real, production task: a change requiring over 687,000 tokens of context, developed through OpenCode, driven by a locally hosted Qwen Coder Next 80B as the orchestrating model, and routed through my own orchestrator (Astera) to open-weight execution models — DeepSeek V4 and Nemotron 3. Zero tokens went to Claude or any other frontier provider, anywhere in the loop — not for orchestration, not for execution. I'll walk through the setup, then compare the actual metered cost against what the identical task would have cost run exclusively on Claude Sonnet 5, as a baseline.

The short version: $0.205 vs. $2.41–$3.62, an 11.8×–17.6× cost difference. The full breakdown — and the exact pricing behind it — is below.

---

Agentic Architecture

A quick note on MCP, for anyone who hasn't run into it: the Model Context Protocol is an open standard for connecting an AI agent to external tools and data sources through one common interface, instead of every agent needing a bespoke integration for every tool. An agent that speaks MCP — Claude Code, OpenCode, and most current coding agents do — can call any MCP server's tools the same way, without either side needing to know anything special about the other. Astera is exactly that: an MCP server the orchestrating agent talks to.

The system used here (Astera MCP Orchestrator) is an MCP server written in Go that exposes four tools:

Tool	Description
plan_task	Read-only repository inspection + structured implementation plan generation by a "planner" model
implement_task	Precise code edit generation (old_string/new_string) by an "implementer" model; optional apply and test execution
review_changes	Code review of a diff or edit list by a "reviewer" model
summarize_logs	Log summarization (root-cause analysis) by a "summarizer" model

At the time of this benchmark, the server had no frontier-model provider wired in at all — every tool call routed to a locally configured, OpenAI-compatible model endpoint. (That has since changed: a newer routing tier, smart_prompt, can optionally cascade into Claude/Anthropic when a task calls for it — but nothing in the run described here touched it.) Astera itself is agent-agnostic: whatever sits outside it — Claude Code, OpenCode, or anything else that speaks MCP — is the orchestrating agent deciding which tool to call next and reviewing the results it gets back. For this benchmark, that outer agent was local too — see the next section.

Model-to-role assignment (from config.yaml)

Role	Provider	Model	Responsibility
Planner	openrouter-nemotron-ultra	nvidia/nemotron-3-ultra-550b-a55b:free	Architectural planning, design decisions, task decomposition
Implementer	openrouter-nemotron-super	nvidia/nemotron-3-super-120b-a12b:free	Code generation, file edits, boilerplate, tests
Reviewer	deepseek-flash	deepseek-v4-flash	Fast, cheap code review — correctness, style, security checks
Summarizer	openrouter-nemotron-super	nvidia/nemotron-3-super-120b-a12b:free	Log summarization, root-cause analysis
Fallback	deepseek-pro	deepseek-v4-pro	Automatically retried, in-process, by Astera itself — no orchestrator involvement — whenever a role's primary model times out or its own response self-reports needs_frontier_review; for implement_task specifically, also when its edits fail validation or the test suite. Covers any role — planner, implementer, reviewer, or summarizer

The orchestrator drives the flow plan → implement → review → (optionally) summarize, keeping local-model token costs entirely separate from — and, as the numbers below show, entirely eclipsing — frontier-model tokens.

---

The Orchestrating Agent: Local, Too

Astera's harness normally assumes a frontier coding agent — Claude Code, for instance — sits above it, driving the four MCP tools while handling planning judgment and escalation decisions itself. For this benchmark, I pushed that a step further: the orchestrating agent was also fully local.

Development ran through OpenCode, with Qwen Coder Next 80B — hosted locally — as the orchestrating model. That model was the one deciding when to call plan_task, when to hand off to implement_task, and how to interpret the results — the role the workflow below describes generically as "the orchestrating agent." No frontier API touched any part of the loop: not planning, not implementation, not orchestration.

Hardware:

Component	Spec
CPU	AMD Ryzen 9 9900X3D
RAM	128 GB
GPU	2× Intel Arc Pro B70, 32 GB each (64 GB VRAM total)
Inference backend	llama.cpp, SYCL backend
Throughput	~70 tokens/sec generation

Why Qwen Coder Next 80B specifically? Two reasons: tool-calling reliability, and speed on the hardware available. Not every open-weight model is a clean fit for driving an agentic loop — some are noticeably less reliable at emitting well-formed tool calls, which matters far more here than in a single Q&A turn, since this model is deciding which of four MCP tools to call, in what order, dozens of times over the course of one task. Qwen Coder Next 80B handles that cleanly. And at ~70 tokens/sec on this hardware, it's fast enough that the day-to-day experience feels comparable to running Claude Code against Anthropic's own models — the orchestrator never feels like the bottleneck.

If you have less VRAM to work with, a smaller Qwen model is a reasonable substitute for this specific role. That substitution works because the orchestrator's job is comparatively light — deciding which tool to call next and interpreting the results, not writing the code itself. Worth being explicit about this: the models actually doing the reasoning and execution inside Astera — DeepSeek V4 and Nemotron 3 Ultra/Super — are higher-quality models than Qwen Coder Next 80B. Qwen only orchestrates; it isn't the thing writing your code.

That's worth underlining: the $0.205 figure isn't just "execution was cheap" — it's the metered cost of the entire development loop, orchestration included, on hardware that fits under a desk. The Claude Sonnet 5 numbers later in this article are a hypothetical baseline: what the same task would have cost if a frontier model had been doing all of it — orchestration and execution alike — instead of a local 80B model running at 70 t/s.

---

Developer Workflow Procedure (Harness)

The working rule for the orchestrating agent — whichever model fills that role — is simple: don't write code by hand, call the tools. This is the general procedure the harness enforces; in this run, it was Qwen Coder Next 80B following it, not Claude.

1. Planning — plan_task. Used when the architecture is unknown, multiple strategies exist, or exploration is required. Returns a plan, relevant_files, and a handoff_prompt_for_coder.
2. Implementation — implement_task. Takes the plan plus a mandatory allowed_files list. Generates edits, optionally applies them, and runs tests. Retries (up to 3) are effectively free — absorbed by Astera and the local model, never billed to a frontier model.
3. Review — review_changes. Local review runs first. Only if the verdict is approve with high confidence and low risk does the procedure call for a lightweight frontier sanity check; a full frontier review is reserved for high-risk changes, low-confidence verdicts, needs_frontier_review, architectural changes, security-sensitive code, or an explicit request. In this particular run, that escalation was never triggered — the local orchestrator handled every step itself.
4. Summary — summarize_logs. Used only when working with logs — debugging, failure analysis. Returns a concise summary plus total_token_usage, an aggregate of local-model cost.

The guiding principle: minimize frontier-model tokens by delegating to Astera whenever it's cheaper — and avoid manual coding, manual full-diff reading, and repetitive repo scanning, all of which quietly burn context for no reason. Here, that principle was taken to its limit: frontier usage wasn't just minimized, it was zero.

---

Actual Token Usage

The table below is real telemetry from the completed task, broken out by model and role:

Role	Model	Input tokens	Output tokens	Total tokens
Reviewer	DeepSeek V4 Flash	277,270	92,257	369,527
Fallback (all roles)	DeepSeek V4 Pro	143,241	25,768	169,009
Planner	Nemotron 3 Ultra 550B	125,758	5,491	131,249
Implementer / Summarizer	Nemotron 3 Super 120B	11,906	5,874	17,780
Total		558,175	129,390	687,565

Total tokens (687,565) run higher than the task's ~600K raw context because the agent cyclically re-reads its own outputs and project state — normal for an iterative process. DeepSeek V4 Flash handled review, Nemotron 3 Ultra did the planning, and Nemotron 3 Super handled routine implementation and summarization. DeepSeek V4 Pro is Astera's fallback model — it isn't tied to a specific role, it steps in for whichever role's assigned provider went unreachable or whose model couldn't finish the task. That it logged 169,009 tokens (24.6% of the total) is itself a useful data point: primary-model failures weren't rare on this run, but the fallback absorbed every one of them for under $0.09 rather than stalling the task.

---

What This Actually Cost

This is the part that matters, and it comes straight from the orchestrator's metered usage — not an estimate. Below is the real per-model pricing and spend for the run above, alongside what the same 687,565 tokens would have cost on Claude Sonnet 5, at both its current introductory price and the standard price it reverts to shortly.

Astera — actual per-model cost

Model	Role	Input tokens	Output tokens	Price ($/1M in / out)	Cost
DeepSeek V4 Flash	Reviewer	277,270	92,257	$0.09 / $0.18	$0.0416
DeepSeek V4 Pro	Fallback (all roles)	143,241	25,768	$0.435 / $0.87	$0.0847
Nemotron 3 Ultra 550B	Planner	125,758	5,491	$0.50 / $2.20	$0.0750
Nemotron 3 Super 120B	Implementer / Summarizer	11,906	5,874	$0.09 / $0.45	$0.0037
Total		558,175	129,390	—	$0.2050

DeepSeek V4 Flash accounted for over half the tokens (53.8%) but, thanks to its price, only about a fifth of the spend — it's the review workhorse. Nemotron Ultra, the most expensive per-token model in the stack, was deliberately used sparingly: 19.1% of tokens, reserved for planning only. And the fallback model, DeepSeek V4 Pro, was busier than you might expect for a safety net — 24.6% of tokens — but even fully priced at its higher per-token rate, it added less than $0.09 to the total.

The same 687,565 tokens on Claude Sonnet 5

Claude Sonnet 5 is currently priced at an introductory $2/$10 per million input/output tokens — a rate that holds through August 31, 2026, after which it reverts to the standard $3/$15. That deadline is close enough to be worth pricing both ways:

Pricing	Input cost	Output cost	Total
Introductory ($2 / $10 per 1M, through 2026-08-31)	$1.1164	$1.2939	$2.4103
Standard ($3 / $15 per 1M, from 2026-09-01)	$1.6745	$1.9409	$3.6154

Savings

Comparison	Astera cost	Claude cost	You save	Reduction
vs. Sonnet 5, introductory pricing	$0.205	$2.410	$2.205	91.5%
vs. Sonnet 5, standard pricing	$0.205	$3.615	$3.410	94.3%

Astera completed the task for $0.205 — 11.8× cheaper than Sonnet 5 at today's introductory price, and 17.6× cheaper once standard pricing kicks in. That second number is the one worth sitting with: as frontier pricing normalizes upward, the case for routing execution work to smaller models only gets stronger, not weaker.

And this was achieved with comparable or better code quality, by design:

• reasoning-heavy work (architecture, planning) is dedicated to a stronger model, Nemotron Ultra, used only where it's needed,
• execution work (edits, review, summarization) is pushed to cheaper models — DeepSeek Flash, Nemotron Super — that are more than capable of it,
• a dedicated fallback model, DeepSeek V4 Pro, catches provider outages and unfinished tasks for any role without stalling the run or needing a human to intervene,
• orchestration itself ran on a local 80B model via OpenCode, with the harness's deeper-reasoning escalation path — handled by whichever model is orchestrating, Claude or otherwise — sitting there as a safety net that this run never needed to use.

---

Benefits Beyond Cost

Aspect	Sonnet 5 only	Agentic coding
Availability	An Anthropic API outage stops Claude Code cold — one provider, one point of failure	Astera always has a fallback to fall back on; hosting it with a different provider than the primary models means one provider's outage doesn't take the whole pipeline down
Scalability	Context-limited	Practically unlimited
Fault tolerance	Single point of failure	Errors isolated to subtasks
Code quality	Uniform but generic	Tuned per layer (architecture vs. implementation)
Auditability	Difficult	Full decision history per agent

---

Conclusions

1. Agentic coding isn't just cost savings — it's a paradigm shift. From "one model for everything" to "the right model for the right task."
2. A real 90%+ cost reduction on complex engineering work is achievable today, with no GPU infrastructure investment — the routing layer is the entire innovation.
3. The key ingredient is an orchestrator capable of decomposing tasks, assessing subtask complexity, and dynamically selecting models from the available pool.
4. The gap will widen, not narrow. As introductory frontier pricing rolls off — Sonnet 5's own promotional rate ends August 31, 2026 — the cost of not routing execution work to cheaper models keeps growing.

As enterprise demand for code generation at scale keeps growing, agentic coding stops being an optional efficiency trick and becomes an economic and quality necessity.

---

Article based on actual telemetry data from a production agentic coding system, developed via OpenCode with a locally hosted Qwen Coder Next 80B as the orchestrating model. Claude Sonnet 5 pricing verified current as of August 2026.