Coding Agent Token Cost Optimization 2026: Where the 70x Gap Comes From

Two August 2026 benchmarks put coding agent bills under the microscope: running the same model on the same tasks, Aider burned roughly 3,500 tokens per solved task while OpenClaw burned 292,000 — a 70x gap. In Composio's enterprise workflow test, cost per success ranged from $0.028 for Pi Agent to $0.195 for Claude Code, and DeepAgents matched Claude Code's pass rate at a quarter of the cost. The problem isn't the model; it's the harness. This post breaks down where the cost actually comes from and ships runnable optimization code.

1. Let the Data Speak First: Where the 70x Gap Comes From

The June benchmark ran 12 harness configurations on the same 12 Python tasks, all through OpenRouter so the model and API were identical. That setup matters: when the model is held constant, any difference in token consumption has to come from the software wrapping it. Tokens per solved task ranged from roughly 3,500 (Aider architect mode) to 292,000 (OpenClaw), and the ordering barely moved when the model changed — pointing squarely at harness software rather than model behavior. In August, Composio ran eight harnesses across 30 enterprise workflows (Airtable, Gmail, Google Calendar, Google Sheets, GitHub, Slack, PostHog) with a programmatic verifier instead of an LLM judge, seeded with decoys and near-identical keys to make cheating impossible. Of 240 runs, 129 workflows completed successfully under a 900-second ceiling. Cost per successful task ranged from $0.028 (Pi Agent) to $0.195 (Claude Code), and DeepAgents matched Claude Code's pass rate exactly while costing a quarter as much per success. The caveats were disclosed honestly — Pi ran a different reasoning setting across two providers, and Prime Agent produced only 24 gradable runs out of 30 — so this is not a clean single-variable experiment. But the direction is consistent across every measurement: harness design moves the bill more than model choice does.

// The measurement that started it all: run the same model
// through different harnesses and count tokens per solved task.
// June 2026 benchmark — 12 configs, 2 models, 12 Python tasks,
// all through OpenRouter so the model and API were identical.

import { countTokens } from "./token-counter";

const harnesses = ["aider", "claude-code", "codex", "goose",
  "hermes", "kilo", "kimi-code", "nanobot", "openclaw",
  "opencode", "qwen-code"];

for (const h of harnesses) {
  const result = await runSuite(h, {
    model: "deepseek-v4-flash",
    tasks: PYTHON_TASKS,
  });
  console.log(h, {
    tokensPerSolved: Math.round(result.tokens / result.solved),
    passRate: result.solved / result.total,
  });
}

// Output (tokens per solved task):
// aider (architect mode): ~3,500
// openclaw:             ~292,000  <- 70x gap, same model!

2. The Startup Tax: Fixed Costs You Pay on Every Turn

At the core of the spread is a single measurement: the startup tax. Before a prompt does any work, the harness ships its own baggage — the system prompt, the tool descriptions, and the environment setup. The benchmark reported around 700 tokens for Aider in architect mode, versus around 26,000 for OpenClaw. A 40x overhead would be tolerable if it were paid once, but the resend pattern makes it otherwise: a harness carrying a 26,000-token floor through fifteen turns spends roughly 390,000 input tokens on scaffolding alone, before the model writes a single line of code. The math checks out under testing: startup tax multiplied by turn count predicts tokens per solved task with an R-squared of 0.99 across both models. That single regression is the most actionable number in the entire debate, because it tells you exactly where to cut: the prompt floor and the turn count. Everything else — caching layers, model swaps, fancy batching — is secondary until those two numbers are under control.

// The startup tax: before a prompt does any work, the harness
// ships its own baggage — system prompt + tool descriptions +
// environment setup. This floor is paid on EVERY turn.

export function measureStartupTax(harness: Harness): number {
  const baseline = harness.tokenize(
    harness.systemPrompt + harness.toolDescriptions.join("")
  );
  // aider architect mode:  ~700 tokens
  // openclaw:             ~26,000 tokens
  return baseline;
}

// Why it compounds: the resend pattern. A 26,000-token floor
// through 15 turns = ~390,000 input tokens on scaffolding alone,
// before the model writes a single line of code.
const floor = 26000;
const turns = 15;
console.log(floor * turns); // 390,000

3. Why DeepAgents Matches Claude Code at a Quarter of the Cost

Composio's comparison is compelling: DeepAgents and Claude Code both hit a 54% pass rate, but cost per success was $0.049 versus $0.195. Same tasks, same programmatic verifier, same isolated fixtures — the difference can only come from prompt design, tool scheduling, and context management. DeepAgents apparently sends leaner tool schemas and tighter system prompts, and it plans turns more economically, so it reaches the same outcome with fewer wasted round trips. This is the practical lesson of the whole benchmark wave: the lever is the harness, not the model. If you are paying frontier prices for every task, you are almost certainly overpaying for the harness's inefficiency. Compress the prompt floor and the bill drops off a cliff. The ordering between harnesses stayed stable across two unrelated models, which means the inefficiency is structural, not a fluke of one model's tokenizer — you can fix it once and keep the savings.

// Composio's August benchmark: 8 harnesses, 30 enterprise
// workflows (Airtable, Gmail, Calendar, Sheets, GitHub, Slack,
// PostHog). 900-second ceiling, programmatic verifier, decoys.

const results = [
  { harness: "pi-agent", costPerSuccess: 0.028, passRate: 0.43 },
  { harness: "deepagents", costPerSuccess: 0.049, passRate: 0.54 },
  { harness: "claude-code", costPerSuccess: 0.195, passRate: 0.54 },
  // DeepAgents matched Claude Code's pass rate exactly
  // while costing a quarter as much per success.
];

// The optimization lever is not the model — it's the harness.
// The same pass rate at 1/4 the cost means the bottleneck is
// prompt engineering of the harness, not model quality.

4. A Predictive Model with R² = 0.99

The most actionable finding is the regression: startup tax multiplied by turn count predicts tokens per solved task with R² = 0.99, and the relationship holds across both models. That means you do not need a PhD in tokenomics to forecast your agent bill. Measure the harness's baseline prompt length, multiply by the average number of turns per task on your workload, and you have a reliable estimate before you run anything. It also means the optimization order is fixed: shrink the floor first (trim tool descriptions to the minimum viable schema, drop rarely-used tools from the active set), then reduce turns (add a planning step, fix the failure modes that cause retries), and only then consider model swapping or prompt caching. Teams that skip straight to caching often find the savings disappoint because they never addressed the 26,000-token elephant in the room. Measure first, then trim — the regression tells you which lever actually moves your number.

// The predictive model: startup tax × turn count explains
// tokens per solved task with R² = 0.99 across BOTH models.
// That is the actionable insight.

export function predictTokensPerTask(harness: Harness, model: Model) {
  const startupTax = measureStartupTax(harness);
  const avgTurns = harness.avgTurnsPerTask(model);
  return startupTax * avgTurns;
}

// Optimization playbook, in priority order:
// 1. Shrink the prompt floor (system prompt, tool schemas)
// 2. Reduce turn count (better planning, fewer retries)
// 3. Only then consider model swapping / caching
export const playbook = [
  "trim tool descriptions to the minimum viable schema",
  "remove rarely-used tools from the active toolset",
  "add a planning step to cut failed-attempt turns",
  "enable prompt caching for the stable prefix",
];

5. The Optimization Playbook

In priority order: trim tool descriptions to the minimum viable schema and drop rarely used tools; add a planning step to cut retry turns; only then consider prompt caching. Concretely, audit your system prompt and delete every sentence that does not change behavior — boilerplate like 'you are a helpful assistant' still costs tokens on every turn. Consolidate rarely-used tools behind a dispatcher so their schemas do not ship into the context window by default. Add a lightweight planner that decomposes the task before execution, which measurably reduces the failed-attempt turns that dominate token spend. Track the two numbers (floor and turns) in CI so regressions get caught the day they land. The prompt floor times the turn count is the skeleton of your bill; everything else is garnish.

6. Give Every Task a Budget

In production, cap tokens per task and fail fast instead of letting an agent burn money in a loop. A simple interval-based checker monitors current context tokens and terminates the run the moment the ceiling is hit. Combine that with a per-task spend budget and alerting, and you turn token cost from an unpredictable surprise into a bounded line item. Failing fast is far cheaper than letting the agent self-repair: a runaway loop at 292,000 tokens per task will bankrupt a credit budget before lunch. Start with the budget guard, then apply the playbook, then re-measure — the R²=0.99 model will show you the improvement immediately. Every token saved is profit.

// Practical harness-side budget guard: cap spend per task
// and fail fast instead of burning tokens on loops.

export async function runWithBudget(task: Task, budget: TokenBudget) {
  const start = countTokens(await systemPrompt(task));
  let used = start;
  const guard = setInterval(() => {
    used = countTokens(await currentContext());
    if (used > budget.max) {
      console.error("budget exceeded", used, ">", budget.max);
      process.exit(1);
    }
  }, 1000);
  try {
    return await runAgent(task);
  } finally {
    clearInterval(guard);
  }
}