How to Stop Wasting Money and Tokens in Claude Code

Claude Code can build surprisingly substantial software from ordinary instructions. You can describe an app, discuss how it should work, and have Claude create the project, implement features, and help you get it running.

But there's a catch. The more ambitious your project becomes, the more usage you can burn through. A long coding session can consume a surprising amount of your allowance, especially when Claude is repeatedly examining files, running commands, and reconsidering decisions that could have been settled earlier.

Fortunately, getting more out of Claude doesn't necessarily mean buying a more expensive subscription.

This guide explains how to choose the appropriate model and effort level, keep your coding sessions under control, and spend your usage on the parts of a project where Claude's intelligence makes the greatest difference.

We'll focus primarily on Claude Code, although several of the principles are equally useful when working with Claude in your browser or desktop app.

First, understand what you're actually running out of

Before trying to conserve tokens, it's worth understanding the different limits Claude has.

If you're using Claude through a subscription, your plan gives you a certain amount of usage over a period of time. Larger models, longer conversations, and more demanding tasks can consume that allowance more quickly.

Claude's usage is shared across its different interfaces, including Claude chat and Claude Code. Moving your planning conversation from Claude Code to the regular chat interface doesn't magically give you a separate allowance.

If you're using Claude Code with an API key instead, you're generally paying according to the tokens you consume. You'll want to keep an eye on your actual spending rather than just when your allowance resets.

Then there's the context window, which is the amount of information Claude can work with in a conversation. Your instructions, previous messages, project files, and command outputs all occupy space in that window.

You can have plenty of subscription usage remaining while working in a conversation that's become unnecessarily large.

Anthropic's guide to Claude's usage and length limits explains these distinctions in more detail.

There's also a distinction between reaching your included usage limit and spending additional money. Claude offers optional usage credits on paid plans that can let you continue at consumption-based rates.

Check whether they're enabled and what spending limit you've set before assuming your subscription is the only thing you're paying for. Anthropic's usage credits documentation explains how these additional charges work.

The rest of this guide is about getting useful work done while keeping all three things under control.

Know the Claude model ladder

Claude has several model families, and they aren't equally suited to every job.

If you've spent much time following Claude releases, you're probably familiar with the excitement surrounding Opus and the newer Fable models. Their capabilities are interesting, but they aren't necessarily the models you should leave running throughout an ordinary development day.

For Claude Code, the practical lineup looks like this:

These are general starting points based on Anthropic's official model overview, not guarantees that one model will always outperform another on a particular task. Available versions and models also depend on your account and setup.

Sonnet deserves particular attention.

For many projects, Sonnet can handle a substantial amount of the actual programming. Building ordinary screens, implementing familiar features, working with APIs, and expanding an established application don't automatically require Opus.

Haiku is worth considering for simpler work, particularly when the change is clear and the result is easy to verify.

Opus becomes more attractive when Claude needs to make important decisions, understand several interacting systems, or solve a problem where the answer isn't immediately obvious.

Fable is available for especially demanding work, including longer autonomous tasks. However, depending on your plan, it may require additional usage credits rather than drawing entirely from your included allowance. Check the model picker before selecting it.

The important point is that you don't need to use the same model for everything.

A project can begin with some substantial architectural work, spend most of its development time on normal implementation, and finish with dozens of relatively small improvements. Those stages have different requirements.

The Claude Task Scale

The easiest way to make model selection more practical is to stop thinking about which Claude model is the most impressive and start thinking about what the job actually requires.

We can divide coding work into eight broad levels. These aren't official Anthropic categories, but they're a useful way to make an initial choice.

Effort suggestions are editorial starting points, not benchmark results. Haiku does not currently support the adjustable effort control in Claude Code. Available levels vary by model and account.

The model doesn't need to rise every time you add another feature.

Imagine you're creating a fitness app. You've already established how workouts are stored, how exercises are organized, and how users navigate between screens.

You now want to add a page where users can see their previous workouts. That's a fairly ordinary feature, and Sonnet would be a sensible place to start.

Now imagine you're starting the same application from scratch. You need to decide how workout data will be organized, how progress will be calculated, what happens when someone uses the app offline, and how future features can fit into the structure.

Those decisions deserve more attention because they're going to influence much of what you build afterward. Opus with higher effort starts making more sense.

You can spend more on that initial foundation and then return to Sonnet for much of the implementation.

The goal isn't to finish an entire project using the cheapest model. It's to avoid spending premium-model usage on work that doesn't need it.

Big jobs aren't always difficult jobs

One of the easiest mistakes to make is to judge a programming task by the amount of code involved.

Suppose Claude needs to modify 80 files because you're replacing an old naming convention with a new one. It sounds like substantial work, but the actual change might be straightforward and repetitive.

Claude needs to identify the relevant occurrences, make a predictable change, and verify that nothing was missed. Depending on the details, Sonnet may be perfectly capable of doing this, and some mechanical replacements may be better handled by an ordinary search-and-replace tool.

Now consider a much smaller problem.

You have a music player that occasionally skips to the next song twice. The problem only appears when someone presses Next at almost the exact moment the current track finishes.

There might be fewer than 50 lines of relevant code, but Claude needs to understand the timing of two competing events, determine what's happening, and work out how to prevent the problem without introducing another one.

That's a considerably more difficult task.

Opus or Fable could be worth using here, particularly if Sonnet has already investigated the problem without finding the cause.

Choose the model according to how difficult the problem is, not how much code Claude will produce.

That distinction becomes especially valuable when building larger applications. You can have thousands of lines of fairly predictable work followed by one small problem that requires much deeper reasoning.

Four questions that help you choose the model

You don't need to memorize the entire task scale. Before beginning a job, ask yourself four things.

How much of the project does this affect? Changing one button is different from replacing the navigation system used by every screen.

Is it a familiar programming task? A normal contact form is well-understood work. An unusual hardware integration might require considerable investigation.

Will other features depend on this decision? If you're creating the foundation for user accounts, stored data, payments, or some other important system, getting the structure right now can make future development considerably easier.

What happens if Claude gets it wrong? A misplaced button is easy to correct. A poorly designed payment system or a data migration that corrupts information can be a much more serious problem.

If the answers point toward a small, familiar, easily reversible task, start with Haiku or Sonnet.

If you're working on something substantial that will affect several parts of an application, consider Opus.

For unusually demanding problems, particularly those involving extensive investigation or long-running development, Fable may justify its additional usage requirements.

There's one question worth remembering above all the others: Will future work depend on what we're building now?

A good foundation makes many later features relatively straightforward. A poor foundation can turn even simple additions into increasingly complicated work.

The three-option strategy

You don't have to predict the difficulty of every task perfectly. A useful alternative is to think of model selection in terms of three options: Recommended, Economy, and Escalate.

Let's use a concrete example.

You want Claude to add a search feature to an existing application. It needs to search stored data, display matching results, and let users apply a few filters.

Recommended: Sonnet with Medium or High effort. This is the sensible starting point if the application already has a working database and established patterns for displaying data. Sonnet can examine those patterns and build the new feature around them.

Economy: Sonnet with Low effort. If you've already specified exactly how the search should work and which existing components to reuse, the job may require less investigation. Haiku might also be suitable for a small, isolated portion of the implementation.

Escalate: Opus with High effort. Suppose the feature turns out to require complicated permission rules, unusual database queries, and changes to how information is stored throughout the application. The task is no longer as straightforward as it first appeared.

Fable becomes another option if the underlying problem is exceptionally demanding and the additional capability justifies its cost.

This approach works because you can begin with a reasonable choice and adjust when the nature of the work becomes clearer.

There is, however, a Claude-specific detail worth knowing. Changing models or effort levels in the middle of a conversation can invalidate Claude Code's prompt cache, causing existing context to be processed again at a higher cost.

There is an exception: Fable 5.1 supports changing effort without invalidating the cache when used with a Claude subscription or API key in supported Claude Code versions. This exception does not apply to every provider or configuration. Anthropic explains the details in its prompt caching documentation.

So don't switch models after every little instruction just to chase theoretical savings. Choose a sensible setup for the current job, keep working while it makes sense, and reconsider when you reach a natural stopping point or encounter a problem that genuinely needs more capability.

Reasoning effort matters too

Choosing a Claude model determines which model handles your task. Effort controls how much work it puts into the response.

This affects more than the amount of reasoning Claude performs. It can also influence how thoroughly Claude investigates the project, how many tools it uses, and how many steps it takes before returning to you.

Claude Code supports adjustable effort on compatible models, with options including Low, Medium, High, XHigh, and Max. The available levels depend on the model.

You can inspect and change them using /effort. Anthropic documents these settings in its Claude Code model and effort configuration guide.

A straightforward CSS change probably doesn't need XHigh. If you're moving a button, changing a font, or adding a menu option that calls an existing function, Low or Medium is a reasonable place to start.

Building an important system from scratch is different. Claude may need to consider several possible implementations, anticipate problems, and check that the individual pieces work together.

Higher effort can be useful there.

But don't automatically choose Max for every difficult task. Max can consume more tokens and may produce diminishing returns compared with a lower setting. Start with a sensible level and increase it when the work demands it.

One practical habit is to check both /model and /effort when beginning a new Claude Code session. Your previous selections may persist, so the settings you used for a difficult architectural problem could still be active when you return to make a handful of small UI changes.

The general principle is to spend more reasoning on difficult decisions and less on predictable execution.

Your conversation history can quietly eat your usage

Model choice and reasoning aren't the only things that matter. One of Claude Code's biggest sources of unnecessary usage is a conversation that has grown far beyond what the current task requires.

Imagine you've spent the morning building a website. Claude has inspected the navigation, reviewed several CSS files, fixed a form, run tests, and helped you investigate an unrelated error.

Now you want to add a simple contact button.

The button itself might require only a few minutes of work, but Claude is still carrying much of the earlier conversation into its requests. Previous messages, file contents, and command outputs contribute to the context it processes.

Claude Code uses caching to reduce the cost of repeatedly processing this information, but cached context isn't free. Long conversations can also become cluttered with information that no longer helps the current task.

Fortunately, Claude provides two particularly useful commands, which are covered in more detail in Claude Code's session management guide.

Use /clear when you're starting something new

The /clear command starts a fresh conversation without deleting your project files or its CLAUDE.md instructions.

If you've finished building the login system and are moving on to the settings screen, clearing the conversation can prevent the earlier investigation from following you into an unrelated task.

Be sure you've saved any important decisions that exist only in the conversation first. Clearing removes that history from the active session, although previous sessions can still be resumed.

Use /compact when you need to continue

Sometimes you don't want a fresh start. You might be halfway through implementing an important feature and need Claude to retain what you've already decided.

That's when /compact becomes useful.

It summarizes the conversation, preserving important context while reducing the amount of history Claude needs to carry forward.

You can even tell it what matters:

/compact Preserve the agreed architecture, modified files, remaining tasks, and important test results.

Claude also has automatic compaction, but you don't have to rely entirely on it.

The distinction is simple. Clear when you're changing jobs. Compact when you're continuing the same job and the conversation has become unnecessarily large.

There's no need to compact after every few messages, either. Compaction has its own cost and can disrupt prompt caching. Use it when reducing the accumulated context is likely to be worthwhile.

Give Claude the right information, not the entire project

Here's another way to reduce unnecessary usage without sacrificing capability.

Suppose you want to change the appearance of a navigation menu.

You could tell Claude to examine your website and figure out how the navigation works before making the change. Depending on the project, it might inspect several directories and read numerous files before finding the relevant CSS.

Alternatively, you could point Claude directly to the navigation component and stylesheet.

Claude Code supports referencing files with @, which attaches the relevant file to your message without requiring Claude to find and read it separately. Referencing the same file repeatedly in one conversation is unnecessary because it can add duplicate content.

You don't have to know the exact file for every task. Finding and understanding the right files is part of what makes Claude Code useful.

But when you already know where something lives, there's little reason to make Claude search for it again.

The same principle applies to your instructions.

Compare asking Claude to make your website look more modern with telling it to increase the navigation spacing, use the existing button styles, and leave the mobile layout unchanged.

The second instruction gives Claude a clearer destination. It reduces the likelihood of unnecessary changes and the additional conversations needed to correct them.

A useful prompt explains the desired result, identifies relevant constraints, and tells Claude how to verify the work.

You don't need to write an enormous technical specification for every small change. Give Claude enough direction to do the job properly, and let it handle the implementation.

Keep CLAUDE.md useful, not enormous

If you're developing a larger project, a CLAUDE.md file can be extremely helpful.

It's a project instruction file that Claude Code reads when starting conversations. You can use it to establish important rules about your application, its architecture, coding conventions, and how changes should be tested.

For example, if your application uses a particular styling system, you can tell Claude to reuse it rather than introducing a new one.

If there's a specific command that verifies the project, include it.

But resist the temptation to turn this file into a 40-page doctrine explaining everything Claude could possibly encounter.

Instructions that aren't relevant to the current task still occupy context. Anthropic recommends keeping CLAUDE.md concise and using more specialized, on-demand instructions for workflows that aren't needed in every session.

You can read more about how this works in Anthropic's CLAUDE.md documentation.

Think of it as giving Claude the rules of the workshop rather than making it reread the entire employee handbook every time you need another button.

Planning may save more tokens than changing models

Imagine you're about to create a relatively ambitious mobile application.

You know roughly what you want, but you haven't decided which screens it needs, how users will navigate, what information must be saved, or which features belong in the first version.

You could open Claude Code and ask it to build the entire application.

Claude would have to make many of those decisions while implementing the software. You might then discover that you wanted the navigation to work differently, that a feature should have been optional, or that the way data is stored doesn't support something you intend to add later.

The application may need substantial revisions.

A more efficient approach is to settle the important decisions before asking Claude to write the full implementation.

You can do that in a normal Claude conversation, or use Claude Code's Plan Mode to investigate the existing project and work out the implementation before changing files.

Anthropic recommends planning for unfamiliar work and multi-file changes while skipping the extra planning overhead for simple, obvious edits.

For a new app, establish the main features, screens, navigation, data requirements, and any important constraints. Once the direction is reasonably clear, turn those decisions into implementation instructions.

You don't need to plan every tiny detail. An excessive planning process can consume just as much usage as unnecessarily complicated coding.

And remember that planning in Claude chat still counts toward your Claude subscription allowance. The potential saving comes from avoiding wasted implementation and rework, not from transferring the conversation to another interface.

Good planning gives Claude fewer unnecessary decisions to make during development.

It also makes the model ladder more useful. You might use Opus to work through a difficult architectural problem and Sonnet to implement the resulting plan.

Claude Code even provides an opusplan model option for this workflow, although switching between models can affect prompt caching. Whether that's worthwhile depends on the complexity of the work.

For small changes, skip the ceremony and get straight to work.

Stop paying for output you don't need

Claude doesn't just consume tokens when it writes code or explains its decisions. Reading files, running tools, and returning command output also contribute to usage.

This is particularly relevant when testing.

If Claude runs a test suite that produces hundreds of lines of successful results, that output can remain in the conversation even though you may only need to know whether the tests passed.

For a small, isolated change, running the relevant tests and returning a concise result may be enough.

For important architectural changes or work involving payments, authentication, and stored data, broader verification may be justified.

Anthropic specifically recommends using quieter command options and examining whether unnecessarily verbose tool output is filling the conversation.

The same thinking applies to explanations. If you're already comfortable with the code, you can ask Claude to summarize what changed and report the verification result instead of producing a lengthy tutorial after every edit.

If you're learning programming, though, those explanations can be worth the usage. Understanding why something works may be more valuable than saving a handful of tokens.

The aim is to eliminate output you don't need, not information that helps you build better software.

Check what's consuming your allowance before upgrading

If you're regularly exhausting your Claude allowance, investigate what's happening before automatically moving to a more expensive plan.

Claude Code's /usage command provides information about your consumption. Subscribers can inspect their plan usage and activity, while API users can examine session token costs. /context is also useful for seeing what's loaded into the current conversation.

Anthropic covers these tools and additional savings techniques in its Claude Code cost management guide.

Consider how you've been working.

Perhaps you've been using Opus for every task, including simple styling changes. Maybe you're carrying the same conversation through several unrelated features or running multiple coding sessions simultaneously.

You could also be using additional services or models that draw on usage credits.

Once you've identified where the allowance goes, you can make a more informed decision.

Sometimes a few changes to your workflow will make your existing plan sufficient. Other times, if you're doing substantial productive work every day, additional usage may genuinely be worth paying for.

The amount of money you spend on Claude matters, but so does the value of the work you're getting done.

When saving tokens becomes expensive

There's a trap on the other side of all this.

Suppose you're implementing an important feature and choose Haiku because you want to conserve usage.

It struggles with the problem. You explain the requirements again, ask it to correct several mistakes, and eventually switch to Sonnet or Opus to repair the implementation.

You haven't necessarily saved anything.

The same problem can occur when you use low effort for work that needs careful investigation. A complicated problem may require several unsuccessful attempts when a more appropriate model and effort setting could have handled it more effectively from the beginning.

Don't keep trying the same approach indefinitely just because it's cheaper per request.

If Claude repeatedly misunderstands a task, first check whether your instructions and relevant project context are clear. If they are, consider moving to a more capable model or increasing the effort.

For a long session filled with failed attempts, starting a fresh conversation with a clearer description of the problem may also help.

The real objective isn't to minimize the number of tokens used.

It's to get the result you wanted without spending more than necessary.

A practical Claude workflow

For a larger project, a sensible workflow is to begin by settling the important requirements and architectural decisions. Use a capable model when the work involves genuine uncertainty or decisions that future features will depend on.

Once the foundation is established, let Sonnet handle much of the ordinary implementation. Bring in Haiku for suitable small tasks, and return to Opus when the work becomes substantially more complicated.

Use Fable when the problem or scope justifies its additional capability and potential cost.

Keep your project instructions concise, give Claude relevant files when you know where they are, and start fresh conversations when moving between unrelated tasks. Check your usage occasionally so you can identify where your allowance is actually going.

Most importantly, change your approach as the project develops.

The model that helps you design an application doesn't necessarily need to be the model that adjusts its buttons three weeks later.

There's nothing wrong with enjoying Claude's more powerful models. Just give them work that makes their additional capability worthwhile.

Spend more on the decisions that matter. Save usage on the work that's straightforward.

That's how you make Claude's allowance last longer without turning token conservation into a project of its own.

Related reading

If you're also using OpenAI's coding agent, our guide to saving money and tokens in Codex covers its model lineup and reasoning levels, with the same focus on matching model capability to the work you're doing.