Maximize intelligence per token
Not by minimizing tokens, but by delivering the right context at the right time
Case Studies • Principles • Techniques • Results • Contributing • Articles
| Tokenmaxxing | Tokenminning |
|---|---|
| "How do I give the model more context?" | "How do I give the model the right context?" |
| Add more context | Add better context |
| Bigger prompts | Denser prompts |
| Load everything | Retrieve what matters |
| More memory | Better memory architecture |
| More tokens | More intelligence per token |
Tokenminning is not: minimizing tokens to cut costs, aggressively shortening prompts, removing useful context, or avoiding large context windows.
Tokenminning is: improving information density, eliminating context debt, and designing systems where the right context arrives at the right time.
Tokenminning isn't a tool—it's a design philosophy. Apply it in 3 steps:
# 1. Audit what's always loaded
grep -r "always.*load\|preload\|startup" .claude/ CLAUDE.md
# 2. Replace full clones with stubs (summary + source-path)
# 3. Add escalation ladder: local cache → stub → on-demand readStart here: Read the Principles → Pick a Case Study → Apply one technique to your setup.
| # | Principle | One-Liner |
|---|---|---|
| 1 | 🔍 Retrieve, don't preload | Supply relevance on demand |
| 2 | 🗜️ Compress, don't repeat | Cut redundant instructions & history |
| 3 | 📋 Structure, don't narrate | Prefer structured data over prose |
| 4 | 🎯 Spend tokens where reasoning matters | Allocate budget to high-value thinking |
| 5 | 🏗️ Design systems, not prompts | Architecture (retrieval, tools, memory) drives savings |
| 6 | ⚙️ Optimize context, not complexity | "What does the model need right now?" |
| 7 | 🧹 Eliminate context debt continuously | Audit memories, routing, config like production code |
Note
These principles emerged from production Second Brain workflows at ServiceChannel, not theoretical speculation.
| Technique | Description | Case Study |
|---|---|---|
| Stub Pattern | Replace full clones with summary + source-path pointers |
Second Brain |
| Grep-before-read | Never read a folder wholesale; search first | Config Audit |
| Escalation Ladder | Level 1: local cache → Level 2: stub lookup → Level 3: on-demand read | [All] |
| Compaction | Keep active context ≤ 15K tokens | Wiki Pipeline |
| Thin Routers | Startup instructions = behavior/routing only; retrieve details on demand | Config Audit |
| Single Source of Truth | Store durable knowledge once, reference everywhere | [All] |
| Metric | Before | After | Change |
|---|---|---|---|
| Second Brain wiki words | 211K | 28K | 87% ↓ |
| Wiki pipeline cost/run | $50+ (11 agents) | $15–25 (2–3 agents) | ~70% ↓ cost, 80% ↓ agents |
| CLAUDE.md size | ~48.6 KB | 34.4 KB | 29% ↓ (~3,500 tokens/session) |
| Stale sync clones | 66% | 0% | 100% eliminated |
| RTK adoption gap | 94% commands bypassed | → upstream fix | 1.5M tokens/30d recovered |
Note
These are measured results from production Second Brain workflows, not synthetic benchmarks.
Case Study 1: Second Brain — 211K → 28K words (87% reduction)
Problem: Team knowledge vault full of full-body clones
Fix: Stub Pattern + Grep-before-read + Escalation ladder
Result: 87% word reduction, $15–25 → $2–4/session, 66% → 0% stale clones
Case Study 2: RTK & LLMLingua Evaluation — 1.5M token adoption gap found
Problem: Which external token tools improve CLI setup?
Fix: Evaluated 4 repos → kept RTK (deterministic tool-output compression), rejected LLMLingua (lossy prompt compression)
Discovery: rtk discover revealed only 6% of Bash calls used RTK (~1.5M tokens/30d missed)
Case Study 3: Config & Memory Audit — 3,500 tokens/session recurring savings
Problem: CLAUDE.md files bloated, MEMORY.md growing unbounded
Fix: 4-type memory classification + CLAUDE.md consistency audit + monthly auto-enforcement
Result: 29% CLAUDE.md reduction, MEMORY.md → 0 bytes, recurring ~3,500 tokens/session saved
Case Study 4: Wiki Pipeline — $50 → $15/run (80% fewer agents)
Problem: Cleanup skill defaulted to full-vault audit (92 wikis) when only 12 changed
Fix: Added "recently-touched" scope tier seeded from builder run; full-vault now opt-in via --full
Result: 11→2–3 agents, ~70% cost reduction, 4 root-cause fixes across 2 skills
Practical applications of tokenminning to specific systems:
| Guide | Focus |
|---|---|
Claude Code & CLAUDE.md |
Keep config focused; retrieve on demand |
| MCP / Tool Scoping | Load capabilities only when workflow needs them |
| Memory Systems | Preserve decisions/constraints, not transcripts |
| RAG Pipelines | Rank → filter → focus; quality over quantity |
| All Examples Index | Quick reference for all 7 patterns |
These are technique guides — not measured case studies. Case studies in
examples/(second-brain-system.md, etc.) show before/after metrics.
Tokenminning operates on a simple escalation ladder — the model only sees what it needs, when it needs it:
┌─────────────────────────────────────────────────────────────┐
│ LEVEL 1: LOCAL CACHE │
│ Hot context, recent decisions, active task state │
│ → Always loaded, ≤ 2K tokens │
├─────────────────────────────────────────────────────────────┤
│ LEVEL 2: STUB LOOKUP │
│ Summary + source-path pointers to durable knowledge │
│ → Loaded on reference, ~500 tokens each │
├─────────────────────────────────────────────────────────────┤
│ LEVEL 3: ON-DEMAND READ │
│ Full source content retrieved only when explicitly needed │
│ → Lazy, precise, unbounded depth │
└─────────────────────────────────────────────────────────────┘
The key insight: Most systems preload Level 3. Tokenminning makes Level 1 the default, Level 2 the bridge, Level 3 the exception.
| Project | Description | Relation |
|---|---|---|
| RTK | Rust CLI proxy for tool-output compression (60-90% savings) | Complementary — handles command output; tokenminning handles context architecture |
| Caveman | Terse communication mode (65% fewer output tokens) | Sibling — reduces prompt verbosity; tokenminning reduces context surface |
| Ponytail | YAGNI code generation philosophy (~54% less code) | Sibling — reduces implementation bloat; tokenminning reduces context bloat |
| GPTCache | Semantic caching for LLM APIs | Different layer — caches model responses; tokenminning optimizes what reaches the model |
We welcome real-world examples, counterexamples, benchmarks, and tool-specific patterns.
- Case studies — Add to
examples/incase-study-XX-name.mdformat - Techniques — Document patterns in
techniques/ - Counterexamples — Where tokenminning doesn't apply (valuable!)
- Tool patterns — Claude Code, Cursor, Codex, Continue, etc.
See CONTRIBUTING.md for details.
Architecture diagrams & decision flows
| Diagram | Description |
|---|---|
| Core contrast visualization | |
|
System architecture comparison |
|
Decision flow for technique selection |
 |
Context surface vs. underlying system |
|
Escalation ladder visual |
MIT — see LICENSE for details.
The term "tokenminning" was introduced in July 2026 as a way to describe an emerging optimization philosophy centered on maximizing intelligence per token.
Inspired by the emerging concept of tokenmaxxing: intentionally using larger context windows and more tokens to improve AI performance. Tokenminning asks the opposite question: what's the minimum context that still produces maximum reasoning?