[PERF] .claude/rules/ consumes 34% of context window on session start (68k/200k tokens)

[riaworks]

Summary

The .claude/rules/ directory contains 16 markdown files totaling 288KB raw / ~68,100 tokens. These are automatically loaded as memory files at session start, consuming 34.1% of the 200k token context window before any user interaction.

Combined with system prompt, tools, skills metadata, and autocompact buffer, over 61% of context is consumed before the first user message. Only ~71k tokens (35.6%) remain for actual work.

Evidence

Context breakdown observed via /context command on a fresh session (Claude Opus 4.6):

Category	Tokens	% of 200k
System prompt	3,500	1.7%
System tools	15,900	7.9%
Memory files (rules)	68,100	34.1%
Skills metadata	1,800	0.9%
Autocompact buffer	33,000	16.5%
Free space	71,000	35.6%

Top offenders by size

File	Raw bytes	Est. tokens
agent-cognition.md	64,707	~16,200
agent-integrity.md	34,403	~8,600
RULE-GROUP-4.md	32,952	~8,200
ANTHROPIC-STANDARDS.md	27,242	~6,800
RULE-GROUP-6.md	23,618	~5,900
RULE-GROUP-5.md	23,740	~5,900
All 16 files total	288,650	~68,100

Architectural Contradiction

CLAUDE-LITE.md documents a lazy loading strategy where rules are loaded on-demand via keyword matching (skill_router.py). However, all 16 rule files sit in .claude/rules/ which Claude Code loads eagerly at session start. The lazy loading intent is defeated by the file placement.

Additionally, CLAUDE-LITE.md itself (~9.6KB) is loaded alongside all the full rule files, not instead of them.

Impact

• Reduced effective context: Only 35.6% available for actual work
• Earlier autocompaction: Conversations lose history sooner
• Degraded multi-step tasks: Less room for tool results, code reading, agent operations
• Cost: ~$1.02 per session start in input tokens (at Opus rates), repeated every API round-trip

Recommendations

1. R1 (HIGH): Move lazy-loaded rules out of .claude/rules/ to a directory not auto-loaded (e.g., core/protocols/). Keep only essential always-needed rules. Target: <15k tokens.
2. R2 (MEDIUM): Consolidate and compress — remove redundant ASCII art/box-drawing, merge RULE-GROUP 1-6, remove agent-cognition.md and agent-integrity.md from auto-load.
3. R3 (MEDIUM): Make skill_router.py inject rule content via hook output only when keywords match, implementing true lazy loading.
4. R4 (LOW): Set a token budget policy for .claude/rules/ (e.g., max 15k tokens total, max 3k per file).

Framework Mapping

Framework	ID	Relevance
OWASP LLM Top 10	LLM10 (Unbounded Consumption)	Self-inflicted resource exhaustion
MITRE ATLAS	AML.T0054 (LLM Resource Exhaustion)	Internal config causing token waste

---

Reported by riaworks security audit | 2026-02-28 | Method: Runtime observation

[andrevvalle]

Great audit @riaworks on the token metrics. But the issue goes deeper than context consumption, the architecture is solving the wrong problem entirely.

The project conflates three fundamentally different things: behavioral instructions (how the agent acts), persona and style (how it reasons), and domain knowledge (what it knows). These require completely different solutions. Putting all three into .claude/rules/ shows a fundamental misunderstanding of what context injection actually does in LLM systems.

RAG makes sense for specific factual retrieval, like "which framework does expert X use for funnel diagnosis", but it cannot transmit reasoning style or cognitive patterns. You can vectorize 500 hours of a CMO's podcast and the agent will still sound generic, because embeddings capture semantic content, not reasoning patterns.
That problem only have one real solution: fine-tuning with a curated I/O dataset, not raw transcript dumps.

The correct architecture separates four distinct layers. Universal behavior lives in a minimal CLAUDE.md under 3k tokens. Persona stays in a cached system prompt, paying full price once and ~10% on every subsequent call via prompt caching. Domain knowledge retrieves on-demand through proper RAG with atomic chunking. Reasoning style gets baked into weights through fine-tuning with quality-curated examples, minimum 200-500 well-structured pairs.

The cost difference is not marginal. Current approach consumes ~122k tokens before user types a single character. Proper layered architecture brings that to 8-12k variable tokens per query. One order of magnitude...

The vision of operationalize accumulated expertise into agents is valid. The execution suggests someone still in early stages of understanding what each LLM mechanism actually does at technical level. Rules don't teach. RAG don't transfer reasoning. Fine-tuning don't retrieve facts. Each have its place...

[riaworks]

@andrevvalle you expanded a lot on what I had seen.

I kept thinking about the persona via prompt caching part, because in practice I haven't seen many people implementing this cleanly. How do you see that flow working in production? Like, when the persona needs to be personalized per user, does caching still hold up?

And about fine-tuning for reasoning style — makes total sense in theory, but it seems like the hardest layer to execute well. Have you had a chance to explore that in practice?