Top 20 Token
Saving Tips

Context accumulates relentlessly — every tool call, file read, and exchange adds to the running total. When you finish a task and move to something else, that history is pure overhead. /compact summarises the session before continuing; /clear resets entirely. The discipline of doing this at every task boundary is the single highest-impact habit to build.

# Summarise session and continue lean
/compact

# Full reset — start from zero
/clear

Vague prompts trigger exploratory behaviour. "Auth is broken" causes Claude to scan broadly, read multiple files, and form hypotheses — all at your expense. "Fix the null check at src/auth/verify.ts:42 — it throws when user.id is undefined" goes straight to the answer. The more precisely you describe location and nature, the fewer tokens get burned on exploration.

# Vague — triggers broad, expensive exploration
"the login is broken"

# Specific — straight to the fix
"fix the null check at src/auth/verify.ts:42
— throws when user.id is undefined"

Claude Code reads files natively. Pasting code you could reference just duplicates that content in the context window — you pay for it twice. Instead of pasting 60 lines, write src/utils/parse.ts:45-105 and let Claude read it directly. For larger functions this is a meaningful saving, and it keeps prompts clean.

# Wasteful — pasting content Claude can read
"here's the function: [60 lines pasted]
can you refactor it?"

# Efficient — reference by location
"refactor the parser at src/utils/parse.ts:45-105"

Every prompt carries the full conversation history. Five separate prompts for related changes = five times the context overhead. If you know you want to fix a bug, update its test, and update the docs, say all three at once. Claude handles multi-part instructions well, and you pay the context cost once instead of five times.

# Expensive — 3 turns, 3× context overhead
"fix the null check in auth.ts"
"now update the test for it"
"now update the docs"

# Efficient — one turn
"fix null check in auth.ts, update its test,
and update the relevant docs section"

Jumping to implementation on a complex task risks Claude going in the wrong direction — which you then spend tokens correcting. Plan Mode forces a read-only planning phase first. You align on approach before a single file is changed. The cost of a short planning session is almost always less than the cost of a wrong-direction implementation and its correction.

# Enter plan mode — read-only, no edits made
/plan

# Review the plan → approve → implement
# Catches misaligned assumptions before they cost you

Mixing "fix a bug + add a feature + refactor something" in one session creates a sprawling context where earlier work crowds out the current task. Each new task in the same session inherits the full history of everything before it. Separate sessions mean separate, clean contexts — each task starts lean, without carrying irrelevant history as overhead.

"How does authentication work?" is open-ended with no natural stopping point — Claude scans broadly and reads extensively before answering. "What does verifyToken() in src/auth/verify.ts return when the token is expired?" is bounded to a single read. Frame questions around specific functions, files, and outcomes rather than broad topics.

# Open-ended — triggers broad, unbounded scan
"how does authentication work in this codebase?"

# Targeted — one read, direct answer
"what does verifyToken() return when the JWT
is expired? (src/auth/verify.ts)"

When Claude misunderstands and heads in the wrong direction, the instinct is to correct in-session. But corrective messages compound the context — you carry the wrong attempt, plus the correction, plus the context of how you got there. It's almost always cheaper to /clear and start fresh with a better prompt than to course-correct mid-session.

# Expensive — correcting in-session
"no that's wrong, I meant X not Y"
"still not right, the issue is actually..."

# Cheaper — clear and rephrase
/clear
"[better, more specific prompt]"

When you have two or more independent research tasks — say, investigating an error log while also checking the schema — running them sequentially in one conversation doubles the context you carry. Dispatching sub-agents keeps that exploratory work out of the main context entirely. The main thread stays lean; sub-agents do the heavy reading in parallel.

Test output lands in the context window. Running a full suite when you've changed one file means Claude reads (and you pay for) hundreds of unrelated test results. Target the pattern relevant to your change — feedback is faster and the context impact is a fraction of the full suite.

# Full suite — lots of unrelated output in context
npm test

# Targeted — only the output that matters
npm test -- --testPathPattern=auth

# Or with Vitest
vitest run src/auth

You can't optimise what you don't measure. /cost shows token spend for the current session. Seeing "that exploration cost $0.40" reshapes how you prompt next time. Build a habit of checking it after expensive-feeling sessions — patterns become visible quickly: which types of prompt are cheap, which burn through budget.

# Check spend for the current session
/cost

# Shows input tokens, output tokens, and estimated cost
# Run it after any session that felt expensive