8 ways to cut your Claude token usage

Hey, it's Cindy. If Claude keeps running out of room or your allowance disappears halfway through a project, the useful question is where the work is going. You can test that. Start with one small job you understand, rather than changing every setting at once.

Before you change anything

This walkthrough is for Claude Code. A token is a piece of text the model processes or generates. Context occupancy, cumulative token usage and your bill are different measurements. A smaller context window does not prove the whole job used fewer tokens.

Run /usage and record the available session token categories before clearing anything. For subscription access, plan usage bars describe your allowance; a displayed API-equivalent dollar estimate is not your subscription invoice. API billing lives in the Claude Console. The usage documentation explains these distinctions. Reducing waste can help an allowance last longer, but it does not reduce a fixed subscription price. There is no universal 80% result.

Keep your model, task and success check the same during your first comparison. If an app version does not expose the token records you need, write “not available” and compare rework and completion instead. Do not convert a usage bar into a made-up token count.

1. Give the task a boundary

Replace “improve my website” with a request that names the file, the change and the check. For example: “In the contact form component, add an error message for an empty email address. Keep the current layout. Check empty, malformed and valid inputs.”

You are giving Claude enough information to choose a sensible starting point. You are not forbidding it from reading a dependency that matters. If you do not know the file, ask for a short search to locate it before making changes. The best-practices guide has further examples of giving Claude a verifiable outcome.

2. Match effort to the task

Open the model and effort controls. Where your selected model supports it, try /effort medium for a bounded edit. Low effort can be worth testing for a very straightforward transformation; a difficult debugging task may need more reasoning.

Effort can save as your default for that model, so run /effort auto to reset it. A cheaper model is a separate pricing choice, and it does not establish that fewer tokens were used. See model configuration for supported levels.

3. Start fresh when the job changes

Before switching from website work to a different project, save the finished changes and a short handover: decisions, important files and remaining work. Then use /clear for the unrelated job.

For the same continuing project, use /compact with a focus, such as preserving the failing test and decisions already made. Read the resulting summary before relying on it. Compaction uses model work itself. Clearing does not refund previous usage or refresh an account allowance. Record your measurement first because session totals can reset with the session.

4. Separate core guidance from occasional procedures

Open your project's CLAUDE.md. Keep instructions that apply to most work here: how to run checks, important project conventions and genuinely recurring constraints. Move a long procedure used only for one kind of task into a skill.

The memory documentation explains project guidance, and skills documentation explains loading reusable procedures when relevant. Skill descriptions still occupy some context. The benefit comes from avoiding the full procedure on jobs that do not need it, rather than making instructions free.

5. Keep the useful part of a long log

Ask Claude to save a verbose tool result to a file and report the failing test, relevant error and file location first. It can inspect surrounding lines if the short excerpt is insufficient.

For example, ask for the first failure and its stack trace before rerunning a large test suite. Do not delete the full log; it is your evidence if the summary misses something. The aim is to avoid repeatedly dragging irrelevant output through the conversation. Lines and tokens are different units, so do not report a token reduction based on line count.

6. Inspect app connections before disabling them

Use /context to inspect what is taking space, then /mcp to review connected servers. Keep connections that support the task and disable unnecessary ones when they create actual overhead.

Claude Code already supports deferred tool discovery, so the number of installed servers alone is not a good measure of their cost. The MCP guide explains tool loading and connection management. After changing a connection, test the action you still need before continuing with a longer run.

7. Delegate a separate job, not the whole conversation

Begin with one agent. Add another when there is a bounded task it can do independently, such as inspecting a particular module while the main agent works elsewhere. Give it a short question and ask for a compact result.

Separate context helps keep the main conversation readable, but the other agent still consumes usage. Include that work in your measurement. Review the subagent documentation before changing their configuration. Stop completed teammates rather than leaving unnecessary activity running.

8. Correct the direction early

If Claude is editing the wrong component or building more than you asked for, press Escape and redirect it. Say what was wrong and restate the finish line. This is often more useful than waiting for a polished answer to the wrong task.

Ask for a small check after the first meaningful change. For the contact form example, inspect the error state before adding further validation. You are trying to catch a wrong assumption while it is still cheap to fix.

Use this prompt on your next task

Help me complete this bounded task: [task]. The relevant files or starting location are [location], and a correct result must pass these checks: [checks]. First identify the smallest useful scope and ask about any missing decision that would change the work.

Keep project-wide instructions concise, inspect only relevant files initially, and save verbose logs to a file while showing the failure and necessary context. Do not remove evidence or skip a check merely to save usage. If the work starts to require a broader change, explain why before expanding it.

At the end, give me the completed result, checks performed, any rework, and the usage records actually available. Separate context occupancy from cumulative tokens and separate token counts from pricing estimates. Do not invent savings or infer token counts from line counts.

Compare two runs honestly

Use a disposable copy or branch so each run starts from the same state. Record the model, effort, change tested, available input/output/cache categories, retries and whether the result passed. Repeat a promising comparison because one run can vary.

Your finish line is a correct result with less unnecessary work. If tokens fall but the output needs more repair, restore the setting. If a count is unavailable, keep the observation qualitative. Start today by writing the file, change and success check for one task; that is useful even before you touch a setting.

For another practical walkthrough, browse all free guides.