First agent bill tends to produce a double-take — it only fixed one small bug. The cause is not the per-token price. It is that every turn resends everything that came before.
In this pagewhere cost comes from, which savings are real. No vendor price tables — reason in §5. Nothing about my own spend either.
Model APIs do not remember the last turn. "Multi-turn conversation" is implemented by sending everything so far plus the new part, every single time.
In chat that is nothing — each turn is a few dozen words. An agent turn contains:
| Contents | Scale |
|---|---|
| System prompt + tool definitions | Fixed overhead, present every turn |
| Project memory file | Fixed overhead — however long you wrote it, you pay it every turn (page 5) |
| Every file it has read | The big one, and it only grows |
| Every command's output | One install log can outweigh the source |
| Every previous exchange | Cumulative |
So cost is superlinear in turns. A forty-turn task is not forty times a one-turn task. It is more.
Precisely because most of each resend is identical to the last one, providers generally support caching: the repeated prefix bills at a lower rate.
To collect that discount you only need one fact: the cache matches on the prefix. Byte-identical from the start counts; insert one character at the front and everything after it is void.
System prompt, tool definitions, project memory — anything constant across the conversation — belongs at the front, with volatile material after. Most tools already order it this way, but watch what you inject yourself, and do not inject at the front.
It also explains something counter-intuitive: editing your project memory file often raises costs — not because the file grew, but because each edit voids the cache you had built up.
| Move | Why it works | Cost to you |
|---|---|---|
| ① One job, one session | Cuts both factors in "turns × context". Nothing else comes close | You do the task decomposition |
| ② Do not let it read whole large files | Once in context, every later turn pays for it again | Teach it to search and locate, not to read entire files |
| ③ Block noisy output | Install logs and full test output are enormous and nearly information-free | Some command config, or have it read only the tail |
| ④ Cheap tier for cheap work | Compression, titling, classification do not need the top model | Requires per-slot model config |
④ needs a tool that supports different models per purpose. Hermes is a ready example:
main model, auxiliary tasks, compression and fallback are independent slots,
each taking its own provider / model / base_url —
so "compression on a cheap tier, main model on a good one" is a config change, not a project.
"Shrink the context window to save money" usually backfires. A smaller window means more turns and re-reading the same files, so the total goes up.
Same with always picking the cheapest model: it gets things wrong more often, wrong means redo, and the redo eats the saving. Count totals, not unit prices.
| Move | Reveals |
|---|---|
| Read the tool's own usage display | Most CLIs have one. Know the order of magnitude before optimising anything |
| Compare one big task against the same work split in three | Measuring it once beats reading ten articles about it |
| Find your single longest session | Cost concentrates hard. Killing the few longest sessions moves the bill a lot |
Because prices change faster than this page does. Written down, they start going stale immediately, and a reader making decisions on a stale number is worse off than one given no number.
The site rule is: facts that expire either carry a checked date or do not get written. Price tables fall into "stale even with a date", so this page gives mechanism only. Mechanism does not expire: resend, prefix cache, superlinear growth — true at every vendor.
provider / model / base_url. Official docs, checked 2026-08-21.