The Expensive Part Is Remembering

Seven weeks. One project. 15.3 billion tokens.

That is what my autonomous shipping harness put through Claude on a single repository between mid-June and the first week of August. I pulled the number out of the local session transcripts rather than a dashboard, because I wanted the raw per-request usage records and not a rounded summary. At Anthropic's list prices that volume is worth about $12,900. I did not pay $12,900, because almost none of it went through a metered API key. It went through a subscription seat, and subscription seats do not bill you in dollars. They bill you in windows, and when the windows run out they bill you in a monthly credit ceiling that you can hit in five days.

I hit it in five days. Then Codex hit its own wall inside twenty-four hours of that. Both lanes of a two-vendor harness went dark in the same week, and the most instructive part was not the money. It was discovering how many separate meters were running the whole time, how few of them I could see, and how badly I had misread which one I was actually spending.

So I measured it properly before touching anything, then priced every fix I could think of against the actual distribution. That second half turned out to matter more than the first. The conventional advice for making agents cheaper is largely folk wisdom, and against real telemetry the ranking inverts: the lever everyone reaches for first is worth under five percent here, and the two that matter are worth forty and forty-eight.

This piece is the diagnosis and the blueprint. What it is not yet is a result. I have not implemented any of it, so treat the projections as arithmetic against measured data rather than as outcomes. Whether they survive contact gets its own article.

The part nobody explains properly

If you have only ever used a coding agent from a terminal, sitting there watching it work, you have one mental model of cost: I type, it answers, that costs something. That model is wrong in a way that stops mattering the moment you automate.

The API is stateless. The model remembers nothing between requests. So every single time the agent calls a tool and gets a result back, the entire conversation so far, every file it read, every command output, every one of its own previous messages, is sent again from the top. A twenty-tool-call task is not one request. It is twenty-one requests, each one carrying everything that came before it.

Prompt caching is what makes this survivable. The provider keeps the unchanged prefix warm and charges you a tenth of the input price to re-read it instead of full price. That discount is the only reason autonomous agents are economically possible at all. It is also the reason my number is 15.3 billion instead of 1.5 billion, because when re-reading is cheap, nothing forces you to keep the context small.

Four meters, counting four different things

The single biggest source of confusion here is that people say "cost" when four different systems are counting four different things. Two are denominated in dollars and two in time-boxed allowances. They interact, they have different reset behaviour, and hitting one tells you almost nothing about the others.

Codex adds a fifth shape that has no equivalent on the Anthropic side: a five-hour window counted in messages rather than tokens. More on that below, because the consequences for an agent loop are not obvious.

The distinction that cost me the most time to understand is between the third and fourth rows. When the CLI prints You've hit your Opus limit, you switch models and carry on. When it prints You've hit your monthly spend limit, switching models does nothing at all, because a spend ceiling is denominated in dollars and every model costs dollars. My harness learned that the expensive way: its adaptive model picker only probed the premium tier, saw it limited, and confidently fell back to the cheaper one, which was equally dead.

Where the tokens actually go

Here is the seven-week breakdown for one project, measured from the local session records rather than estimated.

Read that table twice. Generated tokens, which include the billed reasoning tokens that max effort exists to buy, are one part in 278 of the token volume. The ratio of cache reads to output tokens is 271 to 1. In dollar terms it is less lopsided, because output is priced five times higher than input and cache reads are discounted ninety percent, but the shape survives: of the $12,900 list-price equivalent, roughly $9,200 is cache reads. Re-reading is the single largest line item by a factor of five over everything the model wrote.

One bookkeeping note, because two baselines appear in this article and they are both correct. The $12,900 is what the workload actually cost at list price, mixing the models it really ran on, including a stint on a premium tier priced at double Opus. Later, when I price the optimization levers, I use $10,460 instead, which is the same 15.3 billion tokens costed entirely at Opus 5 rates. The second number is the honest baseline for comparing fixes, because otherwise a lever would appear to save money that was really saved by no longer using the expensive model.

One caveat on that bottom row, because it is easy to misread. Fresh input at 0.04% does not mean the instruction files are economically irrelevant. A token bills as fresh input only when it is not served from a live cache entry. Everything else is written once and then read at the discount until that entry expires or is invalidated, at which point it is written again. The instructions did not stop being consumed. They changed billing category. The 0.04% is a statement about how little of this workload is genuinely novel text, not about what the instructions cost.

The reason for the shape is visible in the per-request context distribution.

Two thirds of all requests carried more than 200,000 tokens of context. The p99 sits at 964,000 against a one-million-token window, and the maximum is 999,890, which is the window to within a rounding error. The top percentile of this harness runs against the context ceiling, and the typical request still re-reads a quarter of a million tokens before the model writes a single new word.

That is the whole cost story in one sentence, and it is why picking a cheaper model is a much weaker lever than it looks. A cheaper model reduces the price per re-read. It does not reduce the re-reading.

What a cache read actually costs, and the cliff underneath it

Cache reads run at about a tenth of the base input price. Cache writes run at 1.25× for the five-minute time-to-live and 2× for the one-hour version. The break-even arithmetic is worth doing once by hand, in units of base input price.

5-minute TTL
  2 uncached requests      = 1.0 + 1.0        = 2.00
  1 write + 1 read         = 1.25 + 0.1       = 1.35   -> pays off at request 2

1-hour TTL
  2 uncached requests      = 1.0 + 1.0        = 2.00
  1 write + 1 read         = 2.0 + 0.1        = 2.10   -> still behind
  3 uncached requests      = 3.00
  1 write + 2 reads        = 2.0 + 0.1 + 0.1  = 2.20   -> pays off at request 3

Then there is the part that is documented, easy to miss, and structurally nasty.

This changes what a good batch shape looks like. A test suite that takes twenty minutes, a wait on CI, a backoff, an hourly poll: under a one-hour TTL every one of those resumes at the 0.1x read rate. Under a five-minute TTL every one of them pays a full cache write to start again. Nothing in the harness changed. The economics underneath it did, silently, because a spend threshold was crossed.

It is worth being precise about which part is expensive. A parked controller sleeping between polls costs nothing at all. The expensive event is the next model call, and specifically whether that call arrives inside the cache window or outside it. Under credits, an hourly poll is always outside it.

The multiplier stack

No single decision made this expensive. Eight independent choices did, and they multiply rather than add. Every one of them was deliberate, and I would defend most of them on quality grounds. That is the point: this is what velocity costs, itemised.

Three of these deserve a second look, because the obvious reading of each is wrong.

Parallelism does not multiply the bill for a fixed batch of tickets. Three workers doing three tickets consume roughly what one worker doing three tickets in sequence would consume. What parallelism multiplies is the rate. And a rolling five-hour window does not measure work, it measures concentration. Running the same tokens three times faster is invisible on an API invoice and fatal to a session window. For a fixed workload, concurrency moves the burn rate rather than the total, which makes it chiefly a limits problem and only secondarily a billing one.

The orientation block costs more than a naive count suggests, and I got this wrong on the first pass. Nine agent lifetimes at 21,500 tokens is only 193,500 tokens if you count the initial load and stop there. But that block sits at the front of the prefix, so it is carried on every request inside each lifetime, not once per lifetime. Across 46,397 requests that is roughly 998 million tokens, 6.6% of all cache-read volume, about $499 at Opus rates. Not the main event, but the same order as the entire reasoning-effort lever, and five thousand times more than my first estimate. A second reviewer caught that, which is the whole argument for having one. The retry ladder is still expensive, but for a different reason: each attempt rebuilds a live working context from the ticket, the comments, the branch, the diff and the CI state, and every subsequent tool call carries the whole accumulated thing again. The fixed prologue is a constant. The working context is the variable, and the variable is where the volume is.

And number six explains the symptom I actually noticed first. My interactive sessions started dying early, and I assumed I was doing more interactive work than I thought. I was not. The background was eating the same meter.

How Claude's meters actually work

Subscription plans meter usage in windows, not dollars, and there are three of them running at once.

On a Team or Enterprise seat the allowance is per seat, on the same rolling five-hour and weekly windows, and it is shared with chat and the other surfaces. Past the seat allowance, an org can enable usage credits, billed at standard API rates, with spend limits set at the organisation, group or individual level. That monthly spend limit is the hard dollar ceiling, and it is the one I burned through in five days.

Three behaviours of that ceiling are worth writing down, because I learned all three from failures.

That nine-minute figure is the one I keep coming back to. It says the harness's burn rate is not merely high, it is high relative to the granularity of the controls available to manage it. A ceiling you can exhaust faster than you can react to is not a budget. It is a fuse.

For calibration, Anthropic publishes its own numbers for human-driven Claude Code across enterprise deployments: about $13 per developer per active day, $150 to $250 per developer per month, and under $30 a day for ninety percent of users. My worst measured days on this one project were $1,320 and $1,330 in list-price equivalent. That is roughly a hundred times the $13-per-active-day benchmark, from one person's harness. The same documentation notes that its own agent-teams feature consumes about seven times the tokens of a standard session. My controller is not that feature, so the number does not transfer directly, but it is the vendor putting a figure on the same phenomenon inside a system it fully controls.

How Codex's meters actually work

OpenAI counts a different unit, and the difference matters more than it first appears. The five-hour window is denominated in local messages, shared across the CLI, the IDE extension and the cloud surface, with weekly limits stacked on top.

Those ranges are wide for a reason that is easy to gloss over: a message is not a fixed cost. Context size, output length and tool-call count all change what one message consumes, so the same allowance yields 15 messages or 90 depending entirely on how heavy your messages are. An agent loop produces the heaviest possible messages: long context, many tools, max reasoning. Read the allowance as a range in which each message consumes variable capacity, and the implication is that an agent gets neither the generous end of the message count nor any shelter from carrying a heavy context. Assume you live at the bottom of every one of those ranges.

Past the window, Codex bills in credits. OpenAI publishes the rate card in credits rather than dollars and does not publish the conversion, so the widely-repeated figure of four cents per credit is a derivation from Sol's API price rather than a published number. Treat the credit column as exact and any dollar equivalent as inferred.

A typical message runs roughly 5 to 40 credits. On ChatGPT Business the credits come from a shared workspace pool with per-user limits set by an admin, so one runaway automation can drain a team. Worth noting for anyone planning this architecture today: as of 2026-06-24, Codex seats are no longer available to new Business workspaces.

Headless and interactive are not the same meter

This is the part I had wrong in my own head for weeks, and it turns out to be the single most consequential thing to understand if you are running automation rather than typing at a terminal. Both vendors have a rule for it, the rules are different, and one of them changed twice this year.

Start with the principle they actually share, because it is not the one most people assume. It is not the interface that decides which meter you spend. It is the credential.

Claude: a separate programmatic credit, announced then paused

Anthropic announced that from 15 June 2026, non-interactive usage would move off the subscription allowance and onto its own monthly credit. The scope was specific: the Agent SDK in your own Python or TypeScript projects, the claude -p command in Claude Code, the Claude Code GitHub Actions integration, and third-party apps authenticating through the Agent SDK. Interactive Claude Code, the web app and Cowork were explicitly excluded and would keep drawing the plan allowance.

The announced amounts, per month, per plan:

Consumed at standard API list prices with no subscription discount, refreshed monthly, and explicitly no rollover. When the credit runs out, usage falls through to your usage credits at API rates if you have them enabled; if you do not, programmatic requests simply stop until the credit refreshes.

Look at those numbers next to the plan prices. Max 20x costs $200 a month and the programmatic credit was also $200 a month, charged at list rates with no discount. For a harness whose measured seven-week run prices out at $12,900, a $200 monthly automation budget is not a constraint, it is a rounding error. It would have lasted me roughly five days. Which, as it happens, is exactly how long my monthly ceiling did last.

Codex: no split, at either end

OpenAI has nothing equivalent, announced or shipped. Sign in with ChatGPT and Codex usage follows your plan allowance identically across the desktop app, the CLI and the IDE extension. A codex exec run in a cron job spends the same five-hour message window as the interactive terminal you had open an hour earlier. Sign in with an API key instead and OpenAI bills that usage through your Platform account at standard API rates, entirely outside the subscription.

There is one wrinkle that is easy to misread as a split. OpenAI's own guidance recommends API-key authentication specifically for programmatic CLI workflows such as CI/CD jobs. That is a routing recommendation, not a separate pool: it is telling you to move automation onto metered billing deliberately, rather than letting it eat the allowance your interactive work depends on. Which, having watched exactly that happen on the other vendor, strikes me as the correct advice.

All four combinations, side by side

The asymmetry is worth stating plainly, because it inverts what you would guess from the marketing. Anthropic has been actively trying to carve automation out of the subscription and price it separately. OpenAI has left the subscription undivided and instead points you at a different credential when you automate. Same underlying problem, opposite mechanism: one draws the line inside the plan, the other draws it at the login.

The confound in my own numbers

One correction to something I implied earlier in this piece, because I went and checked the account topology rather than assuming it.

My harness does not run on the same Claude account as my interactive work. The automation authenticates as a dedicated identity; my day-to-day terminal sessions use a personal Max plan. So when I observed an interactive session working perfectly while a headless probe returned a spend-limit error, the cleanest explanation is not a product-level headless meter at all. It is two accounts with two separate allowances, behaving exactly as two accounts should.

That is a duller finding than the one I was reaching for, and it is the correct one. It also happens to be a recommendation in disguise: separating automation onto its own credential gave me the isolation the paused billing split was designed to provide, without waiting for the vendor to ship it. If you take one operational thing from this article, take that.

The Codex side of the harness is on a ChatGPT Pro plan authenticated through ChatGPT rather than an API key, which is why its failures show up as window exhaustion rather than an invoice.

Side by side

The prices are close enough that vendor choice is not where the money is. The difference that matters is the unit. Anthropic charges you for how much you carry; OpenAI charges you for how often you speak, until you exceed the window, at which point it also charges for how much you carry. Mine takes many enormous turns, which is the unfavourable case on both meters at once.

Hitting the wall is the design working

It would be comfortable to frame all of this as a bug. It is not. Every multiplier in that stack was chosen to buy something specific, and the things they bought are real.

Fresh context per iteration is what makes the loop restartable and what stops a poisoned context from compounding across hours of unattended work. Max effort is what keeps a single worker from shipping something plausible and wrong at three in the morning. The retry ladder is why a hard ticket eventually gets finished instead of silently abandoned. The two-vendor review is the strongest quality control I have, and it is strong precisely because the second opinion comes from a model trained by someone else. Parallelism is throughput. Failover is uptime.

Given all of that, a system that burns a month of allowance in five days is not malfunctioning. It is doing exactly what it was built to do, at the rate it was built to do it. The failure was not in the harness. It was that I built a machine with a burn rate measured in hundreds of dollars a day, and gave it a control surface with a granularity of one monthly number.

The controller log for the period records 14 Codex hit your usage limit events and three Claude hit a limit on claude-opus-5 events. Resist the obvious comparison: those counts come from two different accounting systems, and a failover probe can re-hit the same exhausted state several times in a row, so the numbers measure probe frequency at least as much as they measure exhaustion. What they do show is that both lanes of a deliberately two-vendor system reached their ceilings in the same week.

And the consequences were not confined to the bill. When the review agent hit the spend ceiling, it did the correct thing at every step: it verified against GitHub, it refused to record a review that had not published, and it left each pull request queued. Nothing was faked. But the net effect was a review agent that had silently stopped reviewing while reporting itself healthy, and one pull request sat unreviewed through four consecutive sweeps with people waiting on it. A rate limit stopped being a billing event and became a correctness failure with a delay fuse on it.

Seven things I now believe

The blueprint

I did not want to end on a list of vague intentions, so I ran the levers against the measured distribution before writing them down. Most cost advice for agents is folk wisdom repeated between blog posts. When you price it against real telemetry, the conventional ranking inverts almost completely.

Start with the finding that reshaped the whole plan. I expected a fat tail: a handful of pathological runaway sessions carrying a million tokens each, easy to identify and kill. That is not what is there.

That is far flatter than a cost distribution usually is. The top 5% are still over-represented, carrying 13.8% against the 5% a uniform workload would give them, but that is a factor of under three, not the twenty-fold a real fat tail produces. There is no small set of offenders to snipe. Half the requests carry three quarters of the volume, which is roughly what you would get from a uniform workload with a heavy average. The cost is not concentrated, it is structural, and that rules out an entire class of fix. Outlier hunting, per-session kill switches and p99 alerts would between them address about an eighth of the problem. The thing that moves the rest is lowering the mean.

Priced against the measured trace, not against intuition

Here is what each lever models out to against this dataset. Every figure below is a counterfactual, not a result: it holds request count, task completion and output constant and changes only the one variable named, which no real change ever does. The baseline is $10,460, the same 15.3 billion tokens priced entirely at Opus 5 rates with every cache write at the five-minute rate. Each row assumes the ones above it are not applied, so they are comparable to each other rather than cumulative.

Read the last row against the first two. Reducing reasoning effort until the harness produces a third less output saves under five percent, because the entire output budget for seven weeks was $1,382. You could delete every thinking token and every line the model wrote, keep the reading, and still pay 87% of the bill. Effort is a quality and latency dial. It is not a cost dial, and treating it as one is how you end up with a dumber harness and the same invoice.

The top two rows are close enough that they are not really competing, and they stack cleanly because one reduces the number of tokens and the other reduces the price of each. Cap context at 150k and serve 60% of the remaining volume on a cheap tier and the modelled figure lands near $3,200, a 70% reduction, three times cheaper. Adding the effort cut on top of that contributes another $252.

The honest caveat on the top row is that it is the least free of the five. Capping context is mostly plumbing; moving 60% of token volume to a small model requires actually knowing which 60% can survive there, and getting that wrong costs correctness rather than money. It ranks first on the arithmetic and second on the risk-adjusted ordering, which is why the implementation order at the end of this section does not match the table.

Move 0: instrument, before changing anything

I can tell you the total to the token and I cannot yet tell you which of eight multipliers owns which share. That is a measurement gap, and fixing it first is the difference between engineering and guessing.

Three things go in before any optimization. OpenTelemetry export, which streams per-user token and cost metrics into your own stack regardless of which provider or auth method is in play, and is the only option that works across every setup. The /usage attribution breakdown, which already splits recent usage by skill, subagent, plugin and individual MCP server, and flags any behaviour accounting for 10% or more of consumption, including long context and cache misses. And /context, which shows what is occupying the window right now rather than after the fact.

The fourth piece of instrumentation is organisational rather than technical: separate identities for background automation and interactive work, so that attribution is a property of the account rather than something you have to reconstruct from transcripts. Right now I derive that split by pattern-matching the first user message in a session file, which works but is archaeology.

Move 1: cap what every request carries

This is the 42% lever, and it is the one I would start with even though it is not top of the table, because every technique in it is additive plumbing rather than a bet on model capability. Five of them, roughly in order of how cheap they are to adopt.

Subagent isolation is the highest-leverage and least invasive. Running a test suite, reading a log file, exploring an unfamiliar directory: all of these dump enormous output into the main window, and none of it is referenced again. Delegated to a subagent, the verbose output stays in that subagent's context and only the summary comes back. Anthropic's own multi-agent research system has subagents return condensed summaries of 1,000 to 2,000 tokens. Against a mean of 329,000, that is the whole game.

Subagents also take a model field, which is where moves 1 and 2 collapse into a single edit. A user or project subagent named Explore overrides the built-in one and keeps its own model, so defining it with model: haiku puts every codebase exploration on the cheapest tier while the main conversation stays at the frontier. Nesting is supported too, capped by CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH, so a reviewer can dispatch a verifier per finding and none of that intermediate output ever reaches the parent.

Context editing is the API-level version of the same idea: rule-based pruning of stale tool results from the transcript before the model sees it. Anthropic's published evaluation is the most striking number I found in this whole research pass. On a 100-turn web search benchmark, context editing cut token consumption by 84% and, rather than degrading quality, delivered a 29% performance lift on its own and 39% combined with a memory tool. Pruning made it both cheaper and better, because a context stuffed with dead tool output is not neutral, it is noise the model has to read past.

Hooks that preprocess tool output are the cheapest fix on this list and I have not implemented a single one. A PreToolUse hook can rewrite a command before it runs, so instead of the agent reading a ten-thousand-line log to find three errors, the hook greps for them and returns a hundred tokens. The reduction is one to two orders of magnitude, on the exact class of output that dominates a coding agent's context.

Just-in-time retrieval instead of pre-loading is the architectural version. Store lightweight identifiers, file paths, queries, ticket references, and load the content at the moment it is needed rather than carrying it from the start. This is what my instruction files get wrong: they are a pre-load, and most of what they pre-load is irrelevant to any given ticket. Moving specialised workflows out of always-loaded instructions and into skills, which load on demand, is the same trade.

Finally, tool surface. MCP tool definitions are deferred by default now, so only names enter context until a tool is used, but CLI tools are still more context-efficient because they add no per-tool listing at all. If gh and gcloud already do the job, an MCP server for the same thing is pure overhead.

Move 2: tier the models on input, not on output

The naive version of model tiering asks which model writes the code. That is the wrong question, because output is 13% of the bill. The right question is which model does the reading.

A five-fold difference on the dominant line item. The constraint is that you cannot run the judgment on Haiku, so the design problem is separating the stages that need frontier reasoning from the stages that are mostly reading. In my harness the second category is large and obvious: status reconciliation against the tracker, CI log triage, verifying that a deployed revision matches a pushed image, checking whether a PR's review threads are resolved, reading a diff to confirm a fix is present. None of that is architecture. All of it is currently running at the top tier on max effort.

The advisor-executor shape formalises this: a cheaper executor runs the loop and calls up to the frontier only at the decisions that actually matter, so most tokens bill at the cheap rate while judgment stays at the top. I wrote about that pattern when Anthropic's own team described it. I have not yet applied it to my own harness, which is a reasonable summary of how this whole exercise has gone.

Move 3: give the loop a budget it can feel

The nine-minute burn happened because the only control in the system was a monthly number, and the harness could exhaust it faster than any human could respond. The fix is not a smaller monthly number. It is putting ceilings at the granularity the work actually happens at.

Task budgets are the soft version: a token ceiling for a whole agentic loop, set as output_config.task_budget with a minimum of 20,000 tokens. The model sees a running countdown and paces itself, wrapping up gracefully instead of being cut off mid-thought. It is advisory rather than enforced, which is exactly right for a worker that should finish cleanly rather than die at a hard boundary.

The hard version exists too, on the Managed Agents surface: a per-session dollar cap where the session pauses at the ceiling with a resumable state rather than failing. That is the shape I want. A per-session cap turns a monthly cliff into dozens of small fuses, each of which fails visibly and locally instead of taking the whole system dark at two in the morning.

And the retry ladder needs a cheaper first rung. Six no-progress relaunches at full cost each is the loop paying premium price to discover the same blockage six times. A cheap triage pass that reads the state and decides whether a full relaunch is even worth attempting would cost a fraction and would catch the cases where the answer is "this is gated on a human, stop trying".

Move 4: schedule against the meters

Two of the four meters are sensitive to timing rather than volume, which means there is free money in scheduling that costs nothing in quality.

The five-hour window measures concentration. The same batch spread across two windows costs near-identical dollars and clears the session cap, provided weekly headroom remains. A controller that knows its own reset time and paces the ready set against it is strictly better than one that fires everything as fast as the scheduler allows, and it changes no output at all.

The cache TTL is the other one, and it argues for the opposite shape at a smaller scale: inside a working period, cluster requests tightly enough to stay inside the cache window, because a gap that exceeds it costs 12.5× on the re-entry. Under a subscription that means staying inside an hour. Under credits it means staying inside five minutes, which is a genuinely different scheduler. An hourly poll is the worst possible cadence under credits and a perfectly fine one under a subscription, and nothing in the system tells you when you crossed from one regime to the other.

For anything genuinely asynchronous, the Batch API runs at 50% of standard prices with most batches finishing inside an hour. A nightly sweep, a bulk verification pass, a documentation regeneration: none of those need to be interactive, and half price is half price.

What not to bother with

Two things I had on my list before I measured, both of which the data killed.

Chasing cache misses as the headline fix. Writes are 1.62% of token volume against 97.98% reads, which looks like a 61-to-1 argument for ignoring them. In dollars the ratio is 4.8 to 1, because a write costs 12.5 times what a read does, and $1,547 of the baseline is cache writes. So it is not nothing, and I nearly published that it was. What the numbers do say is that reads outrank writes by a factor of five, so write tuning is a second-order fix that should follow the context work rather than precede it. The exception is the TTL cliff, which turns a modest write cost into a large one very quickly.

Treating instruction trimming as free money. With the arithmetic corrected, the orientation block is worth about $499, or 4.8% of the baseline. That is real, it is roughly the size of the effort lever, and it is far cheaper to implement than either. But it is an order of magnitude below the context and tiering levers, so it belongs in the same bucket as effort: worth doing, not worth leading with.

The order I will actually do it in

Instrument first, because everything after depends on being able to attribute. Then subagent isolation with a Haiku exploration agent, because it is one configuration file and it hits both the 42% lever and the 29% lever simultaneously. Then hooks on the two or three tool calls that produce the most output, which is a morning's work. Then the harder architectural piece: separating the reading stages from the judgment stages so the advisor-executor split has something to divide along. Budgets and scheduling last, because they bound the damage rather than reduce it, and bounding damage on a system you have already made three times cheaper is a much smaller problem.

The prediction I am willing to be held to: context weight and model tiering together get this to somewhere between a third and a half of current spend without touching effort, parallelism, the retry ladder or the two-vendor review, which are the four things I was most afraid I would have to give up. If that is wrong, it will be wrong in public, with numbers, in the next article.