True Cost per Coding Agent Task Across Harnesses and Models
Published token prices hide what coding agents actually cost per completed task.
When engineering teams shop for coding agents, they compare published token prices the way they'd compare gas prices at competing stations, but the number on the sign doesn't determine the bill. Claude Code, Codex, Cursor, and Opencode all charge for tokens, but the rate per million tokens tells a team almost nothing about what a given task will actually cost, because the rate is only one half of a multiplication problem. How many tokens a harness burns completing the task varies enormously between tools running the exact same underlying model on the exact same codebase. Making matters worse, every major tool now bills on some version of subscription-plus-usage-meter, so the pricing page shows the rate but says nothing about the volume a team will run through it. The unit that actually matters is cost per completed task, and that figure is set by two variables a price sheet never shows: how many loops the harness runs to get the job done, and how well it reuses cached context along the way.
Turning one task into many token-burning loops
A coding agent doesn't write a fix and stop. It reads files, traces how functions call each other, runs tests, reads the output of those tests, and then decides what to try next, often several times before the task is done. Each one of those steps is a round trip through the model, and each round trip resends some version of the accumulated conversation so far, whether that's the full history or a compacted summary of it. The harness, not the model, decides how this process is structured: what the model gets to see at each step, which tools it's allowed to call, and how the work carries forward from one turn to the next. Two harnesses pointed at the same model, working the same bug, can rack up very different token totals purely because of how they've built this loop.
Most of the cost in a coding session comes from finding the fix, not from writing it. It comes from finding it. Locating the right file, tracing a dependency chain, reading what a failing test actually printed: these navigation steps consume the bulk of the token budget before a single line of the actual patch gets written. Independent 2026 testing of one documented coding agent run found that 87% of token spend went to navigation, not to producing the fix itself. That number matters because it shows where the real cost lives, and it explains why loop count compounds the way it does. A plan-edit-verify cycle resends the growing context at every step, so three extra verification loops on a medium-sized task don't just add a fixed cost. They multiply the context size by the number of rounds run; a harness that loops more isn't marginally more expensive. It can be dramatically more expensive, even running the identical model as a leaner competitor.
Prompt caching and the cost equation when context is reused
But loop count alone still can't tell you the whole story: a harness that runs more loops isn't automatically the pricier one. Prompt caching changes the math in the opposite direction from what intuition suggests. A cached input token on Claude Sonnet bills at a fraction of the base input rate, so a session that keeps its prefix stable and reuses it across turns actually gets cheaper per token the longer it runs. That's the inverse of the naive model most teams use when they estimate cost as tokens multiplied by a flat rate.
The harness must be built to produce cache hits for caching to pay off. A harness that reshuffles its prompt structure on every loop, or that lets the prefix shift based on whatever a tool call happened to return, will see far fewer cache hits even when the underlying code hasn't changed at all between calls. That architectural detail means two harnesses can run through the same volume of tokens and land on very different real costs. One might run more loops than its competitor but cache aggressively enough to come out cheaper overall, while the other runs fewer loops but starts cold each time and pays the full base rate on every one. Loop count and cache hit rate interact, and neither variable predicts true cost on its own. A team that optimizes for fewer loops while ignoring cache architecture, or that assumes a high cache hit rate automatically means a cheap task regardless of how many rounds it took to get there, will end up routing work to the wrong tool.
Per-task costs for Claude Code, Codex, Cursor, and Opencode on identical work
The gap between harnesses on identical work is large enough that you can no longer use model tier to predict final cost. Independent testing at the frontier tier found Claude Code's harness consuming roughly seventy percent more tokens than Codex to reach the same result on equivalent work, even when the two were running models priced similarly per token. That gap appears directly in the invoice because the harness wrapped around the model takes a more token-hungry path to the answer, not because one model costs more per token than the other.
Cache behavior inside Claude Code swings cost even more than that. Morph's cost analysis found Claude Code's per-task cost spanning a wide range depending on cache hit rate: an uncached, heavy task runs materially more expensive than the identical task completed with a high cache hit rate. That spread shows caching, not model selection, as the variable doing the real work inside this particular harness. Claude Code's design loads native auto memory carrying Claude's accumulated learnings at the start of each session, alongside a CLAUDE.md file that loads project context and instructions up front. That front-loading adds cost at the start of a session, but when that early context gets cached, it lowers the marginal cost of every loop that follows. Claude Managed Agents, which entered public beta on April 8, 2026, layers a session-hour infrastructure charge on top of standard token billing, a detail that matters specifically for long-horizon tasks that run for extended stretches.
Codex takes a different initialization approach. It assembles an AGENTS.md chain before doing any work and keeps its local memory store in a separate location from that chain. That structural choice shapes what the harness ends up caching and what it has to reread fresh on every loop, and it's a meaningfully different design than Claude Code's combined memory-and-instructions load.
Cursor's profile is shaped by where it lives. Built into the editor, it can also run headless through the Cursor Agent CLI and supports running agents in parallel through Cloud Agents. That combination makes it workable as a background-agent harness for team-wide delegation, not just as an interactive pair-programming tool.
Opencode changes the comparison entirely because it isn't tied to one model provider. A team can point the same Opencode harness at a cheaper model for routine work and a frontier model for the hard problems, without switching tools or retraining anyone on a new interface. In one harness comparison, Opencode passed the majority of its tasks at a per-success cost that came in materially below Claude Code's on the same set of tasks, though with a somewhat lower pass rate. That result shows model-agnostic routing driven by cost is a workable strategy, even on tasks where quality is also a concern. Opencode's cost is entirely a function of whichever model sits underneath it, with no separate harness surcharge layered on top, so its loop count and cache hit rate shift depending on which model and provider it's pointed at for a given job. Teams need to actually watch their own runs to know what that profile looks like on their own codebase, rather than assuming a number carries over from someone else's workload.
Platforms like Replicas, which run multiple harnesses in isolated VMs with a choice of agent per task, can observe these cost differences directly: triggering the identical task across Claude Code, Codex, Cursor, and Opencode from one workflow shows which harness actually burns fewer tokens on a team's real codebase, rather than leaning on a published rate card or someone else's benchmark.
Subscription tiers hide the loop-count problem rather than solve it
A team on a capped subscription doesn't see a billing spike when a harness runs extra loops on a task. It hits a rate limit instead, and that cap arrives sooner than expected when the harness underneath it is burning tokens inefficiently. The underlying cause is identical either way: a harness running more rounds than the task required.
A Max subscriber paying for full usage pays $200 a month for a volume of work that could cost several times that on API billing for the same total token count. The subscription functions as a ceiling, not a guarantee that the work underneath it is being done efficiently. A team that burns through that ceiling faster than another team is simply running a less efficient harness and not seeing the cost on a line item, because the cap absorbs it as reduced throughput instead.
If a team bills through the API, which is the model most relevant to cloud agent orchestration set up around something like Replicas, loop count and cache hit rate translate straight into dollars spent per task. That makes harness routing a financial decision with a number attached to it, not a matter of preference between tools that otherwise feel interchangeable.
Routing tasks to the right harness given what you now know about loop cost
Once a team accepts that cost per task is set by loop count and cache hit rate rather than by which model tier is listed on the invoice, the sensible move is to match task types to the harness whose architecture fits the work, rather than picking one tool for everything and absorbing whatever inefficiency that choice carries on the workloads it wasn't built for.
A few patterns follow from the harness profiles already described. If a session runs long on deep-context, multi-file architectural work and reuses the same context repeatedly within it, you want a harness built around aggressive prompt caching and persistent memory. Claude Code fits that description well, and its higher base token rate stops mattering much once cache hits are amortizing the cost of each additional loop. High-volume, parallel, disposable tasks, the kind where sessions are short and independent of one another, favor Codex's background-agent model, where per-task cost stays low and the infrastructure is built for running many of these at once; that same design makes Codex less of a natural fit for the kind of large-repository deep dive where a long context surcharge starts to bite. Editor-integrated work, inline edits, bounded refactors where a developer stays in the loop the whole time, is where Cursor's cost profile holds up well: light tasks with few loops cost little per task, while heavy, fully autonomous loops get expensive relative to CLI-native harnesses built for exactly that kind of work. When the right model for the job isn't settled yet, cost-sensitive or experimental workloads favor Opencode's model-agnostic setup, because it lets a team gather real loop and cost data before locking into a particular harness-model pairing.
Understanding harness architecture turns into something actionable the moment a team can route different kinds of tasks to different agents. A cloud platform built around harness-agnostic delegation lets a team send file-tracing work to whichever agent minimizes context reads on its codebase, and send verification-heavy work to whichever one compacts context most efficiently, which turns loop-count awareness from an observation into an actual routing decision.
None of this works without per-task observability. A team can't route intelligently without attribution data showing which harness handled a task, which model sat underneath it, and how many loops it took to finish. Aggregate spend figures don't carry that information; a single total at the bottom of a monthly bill can't tell a team whether the spend came from one harness running ten loops on a hard problem or another harness running three loops on ten easy ones.
The environment an agent runs in also shapes how many of those loops actually matter. Agents working in isolated, fully configured environments can install packages, run services, and check their own work directly, which cuts down on the re-run loops that occur when an agent is instead operating in a misconfigured or shared environment where verification fails for reasons that have nothing to do with the actual code. Cache behavior is also easiest to track in practice when each task runs inside a persistent, fully configured environment: provisioning an isolated VM per task, preloaded with a team's dependencies and codebase, lets later runs inherit cached context from earlier work on that same repository. Cache hit rates across harnesses can then be measured on real work instead of estimated from a synthetic benchmark that may not resemble the team's actual codebase.
Measurements that keep harness routing accurate over time
Routing decisions made today won't hold indefinitely. Model updates, changes to harness architecture, and shifts in what kind of work a team is actually sending through these tools will all move the cost profile of each one, so the routing choices described above need to be checked against ongoing data.
Four numbers matter at the task level: cost per completed task rather than cost per token, loop count per session, cache hit rate per harness, and pass rate. Pass rate belongs on that list because a harness that looks cheap but completes fewer tasks successfully quietly shifts cost onto engineer review time, a cost that never appears on the AI billing statement. Evidence from engineering productivity research shows that when the volume of agent-generated pull requests rises, the time engineers spend reviewing those pull requests rises sharply along with it. Task cost, measured only against the AI bill, misses that downstream review burden entirely, and that burden is part of the real cost of shipping a feature, whether or not it ever appears on an invoice.
If teams track spending at the level of individual harnesses and individual models, rather than watching one aggregate AI spend number climb or fall, they can actually tell which routing decisions are paying off and which harnesses are burning through loops without improving what gets shipped. The operating model this points toward has background agents returning pull requests for a human to review and decide on, with full attribution recorded on every run: which harness ran it, which model sat underneath, how many loops it took, and what it cost. Replicas' own analytics track that attribution down to the source, the person, the harness, the model, the credential that paid for it, and the skills and MCP servers the agent reached for along the way. That level of detail is what lets an engineering team look at a task like the one it just routed and know, with evidence rather than a guess, which harness to point at the next one just like it.
