Why Claude Code Costs What It Does, and Which Part You Control

Most people meet this question the same way: the bill is higher than expected, and nothing obvious explains it. The prompts are short. The skills are a few kilobytes. Nothing looks expensive. The reason the arithmetic feels wrong is that almost none of the cost is the text you wrote.

Nearly all of it is the conversation, sent again

A coding agent works in turns, and every turn re-sends the whole conversation so far. Turn twenty carries everything from turns one to nineteen. So the cost of a session grows with the square of its length, not in a line, and a long session is expensive because it is long rather than because any single message was large.

The saving grace is that providers charge far less for text they have already seen. Across the Claude models we price, the published cache-read rate is a median of 90 percent below the standard input rate, recorded on August 29, 2026. Claude Code uses this automatically. There is nothing to configure and, for most people, nothing left to win here: the discount is already in the number they are looking at.

This is worth knowing because the most common advice, cache your prompts, is usually advice to do something that is already happening. It is possible to check rather than assume, which is the point of the section below.

The part people forget is the part that runs without them

An interactive session is visible. You start it, you watch it, you stop it. A scheduled task is not: it fires whether or not you are at the machine, it costs the same every time, and it never appears in anyone's mental model of the week. A daily job is thirty runs a month that nobody remembers agreeing to.

Two consequences follow, and the second surprises people more than the first. The obvious one is that cadence multiplies everything: halving how often a job runs halves what it spends, which no other change can match. The subtle one is about timing. Usage allowances are consumed over a rolling window, so a job that fires shortly before you sit down has already spent part of the allowance you are about to use, and you meet the limit sooner during your own work. The monthly total never shows this. The collision is what you actually notice.

The instinct is to move those jobs to the small hours. That usually makes it worse. If the machine is asleep or the app is closed when the time passes, the run does not happen then; it happens at the next launch, which is precisely when you sit down. The hour you want is not your quietest, it is the latest one your machine is reliably awake.

The model is a choice worth several times the price

On August 29, 2026 the range across the Claude models we track runs from Claude Haiku 4.5 at $1.00 per million input tokens and $5.00 output, up to Claude Fable 5 at $10.00 and $50.00. That is a factor of 10 on identical work.

Put a real scheduled run through it. A job consuming 600,000 tokens, in the proportions these runs actually show, with roughly 94 percent served as cache reads and about 6,000 tokens of output, costs $1.16 on Claude Fable 5 and $0.12 on Claude Haiku 4.5. Run daily, that difference is $31.43 a month for the same work.

A scheduled task honours a model line in its own frontmatter: add a model key under the description in its SKILL.md and that one task switches, leaving every interactive session alone. Do it per task rather than through a global default, or you change the sessions where you wanted the capable model.

Which tasks can move is a judgement, and it divides more cleanly than you might expect. A job that runs a script, reads a log and sends an email is orchestration: it is choosing what to call and reporting what came back. A job that drafts an article is producing the thing itself. The first is a candidate. The second is where a cheaper model trades quality for money rather than spending less on the same work, and the difference shows in the numbers: a writing task produces tens of thousands of output tokens per run where an orchestration task produces a couple of thousand.

The one input that costs more than it looks

Because every turn re-sends what came before, anything large fed into a run early is paid for again on every later turn. One wide command can cost several times its own size. The usual culprits are a full JSON dump used for a count, a log query with a high limit, and a whole file read to check one line. Narrowing a single query is often worth more than every prompt edit combined, and it is invisible from the outside: nothing in a task definition says which command returned fifty records where five would do.

Measuring your own, rather than guessing

Everything above is the shape of the problem. Your version of it is in your own transcripts, which record the token counts the API returned for every message, along with the model that served it. That is a measurement rather than an estimate, and it is already on your machine.

Our Claude skill cost tool reads them in the browser and shows what each scheduled task and session actually consumed, on which model, what that would cost at published rates, and what the same tokens would cost on a cheaper model that could still have run the job. It also reads the hours your machine is genuinely awake, so the scheduling advice above becomes your hours rather than a general rule. Nothing is uploaded; the files never leave the page.

Two things tend to come out of it. The first is that the fixed configuration everyone worries about, the skill descriptions and the memory index loaded at the start of every run, is usually a fraction of one percent of what was spent. The second is that one scheduled task is quietly larger than all the others, and nobody had ever seen it as a line item.