Your coding agent works from the files on your disk, and a surprising share of them are files it never needs to read: lockfiles, build output, vendored dependencies, generated types. Every one of those it pulls in spends tokens from the same context budget as your real code — and on a subscription plan, those tokens count against your daily and weekly limits, so you hit the wall sooner. It's a big part of why your agent keeps losing context. Here's how to cut them out.
What actually fills your context
First, an honest scoping, because the usual scare story is wrong: a well-behaved agent respects your .gitignore, so it is not reading all of node_modules on every prompt. The real culprits are narrower and more annoying:
- Committed junk. The big one is a lockfile you check into git —
package-lock.jsonis routinely 500 KB to well over a megabyte — 125,000+ tokens by the standard byte-to-token rule of thumb, and even a lighter 280 KB lockfile is about 70,000. All of it is tokens the model learns nothing from, and because it's tracked, it's fair game whenever the agent looks at dependencies or debugs an install. - Reach-arounds.When you ask the agent to “search the whole repo” or debug a build, it can pull in generated output and vendored code that a normal edit wouldn't touch.
- Repo sprawl. A project that starts at 40 files is thousands by month six — build caches, abandoned folders, vendored copies. The bigger it gets, the more of it is stuff the agent has no reason to read.
The fix: tell the agent what to skip
The most direct lever is an ignore list in the file your agent already reads — AGENTS.md, CLAUDE.md, or your tool's equivalent. A section like this pays for itself immediately:
## Don't read these
- package-lock.json, pnpm-lock.yaml, yarn.lock — lockfiles, huge and no signal
- dist/, build/, .next/, out/ — generated build output
- **/*.min.js, **/*.map — minified and source-map files
- coverage/, *.snap — test artifacts
- vendor/, third_party/ — vendored dependencies you didn't write
- *.png, *.jpg, *.pdf, *.zip — binaries the model can't use as textAdjust the list to your stack — a Python repo has .venv/ and __pycache__/; a Go repo has vendor/; a data project has large .csv and .parquet files. The principle is the same: anything generated, vendored, or binary is a candidate to skip.
A markdown ignore list is advisory — the model reads it and usually complies. Four agents go further and support ignore files their own harness applies as a best-effort block: .cursorignore, .geminiignore, .codeiumignore, and Claude Code's settings deny rules. If your agent is one of them, committing the enforced file means the block doesn't depend on the model's cooperation — how enforcement works.
A quick checklist
- Un-track generated files. If a file is produced by a build or install step, it usually belongs in
.gitignore, not the repo. (Lockfiles are the exception — teams commit those on purpose; just tell the agent to ignore them.) - Name the heavy hitters explicitly. Lockfiles,
dist/, minified bundles, source maps, coverage reports, snapshots, and large fixtures. - Point the agent at real code. Beyond an ignore list, say where the source actually lives (“work in
src/andlib/”) so it spends its budget there. - Revisit as the repo grows.The junk set changes over a project's life; a stale ignore list drifts out of date.
Measure it first
You can't trim what you haven't measured. ContextPruner takes a listing of your file tree (paths and byte sizes only — never contents) and shows you exactly how much of it is prunable, then writes all nine config files in one pass: the instruction files for AGENTS.md, CLAUDE.md, GEMINI.md, Cursor, and Copilot, plus the four enforced ignore files above. It's free and runs entirely in your browser, so your file list never leaves it.
Want the format details for the file you'll be editing? See What is AGENTS.md? and CLAUDE.md vs AGENTS.md.