The token economy of a long session, and where the budget actually goes

People assume cost tracks difficulty — that a hard problem costs more than an easy one. It tracks volume instead, and volume is dominated by file contents being read into the conversation and then carried through every subsequent exchange.

Read a large file once and it is not read once. It sits in the conversation and is re-sent with every following message. A single unnecessary full-file read early in a session is paid for repeatedly until the session ends.

That single mechanism explains most of the difference between an expensive session and a cheap one doing the same work.

Ask for the function, not the file. Ask for the section, not the document. When a file must be read fully, do it late rather than early, so it is carried for fewer exchanges.

This helps beyond cost. A conversation containing three relevant functions produces better work than one containing four full files of which most is irrelevant, because the relevant material is not competing with the rest.

The habit to break is opening things to orient yourself. Search to locate, then read what the search found.

Commands that generate a lot of output — a full test run, a large listing, a verbose build — put all of that into the conversation where it stays.

Redirect it to a file and read only the part you need:

npm test > /tmp/out.txt 2>&1; tail -30 /tmp/out.txt

The same information reaches you and the ten thousand lines you did not need do not.

The same principle applies to delegation: a subagent that reads widely and returns a summary keeps the reading out of your conversation, which is the actual argument for using one.

When you finish one piece of work and start something unrelated, everything from the first task is still being carried. It contributes nothing and is paid for on every exchange.

Ending and restarting costs a little context re-establishment and removes all of it. For a genuinely new task, this is almost always the right trade.

The exception is work that genuinely builds on what came before. There, the accumulated context is the value, and starting fresh means rebuilding it — which is both slower and worse.

Summarising, describing an image, reformatting, explaining a well-scoped function — none of this requires the most capable model available, and all of it is high volume.

Moving those categories to a smaller or local model changes the arithmetic substantially, because they are exactly the tasks that consume tokens without needing capability.

The judgement is about consequence rather than size: if a mediocre answer would go unnoticed and be built upon, keep it on the good model. If a mediocre answer is immediately visible and cheap to redo, route it down.

Track spend for a week and break it down by session. The pattern is consistently the same: a small number of sessions account for most of the cost, and they are usually long ones where a large file was read early.

That is a fixable pattern rather than a fact about the work. Knowing which sessions were expensive tells you which habit to change, and the change is usually one of the four above.

Do this once. It is more useful than any general advice, because the answer is specific to how you actually work.