We Analyzed 100 AI Coding Configs: Most Are Lean — 10 Files Held 97% of the Waste
A lot of AI-coding advice assumes every instruction file is bloated. We wanted measurements instead, so the original tokencheat project collected 100 real configuration files and ran them through the same deterministic scoring and optimization rules now owned by @repo/skill-compiler in tokencheat v2.
The corpus
- 100 files: 34
CLAUDE.md, 47AGENTS.md, and 19.cursorrules - 93 public GitHub files plus 7 anonymized local files
- public files were root-level, forks were excluded, and files were deduplicated by content hash
- token counts use the same approximate
characters ÷ 4estimator used by the deterministic tooling
What a typical config looks like
| Metric | Value |
| --------------------- | ----------------: |
| Median size | 964 tokens |
| Median CLAUDE.md | 1,285 tokens |
| Median AGENTS.md | 732 tokens |
| Median .cursorrules | 1,328 tokens |
| Largest file | 24,186 tokens |
| Files over 200 lines | 24% |
| Files over 500 lines | 10% |
The important result is that the median file was not badly bloated. The problem was concentrated in a relatively small tail.
Where the detectable waste lives
The deterministic optimizer found at least one issue in 34 of 100 files.
- Total detectable waste across the corpus: 14,530 estimated tokens
- The top 10 files held 97% of that waste
- Files over 200 lines represented 24% of the corpus but held 78% of detected waste
- Median detected waste in files at or below 200 lines: zero
The largest recurring problem was not generic verbosity. It was large always-on sections that behaved more like logs, historical notes, or reference material than durable instructions.
Finding breakdown
- Oversized sections: found in 10% of files; 13,348 estimated tokens of potential context reduction
- Duplicate content: found in 16% of files; 1,182 estimated tokens auto-fixable by deterministic rules
- File references needing verification: found in 8% of files
tokencheat v2 deliberately keeps these categories deterministic. It can identify structural issues that can be measured reproducibly without asking an LLM to rewrite the user's intent.
Honest limitations
This is an external-corpus benchmark, not a universal statement about every private repository. The public GitHub sample may skew toward developers who intentionally maintain and publish configuration files. The token estimator is approximate rather than tokenizer-exact, and static analysis cannot prove whether every referenced file is stale without repository context.
The benchmark is most useful as evidence for a practical rule: small instruction files usually are not the problem; oversized always-on context deserves measurement first.
Measure your own configuration
Use the free Agent Config Audit to score and optimize instruction text locally in the browser, or use the v2 CLI from the repository for local filesystem discovery and audit orchestration.
The benchmark corpus and deterministic engine are kept separate from vendor-pricing claims so the results remain useful even as model pricing and provider products change.