Guide to Reducing AI Token Consumption

A guide for those working with coding AI agents (Kimi Code, Claude Code, Codex, Cursor, etc.) and paying for tokens with money or usage limits. All techniques below are battle-tested in practice with measured impact. Ordered from most impactful to least.

0. First, understand where tokens are going

The main misconception is that «long model responses consume all the tokens.» In practice, the primary cost driver is the number of «model ↔ tools» rounds. In every round, the model receives the system prompt, instructions, tool/skill catalog, and dialogue history all over again. A long task with thousands of minor tool calls burns a hundred times more tokens than its «visible» output.

Hence, two directions for optimization:

  1. Reduce what gets loaded into every round.
  2. Reduce the number of rounds.

1. Trim always-loaded instructions

Files like AGENTS.md / CLAUDE.md / rules are loaded into every request. They tend to bloat over time as people dump all rules in indiscriminately «so as not to forget.»

What to do:

  • Keep only universal rules and «routers» in the main file, such as «before task X, read section Y of the reference guide.»
  • Move everything else into reference guides that the agent opens on demand.

Impact: The file can be trimmed by 60–70% without losing a single rule—saving tokens on every round of every session, forever.

2. Check the skill/tool catalog for duplicates

If you sync skills across multiple agents or machines, you almost certainly have duplicates. An agent might treat two copies of the same skill as different (e.g., deduplicating by file path rather than name). Each duplicate is an extra entry in the catalog that gets loaded into every round.

What to do: Keep one active copy of each skill and disable mirrors in the config. Verification: The list of active skills should contain no duplicate names.

3. Don’t blindly shorten skill descriptions

The intuitive urge to «trim all descriptions to 100 characters» is usually useless: agents only include the first ~150–300 characters of a description in the catalog, and the rest isn’t loaded anyway. Measurements confirm this: cutting a description to one-third of its length changed the prompt size by zero tokens.

What actually matters: ensuring the first 150–300 characters contain the name, key trigger phrases (in all languages you use for commands), and applicability boundaries. This serves as a routing index used by the agent to pick a skill. Don’t touch the skill body: it only loads after selection and costs nothing until then.

4. Compress shell command output

Command output is the most underrated context hog: git status in a large repository, ps aux, or test logs can dump thousands of lines straight into the model’s context window.

What to do:

  • Use output-compressing wrappers (such as RTK — Rust Token Killer): measured savings of 60–90% on verbose commands.
  • If the agent doesn’t support automatic hooks for this, enforce the habit via instructions («prefix noisy commands»)—it works.
  • Ask the agent to show counts and errors rather than full listings; redirect full logs to files, bringing only the summary into the context.

5. Consolidate similar skills into routers

If you have many twin skills (the same task for different targets: «install theme A», «install theme B», etc.), each one represents a separate entry in the catalog. Ten such entries waste roughly 1–1.5k tokens per round.

What to do — create a single router skill:

  • List all variants in the description (within the first 300 characters)—they remain routing triggers.
  • Place general rules and a «variant → detailed playbook» table in the body.
  • Store detailed playbooks as separate files alongside it, loading them only upon selection.

Not a single byte of functionality is lost, while the catalog shrinks significantly.

6. Reduce «thinking depth»

If the agent is configured with maximum thinking/reasoning effort, the model generates a mountain of hidden reasoning tokens for every request, often far exceeding the size of the actual response. A medium-high level is sufficient for most tasks; reserve the maximum setting for rare, high-stakes sessions (migrations, production changes, financial operations).

7. Round discipline (free, just behavioral rules)

Add the following to the agent’s instructions:

  • Batch independent reads/checks into a single round instead of executing them one by one.
  • Do not query unchanging state in repeated rounds (no polling).
  • Do not repeat a check if neither code, environment, nor input data have changed—reuse already obtained proof.
  • Avoid spawning sub-agents and chats just for the sake of it: a new role is justified only if it brings an independent decision rather than repeating the same reads.

This is the cheapest optimization: zero infrastructure changes and a direct hit on the «number of rounds.»

8. Protect deletions from resurrection during sync

If settings are synced across machines/agents on a «latest wins, delete nothing» basis, a deleted skill will keep resurrecting from remaining copies. The classic distributed systems solution is tombstones: a file listing deleted items that the sync script forcibly purges from all copies on every run. Otherwise, your optimization will roll back the next time you turn on a second device.

9. Always back up before editing configs

When cleaning up config files, it’s easy to hit a race condition: your script writes to a file at the same time as the application itself—resulting in a 0-byte file.

Three rules:

  1. Make a backup copy before editing: cp config.toml config.toml.bak.$(date +%s).
  2. Write to a temporary file instead of in-place → validate with a parser → mv.
  3. Make sure in advance that you have access to system backups (for instance, for Time Machine snapshots, Terminal needs «Full Disk Access»—granted in Privacy settings, preferably before a fire rather than during one).

What NOT to trim

  • Mandatory safety checks: steps protecting money, data, or production. Cost savings that compromise safety processes lead to future incidents, not actual savings.
  • Skill bodies and reference guides—they aren’t loaded automatically.
  • One-size-fits-all trimming of skill descriptions—see item 3.

Summary Cheat Sheet

TechniqueImpactCost
Trim always-loaded instructions−60–70% of their size, every roundOne-time
Remove skill duplicates−Thousands of tokens per roundOne-time
Shell output compression−60–90% on verbose commandsOne utility
Routers instead of twin skills−Catalog entries permanentlyOne-time
Reasoning effort below maximum−Reasoning tokens on every requestOne line
Round discipline−The single largest cost sourceRules only
Tombstones for deletionsOptimization doesn’t roll backOne file

The bottom line: tokens are saved not by heroically shortening text, but by system design—what gets loaded into every round, how routing works, and what prevents old items from resurrecting. Measure → trim structure → leave processes intact.