Why 2 short messages can use so much of an AI agent's limit

Updated 11 November 2026 · Who measures this.

Your message is short, but the request is not. A coding agent sends the whole conversation with every step, and in Claude Code, after a long pause, it has to write all of that to the cache again, the costliest kind of input. We measured it in our lab: 18 days of token logs and 2 controlled tests in Claude Code, across 4 Macs.

Short answer. In those logs, 60.7% of everything written to the prompt cache came from returning to a conversation after its cache had expired. The median return to a main conversation wrote 449,620 tokens. The median new conversation started at 31,435. In our test, a return after 55 minutes wrote 65 tokens and a return after 61 minutes wrote the whole conversation. When we gave the same task after a 70 minute pause, a new session wrote about 8% of what the return wrote, and compacting before the pause about 25%, and the task got done every time. If you have stepped away from a big session, go back only for the work that belongs in it, and start anything new in a new session.

That is 19,416 requests over 18 days, including subagents. The sessions in these logs are very long, some close to 900,000 tokens, and shorter sessions will show smaller numbers.

One morning in the log

By 10:04 that morning the log held 22 requests: 2,759,335 tokens written to the cache, 13,936,467 read from it. The model's output was at least 11,014 tokens, since the log undercounts it. Of those requests, 4 made up 99% of the writing:

The 42,876 tokens that survived are the start of every request from that project folder, the agent's own instructions and tools, kept warm by other sessions there. Everything after them, the conversation itself, was written again. The fourth row is a different conversation, idle for 2 days, and not even the start of the request was left. The third is the odd one, and we come back to it below.

What happens on every step

The model keeps no memory between requests. Each time the agent acts, it sends the conversation again, along with the new tool result. A cache lets the provider skip most of that work if the start of the request matches what it saw before, exactly, token for token.

So a one-line question in a conversation that holds 800,000 tokens is an 800,000-token request, most of it read from the cache at a fraction of the price. Anthropic's documentation says the same: Claude Code “re-reads that history at the cached token rate, so a one-line question in a session that has been open all day still draws usage for the whole conversation.”

How long the cache lasts

It depends on who is asking. In Claude Code, the main conversation on a subscription, within its included usage, gets 1 hour. By default subagents get 5 minutes, API keys get 5 minutes, and once you go over your plan's limit and draw on usage credits, the main conversation drops to 5 minutes too. The settings promptCacheTtl and subagentPromptCacheTtl change these. Each read restarts the clock (prompt caching in Claude Code).

Past that time, nothing is left to read, and your next message writes the entire conversation again. Newer versions can compact a long conversation left idle on the 1 hour cache before it expires (the idleCompaction setting); in our logs, returns after a pause still wrote the whole conversation.

We tested the hour

We ran 48 short conversations in Claude Code on Haiku 5.5 at low effort, on the MacBook Air M2 and M5. Each one had a first request, a second one 20 seconds later, a pause, and a return. Half the conversations held about 12,000 tokens and half about 56,000.

The whole conversation meant 11,546 to 11,573 tokens at the smaller size and 55,796 to 55,823 at the larger. The 649 is the start shared by every request in this test, which ran with tools turned off. Both Macs agreed at every pause. The line sits somewhere between 55 and 61 minutes, and we did not narrow it further. Size changed the price of going cold, and not the moment.

One real conversation showed the same. One long conversation on the MacBook Air M2, over 6 days, made 482 requests less than an hour after the previous one, above 20,000 tokens, and none of them lost the cache. Of 13 requests after more than an hour, 12 did. We did not look into the exception. Those 12 returns wrote 1,541,624 of the 1,986,969 tokens written there in those days, 77.6%. The median return wrote 115,189, about 26% of the 449,620 above, so a smaller conversation pays less each time and pauses can still make up most of what it writes.

What was written, over 18 days

Reading is the other half. The same 18 days read 7,550,139,476 tokens, 57 for every token written. Requests above 400,000 tokens made up 67.1% of it.

By API list prices, which are not the scale your plan limit uses, reading came to 55.6% of the total, output included, and returns after a pause to 22.2%. On Opus 5.5 a 1 hour cache write costs 2 times the base input price and a read 0.05 times, so for the same conversation one cold return costs as much in cache charges as 40 warm steps. We found no published figure for how a subscription weighs these, or for how tokens turn into a percentage of your limit. The next section is our own reading for one account.

How that lands on one plan limit

One account, an earlier month, a different model. The Claude desktop app kept limit readings every 5 minutes while it was open, 2,615 over 31 days, so we could set them against the 60,799 requests logged in those days. Almost all of them ran on Opus 5.

Each point of the weekly limit went with 0.52 to 1.29 million tokens written to the cache, across 7 stretches between resets. Over the 24 windows of 5 hours in which the limit rose by at least 15 points without reaching 100%, it tracked writes (correlation 0.94) more closely than reads (0.80). A fit put a read at 0.0086 of a write, with a 90% range from 0 to 0.022. On Opus 5, list prices put a read at 0.05 of a 1 hour write (0.025 on Opus 5.5). In that fit writes accounted for about two thirds of the limit used and reads about a quarter.

So for this account, a cold return mattered more to the limit than the price table suggests. Writes and reads rise together, so the weight of a read is poorly pinned down. The meter shows whole percentages. Usage from other devices and from chat counts in the percentage and is missing from these logs. 2 resets that month came mid-week for reasons we do not know, and the vendor can change the rules at any time. Treat this as a direction for one account, and not as a rate for yours.

When the cache breaks without a pause

Compaction aside, 7 of 19,416 requests lost the cache within its lifetime. 3 were model switches. 1 was the client dropping a batch of the oldest images before a request would pass its image limit, which rewrites the conversation from the first removed image onward, as the documentation describes. 3 we cannot explain.

The 17 second case is one of those 3. The client's own log shows the same first 1,644 messages, the same tools and the same settings. The request 17 seconds earlier read 868,005 tokens, and the next one read 868,303. We looked for a restart, a tool change and an edited instruction file and found none. Why the cache was missed is not visible from this side.

On this account it used to be much worse. In one earlier stretch of 42 days, 333 of 1,108 messages typed by a person into conversations above 20,000 tokens reset the cache within its lifetime. In a later stretch of 49 days it was 2 of 4,052. We cannot name the cause from these logs, and the vendor's changelog lists many separate fixes. Resets like these would make a limit melt with nothing visible changing. Whether they explain what other people reported, one account's logs cannot tell, and they do not reproduce here today.

What people find confusing

We read 116 excerpts from GitHub issues, forums and Hacker News about Claude Code, Codex, Gemini CLI and Cursor, and counted threads, since one loud thread is still one thread.

1. The meter and the logs use different units. Limits show a percentage, logs show tokens, and people end up deriving the conversion themselves. This was the most common topic, and it appeared for all 4 agents.
2. The limit went faster and nothing changed. Fewer threads, but the largest ones. Sometimes a real defect: in a published postmortem Anthropic described a bug that, in a session idle for more than an hour, dropped earlier reasoning from every later request, so each one missed the cache, and named it as the likely cause of limits draining faster than expected.
3. Why a tiny edit shows huge cache reads. Mostly Cursor users. For Claude Code the answer is in What happens on every step; Cursor we did not measure.
4. How much subagents, MCP servers and rules add. Advice is plentiful and measurements are rare.
5. What a pause or a resume costs. Almost entirely Claude Code. We found no such thread for Codex or Gemini CLI, so what we measured here should not be carried over to them.

Some popular explanations did not hold up. Duplicate lines in a local log were taken for double billing. A reported 340 million tokens for one Codex subagent turned out to be double counting. Count by request ID, because one request writes several log lines.

We tested the advice after a pause

None of the 116 excerpts had before and after numbers for the usual advice, so we measured it. We generated a Python package of 30 modules and had Claude Code read all of it, which grew the conversation to about 145,000 tokens. Then came one task: add a function to one module with tests, and make the tests pass. Each round gave that task 4 ways, on identical copies of the package:

Medians of the 12 counted rounds on the 2 MacBook Airs, rounded to the hundred; the compact row includes the compaction itself. The cold return wrote the conversation again, 142,123 to 145,314 tokens. A new session wrote about 8% of that and compacting before the pause about 25%, and both wrote less than the cold return in all 12 rounds. Reading did not change the order: the new session and the compacted one read less too. The warm return wrote the least and read the most, because every step of the task reads the whole conversation from the cache. A new session beats it if a read counts for more than about 0.007 of a write. At list prices a read is 0.025 to 0.05 of a 1 hour write; our fit for one account put it at 0.0086, with a range from 0 to 0.022.

We wrote down before the first counted round what would make each tip stand: it had to write less than the cold return in at least 10 of 12 rounds and finish the task as often. The rounds ran in Claude Code on Haiku 5.5 at low effort, 6 each on the MacBook Air M2 and M5. The MacBook Pro M1 Pro, with a newer Claude Code, ran 6 more and gave the same shares, 7.8% and 24.3%. The session log and Claude Code's own running total agreed to the token on every task.

What this does not show. The task needed nothing from the conversation, because everything it needed was in the files. Real work often depends on what was said, and a new session then pays for explaining it again, which we did not measure. We did not try compacting after the pause. A bigger conversation makes the cold return dearer, and a new session does not carry it. And none of this is a percentage of a plan limit.

What to do

• Return to a big session only for work that needs it. A new topic goes in a new session. The price of this is explaining the task again. In our test a new session wrote about 8% of what a return after 70 minutes wrote.
• Compact before a break, not after it. /compact has to read the whole conversation, and after a break, Anthropic's documentation says, it reprocesses all of it as uncached input. We did not measure compacting after a break. Compacting right before a 70 minute pause wrote about 25% of what a cold return wrote, compaction included.
• /clear costs nothing. The next message starts a new conversation with a small cache of its own. Editing the CLAUDE.md at your project root or your user-level one mid-session neither breaks the cache nor applies until the next /clear, /compact or restart.
• Look before you guess. On a subscription, /usage (also /cost) in Claude Code shows what is driving your usage, and in recent versions, for the main conversation, cache misses, tokens re-cached and whether the cache is warm or cold.
• Read our numbers as a direction. The 8% and 25% come from one task, Haiku 5.5 and a 145,000 token conversation, the logs from one account, and nobody publishes how tokens turn into your limit.

The Macs and how we measured

What we do not know

The official conversion from tokens to your limit, or how reads and writes count in it. What happened on the server in the 17 second case. The cause of the earlier cache resets. The exact minute the cache expires, somewhere between 55 and 61. Whether the hour holds for other models and accounts, since the test used one of each. How the 8% and 25% move with a bigger model, a longer conversation or a task that needs what was said before. Anything about other Macs: the 18 days are one machine and one way of working.

Related: what AI tools cost a Mac battery · what Claude costs