Cut Claude Token Costs: Prompt Caching, MCP Overhead, LSP and Model Switching

A Claude bill can climb even when nobody switches to a bigger model. More often the cause is a pile of tools that get loaded and never called. A session that suddenly feels slow is usually the first hint, and the usage numbers tell the rest. The same handful of habits keep draining budgets for lots of developers, so they're worth walking through.

Where the money goes: input tokens

The model has no memory of the previous message. On every turn the entire conversation is sent again. By the twentieth message, you're paying to resend the first nineteen before a single new word gets written.

Output tokens cost roughly five times more than input tokens, and that's the figure everyone quotes. But output stays small next to a long chat's input, and input is what accumulates. As a rough conversion, 100 tokens equal about 75 English words. Do the arithmetic on an hour-long session and the total gets uncomfortable fast. Input tokens compound with each turn, while output tokens don't.

Prompt caching, the discount few people use

Anthropic keeps the opening portion of a prompt cached, provided it matches exactly. Reading from that cache is billed at roughly ten percent of regular input pricing. A miss is slightly pricier than no caching at all, since creating a cache entry carries a 1.25x surcharge over the base price.

The default cache lifetime is five minutes, and each hit refreshes it at no charge. A one-hour option exists, but writing to it costs double.

The lifetime matters a lot. In March 2026, Claude Code reportedly moved from the one-hour cache to the five-minute one. A developer went through their own API bills and filed a GitHub issue. With the one-hour cache, about 1% of spending went on rewriting the cache. After the change, the share ranged from 15% to 53%.

A second developer modeled a 200K-token Opus session. Leave for longer than five minutes and the entire context must be written afresh when you return, about $1.25 each time. Over a full day, some sessions ended up 30% to 60% costlier, with identical work. The cache window was the only difference.

Return within five minutes and you pay a tenth. Miss the window and you pay 1.25 times.

There's a catch: the match must be exact. Any edit to the system prompt, any tool added or dropped, or a model swap in the middle of a session wipes it out. According to Anthropic's documentation, changing a single tool definition invalidates the entire cache. How forgiving the matching is under heavy load is less clear, since busy sessions can behave less predictably than the spec suggests. The usage dashboard is a safer guide than mental math.

The practical version: choose the model first, keep the system prompt stable and don't add tools halfway through. On the API, if the pauses between turns regularly exceed five minutes, the one-hour cache may well be cheaper.

MCP servers aren't free

Every connected tool adds its schema to the prompt: the name, the description and every parameter. That cost recurs on each turn while the tool is loaded, used or not.

One developer's blog post made many people check this. Starting a Claude Code session with several MCP servers, the tools alone consumed over 66,000 tokens before a word was typed. That's a third of a 200K window. Running /doctor put the real figure closer to 82,000, and a single search server with 20 tools accounted for about 14,000 tokens.

Worse cases exist. In a GitHub issue filed in November 2025 a Docker MCP server with 135 tools consumed around 126,000 tokens by itself, and the reporter got a "context low" warning on every command.

MCP earns its price when structured, repeated access to a service is needed. It doesn't earn it by sitting unused in context.

Recent improvement. January 2026 brought Tool Search to Claude Code. If MCP descriptions would take up more than a tenth of the context, their full schemas stay out of the prompt. A lightweight search tool is offered instead, and a definition is fetched only at the moment it's required. Anthropic reports roughly an 85% reduction in tool token overhead.

The recurring charge has shrunk, yet it hasn't vanished. Setups that stay under the threshold still load every schema up front. Other clients may not defer at all. And piling on tools still hurts accuracy even when they're cheap. Running /context shows what's actually being paid for.

Command-line tools avoid the whole issue. The model already knows git, curl and the GitHub CLI, or can run --help. There's no schema and no standing cost. For something needed only now and then, the CLI wins.

Code search burns more than expected

Grep sees code as plain text. Searching for where User is defined brings back every mention: classes, variables, comments, imports, stylesheet selectors and database columns.

A write-up of one real project reported 847 matches across 203 files for exactly that kind of search, with the model then reading every one to find the true definition. Timing from the logs: up to a minute of grepping, against around 50 ms when a language server answered.

The same pattern shows up on a smaller scale. On a 30K-line repo, grepping for a function rename produced 733 hits, and only 501 mattered. Every irrelevant hit still gets read and paid for. Pointing the model at an LSP takes it straight to the 501, which saved roughly 13K tokens on that one search. Whether the ratio holds elsewhere is uncertain, though it did on both repos that were measured.

Two cautions come from longer-term users:

• Claude defaults to grep even when LSP is on. One developer found the LSP fired only about 1% of the time until explicit instructions went into CLAUDE.md.
• Grep still has a place. It's the right tool for logs, configs, string literals and anything that isn't a code symbol.

Grep returns every text match, while an LSP returns the one symbol that was requested.

Does the "talk like a caveman" trick work?

A widely shared GitHub skill claims up to 65% fewer output tokens by forcing clipped, ungrammatical replies, and it has collected tens of thousands of stars. Ordinary chat testing showed gains near 10%, and coding or agent work hardly changed, because source code can't be squeezed like prose.

A controlled comparison by JetBrains put numbers on it: the advertised saving was 65%, while real agent tasks showed 8.5%. Even that figure came with the skill forced on, which the team called an upper bound, not a typical result.

The repository now concedes the point. The skill shrinks only the output. Input and reasoning tokens stay untouched, and the skill itself adds roughly 1,000 to 1,500 input tokens per turn just by existing. The episode says more about how token savings get marketed than about what actually saves tokens. A six-line prompt asking for concise answers delivers most of the same effect.

Switching models mid-session costs twice

Of all these points, this one catches people off guard. Dropping to a cheaper model halfway through sounds thrifty, yet it rarely is. The stored prompt belongs to the previous model, so its replacement must process everything again and pay the write surcharge.

Pick the model before starting. Anyone who wants routing without paying for the switch can use a router that chooses the model before the request goes out, which avoids the problem completely.

The habit with the biggest effect: precision

Say exactly which format, fields and length are wanted, and the model stops producing things nobody asked for. Compare this prompt:

Return a JSON object with keys: "title", "price", "inStock".
No extra commentary.

with "give me the product info". The second isn't just lazy. Vagueness invites over-answering. Specificity is the thread running through nearly every good prompting technique, and it ties in with how much is requested from the model in one go.

What it adds up to

None of this is about choosing a cheaper model. It's about what goes into the model and how often it has to reread itself. The checklist is short:

• keep the system prompt stable
• stay with one model
• run /context and remove tools that aren't used
• enable LSP, then state in the instructions that it should be preferred
• spell out the precise output shape wanted

That covers most of the gain, and it costs nothing to start tomorrow.

Quick answers

Do output tokens really cost more than input tokens? Yes, about five times more per token on Claude models. In a long conversation, though, input still dominates, since the full history is resent each turn.

Does a mid-conversation model change always raise the cost? The change by itself doesn't. What hurts is the broken cache, which means the next request is charged at the write rate instead of the discounted read rate. Deciding on the model first avoids this.

Are extra MCP tools always a token problem? No. They make sense when a service needs structured, repeated access, and Claude Code postpones loading schemas once they get big. Trouble appears in small configurations, in clients without deferral, and in accuracy once the model faces too many choices.