Explainers · measured July 2026
Your AI runs out of room. Most of what filled it was junk.
Ask ChatGPT enough questions in one chat and it starts losing the top of the conversation. Point Claude Code at a large repository and it slows to a crawl, re-reading files it already opened. Same cause. And it is not a dumb model, it is a full one. Every model has a context limit: a hard ceiling on how much it can hold in mind at once. On a real 4.47-million-file machine we measured what actually fills that space during an agent's day, and the biggest tenant is not your problem: it is the exhaust from looking for files.
Start here · the definition
What a context limit is. And why yours keeps filling up.
A context limit is the maximum amount of information (measured in tokens) that a language model can hold in its working memory at one time.
Tokens are the fragments text is split into; very roughly, one token is about three-quarters of a word. Everything the model is working with shares that single budget: your instructions, the conversation so far, every file it has opened, the output of every command it ran, and the reply it is about to write. Fill the budget and the oldest material falls off the back, which is the exact moment ChatGPT starts losing the top of a long chat, and the reason an agent slows down on a big project as it re-reads what it already saw.
For the container itself and how tokens get counted, see what is the context window and what are LLM tokens.
- -A context limit is a fixed token budget: the model’s working memory. It does not grow mid-task.
- -Everything shares it: your instructions, the chat history, every open file, and every tool’s raw output.
- -On one measured agent run, about 58% of the tokens went to finding files, not to solving the problem.
- -Hitting the limit is usually a junk problem, not a model problem. The fix is to stop filling it with search exhaust.
- -An instant, always-fresh index answers where-is-it questions in one call (16 ms instead of seventy-one round trips), leaving the window free to think.
The same ceiling, two ways to fill it
Watch the window fill.
A context limit does not stretch. Every directory listing, every search dump, every wrong file the agent opens on the way to the right one lands in the same fixed box, and stays there, crowding out the reasoning you are actually paying for.
The ~58% figure is the measured share of one Claude Code session's tokens spent finding files on our test machine, the same errand detailed in the real cost of ls. Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files.
One real task · same machine · same drive
The same file hunt, with the window and without.
We watched an agent find one file the ordinary way (shelling out to directory listings and content search), then gave it an instant index and asked for the same file. Six minutes and fifty-seven seconds became sixteen milliseconds; seventy-one round trips became one. That is roughly a seven-million-fold difference, and every one of those seventy tool calls it no longer makes is output that no longer fills the window.
| Measured on one agent task | Hunting by hand | With an instant index |
|---|---|---|
| Time to the file | 6 min 57 s | 16 ms |
| Tool calls (each one dumps into the window) | 71 | 1 |
| Session tokens spent finding, not thinking | ~58% | ~0% |
Measured on one Claude Code session: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. The full dollar version is in the token cost of hunting for one file; the wider picture (why this is the slowest layer under every agent) is in the backbone of the LLM economy.
Why the window fills
Every search pours its results into the window, and leaves them there.
An agent cannot see your disk. To find anything, it runs a command and reads the output back into its context, and that output is verbose. A directory listing is dozens of lines. A content search across a real repository can be hundreds. Open the wrong file and its entire contents land in the window too. None of it gets thrown away mid-task; it all just sits there, occupying the fixed budget, until the useful material at the top starts falling off the back.
That is why the biggest tenant of the window is so often the least valuable one. About 58% of a measured session's tokens(more than half the working memory you are paying for) went to errands the model will not remember and did not need to see. The reasoning you actually wanted gets whatever room is left. A bigger context limit does not fix this; it just gives the exhaust more room to spread. The fix is to answer the question without the exhaust: one clean lookup instead of dozens of noisy tool calls.
The reclaim
Answer the question once. Keep the window for thinking.
An instant, always-fresh index turns where is it? into a single answer. The agent asks once and gets the exact path (or the exact matching lines) back in about 16 milliseconds, faster than the roughly hundred-millisecond blink of an eye, then spends the rest of its window on your actual problem. Because the index stays warm in the background (around 44 MB at rest, less than one browser tab) and refreshes within about a millisecond of every save, the answer is always current. And a knowledge vault that reads your machine's own git history means the next session does not start from zero: it already knows which files change together and which repos share code, so the agent stops re-discovering the same project every time. Not a bigger context limit, a cleaner one.
Stop the leaks
Five ways a context limit leaks, and how to plug each one.
Directory archaeology. The agent runs ls, tree, and dir over and over to learn a layout it will forget, and every dump stays in the window.
Fix: One indexed lookup returns the exact path: nothing to scroll, nothing to remember.
Grep floods. A single content search across a big repo can pour hundreds of matching lines into context at once.
Fix: An indexed content search returns only the hits you asked for, in about 16 ms.
Dead-end reads. The agent opens four wrong files before the right one, and all four keep occupying the window.
Fix: The index points at the right file first, so only it gets read.
Re-hunting every session. A new chat forgets what the last one learned and rediscovers the project from scratch.
Fix: An always-fresh index plus a knowledge vault carry what was learned across sessions.
Cross-repo wandering. Walking folder by folder for something that lives in another repo, or in a git-ignored file a project search never sees.
Fix: One whole-machine query covers every repo and every file at once.
One signed installer auto-configures 19 AI clients (Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest) with no JSON editing. Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.
Questions people actually ask
Context limits, answered.
What is a context limit?
A context limit is the maximum number of tokens a model can hold in its working memory at once. Your instructions, the conversation, every file it has opened, and the reply it is about to write all share that one fixed budget. Exceed it and the oldest content is dropped.
Is a context limit the same as the context window?
Effectively yes: the window is the container, the limit is its size. People say “context window” for the space and “context limit” for the ceiling on it.
Why does my AI agent forget things in the middle of a task?
Usually because the window filled up. Long tool outputs (directory listings, search dumps, files it re-read) push earlier messages off the back. Trimming that junk helps more than a bigger model does.
How much of the context limit does file hunting really waste?
On a measured Claude Code session on our 4.47M-file test machine, about 58% of the tokens went to finding files rather than solving the task. An index dropped a 6-minute-57-second, 71-call hunt to 16 milliseconds and a single call.
How do I stop wasting my context limit?
Stop feeding it raw search output. Give the agent an instant index so “where is it?” is one clean answer instead of dozens of noisy tool calls, and let a persistent knowledge vault carry what it learned into the next session.