What a month of AI coding agents actually costs: $599 on subscriptions, $7,566 at API prices

For thirty days of running my agent fleet, the tracker recorded about 8.7 billion tokens through three vendors' models in 70,227 calls across 2,861 sessions. It estimated $7,566 at API list prices. The three subscriptions that covered the work cost $599, a comparison of nearly thirteen to one. Most of the recorded tokens were cache reads.

The local tracker reads session transcripts and applies model-specific API rates to reported usage. Two of its ten models use estimated token counts because their CLIs do not report exact ones; they account for about seven percent of the modeled cost. The aggregates below summarize that accounting. They do not include the complete per-model token categories, rate dates, or cross-vendor normalization needed to independently reproduce the $7,566 estimate. Treat it as a modeled comparison for this workload, not a bill I paid or a current price quote.

The API bar is an estimate. The graphic's cache ratio is reads divided by reads plus fresh input; cache writes are excluded.

Ninety-five percent of the tokens were re-reads#

The published breakdown was 154 million fresh input tokens, 40 million output tokens, 222 million cache writes, and 8.29 billion cache reads. About 95 percent of total token volume was reads. The 98.2 percent figure uses a different denominator: 8.29 / (8.29 + 0.154), reads divided by reads plus fresh input. It excludes writes. Including the 222 million writes gives about 95.7 percent of input served from cache. Anthropic's usage documentation includes reads, writes, and uncached input in total input; a cross-vendor tracker also needs to normalize each provider's fields before combining them.

That shape is what an agent session looks like from the inside. Every turn the model takes, it re-reads the system prompt, the rules files, the tool results and the whole conversation so far, then writes a few hundred tokens of decision. A product call is the opposite shape: a short prompt, a short answer, nothing carried forward. The largest of these APIs prices cache reads at a tenth of fresh input, which is why I once spent a post on getting the cache prefix right, and even with that discount the re-reads dominate the API-equivalent bill. A flat-rate subscription with a weekly allowance is priced for exactly this shape, which is presumably why the allowance, and not the dollars, is the scarce resource on every plan I pay for.

The supervisor costs more than the typists#

By model, the frontier tier I use for supervision, planning, briefs, diff review and merge decisions, accounted for $3,455 of the $7,566, across 7,954 calls and 2.9 billion tokens. It wrote almost no code. The second vendor's mid-tier model took 23,201 calls and 2.6 billion tokens for $1,468; the mid-tier on the first vendor took 9,075 calls for $1,221. The model that typed the bulk of the last week's merged code, a third vendor's coding model that I dispatch with a written brief, took 9,391 calls and 560 million tokens for $295. The small model that runs the mechanical wrapper scripts made 9,771 calls for $97.

Read as a ratio, the frontier supervisor cost twelve times what the typist cost, for the same month of shipped work. That is the price of the routing rule I wrote in July: the frontier model thinks, cheaper models build, the off-quota model types. The rule moved the typing off the expensive meter, as intended. It did not move the reading, because reading is what supervision is. Every review turn re-reads the session, and the session is where all the context accumulates, so the supervisor's bill scales with session length while the typist's scales with diff size. The typist's diffs were larger. The supervisor's sessions were longer, and length won.

The daily peaks make the same point. The four most expensive days of the month, August 26, August 27, August 31 and September 7, each moved between 860 million and 1.16 billion tokens and would each have billed between $640 and $1,004 on the API. Those were merge waves: dozens of pull requests reviewed and landed in a day, which means dozens of full-session re-reads by the supervisor, not dozens of large diffs. On the subscription those days cost nothing extra. They cost allowance, and an earlier wave in July, when a fan-out of frontier-tier subagents tripped the allowance outright, is how I learned to cap the fan-out.

What the thirteen to one does not mean#

It does not mean the API is overpriced, and it does not mean I would have spent $7,566 without the subscriptions. Nobody runs this shape of workload on a metered API without changing the shape: shorter sessions, aggressive context trimming, fewer review passes. The counterfactual is what this behavior would have cost, and the behavior exists because the flat rate made it free at the margin. The subscription did not save me $6,967. It let me work in a way that would not have occurred to me on a meter.

It also does not mean subscriptions are the answer for everything. The site's backend makes its own model calls when a reader asks the finance tools a question, and those run on the API, metered per call. They are small, independent and infrequent, the opposite shape from an agent session, and the bill is small enough that I have declined to dress it up as a cost story before. The line between the two meters is the line between development and runtime, and I have never had a reason to cross it in either direction.

Route by who pays for the retry#

The rule I run now is one sentence. If a call's cost scales with how much has to be re-read, it goes on a subscription; if it scales with how much has to be answered, it goes on the API. Agent sessions re-read, so they live on three flat-rate plans, and the routing across them exists to protect the weekly allowances, not the dollars. Product calls answer, so they live on the meter, where a short request costs a fraction of a cent and nothing accumulates between requests.

I watch the reads-to-reads-plus-fresh-input ratio alongside cache writes and the remaining subscription allowance. If that ratio falls, I need to inspect the workload and token categories before blaming lost reuse. More fresh work, a different model mix, and missed cache reads can all change it. The label and denominator have to stay attached to the number.