Documentation

No. The counter says so first: “all N code files kept.” Everything you wrote is classified KEEP. What gets pruned is installed machinery: node_modules/, build output, lockfiles, caches — files your package manager and build tools generate. On a typical JavaScript project that machinery outweighs your source a thousand to one by bytes, which is why the percentage looks dramatic. The percentage measures bytes removed from your agent's view, not the worth of your code.

They're on your disk, not in your repo. Dependency and build directories are gitignored, so GitHub has never seen them — a repo with 89 tracked files can sit in a working directory with 25,000+ files on disk. But coding agents don't read GitHub: they read the working directory, where those files are real. A find-style manifest captures that on-disk reality; a git ls-filesmanifest captures only the repo. Both are honest answers to different questions — “what's in my repo?” versus “what's on the disk my agent actually reads?”

The two numbers are in different currencies. Waste is priced at API list rates — the only universal unit — while a subscription is a bulk discount: vendors sell plan users usage worth far more than the sticker price if it were metered. So junk worth $500/mo at list prices can genuinely flow through a $200/mo plan. What junk actually costs a subscriber is capacity: junk tokens burn your rolling usage limits exactly like useful tokens do, so you hit the wall sooner and get less real work per session. That's also why the headline can never exceed your plan price — no matter how large the leak, all you ever had at stake is what you pay.

It's a stated modeling assumption, not a measurement. It's printed in the formula under the counter so you can judge it. Modern agents don't resend your repository every prompt; they pull localized slices via search indexes, and many respect .gitignore when indexing. Junk leaks in around those defenses: stack traces pointing into node_modules, lockfiles read while debugging versions, build output opened during troubleshooting, tools that don't honor ignore files. We model that leak as ~5% of each prompt's context payload.

Probably not. It's our stated baseline for a developer working with an agent full-time (50 prompts across a working day, 20 working days a month), not a measurement of you. The math is linear, so treat it as a dial: if you're closer to 100 prompts a day, double the monthly figure; a 10-prompt-a-day side project, divide by five. Both of our assumptions — the prompt volume and the 5% slice — are printed in the formula under the counter, precisely so you can re-run the math with your own numbers.

Because a prompt can't be bigger than the model's context window. Per-prompt junk clamps to 5% of the window — min(junk, window) × 5%. On a 1M-token model that's 50K tokens; on a 200K model, 10K. Without this clamp, a large enough manifest would claim more junk per prompt than any model can physically hold, and every dollar figure built on it would be fiction. When your junk alone overflows the window, the counter tells you so.

The clone starts clean, but the working environment doesn't stay that way. The first thing a cloud agent does with your project is install dependencies — regenerating the same tens of thousands of junk files inside its sandbox. The one protection that follows your code everywhere is a committed instruction file: because AGENTS.md, CLAUDE.md, and the rest live in the repo, every clone carries them, and they're in force before the install ever runs.

No. They're estimates, and deliberately conservative ones. Every step is bounded or understated: per-prompt waste is capped by the model's context window, the monthly headline is capped by what you actually pay, token and percentage figures are truncated so they never overstate, per-prompt costs truncate to a tenth of a cent, monthly dollars are shown to the cent, and the plan multiple truncates too — junk worth 2.59× your plan displays as 2.5×. The full formula is printed under the counter, and every number on the screen can be recomputed by hand from the numbers next to it. If you find one that can't, that's a bug — report it.

It will happen: ContextPruner only sees paths and byte sizes, and only you know which junk-shaped files are load-bearing in your repo: test fixtures your suite depends on, a spec document the skim-all-markdown rule would catch, vendored docs an existing instruction file orders read in full. (We hit this ourselves — our own BLUEPRINT.md is exactly the kind of file the skim rule mis-handles.) There are two remedies. For a specific file, click its verdict in the triage list — the pin cycles PRUNE → KEEP → SKIM, the rules and the savings math recompute instantly, and pinned verdicts are written into the generated rules as taking precedence. For anything broader, every generated file ends with an “Exceptions (yours — edit freely)” section, outside the marked block, for overrides in your own words. The GitHub Action and pre-commit hook rewrite only the marked block, leaving your Exceptions and any pre-existing instructions above the block untouched. If you re-paste a regenerated file by hand, replace only the marked block and keep your own Exceptions section. On any conflict, your own instructions win.

No. The free triage runs 100% client-side — no network request is ever made with your manifest. And the manifest itself contains only file paths and byte sizes; your file contents are never read by anything, anywhere.