Last updated: July 2026
Agents re-read the same file because their only memory is the context window — after a compaction, a long gap, or a summarization step, the file falls out and gets pulled back in. Each re-read re-adds that file's full token count. Stop it by naming exact files upfront, pinning them in context, committing your work, and keeping sessions short and focused.
If you have ever watched your coding agent open the same file three times in one session, you have watched money leak. Every re-read re-injects that file's contents into the context and bills you for the tokens again. It is one of the quietest cost drivers in agentic coding — and one of the easiest to fix once you understand why it happens.
When an agent reads a file, the file's contents are injected into the conversation as input tokens. Read a 2,000-line file once and you pay for ~15,000-25,000 tokens. Read it again later in the same session and you pay for those tokens a second time — and, because context accumulates, that content then rides along on every subsequent turn too.
A single duplicate read of a large file can add more to your bill than a dozen typed prompts. The frustrating part is that the re-read usually adds no new information: the agent already saw the file, it just forgot. Understanding why it forgets is the key to stopping it. For the bigger picture on where tokens go in a session, see our breakdown of AI coding agent costs.
This is the root cause of nearly every re-read. An agent has no persistent memory of your files. Its entire working memory is the context window — the running transcript of the session. If a file's contents are in that window, the agent "knows" the file. If they scroll out, the agent's knowledge of that file is gone, and the only way to get it back is to read the file again.
So the agent is not being wasteful for its own sake. From its perspective, re-reading is the correct move: it needs the file to complete the task and can no longer see it. The token cost is real, but the behavior is rational. That reframe matters because it tells you the fix is about keeping the file in the window, not about scolding the agent.
The most common trigger is a context reset. When you run /compact in Claude Code, or the tool auto-summarizes a long session, earlier turns — including file contents — are collapsed into a short summary. The summary might say "read auth.js and refactored the login handler," but the actual lines of auth.js are gone. The next time the agent needs a detail from that file, it re-reads the whole thing.
Long gaps do the same thing more gradually. In a session that runs for dozens of turns, the earliest file reads eventually fall out of the window as newer content pushes them out. The agent hits a moment where it needs code it read forty turns ago, cannot see it, and reads it again. If you want to reduce how often this happens in Claude Code specifically, our guide on reducing the Claude Code context window covers how to keep a session lean enough that fewer things fall out.
The other big trigger is you. When you tell an agent "look around the codebase and figure out how X works," you are explicitly authorizing it to scan — open directories, read files, follow imports, and read more files. Broad instructions produce broad scanning, and broad scanning re-reads the same shared files (config, types, the main entry point) over and over as it chases different threads.
Under-specified tasks also make the agent wander and self-correct, and each loop tends to re-open the files it already touched. A vague prompt does not just cost more once; it sets the agent up to keep re-reading for the rest of the session.
Every fix below does one of two things: keeps the right files in the window, or removes the reason to re-scan. Combine a few and duplicate reads mostly disappear.
src/auth.js and src/session.js, change the token expiry to 30 minutes." When the agent knows precisely what it needs, it reads those files once and gets to work instead of scanning to find them./add. Adding files with /add keeps them in the chat context deliberately, so the agent has them without re-reading. See our Terse for Aider guide for how this fits a tight-context workflow.@filename, tells Cursor to keep it in context rather than rediscovering it each turn.parser.py") gives the agent nothing to wander toward. Specificity is the single highest-leverage habit for cutting re-reads.You cannot fix what you cannot see. The plain signal is in the tool-call log: scroll back and look for the same read operation hitting the same path more than once. If you see read auth.js at turn 4 and again at turn 22, that is a duplicate you paid for twice.
Because scanning logs by hand is tedious, Terse watches for this automatically. When a file has been read multiple times in a session, Terse flags it with a light-touch notice — not a nag, just a visible signal that a duplicate read happened, so you can decide whether to pin the file or tighten the task. Making the re-read visible is usually enough to change the habit. And if you want to estimate the token cost of a given file before you ever hand it to an agent, our token calculator gives you the number.
Terse monitors your agent session on-device, flags when the same file is read more than once, and tracks per-turn token cost — so re-reads become visible instead of silent. No API calls, no latency.
Terse for Claude CodeThe agent's only working memory is its context window. After a /compact, a long gap, or a summarization step, earlier file contents fall out of that window, so the agent re-reads the file to see it again. Vague instructions like "look around the repo" also trigger repeated scanning.
Yes. Each re-read injects that file's full contents into the context again and is billed as input tokens. A single large file read three times in a session is billed three times, on top of riding along in later turns.
Name the exact files it needs upfront instead of saying "explore the codebase." In Aider use /add to pin files in context; in Cursor pin or @-reference them. Commit your changes so the agent does not re-scan a dirty tree, and keep sessions short and focused.
Watch the tool-call log for repeated read operations on the same path. Terse flags when a file has been read multiple times in a session with a light-touch notice, so duplicate reads are visible before they inflate your bill.