Practical Tips for Saving Tokens in Claude Code CLI

Claude Code charges per token — every search round you avoid, every context you don’t carry forward, translates directly to cost. This post covers the key levers available, from quick prompting habits to deeper session architecture decisions.

The Two Axes of Token Savings #

There are two independent dimensions to think about:

• Within a session — how much context accumulates as you work
• Across sessions — how much re-explaining and re-exploring happens each time you start fresh

Each has its own tools.

Saving Tokens Within a Session #

Be specific upfront #

Vague prompts force Claude to explore before acting. Saying “look at src/auth/middleware.ts” is cheaper than “find the auth middleware” — the latter triggers Glob and Grep rounds before any real work begins. Point at files directly whenever you can.

Use /compact #

/compact compresses the conversation in-place by asking Claude (the model itself) to summarize it. It’s not a deterministic algorithm — Claude decides what’s worth keeping based on task-relevance. The summarization call itself consumes tokens, so /compact is a tradeoff: you pay a small cost now to avoid a larger accumulating cost later.

It tends to retain:

• Current task state and where you are in it
• Key decisions made
• File paths and symbols referenced or edited
• Errors found and how they were resolved
• Explicit instructions and preferences you stated

It tends to drop:

• Exploratory back-and-forth that led nowhere
• Repeated explanations of the same thing
• Resolved tangents and tool call results already acted on

Tip: the cleaner and more focused your session is, the better the compact summary. A session full of pivots produces a fuzzier result.

Use /clear between unrelated tasks #

If you’re switching to a completely different task, /clear is cheaper than carrying all prior context forward. Every turn in a long session pays for everything that came before it.

Choose the right model for the task #

Haiku-class models are significantly cheaper per token than Sonnet or Opus. Use them for mechanical tasks — renaming, formatting, boilerplate — and reserve the heavier models for reasoning-heavy work. Check the Anthropic model docs for the current Haiku model ID, as these change with each generation.

Use --print for one-shot tasks #

--print (shorthand -p) runs Claude Code in non-interactive mode: it processes your prompt and exits, printing the response to stdout. No session is opened.

claude --print "summarize this file" < file.txt
claude -p "what does this function do?" < src/auth.ts

The token savings come from two things: there’s no session scaffolding (no memory loading, no project context initialization), and the model sees only your prompt and the piped input — nothing else. For scripted pipelines, Makefiles, or CI steps, this is the leanest option. For anything that needs back-and-forth, use the interactive session instead.

Saving Tokens Across Sessions #

How memory works #

Claude Code has a file-based memory system at ~/.claude/memory/. It has two layers:

• MEMORY.md — the index file, always loaded at the start of every session. One line per memory file, kept concise.
• Individual memory files — loaded on demand. Claude reads the index, judges which files are relevant to the current task, and fetches only those.

This means having many memories doesn’t bloat every session. A memory about PostgreSQL won’t be loaded if you’re asking about CSS — unless Claude judges it relevant. The one-line description in MEMORY.md is what drives that relevance decision, so vague descriptions lead to memories that get missed.

Save context before wiping #

The “save + clear” pattern is the closest thing to selective context removal:

1. Tell Claude what to save — be explicit:
   “Save to memory: we decided to use PostgreSQL for the session store, and the auth middleware lives at src/auth/middleware.ts.”
2. Run /clear to wipe the conversation. Memory files are untouched.
3. Start your next turn normally. Claude loads the index and pulls relevant memories in.

The saved context survives. The unwanted subject doesn’t come back.

This is what /compact does automatically — but without any selectivity. The save + clear pattern gives you full control over what survives into the next context window.

Make memory descriptions specific #

Since MEMORY.md entries drive relevance decisions, write them to be retrievable:

“Decided to use PostgreSQL for session store” ✓
“Some backend decisions” ✗

You can also trigger a memory load explicitly by referencing the topic in your first message: “continuing work on the auth system” signals Claude to pull auth-related memories before you ask anything specific.

Session Architecture: Per-Folder vs. Shared Sandbox #

A common workflow question: should you open a separate Claude session per project folder, or work from a single parent sandbox containing multiple repos?

What you gain from per-folder sessions #

Memory isolation. Each project gets its own MEMORY.md index and memory pool. No context bleeds between unrelated repos.

Scoped file search. Glob and Grep run from the project root. “Find the auth middleware” hits one codebase, not three. Less token waste on disambiguation.

Per-project settings. .claude/settings.json applies only to that folder. Different repos can have different permissions, allowed commands, and hooks.

Cleaner /compact summaries. The summary reflects only the current project’s work — no noise from sibling repos.

What you give up #

Cross-repo tasks require switching sessions. There’s friction in opening and closing sessions as you move between projects.

The tradeoff in practice #

For unrelated repos, per-folder is strictly cleaner. For tightly related repos where you frequently jump between them, a shared sandbox trades isolation for convenience — a reasonable call.

Can you switch folders mid-session and get per-folder behavior? #

Not today. When a Claude Code session starts, the working directory anchors the project identity — memory pool, index, and settings are all tied to the launch path. There’s no /switch-project command that reloads those for a different folder mid-session.

What partially works:

• Per-repo CLAUDE.md files — Claude reads them when it navigates into a subfolder, so project-specific instructions do kick in contextually
• Explicitly scoping Claude’s work: “work in ./repo-b/ from here”

What doesn’t:

• Memory doesn’t swap — repo-b memories don’t load automatically
• Settings don’t change — hooks and permissions stay as launched

If per-folder isolation matters, separate sessions remain the cleanest option.

Quick Reference #

Token efficiency in Claude Code is mostly about reducing redundant work — searches that could be avoided, context that doesn’t need to carry forward, re-explanations that a memory could replace. The tools are all there; it’s mostly a matter of building the habit of reaching for them at the right moment.