Coding agents are two workloads, not one.

Interactivity-mode is when a human is staring at a token stream waiting to react. The metrics that matter are time-to-first-token (target sub-2 seconds), inter-token latency (target 80+ tokens/second perceived), and the cost of a retry the user kicks off because they got bored. Throughput-mode is when nobody is watching. The metrics that matter are total tokens processed per dollar and total wall-clock to a job-complete callback. The two have opposite cost curves: interactivity pays a premium for low TTFT, throughput pays the lowest possible per-token rate and is fine waiting up to 24 hours for an answer.

Anthropic's Message Batches API runs requests asynchronously inside a 24-hour SLA at exactly 50 percent of the standard input and output rates, on every model including Opus 4.7. The 50 percent batch discount stacks with the 5-minute prompt caching discount: a cache read is normally 0.1x the base rate (so $0.50 per million tokens on Opus 4.7), and on the batch API that read becomes 0.05x base, roughly $0.25 per million tokens. That is a 20x reduction from the $5 per million list rate. The catch is that batch jobs return when they return; you cannot stream and you cannot pin the response under a real-time deadline. Anything where the user is at the keyboard fails immediately.

Anything you can run overnight or at the end of the workday and review the next morning. Concrete examples: codemods across thousands of files, nightly review passes on every open PR, regenerating an embedding index over a repo, running an eval harness against a new model version, generating release notes from the day's commits, bulk porting test names, security review of dependencies after a major bump, regenerating boilerplate from a spec, regenerating typed API clients after an OpenAPI change, generating per-file documentation across a monorepo. None of these need a human in the loop during the run; all of them are willing to wait hours for a 50 percent off bill.

Anything where a human is in the loop right now. Claude Code at the keyboard. Cursor inline completion. A live debugging session. Code review where the engineer is reading the diff as it streams. A pair-programming voice agent. Anything where TTFT above 5 seconds breaks the user's flow and where any retry the model kicks off is paid in human attention. The interactive lane runs on the streaming API at full list price; the small win here is picking a fast model (Haiku 4.5, Sonnet 4.6, DeepSeek V3.2) for low-stakes turns and reserving Opus 4.7 only for the tricky judgment calls.

On a 250,000-token cached prefix, an 8,000-token fresh input, and a 12,000-token output, one Opus 4.7 turn on the interactive surface lands at roughly $1.90 with prompt caching wired correctly. The same turn on the batch API with the same caching lands at roughly $0.10 to $0.25 depending on whether you can pin the cache write across the batch window. A team running 200 batchable jobs per day on the interactive surface (review passes, eval runs, codemods, doc regen) is burning roughly $380 per day on a workload that should cost $20 to $50. Across a quarter, that is a six-figure rounding error.

Three reasons. First, the routing layer has to be written; it is not a setting you toggle. Second, batch jobs need a results poller and a queue, which is real infrastructure most coding-agent stacks did not build because Claude Code, Aider, and Cursor are all interactive-first. Third, most of the visible AI-for-engineering content online is sold by course operators and 'AI growth partners' who have never shipped a routing layer in production and do not write about it because it is not in their playbook. The result is that a four-line decision (is a human watching this stream right now, yes or no) gets skipped, and the bill quietly inflates.

Yes, more than people think. The interactive surface in a Claude Code style loop is dominated by a long, slowly-mutating cached prefix (tool definitions, file reads, accumulated diffs, system prompt, skills). With 5-minute prompt caching wired correctly, the second turn in a session is already cheaper than the first because reads are 0.1x base. Without it, you pay full input rate on a 250K-token prefix every turn, and a single multi-turn session can cost more than a small batch job on the same task. Wire caching first; only after that does the throughput vs interactivity routing decision actually move money.

A four-line router in front of the agent loop. If the call is initiated from a streaming surface (CLI prompt, IDE extension, web chat) and the user is waiting, send it to the streaming API at list price with prompt caching on. If the call is initiated from a cron, a CI hook, a webhook, or a 'submit and forget' UX with a results page, queue it for the batch API. Hold the batch ID, poll the results endpoint, write the output back to a per-job artifact. Maybe 200 lines of Go or Python. Once the router exists you can vary the model per lane (Haiku 4.5 for low-stakes interactive, Opus 4.7 for everything else) without touching the agent loop.

When the total monthly API spend on coding agents is below roughly $500 a month. The savings from routing are real but they have a fixed engineering cost (the router, the queue, the monitoring) and below that threshold the engineer-hours to ship the router beat the API savings for a year. Above $500 a month and especially above $2,000 a month, the router pays for itself inside a quarter. This is the same threshold where prompt caching wiring also stops being optional.