How to manage API costs when using Claude Sonnet for automated coding

How to manage API costs when using Claude Sonnet for automated coding

Anthropic's prompt caching lets you reuse the processed state of a prompt prefix across API calls, cutting the cost of those repeated tokens by 90 percent on a cache hit. For agentic coding tools like Cline or Continue.dev, which resend your entire codebase context on nearly every turn because Claude has no memory between requests, this is the difference between a coding session costing a few dollars and costing thirty. The catch is that caching only works if you structure your prompt so the static parts stay identical, byte for byte, at the front of every request.

Why agentic coding tools are so expensive by default

An agent loop looks simple from the outside: you type a task, the model reasons about it, calls a tool, gets a result, and repeats until done. Underneath, every one of those steps is a brand new HTTP request to the Anthropic API. Claude doesn't retain state between calls. Whatever context the model had in its head on turn four is gone by turn five unless the tool re-sends it.

That means Cline and Continue.dev both work by reconstructing the full conversation on each call: system prompt, project instructions, the files it has read, previous tool outputs, and the running back-and-forth. On turn one that might be 15,000 tokens. By turn ten, once you've had the agent open six files and run four shell commands, you could easily be pushing 60,000 tokens per request, and every one of those tokens gets billed at full input price unless caching kicks in.

I've watched a moderately involved refactor task in Cline burn through more tokens in redundant re-sent context than in actual new reasoning. The model isn't doing 60,000 tokens of thinking each turn, it's re-reading the same file it read three turns ago because the tool re-includes it every time.

What prompt caching actually does under the hood

The mechanism is documented in Anthropic's prompt caching guide: you mark a point in your prompt with a cache_control breakpoint, and everything up to that point gets cached on Anthropic's servers. On a subsequent request, if the prefix up to that same breakpoint matches exactly, the API skips reprocessing it and charges the discounted cache-read rate instead of the full input rate.

A few mechanics matter specifically for coding agents:

• Caching is prefix-based and exact. The cached segment has to be identical from the start of the prompt through the breakpoint. Change one character before that point (a timestamp, a reordered file list, a trailing space) and the whole cache entry misses.
• There's a cache write cost and a cache read cost. Writing to the cache the first time costs somewhat more than a normal input token. Reading from a hit is where you get the 90 percent discount.
• Cache entries expire. The default lifetime is short, on the order of minutes, so long idle gaps between agent turns will silently cost you a fresh cache write.
• You can set multiple breakpoints in one request. That lets you cache the system prompt, a large reference file, and the semi-static "current task" context as separate layers, each surviving independently.

This is a fundamentally different model from a naive chat loop that just concatenates a growing transcript and ships it as one blob every time. Naive concatenation guarantees the entire prompt is reprocessed from token one on every call, because nothing about it is guaranteed to match the previous request's prefix.

How does context get resent by tools like Cline and Continue.dev?

Both tools assemble a request from roughly the same layers: a system prompt (agent behaviour, tool definitions, project rules), file and project context, and then the accumulating conversation and tool-call history. Continue.dev exposes its model provider configuration, including how it talks to Anthropic, in its Anthropic provider docs, which gives you some visibility into how the system prompt and model parameters are set. Cline's request construction lives in its own extension logic, and you have less direct control over ordering there, though the project is open source and you can inspect the Cline repository if you want to see exactly how a given release builds its prompts.

The part that actually determines whether you get cache hits is ordering, not content. If static material like your system prompt and a large schema file sits at the top and never shifts position, it's cacheable. If a tool interleaves something dynamic, like a live diff or a freshly re-rendered file listing, before that static block, you break the prefix match on every single call regardless of how much of the prompt is technically unchanged.

This is the quiet cost leak in a lot of default agent setups. A tool that reloads a big reference file on every turn, and formats its inclusion slightly differently depending on what else changed that turn, will almost never hit cache even though the file's actual content hasn't moved.

Structuring context to maximise cache hits

The rule is easy to state: static content first, in the same order every time; dynamic content last. In practice, a cache-friendly layout for a coding agent session looks like this:

1[1] System prompt / agent instructions (static, cache breakpoint here)
2[2] Project standards, architecture notes (static)
3[3] Large reference files rarely edited (static, second breakpoint)
4[4] Files relevant to the current task (semi-static, changes per task)
5[5] Conversation and tool-call history (dynamic)
6[6] Latest user instruction or diff (dynamic, always last)

A few tactics follow directly from this:

Freeze the system prompt for the duration of a session. Every tweak to your Cline custom instructions or .clinerules file, or your Continue.dev config, invalidates the cached prefix on the next call. Decide on your instructions before you start a long, agentic run, not halfway through it.

Load big reference files once, as a stable block. If the agent needs a full API spec or schema, include it as one static chunk with its own breakpoint rather than letting the tool re-fetch and re-inject it every time a related file gets touched.

Don't let semi-static content drift into the dynamic zone. Files open for the current task should sit in a tier that only changes when you switch tasks, not one that gets re-rendered with different whitespace or ordering on every message. Trailing whitespace differences alone are enough to break a byte-exact match.

Put the thing that's guaranteed to change last. Whatever you just typed, or whatever the last tool call returned, goes at the very end of the request. Everything before it can still hit cache even though that trailing piece obviously can't.

Respect the cache TTL. If you step away for a long coffee break past the cache's lifetime, the next call pays full cache-write price again. For a long refactor session, working in a tight rhythm actually saves money, which is a strange thing to say about an AI coding tool but is true here.

What actually breaks the cache in practice

A handful of failure modes show up repeatedly once you start watching your Anthropic usage dashboard closely:

A timestamp or run ID embedded near the top of a system prompt for logging purposes. It looks harmless and quietly kills every cache hit for the session because the "static" block is technically different every call.

Auto-formatting differences between calls, where a JSON context block gets serialised with different key order or spacing depending on some upstream state. The content is the same to the human eye and completely different to a byte-exact cache check.

Editing your rules file or config mid-session to nudge agent behaviour. It feels like a small tweak. It resets your cache baseline immediately, and the next several turns pay full price until a new stable prefix forms.

Long idle gaps that exceed the cache TTL, worth checking against Anthropic's current documented value rather than assuming it matches whatever you remember from an earlier model generation.

Roughly what this saves you

Picture a Cline session with 15,000 tokens of stable system prompt and reference material, plus 5,000 tokens of dynamic conversation, repeated over 20 turns. Without caching, that 15,000-token static block gets billed in full on every one of those 20 calls, meaning content that never changed gets paid for 20 separate times. With caching working correctly, you pay the elevated write price once, then the 90 percent discounted read price for that same block on the remaining 19 turns. The dynamic 5,000 tokens are billed normally every time since they're never identical between calls. Since the static portion is usually the bulk of the token volume in a long agentic session, this is where almost all the savings live. Exact dollar totals depend on your current model and rate tier, which you should check against Anthropic's API pricing page rather than assume, since rates get revised.

Making it work with the tools you actually have

Neither Cline nor Continue.dev ships a single "optimise for caching" switch as of the versions most people are running right now. What you can control:

• Keep custom instructions and rules files frozen during an active session, and treat any edit as the start of a new cache baseline.
• Avoid touching reference documentation the agent has already loaded, since even a comment fix invalidates the cached copy.
• Consolidate context into a few large stable files rather than many small ones that each shift independently, since fewer stable prefixes are easier for a tool's internal prompt assembly to keep consistent.
• Check your Anthropic usage dashboard for the ratio of cache read tokens to cache write tokens. Mostly writes and few reads means your context isn't stable enough to be paying off, and it's worth tracing exactly what's changing between calls before you assume caching is broken rather than misconfigured.

If you're running either tool for real development work and haven't looked at that read-to-write ratio yet, that's the first place to check. It tells you in about thirty seconds whether the discipline described above is actually landing, or whether something in your setup is quietly resetting the cache on every turn.