How do you reduce coding agent cost without lowering quality?

Start with the completed task

A cheap model call can still produce an expensive task when the agent needs extra turns to recover missing context, repeats a command, or sends a weak result to a reviewer. Track total input and output tokens, tool calls, elapsed time, retries, failed runs, and review minutes until the task is accepted.

GitHub's September 2 engineering report [1] says Copilot evaluates efficiency at the task level. Its team tested harness changes offline and then in controlled online experiments before release.

Use a stable set of repository tasks that represents your actual mix, such as bug fixes, tests, documentation, migrations, and investigation. Report results by task family because an average can hide an expensive or unsafe slice.

Remove model turns that do not need reasoning

Look for places where orchestration asks the model to fetch a result the harness already received, poll completed work, reformat structured data, or repeat an unchanged search. Return completed background results with the notification and batch results that finish together.

Use deterministic code for parsing status, counting failures, selecting a known file range, and checking whether a command succeeded. Keep the model for work that needs judgment, synthesis, or an ambiguous next action.

Measure the retry and recovery rate after each removal. A deleted turn saves nothing when later calls must reconstruct its missing information.

Compress tool output by content type

Source code, diffs, exact error messages, and user text may require lossless handling. Repetitive install logs, progress bars, and repeated test successes can usually be summarized when the full output remains available through a file or tool reference.

Classify output before compression. Keep arbitrary source text unchanged, reorganize search results without dropping matches, and compress only predictable repetition. Include exit status, failing test names, the first useful error, and a path to the complete log.

Test whether agents request the full result and whether compressed runs produce more wrong edits, repeated commands, or reviewer corrections.

Keep stable context early and changing context late

OpenAI's prompt-caching guide [3] explains that cache reuse depends on a matching rendered prefix. Put stable instructions and tool definitions first, then place task-specific files, user messages, and changing state later.

Anthropic's context-engineering guide [2] treats context as a finite resource that includes instructions, tools, external data, and message history. Give the model the smallest high-signal state that still supports the next decision.

Do not remove repository rules, acceptance criteria, security boundaries, or failing evidence just to improve a cache metric. A higher cache-hit rate matters only when accepted task cost falls without a quality regression.

Run a matched cost experiment

• Choose 20 to 50 representative tasks with fixed starting commits and acceptance checks.
• Run the current harness several times to measure normal variation.
• Change one layer, such as completion delivery, log compression, prompt wording, or prefix order.
• Compare accepted-task rate, tokens, latency, retries, review time, test results, and escaped defects.
• Inspect every regression instead of approving a lower average cost alone.
• Canary the change on bounded production work and keep a rollback path.

Common cost cuts that backfire

• Hard output caps can truncate the diagnosis or omit the evidence a reviewer needs.
• Aggressive history deletion can make an agent repeat exploration and forget constraints.
• Cheaper models can require more retries or human repair on tasks outside their strength.
• Summaries without links to full logs prevent recovery when the summary misses the relevant line.
• One public benchmark cannot represent your repository, tools, permissions, or review standard.
• Token cost alone omits latency, infrastructure, failed attempts, and reviewer time.

Frequently asked questions

• Should I shorten every tool response? No. Preserve exact source and evidence. Compress predictable repetition and retain a recovery path.
• Should I switch to a smaller model first? Usually no. Remove avoidable calls and noisy context, then compare models on the same accepted-task measure.
• Does prompt caching reduce output cost? It reduces repeated input processing for eligible matching prefixes. The model must still process new input and generate the answer.
• What is the best single metric? Use cost per accepted task, then inspect quality, latency, retries, and review effort beside it.
• How often should I rerun the test? Run it for any model, prompt, tool, context, compression, or orchestration change that can alter behavior.