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 95 percent below the standard input rate, recorded on October 23, 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 October 23, 2026 the range across the Claude models we track runs from Claude Haiku 5.5 at $0.10 per million input tokens and $0.50 output, up to Claude Fable 5.1 at $10.00 and $50.00. That is a factor of 100 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 $0.74 on Claude Fable 5.1 and $0.01 on Claude Haiku 5.5. Run daily, that difference is $21.88 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.
What this looked like on one real install
Worked through on 2026-09-01, on a machine with eight scheduled tasks, six skills and four commands. Every figure below is measured from that install's own transcripts, and it is a snapshot of one setup on one date rather than a forecast for yours.
The first surprise was where the money was not. The fixed configuration, the skill descriptions and CLAUDE.md and the memory index that load at the start of every run, came to under two thousand tokens. That is the part people worry about and shorten. In the same install, a single daily job was consuming 619,916 tokens per run. The thing everyone edits was three thousandths of the thing nobody was looking at.
That job is a digest: it runs a script, reads a log and sends an email, across 11.2 messages a run, almost all of it the conversation being re-sent. Nobody had ever seen it as a line item, because a scheduled job produces no invoice and no interruption. It simply ran.
The three changes, and what each returned
The models moved, but not all of them. Everything was running on the largest model available. The daily digest and a weekly analytics digest are orchestration: they call a script and report what came back. Both moved to the smallest model in the same family. A third task drafts articles for review and stayed where it was, because it produces 39,223 output tokens per run against a few hundred for the weekly digest. That is the one place a cheaper model trades quality for money instead of spending less on the same work.
Measured after both had run again on the new model, per run: the daily digest went from $0.78 to $0.18 and the weekly from $0.29 to $0.04. That is 76 and 88 percent, or about 80 percent across the two. The daily one runs thirty times a month, so its share of that is roughly $18 a month for output nobody could tell apart.
The schedules moved, and the first attempt was wrong. All of them were set for the small hours, which looks considerate and is not: the machine was asleep at 05:00, so every run was deferred to the next launch, which is the moment work starts. The transcripts show the hours plainly, because a message at an hour proves the machine was on at that hour. This install was busy from 08:00 to 16:00 and awake but quiet from 17:00 to 22:00. The jobs went to the evening, half an hour apart, longest first.
Nothing was done about caching, because 94.7 percent of the tokens were already cache reads, billed at a fraction of the input rate. The most repeated advice about AI costs had nothing left to give here, and the only way to know that was to look.
Why 80 percent is not a promise
That figure came from a five times price gap between two specific models, applied to work that turned out to be orchestration. A reader already running the middle tier would see about 60 percent for the same move. A reader whose scheduled task writes something should not make the move at all. And the absolute number was modest: all the scheduled tasks together came to about $42 at published rates across the two months recorded, against interactive work several orders of magnitude larger.
What generalises is not the percentage. It is that the expensive part was a job nobody was watching, the safe change was mechanical, the change that felt obvious made things worse until it was checked against real hours, and the advice everyone repeats was already redundant. None of that was knowable without measuring, and all of it took an afternoon.
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.