How to Cut Your Claude Token Usage in Half

If you're on the $20/month Claude plan and you keep hitting the "you've reached your limit" wall before lunch, this post is for you.

I hit that wall constantly for months. My first instinct was the obvious one: pay more. But before upgrading, I decided to actually understand what was eating my quota. What I found surprised me — roughly half of my token usage wasn't buying me better answers. It was pure waste: bloated conversations, re-explained context, files pasted "just in case," and verbose output formats I never asked to change.

Once I fixed the workflow, the same daily workload fit comfortably inside my plan. Not by using Claude less. By feeding it less junk.

This is the complete playbook. No hacks, no "secret jailbreaks" — just an honest explanation of how the meter works and a set of repeatable habits that cut usage roughly in half while keeping answer quality the same or better. In several cases the answers got noticeably better, because a lean context is also a smarter context. More on that below.

What tokens actually are, in plain English

Every AI assistant — Claude, ChatGPT, all of them — reads and writes text in small chunks called tokens. A token is usually a short word, part of a longer word, or a piece of punctuation.

Rough rules of thumb:

• 1 token ≈ 4 characters of English text
• 1 token ≈ 0.75 words
• 100 tokens ≈ 75 words ≈ a short paragraph
• 1,000 tokens ≈ 750 words ≈ a two-page email
• 10,000 tokens ≈ a 15-page document

So "the quick brown fox" is about four tokens. This blog post is around 6,000 tokens. A 50-page PDF might be 25,000–35,000 tokens.

Here's the part most people miss: you pay for tokens in both directions. Everything you send Claude (your message, your pasted files, and — critically — the entire conversation history) counts as input tokens. Everything Claude writes back counts as output tokens. Output tokens are significantly more expensive than input tokens, typically about five times more.

On a subscription plan you don't see a per-token bill, but the same accounting runs underneath: your usage limit is a token budget in disguise. Burn tokens faster, hit the wall sooner. The API prices make the underlying economics visible, and they're worth internalizing even if you never touch the API:

Model tier	Best for	Input cost (per 1M tokens)	Output cost (per 1M tokens)
Haiku (small, fast)	Simple lookups, formatting, quick drafts	~$1	~$5
Sonnet (mid-size)	Everyday writing, analysis, coding	~$3	~$15
Opus (large)	Hard reasoning, long multi-step work	~$5	~$25

Two things jump out of that table:

1. Output costs roughly 5× input. Asking for a "comprehensive detailed report" when you needed three bullet points is the single most expensive habit in casual AI use.
2. The big model costs roughly 5× the small one. Using the flagship model to reformat a table is like hiring a senior consultant to staple documents.

Keep those two ratios in your head — 5× for output, 5× for model tier — and half of this article follows logically.

Why long chats get expensive AND dumb

This is the mechanic that explains most mystery quota burn, so let me spell it out.

The model has no memory. Every single message re-sends the entire conversation.

When you send message #40 in a long chat, Claude doesn't just read message #40. Behind the scenes, the app sends messages #1 through #39 — every question, every answer, every pasted file, every dead end — plus your new message, all as fresh input. The model reads the whole thing from the top, every time.

Do the math on what that means:

• Message 1: you send 500 tokens of context. Cost: 500 input tokens.
• Message 10: the history is now ~8,000 tokens. Your one-line follow-up costs 8,000+ input tokens.
• Message 40: the history is 45,000 tokens. Typing "can you rephrase that?" costs 45,000 input tokens.

That "quick follow-up" at message 40 costs ninety times more than the same question would cost in a fresh chat. Long conversations don't grow linearly in cost — the total spend grows roughly with the square of the conversation length, because each new message re-pays for everything before it. One mega-chat that runs all day can quietly burn more tokens than twenty focused sessions.

And here's the kicker: you're paying that premium for worse answers. This is called context bloat, and it degrades quality in three ways:

1. Dilution. The instruction that matters is buried under 40,000 tokens of stale discussion. Models pay less reliable attention to the middle of a huge context — your key constraint from message 3 effectively fades.
2. Contamination. Every abandoned approach, every "no wait, ignore that," every wrong draft is still in the context, still influencing the output. You told it to drop the formal tone twenty messages ago, but the formal drafts are still sitting there as examples of "what we write like."
3. Drift. As the conversation sprawls across topics, the model's sense of what you're actually working on right now gets blurry. You start getting answers to the conversation instead of answers to the question.

Expensive and dumb is a bad combination. The fix costs nothing and is the highest-leverage habit in this entire post.

Habit 1: Start fresh sessions instead of one mega-chat

The rule I use: one task, one chat.

Writing a proposal? One chat. Debugging a spreadsheet formula? New chat. Back to the proposal? Back to that chat — or better, a new one with a two-line summary of where things stand.

When to start fresh:

• The topic changed. Even slightly. "While I have you here..." is a token tax.
• The chat crossed roughly 15–20 exchanges. Past that point, you're paying heavy freight on every message.
• Quality is degrading. If Claude starts forgetting instructions or contradicting earlier decisions, the context is bloated. More messages won't fix it; they compound it.
• You finished a phase. Research done, moving to drafting? Fresh session, carry over only the conclusions.

The objection everyone raises: "But it loses all my context!" It doesn't have to. Use a handoff summary. Before abandoning a long chat, send one final message:

"Summarize this conversation in under 150 words: the goal, the decisions we made, and what's left to do. I'll use this to continue in a new session."

Paste that summary into the fresh chat. You've converted 40,000 tokens of sprawl into 200 tokens of signal — and the new session usually gives sharper answers because the model sees only the conclusions, not the mess that produced them. This is the core move of context engineering, and it's a skill worth practicing deliberately (I keep a whole skill dedicated to it — linked at the bottom).

Habit 2: Write tight prompts

Tight doesn't mean short at all costs. It means every sentence earns its place.

The waste I see most often in other people's prompts (and, honestly, my old ones):

• Throat-clearing. "Hello! I hope you're doing well. I was wondering if you could possibly help me with something, if it's not too much trouble..." — that's 30 tokens before any information arrives. Politeness is free with humans and pointless with models. Just state the task.
• Redundant framing. "I'm going to paste a document below. The document is a contract. When you read the contract, please analyze the contract..." Say it once.
• Vague asks that force retries. The most expensive prompt is one that produces a wrong answer, because now you pay for the answer, the correction, and the redo — with the failed attempt riding along in context forever after. "Make this better" costs three rounds. "Tighten this to 200 words, keep the pricing details, drop the history section, plain tone" costs one.

A tight prompt has four parts, usually in ten lines or fewer:

1. Task — what to do, one sentence.
2. Context — the minimum background needed, not everything you know.
3. Constraints — length, tone, format, what to exclude.
4. Output shape — what "done" looks like.

Example: "Rewrite the email below for a client who rejected our first quote. Keep it under 120 words, warm but not apologetic, and end with a specific next step. Don't mention the discount yet."

That's ~40 tokens of instruction and it produces a usable result on the first try. First-try accuracy is the cheapest token optimization there is. If you want the full treatment on prompt structure, I've written a complete guide (linked in the resources).

Habit 3: Use project instructions instead of re-explaining yourself

Count how many times you've typed some version of: "I run a small marketing agency, we write in a casual but professional tone, our clients are mostly SaaS companies, keep answers concise, use British spelling..."

If you type that intro in every chat, you're paying for it in every chat — and paying again each time the conversation re-sends history.

Both Claude and ChatGPT solve this with persistent instructions:

• Claude Projects let you attach standing instructions and reference documents to a workspace. Every conversation in that project starts already knowing your context.
• Custom instructions / profile settings apply globally: who you are, how you like answers formatted, what to always avoid.

Move anything you say more than twice into persistent instructions. Good candidates:

• Your role and what you're generally working on
• Tone and style preferences ("plain English, no hype, no emojis")
• Format defaults ("answers under 300 words unless I ask for depth")
• Standing constraints ("we can't recommend competitor X," "always UK spelling")
• The one-paragraph description of your business you keep retyping

There's a quality bonus here beyond the token savings: persistent instructions are stable. When your preferences live in the project, they apply with full strength in message 1 of every fresh session — which makes the fresh-session habit from earlier truly costless. You get short conversations and full context. This combination — fresh sessions plus persistent instructions — is the backbone of my whole workflow template.

One caveat: don't stuff the project instructions themselves. They're loaded into every conversation, so a 3,000-word instruction document is its own tax. Mine are under 250 words. If yours read like a novel, prune them — that's part of the weekly hygiene routine at the end.

Habit 4: Attach only relevant files

The "just in case" attachment is a budget killer. Every page of every attached file becomes input tokens — often on every message of the conversation, not just once.

A rough sense of scale: a 50-page PDF is ~30,000 tokens. Attach it to a chat and ask five questions, and you may have spent 150,000+ input tokens — the majority of them on the 47 pages that were never relevant.

Better moves:

• Extract before you attach. If your question is about clause 7 of the contract, paste clause 7 — not the contract. Ten seconds of copy-paste can save 95% of the tokens.
• Ask for the map first. For a genuinely unknown document, use one cheap pass: "List this document's sections with a one-line summary of each." Then start a focused session on only the section you need.
• One file per purpose. Attaching three versions of a draft "for comparison" when you only need feedback on the latest means paying triple. Attach the latest; describe the delta in a sentence.
• Keep reference docs in the project, not the chat. Files that genuinely matter to everything you do (brand guide, product one-pager) belong in project knowledge, where the tooling manages them more efficiently, rather than re-pasted into conversations.
• Beware spreadsheets and exports. Raw CSV dumps are token-dense and mostly noise. Aggregate first, or paste the 20 relevant rows instead of 5,000.

The test I apply before attaching anything: could Claude answer my question if it saw only 10% of this file? If yes, find that 10%.

Habit 5: Ask for concise output formats

Remember the ratio: output tokens cost about 5× input tokens. Yet most people optimize their prompts and let the model write whatever length it feels like. By default, that's long — models are tuned to be thorough, which reads as helpful and bills as expensive.

You have full control over this. Use it:

• Cap the length. "Answer in under 100 words." "Three bullets, max." "One paragraph." Length caps are the most reliable single-line saving in this post.
• Ask for the answer, not the essay. "Give me the answer first, one line of reasoning only if essential." You skip the preamble, the caveats, the restating of your question, and the summary of what it just said.
• Choose dense formats. A table is usually far more token-efficient than the same information as flowing prose — and easier for you to scan. "Compare these three options in a table: cost, effort, risk."
• Skip the explanations you don't need. When you ask for a rewrite, say "return only the rewritten text, no commentary." Otherwise you pay for two paragraphs about why the rewrite is good.
• Iterate on sections, not wholes. If you're refining paragraph 2 of a five-paragraph draft, ask for paragraph 2 back — not the entire draft regenerated with one paragraph changed. Regenerating unchanged text is paying full price for a photocopy.

None of this makes answers worse. Verbosity is not quality. A 60-word answer that's exactly right beats a 600-word answer with the same content padded in — and it costs a tenth as much.

Habit 6: Match the model to the task

If your plan lets you choose between models — and both Claude and ChatGPT plans do — model selection is a 3–5× lever per task.

My routing rules:

Small/fast model (Haiku-class) for mechanical work:

• Reformatting, cleaning up text, fixing grammar
• Summarizing a document you'll read anyway
• Simple factual lookups and definitions
• Generating boilerplate: meeting agendas, standard emails, checklists

Mid-size model (Sonnet-class) as the everyday default:

• Drafting real documents, emails, and posts
• Everyday coding and debugging
• Analysis with a clear structure
• Most of what most professionals do most of the day

Large model (Opus-class) reserved for genuinely hard problems:

• Multi-step reasoning where a wrong answer is costly
• Nuanced strategy, tricky negotiations, complex documents
• Long agentic tasks in Claude Code
• Anything where you'd otherwise ask a senior expert

The mistake is defaulting to the biggest model for everything "to be safe." For mechanical tasks, the small model's answer is indistinguishable — you're paying a 5× premium for zero visible difference, and on subscription plans the big models typically draw down your limits much faster.

A pattern I use daily: draft small, polish big. Have the cheap model produce the rough structure, then bring the strong model in for one focused pass on the part that actually needs judgment. Two cheap calls plus one expensive short call beats one expensive long call, on both cost and often quality.

Habit 7: Batch your questions

Every message in a conversation re-sends the history. So ten small questions asked as ten separate messages pay the history tax ten times. The same ten questions in one message pay it once.

Instead of:

"What's a good subject line for this email?" (answer) "And what about the preview text?" (answer) "Should I send it Tuesday or Thursday?" (answer)

Send:

"For the email below: 1) suggest three subject lines, 2) suggest preview text, 3) recommend Tuesday vs Thursday send and say why in one line."

One message, one response, one pass through the context. As the conversation gets longer, the savings get bigger — at message 30 of a working session, batching three questions into one message can save tens of thousands of input tokens versus dribbling them out.

Batching has a quality benefit too: the model answers with all three questions in view, so the subject line, preview text, and timing advice are consistent with each other instead of generated in isolation.

The limit: don't batch unrelated tasks into one chat — that's how mega-chats are born. Batch related questions within a task; separate sessions between tasks.

Habit 8: Build reusable skills and templates instead of re-prompting

Here's where occasional users and systematic users permanently part ways.

If you've ever written a really good prompt — one that took four rounds of refinement before the output was exactly right — and then lost it in your chat history, you've paid a refinement cost you'll pay again next month. Re-deriving a good prompt from scratch costs every failed attempt, every time.

The fix is to treat prompts as assets:

• Templates. Keep a note (or a doc, or a text expander) with your proven prompts: the weekly report prompt, the client email prompt, the meeting-notes-to-actions prompt. Fill in the blanks, paste, done. First-try quality, zero re-derivation cost.
• Skills. Claude supports reusable skills — packaged instruction sets that load only when relevant. Instead of pasting your 400-word "how I want research briefs structured" instruction into every research session, it lives as a skill and activates when needed. You define the workflow once; every future invocation is a few words.
• Project-level workflows. A project whose instructions encode a repeatable process ("every draft goes: outline → my approval → full draft → tightening pass") means you never spend tokens negotiating process again.

This is the deepest theme of everything I write: repeatable workflows beat one-off tricks. A clever prompt saves you tokens once. A template saves you tokens every week forever, and the outputs get more consistent as a side effect. My most-used skills — the ones for context engineering, structured research briefs, and getting Claude to interrogate my assumptions before answering — are all downloadable from this site and linked below.

When caching helps (and what it means for you)

You'll hear the term "prompt caching" and it's worth understanding, because you can arrange your work to benefit from it.

The idea: when the beginning of your request is byte-for-byte identical to a recent request, the system can reuse its processed form instead of re-reading it from scratch. On the API this is explicit and dramatic — cached input is billed at roughly a tenth of the normal price. Inside the consumer apps, similar machinery runs under the hood and helps the provider serve you faster and cheaper, which is part of why stable project setups feel snappier than chats where everything changes constantly.

Caching is prefix-based, which leads to one practical rule: stable stuff first, changing stuff last. The cache breaks the moment anything earlier in the context changes.

What this means in practice:

• Keep project instructions and reference documents stable. Editing your project instructions daily invalidates the reusable prefix; a settled setup gets cheaper and faster over time.
• Put your big unchanging context up front, questions after. In a session anchored on a document, attach the document once at the start, then ask your questions in sequence — rather than re-pasting or editing the document mid-conversation.
• Work in focused bursts. Caches expire after minutes of inactivity. Ten questions about a contract asked in one 20-minute sitting reuse the same processed context; the same questions scattered across the day re-pay repeatedly.
• Don't edit earlier messages if you can avoid it. Editing message 2 of a 20-message chat invalidates everything after it. Append a correction instead.

You don't have to think about caching constantly. But "stable context first, focused bursts, don't churn the setup" is a habit that quietly compounds.

The before/after: same task, half the cost

Let me make this concrete with a realistic task: reviewing a 30-page vendor contract before a renewal call, and drafting a negotiation email.

The "before" workflow — how I used to do it:

Continue in yesterday's all-purpose chat (already ~20,000 tokens of unrelated history). Attach the full 30-page contract (~18,000 tokens). "Can you look at this contract and tell me what you think?" Get a long general summary I didn't quite need (~1,200 output tokens). Ask about termination terms. Ask about the price escalation clause. Ask it to explain clause 9 again, simpler. Ask for a negotiation email — get 500 words of formal prose in the wrong tone, because the tone guidance was buried twenty messages back. Ask for a rewrite, warmer. Ask for it shorter. Nine exchanges total, each one re-sending the old history plus the full contract.

Rough token math: the contract plus bloated history rode along on every one of nine messages — on the order of 350,000–400,000 input tokens and ~5,000 output tokens for the session. One task, and a visible dent in the day's limit.

The "after" workflow — same task, same quality bar:

1. Fresh chat inside my "Vendor & Contracts" project, whose standing instructions already say who I am, my negotiation style, and "concise answers, tables where possible."
2. First message, batched: attach the contract once and ask — "Renewal call Thursday. From this contract: 1) termination and auto-renewal terms, 2) the price escalation clause with actual numbers, 3) the three clauses most worth renegotiating, one line each. Table format."
3. One focused answer (~600 output tokens), everything I need for the call.
4. Second message: "Draft the negotiation email: push back on the escalation clause, propose a 2-year lock at current pricing, under 150 words, return only the email." The tone is right the first time because it lives in the project instructions.
5. Done in three exchanges. The contract was processed at full price once, then reused cheaply within the burst.

Rough token math: on the order of 60,000–80,000 input tokens and ~1,000 output tokens. Same contract, same deliverables, better email on the first draft — at well under half the cost. Honestly closer to a fifth, but I promised you half, and half is what you'll reliably get while you're still building the habits.

Nothing in the "after" version required expertise. It required a fresh session, persistent instructions, one batched question, an output cap, and not dragging the file through a bloated chat. Every one of those is a decision you can make tomorrow morning.

The weekly context hygiene routine

Habits decay without maintenance. This takes me about ten minutes every Friday:

1. Kill the zombie chats. Any conversation I've been "continuing" for more than a week gets a handoff summary extracted, then retired. Long-lived chats are where quota goes to die.
2. Prune project instructions. Read them start to finish. Delete anything I added for a situation that's over. Instructions only ever grow unless you cut them — and you pay for every word in every conversation.
3. Audit project files. Remove attached documents that no longer earn their place. That "temporary" spec from March is still billing you.
4. Promote repeated prompts. Scan the week's chats for anything I typed twice. Second time I write a prompt, it becomes a template; if it encodes a real workflow, it becomes a skill.
5. Check my model defaults. Did I burn flagship-model quota on formatting tasks this week? Adjust the default, or adjust me.
6. Note the limit pattern. If I hit usage caps this week, note which day and which task. Almost always the culprit is one bloated session, not overall volume — and now it has a name.

Ten minutes. It keeps the system lean, and lean is what makes everything else in this post work.

The 10-point checklist

Print this, or pin it. If you do nothing else, do these:

1. One task, one chat. Start a fresh session whenever the topic changes or the chat passes ~15–20 exchanges.
2. Exit long chats with a handoff summary (under 150 words) and carry that into the new session — not the whole history.
3. Move anything you've typed twice into project instructions — and keep those instructions under ~250 words.
4. Attach the relevant 10% of the file, not the file. Extract the clause, the section, the rows you actually need.
5. Cap the output. "Under 100 words," "three bullets," "table format," "return only the rewrite."
6. Route by difficulty: small model for mechanical tasks, mid-size as the daily default, big model only for genuinely hard reasoning.
7. Batch related questions into one message instead of dribbling them across five.
8. Iterate on the section, not the document. Never regenerate unchanged text.
9. Keep stable context stable — settled instructions, document attached once up front, questions in a focused burst. That's how you benefit from caching without thinking about it.
10. Run the ten-minute Friday hygiene routine: retire zombie chats, prune instructions, promote repeated prompts into templates and skills.

Half your token usage is hiding in those ten lines. The answers don't get worse — mostly they get better, because everything you stopped sending was noise.

Resources & links

• Six Claude prompts that put you ahead of 99% of users — the highest-leverage prompt patterns to pair with the tight-prompt habit.
• Claude Code explained for normal people — what Claude Code is and when it's worth your tokens, in plain English.
• The complete prompt engineering guide for 2026 — the full deep-dive on prompt structure, from basics to advanced patterns.
• My Claude workflow template — the fresh-sessions-plus-persistent-instructions system from this post, packaged as a copyable setup.
• Secret Claude Code commands — lesser-known commands, several of which exist specifically to manage context and cost.
• Context engineering skill — a downloadable skill that automates handoff summaries and lean-context habits.
• Karpathy guidelines skill — coding-assistant guardrails that keep outputs short, focused, and re-usable.
• Grill Me skill — makes Claude interrogate your assumptions before answering, so you pay for one right answer instead of three wrong ones.
• GSD Core skill — my getting-stuff-done workflow core: one task, one session, defined outputs.
• Superpowers skill — a bundle of reusable workflows that replace re-prompting with one-word invocations.
• Deep research brief skill — produces tightly-scoped research briefs so long research sessions start lean and stay lean.

If this saved you a usage limit or two, I write one practical, hype-free piece like this every week — join the newsletter at alexandrrich.substack.com.