Developer Spent a Month Watching Agents in His Codebase: A File Tree Costs More Than JSON

A year ago, the author of this Habr piece copied files into a chat window one at a time. Today agents read his project themselves through an MCP server, and he spent a month watching what exactly they pull into context. The conclusions are practical. A text file tree costs more than JSON, a build folder can't be excluded by name, passwords can be hidden in a way that stops the code from working, and an agent left uncontrolled manages context far more wastefully than you'd expect.

The original article is available only as an announcement, so what follows covers the stated points and the engineering logic behind them. For the author's exact measurements, see the original source.

Why a tree costs more than JSON

Intuitively, it looks like the opposite should be true. A tree with indentation and box-drawing characters is easy on the eyes, while JSON with its quotes, brackets and repeated keys looks redundant. But a model counts tokens, not characters. Branch symbols, long runs of spaces and repeated path prefixes tokenize inefficiently. This is our assumption about the mechanism; the author may have explained it differently. The conclusion itself is worth testing on your own repository: for a large project, the cost gap grows with the number of files.

MCP plays a special role here. The protocol turns reading a project into a set of tool calls: file listing, file contents, search. The response format of each call lands in context in full, and every agent request pays for it.

The build folder and passwords

The second lesson is about filtering. A rule like "skip folders named build" looks reasonable until the project has a directory with the same name that holds source code rather than build artifacts. It's more reliable to look at what the folder does: whether it appears in .gitignore, whether the build generates it, and how long ago it last changed.

Secrets are harder. If you simply cut out the line with a password, the configuration stops parsing, and the agent starts fixing something it effectively broke itself. A workable approach is different: put a placeholder in place of the value while keeping the file's structure, the key and the data type. The code stays readable, and the real secret stays outside the context.

An agent without supervision

The author describes the most interesting thread briefly: what an agent does with context when no one is watching. The typical symptoms are familiar to anyone who has run long sessions: re-reading the same files, loading unnecessary directories, and bloating the window with old tool results. Each of these steps costs tokens and degrades the quality of answers, because the useful signal drowns in noise.

• Project description format: a text tree costs more than JSON.
• Filters: a folder name is not good enough as the only criterion.
• Secrets: mask values instead of deleting lines.
• Transport: the MCP server as a single point of control over what the agent sees.
• Risk: uncontrolled context growth in long sessions.

Where to start checking your own project

First, look at what actually goes into context. If your MCP server or agent harness doesn't log response sizes, add a token counter to every call. Without one, there is nothing to optimize.

Next, compare formats. Run the same repository through a tree and through compact JSON, and compare the token counts. Then revisit your exclusion rules: rely on .gitignore and signs of generated files, not on a list of names.

Finally, mask secrets before the data goes to the agent, not after. Check that the masked config still passes the parser. And give the agent a budget: a limit on context size and on the number of repeated reads of a single file. That way a month of observation turns into a set of rules rather than a one-time surprise.