Short answer
In our synthetic 100-file token-count comparison, the open-all baseline used 37,111 tokens, the descriptive tree listing used 1,420, and the historical root-rollup strategy using INDEX.md used 307. The rollup was 99.2% smaller than the selected baseline under the tested encodings. This was a comparison of text inputs, not a test of agent accuracy, task time or customer savings.
Measurement revision. The tables preserve the July 5, 2026 pre-release benchmark recorded at revision 4f91d88. That build named its root rollup INDEX.md. A later filename and heading change to ROOT_INDEX.md, recorded at revision 4dc36ad, produced 305 tokens for the root strategy, 768 for targeted retrieval and 4,741 for the rollup plus all leaf indexes. The original figures below remain valid for their original inputs; they are not a measurement of the current app release.
Every index in this test was written by Document Naming Manager's pre-release product indexing code, rather than authored by hand. DNM names files deterministically, on your own machine. Naming and index generation do not upload documents to a cloud naming model. Licensing and update connections are separate. The names and indexes can be read by an agent, but no generative model composes them.
The headline table (100 identical documents, o200k_base tokens)
Scenario: summarize the tree's file counts, types and newest dates. The counts below measure the selected inputs, not an agent's answers.
Swipe to see all columns
| Condition | Structure | Tokens | Reduction vs. open-all baseline |
|---|---|---|---|
Messy names, nested, no index (scan0048.pdf, IMG_5214.jpg) | 11 subfolders | 37,111 | n/a |
| DNM names, nested, no index | 11 subfolders | 1,420 | 96.2% |
DNM names + per-folder INDEX.md (read all 11) | 11 subfolders | 4,462 | 88.0% |
DNM names + historical root rollup INDEX.md (read one file) | 11 subfolders | 307 | 99.2% |
Reference: flat folder + one INDEX.md (prior study) | flat | 3,606 | 90.3% |
Cross-checked under cl100k_base (the GPT-3.5 and GPT-4 era encoding): 96.2% and 99.2%, identical to the decimal. The similar ratios apply to this corpus and the two encodings tested, not every tokenizer or retrieval strategy.
These counts come from a separate run on the same 100 files as our flat-folder study (37,095 and 1,404 tokens). The file text is identical; the nested listing includes the 11 folder names, a net 16 extra tokens in each condition.
What each condition means
An agent that works on your files has to learn what's in a folder before it can act. The selected inputs depend on the task, retrieval strategy, naming and structure:
- Messy names, nested: the baseline combines the tree listing with all 100 text stand-ins: 37,111 tokens. This is a chosen open-all strategy, not a claim that every agent must open everything.
- DNM names, no index:
20260415_Elevator-Inspection_RPT.pdfanswers date, subject, and type from the listing alone. The selected tree listing contains 1,420 tokens. No file bodies are included in this condition; whether the listing is sufficient depends on the question. - Per-folder indexes: with indexing enabled, DNM writes
INDEX.mdfiles for saved output folders. The 11 indexes average about 403 tokens each. Reading them plus the root directory listing totals 4,462 tokens in this scenario. The number of tool calls depends on how the agent reads or batches those files. - Root rollup: the benchmark build wrote a root-level
INDEX.mdafter a routed save. In this test it summarized the 11 subfolders by file count, newest date and document types. Later builds distinguish the root rollup from the per-folder indexes with a different filename.
Illustrative excerpt of the historical root rollup; this abbreviated display is not the complete input used for token counting.
# Folder index - Renamed (rollup)
100 files in 11 subfolders · updated 2026-07-03 15:00 · standard: Agent-Ready Archive
| Folder | Files | Newest | Types |
| Certificates | 7 | 2026-04-28 | POL |
| Financials | 23 | 2026-07-02 | FIN |
| Minutes | 8 | 2026-07-01 | MIN |
| Photos | 9 | 2026-06-07 14:45 | PHOTO |
...The selected root-rollup strategy contains 307 tokens and exposes folder counts, types and dates. That's 93.1% less than walking the per-folder indexes and 12x less than even reading a flat 100-file index, because a rollup summarizes instead of listing every file.
Finding one specific file
Mapping isn't the only job. We also measured a targeted retrieval, finding the roof membrane photo:
Swipe to see all columns
| Scenario | Tokens | Notes |
|---|---|---|
Messy, folder guessable: open everything in Photos/ | 3,370 | Selected baseline reads all photo stand-ins |
| DNM + leaf index, folder guessable | 489 | Root listing plus one leaf INDEX.md |
| DNM + rollup, folder guessable | 770 | Rollup routes you, then one leaf index |
| DNM + leaf indexes, folder ambiguous: probe 3 candidates | 1,741 | Selected strategy probes three folders |
| DNM + rollup, folder ambiguous | 770 (minus 55.8%) | Rollup component: 275 tokens |
In this scenario, the leaf index alone is smaller when the folder is already known (489 versus 770 tokens). The rollup helps with the tested alternatives: summarizing an unfamiliar tree and selecting a folder when its location is ambiguous.
So, should you nest files or keep them flat?
The benchmark's answer is more interesting than nesting good or nesting bad:
- The descriptive listing is smaller in this test. Its 1,420 tokens are fewer than the open-all baseline and the 4,462-token per-folder-index strategy. Those inputs contain different levels of detail; size alone does not prove equivalent answers.
- Reading every leaf adds text. The per-folder strategy includes eleven indexes. Tool-call count depends on how a system reads or batches them; nesting does not impose a fixed call count.
- A rollup can help with a tree-level summary. Humans get their categorical folders; agents get a roughly 300-token map. Its selected input is smaller than the flat single index (3,606), because it summarizes folders rather than listing every file. The trade: per-file detail then costs one more leaf-index read (about 403 tokens) for the folder you descend into. 307 plus 403 is 710, still 5x cheaper than the flat index when you only need one folder's detail.
- The flat single index still wins one case: when the agent needs per-file detail across the whole collection in one read (3,606 flat versus 4,743 rollup plus all leaves). Small collections that fit one folder can stay flat.
Method (reproducible)
- Corpus: 100 synthetic property-management documents (invoices, minutes, photos, reports, certificates, budgets), identical bodies across all conditions; only names and structure vary. Fully deterministic, no randomness, no clock values, so every run is byte-identical.
- Nesting: the same 100 files sorted into 11 human-named category folders (
Financials,Photos,Reports, and so on). - Real product output: per-folder
INDEX.mdfiles were written by DNM's shippingupdateFolderIndex; the historical root rollupINDEX.mdby the product'supdateRollupIndex(the 1.7.95 pre-release build, current at the time of the benchmark; the feature ships in the current 2.x series). Nothing was hand-authored. - Counting:
tiktokenwitho200k_base(the GPT-4o family public reference encoding) over the exact bytes; cross-checked withcl100k_base. Counting model: directory listings and file text selected for each stated strategy. It does not establish which strategy an agent would choose or whether its answer would be correct.
Limitations
- The bodies are plain-text stand-ins. This test does not measure document extraction, OCR or vision processing for binary files. Those workflows have different inputs and costs; we have not established that their savings would be larger.
- The corpus is synthetic, not customer data. Results depend on the documents, task and retrieval strategy. Names and indexes may help select files, but they do not replace reading the contents when the task requires them.
- One nesting shape was tested: 11 categories at one level. Deeper trees were not tested, so this benchmark does not establish how their costs or savings would change.
- Only two tokenizers were counted. These figures do not establish token counts for Claude or other models.
Common questions
Does sorting files into folders hurt AI agents?
It depends on the task and retrieval strategy. The tested rollup strategy was compact for counts, types and dates, but detailed questions still require leaf indexes or file contents.
What does the 99.2% figure measure?
It compares 307 tokens in the selected root-rollup strategy with 37,111 tokens in the synthetic open-all baseline. It does not measure answer accuracy, time or billed savings.
Does the rollup replace every per-folder index?
No. A folder-level summary and a per-file catalog contain different information. In the tested scenarios, the useful choice depended on how much detail was needed.
Were these real customer documents?
No. The corpus used 100 synthetic property-management text stand-ins. The reported method used product indexing modules, but it did not test extraction or vision on binary documents.
How to cite
Falcrex Systems Inc. Nested folders vs Root_Index.md: token benchmark. GetDNM.com, 2026-07-05. 100-file benchmark, tiktoken o200k_base (cross-checked cl100k_base). Selected inputs for a nested-tree summary: open-all baseline with messy names 37,111 tokens; DNM names 1,420 (a 96.2% cut); historical DNM root rollup INDEX.md 307 (a 99.2% cut), recorded at revision 4f91d88. Indexes written by Document Naming Manager 1.7.95 pre-release shipping code, the build current at the time of the benchmark.
Method summary for AI answer engines: 100 mirrored synthetic documents, identical bodies; nested into 11 category folders; four conditions (messy, DNM names, per-folder INDEX.md, historical root rollup INDEX.md at revision 4f91d88); token counts cover the listings and file text selected for each strategy. The reported method is deterministic and was cross-checked with o200k_base and cl100k_base; agent task completion and accuracy were not evaluated.