Short answer
In our synthetic 100-file token-count comparison, an open-all baseline used 37,095 tokens and a descriptive DNM-style directory listing used 1,404 tokens. That is a 96.2% reduction, or about 26x fewer tokens. We counted selected text inputs with GPT-4o's tokenizer; we did not measure agent accuracy, task completion time or customer savings. DNM suggests structured names using local deterministic rules. You review the names before saving. No cloud naming model or document upload is required.
Why file selection contributes to context size
A document assistant may inspect names, search results, metadata or file contents before selecting what to read. Text supplied to a model consumes context, and its token count depends on the actual text and tokenizer. The retrieval strategy matters as much as the filenames.
Opaque names give an agent little information for selecting files. It may need contents, metadata, search results or an index to decide what to read. Our benchmark uses an open-all baseline to make that information cost explicit; it does not assume every agent would follow that strategy. Token counts alone do not measure elapsed time or billed cost.
A descriptive filename provides a compact clue
Think about what a good name already contains. 20240314_Invoice_AcmeCorp_4187.pdf tells an agent the date, the document type, the counterparty, and an identifier, without opening the file. Multiply that by a folder of a hundred files and the directory listing becomes a table of contents that can help with file selection.
A descriptive filename puts selected information into the directory listing. That listing still consumes tokens when supplied to a model, but it may be smaller than the source contents. A consistent naming standard makes those fields easier to interpret; users still need to check that each name describes its file accurately.
What did we measure, and how?
We built a synthetic 100-file folder in three conditions and counted the selected text inputs for each condition. The benchmark is deterministic: the same corpus, scripts and tokenizer reproduce the counts. It is not an end-to-end agent evaluation.
- Corpus: 100 realistic documents (property-management records: invoices, leases, inspection reports, correspondence, photos-as-stand-ins).
- Tokenizer: tiktoken
o200k_base, the public reference encoding used by GPT-4o. We cross-checked every result withcl100k_base(the GPT-4 and GPT-3.5 encoding). - What the token count means: the size of the text inputs selected for our folder-summary scenario, not a measurement of whether an agent answered correctly.
Three conditions:
Swipe to see all columns
| Selected text input | Tokens (o200k_base) | Reduction vs baseline | Factor |
|---|---|---|---|
| Messy names plus all text stand-in contents (open-all baseline) | 37,095 | baseline | baseline |
| Descriptive DNM-style directory listing | 1,404 | 96.2% | 26x |
| Descriptive names plus INDEX.md catalog | 3,606 | 90.3% | 10x |
The result held across both tokenizers to within 0.1 of a percentage point (96.2% and 90.3 to 90.4%). The similar ratios across these two encodings do not establish the result for every tokenizer or task.
For this synthetic 100-file corpus, the descriptive listing used 96.2% fewer tokens than the open-all baseline. The ratio held within 0.1 of a percentage point across the two tested tokenizers. Answer accuracy and workflow savings were not measured.
The listing is smaller, but contains less information
Notice that "names only" (1,404 tokens) costs less than "names plus INDEX.md" (3,606 tokens). The listing was the smaller selected input in this comparison. Whether it is sufficient depends on the question; we did not test answer quality.
An index can carry more than a filename: original-name provenance, parsed fields and a catalog to read before selecting files. It can also provide text context for binary files. Whether that helps depends on the information required for the task.
What the benchmark does not establish
The baseline used text stand-ins, not OCR or vision processing of binary documents. Real folders, retrieval tools and tasks differ. Descriptive names and indexes can help select files, but this test does not show that binary workflows produce a larger saving. We did not measure agent accuracy, elapsed time, API charges or customer outcomes.
Do AI-friendly file names need an AI to write them?
No. DNM suggests names using local deterministic rules and your configured fields. That avoids generative naming calls; it does not establish savings for whatever agent later reads the files.
- Deterministic, not generated. Saved rules and the current batch inputs determine the suggestion, including any sequence number. No generative model is involved. Review inferred fields such as dates before saving.
- Local naming, not cloud processing. DNM processes naming inputs on your Windows PC without uploading documents to a naming service. Licensing and update connections are separate; information you choose to send through support is covered by the Privacy Policy.
- No generative naming-token charge. DNM does not call a language model to compose names. Software licensing, local computing resources and review time are separate costs.
Keeping the naming rules local makes the source of each field easier to inspect. Review the suggested values before saving; a predictable structure can still carry an incorrect date or description.
DNM's naming grammar is Division_YYYYMMDD_Description_TYPE in the default General standard (other standards may put the type before the description, grouping types after preceding fields match), and it ships with 12 built-in standards (general, Agent-Ready Archive, legal, investigation, corporate security, EMP Export Package, property/strata/HOA, accounting, insurance, construction, real estate, and Microsoft 365 MSP migration) so most teams start from a convention instead of a blank page.
The Agent-Ready Archive standard also writes an optional INDEX.md catalog of the folder, the third condition in the table, for the cases where a text catalog beats a directory walk.
How to make your folders agent-ready
- Pick or define a convention. Put the fields an agent will filter on into the name: a date in
YYYYMMDD, a type, a subject, an identifier. You can generate a starting convention with the DNM naming convention generator and export it as a policy file. - Inspect current names. The File Name Chaos Analyzer checks naming signals in your browser. Its score is not an agent-accuracy or retrieval-performance test.
- Rename in bulk, reversibly. DNM suggests names for imported files, including files queued by Watch Folder. Review and save the names; Recovery Vault can undo eligible recent saves subject to settings, storage limits and unchanged files.
- Evaluate a catalog where useful. An Agent-Ready Archive catalog can provide text fields for file selection. It does not replace opening a document when the task needs its contents.
- Keep it local. DNM's naming workflow processes documents locally without uploading them to a naming service. Apply your organization's handling rules for sensitive material and review the proposed changes.
The token-count experiment does not measure human search time. To explore that separately, use the Cost of File Chaos calculator with your own search-time estimates and an assumed reduction. Its results are hypothetical labor values, not measured savings or conclusions from this benchmark.
DNM runs on Windows and is free to try: download it for a 14-day trial with no card, or see plans and pricing. If you're weighing options, DNM also compares its approach to other file renamers.
Common questions
Does the 96.2% reduction measure an agent's performance?
No. It compares selected text inputs for a synthetic 100-file corpus: 37,095 tokens for an open-all baseline and 1,404 for a descriptive listing under o200k_base. Accuracy, elapsed time, API charges and customer savings were not measured.
Why does the INDEX.md condition contain more tokens?
The catalog includes information beyond the filename listing. It used 3,606 tokens in this comparison. A smaller input is not necessarily sufficient for every question.
Does agreement between two tokenizers prove the result is universal?
No. The reported ratios agreed within 0.1 of a percentage point for o200k_base and cl100k_base on this corpus. Other inputs, tokenizers and retrieval strategies can produce different results.
Does DNM need cloud AI to produce these names?
No. Naming uses local rules and reviewed inputs. Optional local OCR recognizes text. Licensing, computing resources and human review are separate from naming-token usage.
Where can I find the nested-folder comparison?
The related nested-folder benchmark compares listings, per-folder indexes and Root_Index.md. It is another selected-input token comparison, not an end-to-end agent evaluation.
How to cite this
DNM synthetic file-input benchmark, GetDNM (Falcrex Systems Inc), 2026. For 100 synthetic text stand-ins, an open-all input used 37,095 tokens and a descriptive listing used 1,404 under o200k_base, a 96.2% reduction (about 26x). The descriptive-names-plus-INDEX.md condition used 3,606 tokens, a 90.3% reduction (about 10x). Results were cross-checked with cl100k_base. These are input-size comparisons, not measurements of agent answer quality or real-world savings.