Where the money goes in a CI agent run

CI5 min read

Before you cut a bill, find what is in it. We split the cost of CI agent runs, without Context Mode, by the part of the request that caused it. A third is the fixed prefix, a third is tool results and history, and a little over a third is the model's own writing. On short jobs, 65% to 78% of the money is cache writes. One price rule explains why: a cache write costs far more than a cache read.

TL;DR

The split

We took direct runs of CI jobs (an agent, a model, no Context Mode) and priced every token the provider reported. Then we grouped the cost by where the tokens came from. This is the mean over the areas we ran.

Part of the requestShare of cost
Fixed prefix: tools, system text, skill and agent lists33%
Tool results and history33%
Thinking7%
Answer and tool-call text27%

Per-area splits, with the tool mix beside them, are in the lab notes: night round notes.

Two parts are out of reach for any proxy: the answer and the thinking, 34% together. The other two parts, 66%, are what the request carries. That is where a saving can come from.

Short jobs are mostly cache writes

A review or a triage job makes two or three requests. The prompt is large, the work is small. Almost all of the cost is the first write of the prompt to cache. On those short jobs, cache writes are 65% to 78% of the bill.

That is a useful fact. It tells you to attack the write, not the read.

The prices

List prices in USD per million tokens, from the provider's price page (read 2026-10-31):

ModelInput5m write1h writeReadOutput
Sonnet 5.5$2$2.50$4$0.10$10
Opus 5.5$4$5$8$0.20$20

Look at the write and read columns. A one-hour write on Sonnet 5.5 costs $4. A read costs $0.10.

The 20-to-1 rule

Count in units of the plain input price. At the one-hour setting that Claude Code uses, our cost model bills a write at 2.0 units and a read at 0.1 unit. That is 20 to 1. On Sonnet 5.5 the read is cheaper still, so the gap is wider.

The rule has a sharp edge. Say you remove n tokens from a cached prefix of P tokens, and the next turn would have been a cache hit. You do not save 0.1 per removed token. Any change inside the prefix breaks the cache from that point on, so the turn writes the rest again at 2.0 instead of reading it at 0.1. That costs about 1.9 units per token of P. Each later turn then saves 0.1 per removed token. You break even only when

n x later turns > 19 x P

For a 10,000-token prefix, you must remove 190,000 token-turns of text to come out ahead. Fewer tokens in the request can mean a higher bill. We have seen it: bytes removed and dollars saved are two numbers, and they can have opposite signs.

What we do with the rule

The total

On the CI failure fix job with Sonnet 5.5, the average run cost $0.0502 direct and $0.0420 through Context Mode. That is a 22.8% saving, 95% range 11.6 to 32.2%, on 16 tasks, or $8 per 1,000 runs. The tests passed Tests pass 16 of 16 direct, 15 of 16 with Context Mode (McNemar p = 1). Plan and rows: RESULTS-r2.

The saving is about a fifth and not more because the answer and the thinking, 34% of the bill, stay as they are.

Check your own split

Run a job on the try page and see your saving with your own key, or rerun our tests in your own repo.

curl -fsSL https://claude.ai/install.sh | bash
npx @context-mode/cli login
npx @context-mode/cli ci init

Open the try page, or copy the lab template. The first post in this series, how Context Mode cuts the cost, names each lever.

Get started free

Context Mode Gateway: your coding agent costs less and remembers your project. Context Mode Engine installs from your terminal.

Start free: 1,000 requests, every feature, no card. After you sign in, the console gives you one command to connect your coding agent.

Read the docs