Why Coding Agents Fail When You Only Optimize for Token Costs

Coding agents fail when you treat them like simple text completion tools because token-based cost-cutting ignores the actual "work" being done. You aren't paying for tokens; you're paying for the resolution of a task, and if your harness wastes context or your model lacks the reasoning depth to hit the target in one shot, your bill will skyrocket regardless of how cheap the model is per million tokens.

Token costs are a vanity metric for engineering leaders

If you’re optimizing for token price, you’re looking at the wrong variable. A model that costs $2.00 per task but requires five retries and massive context injections is fundamentally more expensive than a "premium" model that nails the PR in one pass. We’ve seen teams obsess over switching to a cheaper model, only to watch their total latency and cumulative token usage climb because the cheaper model needed to read the entire codebase three times to understand a simple dependency injection.

True llm cost optimization requires measuring the "cost-per-resolved-ticket," not the "cost-per-token." If your agent is spinning its wheels because it can’t find the right React component or it’s hallucinating file paths in a massive monorepo, no amount of model-swapping will save your budget. You need to stop looking at the price tag and start looking at the success rate per interaction.

Harness-driven context is the real efficiency lever

The harness you use to wrap your agent matters more than the specific model under the hood. We’ve tested setups where the same model, when moved from a bloated, context-heavy harness to a lean, surgically precise one, performed the exact same task for less than half the cost. It’s not magic; it’s about what you feed the agent.

If your agent is forced to ingest the entire node_modules or thousands of lines of irrelevant boilerplate just to fix a CSS alignment issue, you’re paying for noise. You need a way to feed the agent exactly what it needs—the DOM context, the specific file path, and a screenshot of the UI—without dumping the entire world state. This is where tools like markagent change the game; by capturing the exact element context and structured prompt data, you eliminate the "context bloat" that makes agents burn through tokens and hallucinate solutions.

Model benchmarking must be local and task-specific

Public benchmarks like SWE-Bench are essentially useless for your internal codebase. They are contaminated by training data and fail to represent the specific architectural patterns—the proprietary gRPC calls, the legacy Scala services, or the custom Bazel build targets—that your team actually ships.

To achieve real ai engineering efficiency, you have to build your own benchmark using your own history. Take your last 50 merged PRs, strip out the solution, and use those as your test suite. If a model can’t solve your specific flavor of a TypeScript bug, it doesn’t matter if it’s top-tier on a public leaderboard. You need a data-driven feedback loop where you test new agents against your own "Ground Truth" before they ever hit your actual production environment.

Stop the "Git history" shortcut

Early experiments often show inflated performance because agents are "cheating." If your agent has access to a working Git environment and can simply git checkout the final version of a file or read the commit history, it’s not solving the problem—it’s just copying the answer.

When you run your model benchmarking, you must isolate the working directory. Seal the history. If the agent can't solve the task from the provided context and its own reasoning, it’s a failure. We’ve found that many agents look like geniuses until you cut off their access to the existing Git history, at which point their "reasoning" falls apart. True capability is measured by the agent’s ability to generate code from intent, not its ability to parse logs of code that already exists.

The case for a model-agnostic infrastructure

Vendor lock-in is the enemy of progress. If you build your entire agentic workflow around a single model’s specific prompt structure or proprietary harness, you’re dead in the water the moment a better, cheaper, or more capable model arrives.

Invest in an infrastructure that allows you to swap models as easily as you swap dependencies. Your agentic harness should be a thin layer that orchestrates the flow of data, not a heavy framework that dictates which model you have to use. By decoupling the task-capture layer—the part where you identify what needs to change—from the execution layer, you gain the freedom to route "easy" tasks to cheap models and "complex" architectural changes to the heavyweights.

Developer productivity isn't just about speed

Sometimes, the most efficient path is a human-in-the-loop moment. We often try to force agents to do 100% of the work, but the biggest gains in developer productivity happen when the agent acts as a force multiplier for a human engineer.

Instead of waiting ten minutes for an agent to struggle through a complex refactor, a developer can use a targeted tool to highlight the specific UI components and logic blocks that need attention. By providing the agent with the precise context it needs, you reduce the iteration cycle from an hour of trial-and-error to a five-minute verification. Focus on tools that help you communicate intent clearly, rather than tools that try to guess what you want by reading your entire file system.

Stop chasing the cheapest model and start optimizing the data you feed it. Build your own benchmarks, control your context, and stop letting the agent wander through your codebase blindly.