Code Repo Map Generator
Turn a file listing into a repository map that fits a token budget, folding directories rather than truncating the list.
17 files shown out of 17 read. This goes in front of every question you ask about the codebase, so it is a per-request cost.
- Files in your listing
- 17
- Files after the ignore list
- 17
- Lines of code covered
- 3,502
- Map characters
- 411
- Directories folded to fit
- 0
git ls-files there are none and the size columns say so rather than showing zero. The budget is met by folding whole directories, largest first, never by dropping files without saying which. Token figures are characters ÷ 4 and are estimates. Everything on this page runs in your browser. Nothing you paste is uploaded, logged or sent anywhere.A coding assistant that cannot see the shape of your repository spends its first three turns discovering it, and often guesses instead — which is where imports of files that do not exist come from. A map fixes that for a few hundred tokens, and unlike the files themselves it is small enough to sit in a system prompt permanently.
Why a budget, and why folding rather than dropping
The naive map of a real repository is thousands of tokens, most of them spent on directories the model will never touch. The fix is not to truncate — a list cut off at line 200 tells the model your project stops at the letter M — but to fold. A line reading node_modules/ …8,412 files costs four tokens and is honest; the same directory listed in full costs more than the code you are asking about. Everything folded is named underneath so you can disagree with the choice.
Line counts change what the map is for
A listing with sizes is a different object from a listing without one. With sizes, the model can tell which file is the 400-line component holding the logic and which is the 12-line barrel export, and it will ask for the right one. That is worth the extra command: git ls-files | xargs wc -l gives it, and this page reads that format directly, total line and all.
The flat list is the check
The second output is every path the map still shows. Paste it back into the input and you should get the same tree — same files, same folding decisions — which is the only way to be sure the tree above is a view of your listing rather than an artistic impression of it. It is also the more useful of the two outputs if you are feeding a script rather than a model.