Token Efficiency
Cut agent token spend by preferring shell, sed, cp, and append patterns instead of read-edit loops across large files.
Overview
Token Efficiency is a journey-wide agent skill that reduces context token use by routing repetitive file work through shell commands instead of read-edit loops.
Install
npx skills add https://github.com/delphine-l/claude_global --skill token-efficiencyWhat is this skill?
- Documents before/after token cost comparisons for repetitive file edits
- Promotes batch sed and glob loops instead of per-file Read/Edit cycles
- Shows cp and echo-append patterns to avoid loading large logs into context
- Examples cite up to 99.95% token reduction on append-only log updates
- Core rules live in SKILL.md with extended calculations in companion examples
- Example documents 99.8% token savings on batch-updating 10 config files via Bash versus Read/Edit loops
- Example documents 99.95% token savings on log append versus read-rewrite of a large log file
Adoption & trust: 1.4k installs on skills.sh; 14 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent burns tens of thousands of tokens re-reading large configs and logs for edits that a one-line Bash command could do locally.
Who is it for?
Cost-conscious solo builders running long agent sessions on monorepos, large configs, or chatty status-check workflows.
Skip if: Edits that require semantic AST refactors, careful partial transforms inside huge files, or environments where shell access is disabled.
When should I use this skill?
The agent is about to Read, Edit, or Write large files for mechanical changes that shell commands, copy, or append could perform with minimal context.
What do I get? / Deliverables
You get repeatable command-first patterns so multi-file updates and log appends stay cheap in tokens across every phase of shipping.
- Lower-token command patterns for batch edits and status checks
- Documented before/after savings rationale for team habits
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Replace a value across ten config YAML files with one sed loop before a feature flag rollout.
Apply uniform lint autofixes via shell batching instead of per-file agent reads during pre-release cleanup.
Append an incident note to a large application.log without loading the full log into context.
Run a quick status grep pipeline when the user asks what broke instead of dumping entire log files.
How it compares
Agent execution discipline—not a linter, formatter, or model-routing product.
Common Questions / FAQ
Who is token-efficiency for?
Indie developers using Claude Code, Cursor, or Codex who pay per token or hit context limits and want the agent to prefer Bash for mechanical file work.
When should I use token-efficiency?
Use it during Build feature work, Ship refactors, Operate log fixes, and anytime you batch config or status checks—any journey phase where the agent might Read huge files unnecessarily.
Is token-efficiency safe to install?
It encourages shell commands on your machine; review Security Audits on this page and restrict destructive glob/sed patterns in production repos.
SKILL.md
READMESKILL.md - Token Efficiency
# Token Efficiency - Examples and Cost Calculations This file contains extensive token savings examples with before/after comparisons and targeted learning examples. See [SKILL.md](SKILL.md) for core rules. --- ## Token Savings Examples for Bash Commands ### Example 1: Update 10 config files Wasteful approach: ```bash Read: config1.yaml # 5K tokens Edit: config1.yaml Read: config2.yaml # 5K tokens Edit: config2.yaml # ... repeat 10 times = 50K tokens ``` Efficient approach: ```bash Bash: for f in config*.yaml; do sed -i '' 's/old/new/g' "$f"; done # Token cost: ~100 tokens for command, 0 for file content ``` **Savings: 49,900 tokens (99.8%)** ### Example 2: Copy configuration Wasteful approach: ```bash Read: template_config.yaml # 10K tokens Write: project_config.yaml # 10K tokens # Total: 20K tokens ``` Efficient approach: ```bash Bash: cp template_config.yaml project_config.yaml # Token cost: ~50 tokens ``` **Savings: 19,950 tokens (99.75%)** ### Example 3: Append log entry Wasteful approach: ```bash Read: application.log # 50K tokens (large file) Write: application.log # 50K tokens # Total: 100K tokens ``` Efficient approach: ```bash Bash: echo "[$(date)] Log entry" >> application.log # Token cost: ~50 tokens ``` **Savings: 99,950 tokens (99.95%)** --- ## High-Level Token Savings Examples ### Example 1: Status Check **Scenario:** User asks "What's the status of my application?" **Wasteful approach (50K tokens):** ```bash Read: /var/log/app.log # 40K tokens Bash: systemctl status myapp # 10K tokens ``` **Efficient approach (3K tokens):** ```bash Bash: systemctl status myapp --no-pager | head -20 # 1K tokens Bash: tail -50 /var/log/app.log # 2K tokens ``` **Savings: 94%** --- ### Example 2: Debugging Errors **Scenario:** User says "My script is failing, help debug" **Wasteful approach (200K tokens):** ```bash Read: debug.log # 150K tokens Read: script.py # 30K tokens Read: config.json # 20K tokens ``` **Efficient approach (8K tokens):** ```bash Bash: tail -100 debug.log # 3K tokens Bash: grep -i "error\|traceback" debug.log | tail -50 # 2K tokens Grep: "def main" script.py # 1K tokens Read: script.py (offset: 120, limit: 50) # 2K tokens (just the failing function) ``` **Savings: 96%** --- ### Example 3: Code Review **Scenario:** User asks "Review this codebase" **Wasteful approach (500K tokens):** ```bash Read: file1.py Read: file2.py Read: file3.py Read: file4.py # ... reads 20+ files ``` **Efficient approach (20K tokens):** ```bash Bash: find . -name "*.py" | head -30 # 1K Bash: cloc . # Lines of code summary - 1K Bash: grep -r "^class " --include="*.py" | head -20 # 2K Bash: grep -r "^def " --include="*.py" | wc -l # 1K Read: main.py (limit: 100) # 3K Read: README.md # 5K Grep: "TODO\|FIXME\|XXX" -r . # 2K # Then ask user what specific areas to review ``` **Savings: 96%** --- ## Targeted Learning Examples ### Example 1: Variable Number of Outputs in Galaxy Wrappers **User query:** "How do variable number of outputs work in Galaxy wrappers?" **Execution:** ```bash # Step 1: Identify concept # Concept: dynamic outputs, discover_datasets # File type: Galaxy XML wrappers (*.xml) # Step 2: Search for examples grep -r "discover_datasets" --include="*.xml" -l # Output: tools/samtools/samtools_merge.xml, tools/kraken2/kraken2.xml, ... # Step 3: Rank examples ls -lt tools/*/samtools_merge.xml tools/*/kraken2.xml # Pick: samtools_merge.xml (recent, well-maintained) # Step 4: Read example fully Read: tools/samtools/samtools_merge.xml # Step 5: Find another variation grep -r "collection_type.*list" --include="*.xml" -l | head -1 Read: tools/example/collection_output.xml ``` **Explanation provided:** ``` I found two main approaches for variable outputs in Galaxy: 1. **discover_datasets pattern** (samtools_merge.xml:45-52): - Use <discover_datasets> in output section - Specify pattern and format - Galaxy auto-detects files matching pattern 2. **output_collection pa