An AI coding agent works from the files on your disk, and its context window is finite. Every file it reads spends from the same budget as your real code — so when a search pulls in a committed lockfile, a minified bundle, or a folder of vendored dependencies, that budget goes to noise, and the agent has less room for the code and the instructions that actually matter. It's a large part of why an agent keeps losing context. ContextPruner's whole job is to keep that budget on your code.
The idea: your code is signal, the machinery is noise
A repository is two kinds of files. There's the code you wrote — every bit of it worth the agent's attention — and there's the installed machinery your tools generate around it: dependency directories, build output, lockfiles, caches, minified files, coverage reports. On a typical project the machinery outweighs the source by a thousand to one in bytes. None of it teaches the model anything about your project, but any of it can leak into a prompt and crowd out the parts that do.
The fix is old and simple: tell the agent which files to skip. The hard part isn't knowing that — it's doing it well across every tool you use, writing rules a machine can act on, and keeping them accurate as the repo grows and the junk set drifts. That is the gap ContextPruner fills.
What it never sees
The design starts from a hard privacy line: your source code never leaves your machine. To decide what to skip, ContextPruner needs to know only what files exist and how big they are — a listing of paths and byte sizes. It never reads, uploads, or stores the contents of a single file.
- The free tier runs in your browser. You paste a listing of your file tree and it's analyzed with JavaScript on your own machine — no network request is ever made with it.
- The paid automation sends paths and sizes only. When you wire up the GitHub Action or pre-commit hook to keep your config files current, your machine sends the path-and-size listing, our API returns the config text, and your own runner commits it. We never receive file contents and never hold your repository credentials.
- The runtime filter stays local. The paid on-machine filter reads real file contents to do its work, which is exactly why it runs entirely on your computer and sends nothing back — the only thing it ever shares is two aggregate counts, and only if you opt in. See our privacy page for the full accounting.
How the pieces fit: generate, lint, enforce
ContextPruner reads your file listing, decides for each path whether it's code worth keeping or machinery worth skipping, and turns that into rules the agents can use. Three stages build on each other:
- Generate. From one file listing it writes the config files each agent reads — the advisory instruction files (
AGENTS.md,CLAUDE.md,GEMINI.md, Cursor rules, Copilot instructions) with the “skip these” list filled in, plus a matching set of enforced ignore files. It also shows you, in conservative and fully itemized terms, what the junk is costing your context budget. - Lint.A config written months ago quietly stops matching a repo that kept changing. Lint checks an existing config against your current file tree and grades it, flagging rules that no longer match, junk that isn't covered yet, and configs that disagree with each other — so the advice stays honest as the code drifts.
- Enforce. This is where the rules gain teeth, in three tiers of increasing firmness — covered next.
The Enforce stage is layered on purpose, because agents give you different amounts of leverage:
- Advisory. The markdown instruction files ask the model to skip the junk. It reads them and usually complies, but nothing stops it from opening a file anyway.
- Enforced. Some agents support ignore files their own harness applies —
.cursorignore,.geminiignore,.codeiumignore, and Claude Code's settings deny rules. There the tool layer blocks the read before the model sees the bytes. It's a best-effort block, not an airtight seal, but it doesn't depend on the model's cooperation — how enforcement works. - Runtime filter (paid). The firmest tier runs on your machine and drops junk paths out of broad, repo-wide searches — the moment junk floods in as pure noise — while leaving a pointed read of a named file untouched. It never hides results silently: each filtered search says how much it dropped and gives you a one-step way to see everything.
Generating the rules, checking them, and enforcing them is a full loop, and the $9/month tier keeps every file current on each push so the configs never drift stale. What ContextPruner deliberately keeps to itself is the recipe underneath — exactly how it classifies each path and derives each rule. The point of this page is the philosophy, not a blueprint.
Why not just write an ignore file yourself?
You can, and for a small, stable repo you probably should — an ignore list in AGENTS.md is a real, free win. ContextPruner earns its place on three things a hand-written list struggles with. It covers everyagent's file format from one source instead of you maintaining five. It stays current automatically as the repo grows, rather than going stale the week after you write it. And it measures the cost honestly, so the decision is grounded in numbers you can check rather than a guess. For a fuller comparison of the approaches, see AI context tools compared.
What ContextPruner doesn't do
Being clear about the edges is part of the point:
- It doesn't read, route, or store your code. The engine works from paths and byte sizes; the on-machine filter that does touch contents never sends them anywhere.
- It doesn't rewrite or summarize your files. It decides what the agent should skip; it never alters what it keeps.
- It doesn't overstate the savings. Every figure it shows is bounded and truncated so it can't read higher than the truth, and the full formula is printed so you can check it by hand — the math is defended question by question.
- It doesn't decide for you. When a rule is wrong for your repo — a fixture your tests depend on, a doc you want read in full — you pin the exception and your instruction wins.