Claude Code Slow and Costly? Check the Cache Prefix

Halfway through a long task you switch models. The first response is noticeably slower, the usage record shows a jump in cache writes, and the bill climbs with it. The natural first thought is that the cache is broken.

But switching models, changing configuration, compacting the conversation, and even stepping away for a coffee can each make responses slower and costlier, and each has its own cause.

To tell them apart, you first need to know what the cache actually reuses. Prompt caching reuses the stretch at the very start of a request that is identical, the prefix. While the prefix stays the same, only the newly appended conversation and tool results need processing.

When the prefix changes at some point, everything after that point is processed again. Billing for cache reads and writes, and how long entries last, come with their own conditions.

A prefix diagram makes the mechanism concrete, and then seven common changes get a look at what each does to the cache: switching models, changing tool definitions, using /compact, a long gap between requests, and more.

A sample usage record then lets you practice the call: a cache rebuild, a prefix that keeps changing, or a slow tool. Slow and costly can have many causes, the cache is only one of them, and the record comes before the conclusion.

When you need a stronger model or tighter permissions, the task's requirements outrank the cache.

01 The cache reuses an identical request prefix

When Claude Code calls the model, it assembles the system instructions, project context, the conversation and tool results, and the current input. The model works from what is available in this request, so content from earlier turns has to be supplied again as part of this request's context.

Prompt caching lets the server reuse input it has already processed when the prefix is identical. The Claude API prompt caching documentation describes the mechanism. The prefix is the unbroken stretch at the start of the request that stays the same. When a conversation simply grows, the front usually stays put:

Turn 1: [Stable instructions A][Project background B][Request C]
Turn 2: [Stable instructions A][Project background B][Request C][Response and new message D]
Turn 3: [Stable instructions A][Project background B][Request C][Response and new message D][New E]

Previously processed prefixes such as A, B, and C that still match → eligible for cache reuse
Newly appended content → processed next
Earlier content changes → subsequent content is reprocessed from the affected position

A match requires the actual request prefix to be identical and the cache conditions to be met. Rewording earlier rules with synonyms can break the match, while appending a new tool result at the end usually leaves the front eligible for reuse.

Prompt caching cuts the cost and delay of reprocessing identical input. It doesn't reuse the previous answer, enlarge the context capacity, or guarantee correct code. A new answer is still generated from this turn's input.

Cache reads come with billing and lifetime conditions. The documentation says cache entries last 5 minutes by default, and a 1-hour option is available. Whether a request hit the cache shows up in the actual statistics. What you want to know is whether this turn appended to existing content or changed the front that had already been processed. Models and integration conditions differ, so the request and usage records have the final say.

02 Which changes can invalidate the cache

Use the prefix diagram above to judge a change: is it only appended content, or did it alter the existing front? An identical prefix isn't enough on its own, because the model, the cache lifetime, and service conditions also affect reuse.

Installing a Plugin can have different effects depending on whether it adds only on-demand Skills or changes the set of tools at the front. The moment a configuration is written to disk and the moment the current request actually uses it often differ, too.

Choosing a suitable model, reasoning settings, and the tools you need at the start of a long task helps cut pointless changes. If the current model can't make a needed judgment, or a tool has to be restricted, change it anyway. A cache saves cost and waiting time, but when you need to adjust capability or tighten permissions, the task's requirements come first.

03 Editing files and editing rules affect the cache differently

Normal code edits leave the older read records already in the session as they were. Reading new content later appends fresh information to the history, so the front usually stays eligible for reuse.

Root-level and user-level CLAUDE.md files usually load at the start of a session. If you edit the file on disk midway, the version already loaded is still the old one. To confirm that new rules took effect, look at what loads after a clear, a compaction, or a restart. Whether the cache changed, whether the new rule took effect, and whether the rule content is still correct are three separate questions.

A normal permission-mode change usually leaves the existing prefix alone as long as the model and the tool definitions stay put. If it also triggers a model switch, analyze it as a model change. A Skill or command that adds content where it's invoked usually counts as an append, whereas re-summarizing and replacing history is different. Judge by the actual change.

04 Read a usage record to judge a cache problem

Here is a usage record from a long task. The table is a teaching scenario that only demonstrates the judgment:

Statistics can help judge a cause, and pinning down the root cause often takes other clues too. High cache writes, for example, can also come from a lot of new input, so read them together with the read volume, the input size, the time gap, and configuration changes. A single response time mixes input processing, output generation, the network, and tool waits, so split it apart.

Back to the record at the start: cache writes rose on the first turn after the model switch, and reads resumed in later turns. That fits a one-time cache rebuild. If the new model really suits the task better, see whether later turns stay stable and then decide whether anything needs adjusting. A single cache rebuild that doesn't get in the way of finishing the task can simply be watched.

Change the conditions: the model wasn't switched, but the tool definitions are rebuilt differently before every call, and the cache keeps rebuilding. Now the tool-loading strategy deserves a look.

05 Save state before you compact, then weigh the cache

Compaction replaces part of the history, and it can lose the reasons for decisions, temporary constraints, and unverified state. What to keep and how to write a handoff are covered in Claude Code session getting messy? Clear or compact This section adds only the cache tradeoff.

Compact at a stage boundary, after you've organized the state: exploration is wrapping up and you're about to build, or the code is done and you're about to verify. A line like "session-restoration logic changed, unit test passes, browser refresh not yet verified" separates changes, results, and gaps, and it helps you continue better than "nearly done."

Compaction changes the conversation cache. When deciding whether to compact, compare the current information load, what later tasks need, and the cost of rebuilding. In versions that can show statistics, /usage shows cache information, and the costs documentation has a Prompt cache statistics section. Elsewhere, look at the real API usage records. First confirm whether it was a cache miss or time spent in tools, the network, or output generation, and then adjust.

After a cache hit, whether the code is right is still to be verified. When the slowness is solved, whether the feature is fixed needs its own confirmation. Slow, wrong, and outdated configuration are three kinds of problems, and the next article, Five checks that prove AI-written code works, covers the last two.