Guides · Claude Code at scale
A big repo never fits in the context window. Set Claude Code up to find, not hold.
On a small project you can paste the whole thing in and let the model keep it in its head. A large codebase (dozens of packages, a handful of repos that ship together, hundreds of thousands of files) breaks that. The model can't hold it, so the entire job becomes retrieval: how fast, and how exactly, the agent finds the one file, symbol, or past decision it needs. Set Claude Code up around that single fact and it stops getting lost. Here is the setup, then the measurements.
New to the term? What the context window is, and why a large codebase can't live inside it.
TL;DR · Key takeaways
A big codebase never fits the context window, so the whole job becomes retrieval: set Claude Code up to find the one file fast, not to hold the tree in its head.
Four habits keep a session tidy: a lean CLAUDE.md, name the path, one concern per thread, checkpoint before the window fills. The fifth, fast whole-machine retrieval, is the one that keeps the agent from getting lost.
Claude Code greps one repo and Cursor indexes one workspace. Both stop at the repo you opened. A real product is several repos that ship together, plus the files outside git.
One always-fresh index across every repo answers filename lookups in 85 µs (139 µs median across 20 queries, 4.47M files) and content in 7 to 9 ms, turning a 71-call, 6m57s file hunt into a single 16 ms call.
Interlinked Files is that index: one install wires it into 19 AI clients, local and offline at ~44 MB at rest. Everything local is free forever, no card. Hosting starts at $5.99/mo.
Five things to set up, in order of impact
Four keep it tidy. One keeps it from getting lost.
None of this is a trick. It is the honest checklist for pointing Claude Code (or any agent) at a codebase too big to fit in its head. The first four are discipline. The fifth is infrastructure, and it is the one worth measuring.
Make CLAUDE.md a map, not a manual.
Claude Code re-reads it on every turn. Give it the shape of the codebase (where the packages live, the conventions, the one line that says “this ships with those three repos”), then stop. A bloated project file is a tax you pay on every message, and it crowds out the code the model actually needs to see.
Say where, not just what.
In a tree of hundreds of thousands of files, “the rate limiter in packages/api” resolves in a fraction of the turns “find the rate limiter” does. A path is the cheapest hint you can give: the agent spends its budget editing, not hunting.
Scope each session to one concern.
One package, one bug, one feature per thread. Independent corners can go to subagents that explore in parallel without filling the main thread with everything they read. A big codebase punishes a session that tries to hold all of it at once.
Checkpoint before the window fills.
On a long run the context quietly fills with stale directory listings and file dumps the model keeps re-reading. Compact or start fresh before that point: on a large repo a clean window is routinely faster than a full one.
Give it fast retrieval across the whole codebase.
This is the one that decides whether the agent is lost. The four above trim overhead; this removes the reason it grinds. Instead of shelling out to walk the tree on every question, it asks a prebuilt, always-fresh index and gets the exact file back instantly. The rest of this page is about setting that up.
The recommended setup, in one picture
Agent, scope, one index.
The whole design collapses to three parts. The agent asks in plain language. You set one scope: whole-machine when you don't know where a thing lives, pinned to a path when you do. And the query hits one index that spans every repo on the machine, not just the one you opened. That last part is the large-codebase move: a real product is usually several repos that ship together, and an index across all of them is what stops the agent from getting lost between them.
Scope is the only knob you actually touch. Go whole-machine and the agent catches the file in the sibling repo (or the one outside git) that a project-scoped search never sees. Pin to a path and the same lookup returns in microseconds, because the answer set is a folder instead of a drive. Either way it is one tool call, not seventy-one, and the model spends its turn thinking instead of walking directories.
The two anchors · Claude Code & Cursor
Both see one repo. A big project is several.
The two agents most people reach for take opposite routes to the same place. Cursor builds an index of the repository you open and searches it well. Claude Code keeps no standing index and instead shells out to ripgrep, grep, find and glob to explore. Both are genuinely good at their job. Both share the same blind spot on a large codebase: they work on the one repo or workspace you pointed them at.
Searches with shell tools: ripgrep, grep, find, glob.
The directory you launched it in.
No standing index; it re-walks the tree on every query.
Builds an index of the repository you open.
That one workspace.
Re-indexes as the repo changes, still scoped to the workspace.
That gap is invisible on a single repo and painful on a real product. Your checkout is often a set of separate repos that ship together (an API, a web app, shared libraries, infrastructure) plus everything that never lives in git: build output, generated clients, an .env, the design doc in your Downloads with the answer. A repo-scoped tool can't look there, and it can't see that those repos belong together. Keep whichever in-repo tool you like; the setup a large codebase needs is a layer across all of them. How Cursor indexes your codebase covers the in-repo half in depth.
Measured, not claimed
What fast retrieval is worth, on a big checkout.
We measured the same single-file task with and without a whole-machine index, on a real 4.47-million-file machine, the scale of a serious multi-repo checkout, not a toy repo. Same model, same request. The retrieval floor is what moved.
| The searcher | What ran | Time | vs Interlinked |
|---|---|---|---|
| Interlinked Files | one indexed filename lookup | 85 µs | baseline |
| VS Code (Ctrl+P) | same file, same drive | 35 s | 412,000× |
| Windows Search | median of 20 queries | 67 s | ~480,000× |
| ripgrep | same content query, same corpus | 93.8 s | 58,625× |
| Claude Code (no index) | one file, agentic archaeology | 3 m 13 s | 2,276,000× |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename lookups are microsecond-scale (85 µs single, 139 µs median of 20 queries; median, not best case). The ripgrep row is the same content query, content-to-content (93.8 s → 16 ms; 58,625× across the five-query set, 5.6 ms mean). The Claude Code row is a measured single-file agent run given no index. Full per-tool method in the 412,000× VS Code write-up and the ripgrep comparison. The single lookup alone is 2,276,000×; the full agentic task collapses more than seven-million-fold when the answer is one indexed call instead of seventy-one filesystem walks.
The recommended setup, named
One index across every repo. Plus the map between them.
Interlinked Files is that whole-machine index, exposed to any agent over MCP. One signed install wires up 19 AI clients (Claude Code and Cursor among them) with no JSON to edit. It holds names and contents for every repo on the machine plus the files outside git, answers filename lookups at 85 µs (139 µs median across 20 queries) and content in 7 to 9 ms, and stays fresh: save a file and it is searchable again in about a millisecond, under 30 ms worst case. Local, offline, nothing leaves the disk. At rest the whole engine sits around 44 MB and the on-disk index stays under 1% of the drive.
And because it sees across repos, it can record what no in-repo index can: that this folder is a set of separate repos that ship together, which files change together, which repos share hundreds of identical files. On a fresh machine it found 12 of 12 repos and replayed 8,455 git events in 1.7 s into 26,958 relationship pairs. No model in the loop, just receipts. That map is fed back to the next agent on the searches it already runs. Speed finds the file; the map knows why it matters.
ONE INSTALL · 19 AI CLIENTS · EVERY REPO ON THE MACHINE, NOT JUST THE ONE YOU OPENED.
FAQ · Common questions
Common questions. Straight answers.
The things people check before they wire an agent to a codebase too big to fit in its head: same setup, same numbers as above.
Why can't I just paste the whole codebase into the context window?
A large codebase (dozens of packages, several repos, hundreds of thousands of files) is far bigger than any context window, so the model can't hold it. The entire job becomes retrieval: how fast, and how exactly, the agent finds the one file, symbol, or past decision it needs.
Does Claude Code index my project the way Cursor does?
No. Claude Code keeps no standing index: it shells out to ripgrep, grep, find and glob and re-walks the tree on every query. Cursor does build an index, but only of the single workspace you open; both stop at the one repo you pointed them at.
What's the single highest-impact thing to set up for a big project?
Fast retrieval across the whole codebase. A lean CLAUDE.md, naming the path, one concern per thread, and checkpointing early all keep a session tidy, but the move that stops the agent grinding is giving it a prebuilt, always-fresh index it can ask instead of re-walking the tree.
How much faster is an index than grepping the tree?
On a 4.47-million-file machine, a filename lookup returns in 85 µs (139 µs median across 20 queries) and content in 7 to 9 ms. The same content query took ripgrep 93.8 s versus 16 ms from the index (58,625×), and a no-index Claude Code file hunt of 6m57s across 71 tool calls collapses to a single 16 ms call.
Is it local, and what does it cost?
Everything stays on the machine (local, offline, nothing leaves the disk, ~44 MB at rest) and a saved file is searchable again in about a millisecond. Everything is free forever, no card. Hosting starts at $5.99/mo.
Do this today
Set Claude Code up for scale in one install.
Install once. One signed installer wires up 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No claude mcp add, no JSON to edit.
Let it index the whole tree. Filename search works immediately; contents fill in behind it, across every repo. At rest the engine sits around 44 MB and the index stays under 1% of the drive.
Pin a path when you know; go whole-machine when you don't. Scoped queries return in microseconds; whole-machine catches the file in the sibling repo (or outside git) that a repo search would miss.
Keep CLAUDE.md lean. Stop pre-pasting file trees to orient the agent. Let it ask the index instead. That is the move that takes the search tax on a big codebase down toward zero.
Everything (the app and the MCP index every client plugs into) is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.
Related: How to make Claude Code faster · How to set up an MCP server in Claude Code.