Automate tasks with Anthropic Claude

Claude has no memory between runs. Every time your task fires, the step sends the whole prompt again — your instructions, your examples, your rules — and Claude reads all of it from scratch before answering.

That reading is what you are billed for. If your step carries three pages of instructions and the task runs five hundred times, you have paid five hundred times to have those same three pages read.

The answer itself is usually the small part. On a long, carefully written prompt, most of the cost is the reading, not the writing.

Three levers, roughly in order of how much they give back.

Shorten the fixed block. Instructions grow by accretion: a rule gets added because one case came out wrong, then another, and nothing is ever removed. You pay for all of it on every run. Re-read the whole block from time to time and delete what no longer earns its place — worked examples especially, since they are usually the heaviest part.

Do not send the same data twice. A common pattern is to list the task's tags at the end of the instructions and again in the request box. Claude then receives the product, the article or the message twice: you pay for it twice, and the model has to reconcile two copies that are often labelled slightly differently. Keep one.

Match the model to the job. The list ranges from fast, inexpensive models to the most capable ones, and the gap between the ends is wide. Pouring a product listing into a template is not the same job as analysing a contract. Start at the cheap end and move up only if the output is not good enough — not the other way round.

Think of Claude as a specialist you hand a thick dossier to, followed by a short question. Without caching, every consultation is the same: read the dossier cover to cover, answer, throw it away. Caching lets the specialist leave the dossier open on the desk with a bookmark in it. Next time, the reading starts at the bookmark.

What matters is where the bookmark goes. Caching always covers a prompt from the very beginning up to the bookmark — never a piece taken from the middle. Everything before it is reused; everything after it is read fresh every time.

That single rule has a sharp consequence: if one character changes anywhere before the bookmark, the whole saved portion is discarded. Reuse depends on the beginning of your prompt being identical, character for character, run after run.

There are three reasons, and none of them shows up as an error. The step simply costs what it always did.

The reused part is too small. Keeping a dossier on the desk has its own overhead, so there is a minimum size below which nothing is stored — re-reading a short note is cheaper than filing it. A few paragraphs of instructions are usually under that line.

Too much time passes between runs. The dossier is not left on the desk forever; it is cleared after a fairly short idle period. A task that fires once an hour tends to arrive after the desk has been cleared, pay to leave the dossier again, and never come back in time to use it.

The stable part is not actually stable. If anything that changes per run — a date, a name, an id coming from the trigger — sits inside the block you meant to reuse, then that block is different every time and there is nothing to match against.

The exact minimum size and the exact expiry are set by Anthropic, they differ between models, and they are revised from time to time. Check their current figures rather than a number you remember.

Two conditions have to hold at the same time: the reused part has to be large, and the reuse has to be frequent.

The clearest win is a step that runs many times in quick succession on the same fixed instructions — a trigger that returns thirty items and a Claude step that handles each one. The first call pays to store the instructions; the twenty-nine that follow read them back at a fraction of the price, and they happen close enough together to land before the expiry.

The clearest non-win is the opposite: a task that fires once an hour with a short instruction block. Too small to be stored, too far apart to be reused — caching would add a little cost on every single run and give nothing back.

A rule of thumb that survives price changes: caching only pays from a handful of reuses onward. If your prompt will not be reused at least that often before it expires, leaving it off is the cheaper choice.

The step gives you two boxes: System message for context and rules, and New user message for the actual request. That split is not decoration — it decides what can be reused, and it makes the step far easier to maintain.

Put everything that is the same on every run in the first box: the role, the rules, the output format you want, the worked examples. Put everything that changes in the second: the article to summarise, the message to classify, the row that just arrived.

The trap is subtle, and it is the one we see most often. If you drop a tag from your task — a date, a customer name, a product id — into the System message, that block stops being identical between runs and can no longer be reused. Worse, people often end up pasting the same tags into both boxes, so the data travels twice and gets paid for twice.

The fix is the same in both cases: tags belong in the second box only. Same information, same answer, lower cost.

Not at the moment. The step sends your prompt in full on every run.

It is on our list, and the questions above are here so you can work out in advance whether it would help you — for a lot of tasks it would not, and that is worth knowing before you ask for it. The advice in the other answers, on the other hand, lowers your cost today and does not depend on any of this.

If you have a task that fits the profile described in Which of my tasks would actually benefit from caching — a large fixed instruction block reused many times within a short window — tell us about it. Real cases are what move this up the list.