Four Practical Techniques to Keep Claude Conversations Lean Before They Get Heavy

When you glance at the usage indicator mid-session and realize you're almost out, the instinct is to close the tab and hope it resets faster. I've been there more times than I'd like to admit. The frustrating part isn't the limit itself — it's the feeling that the ceiling arrived earlier than it should have.

Most of the time, that "almost out" state is self-inflicted. The single biggest cause is carrying one conversation on for too long. Behind the scenes, Claude re-reads the entire chat history with every reply, so each round in a long thread gets more expensive than the last. It snowballs quietly. By the time a single conversation has 30 or 40 exchanges, each new message is paying for all of those prior turns to be re-ingested.

This article walks through four techniques I use in real client work to keep conversations lean. None of them require new features or paid upgrades — you can start applying all four today.

Technique 1: Start a new chat the moment the topic changes

This is the one that works the best and the one most people forget.

A Claude conversation looks continuous on screen, but internally each reply replays everything that came before. If you spent the morning debugging a CSS layout and then pivot to API design in the afternoon, every API reply still ships with the full CSS history attached. You don't see it in the UI, but you absolutely pay for it in tokens.

My rule is to start a new chat whenever:

• The file or feature I'm working on changes
• I'm coming back after an hour or more away
• Replies start feeling noticeably slower
• I catch myself scrolling up to find an earlier decision — if I can't remember it, it's probably not alive in the conversation anymore anyway

The worry is usually "but I want Claude to remember the previous context." That's fair — and we'll handle it directly with Technique 2.

One small habit helps here: rename the chat the moment you finish a topic. If the conversation is titled "Supabase RLS policies for the orders table," you have visual permission to close it and open a fresh one the next time you're working on something different. Leaving chats as the generic auto-title invites the brain to keep piling unrelated topics into the same thread.

Technique 2: Hand off a three-line summary to the new session

When you start a new chat, bring only the conclusions from the previous one — not the full transcript.

For a code review follow-up, I paste something like this at the top:

Decisions from the previous conversation:
- Auth: custom JWT, not Auth0
- Token TTL: 2 hours / refresh: 30 days
- Error logs: Cloudflare Logpush -> BigQuery
 
Today I want to design the fallback for dropped log events.

Those three lines replace hundreds of prior exchanges. The responsiveness difference is immediately noticeable, because the model now re-reads five lines of scaffolding instead of fifty back-and-forths. In practice, the new chat also tends to produce cleaner answers, because it isn't being pulled toward tangents buried in the old transcript.

A small trick: ask Claude to write the summary at the end of the previous chat. Something like "summarize our conclusions in three lines, formatted to paste into the next session" — the output is usable almost verbatim. I treat this as the last step of every long conversation now, the same way I'd write a short meeting note before closing the tab.

If you work across multiple topics in a week, save these three-line summaries in a simple notes app. Over time they become a searchable log of "what Claude and I agreed on" that is far easier to scan than scrolling through old threads.

Add one line for the options you rejected

The piece most often lost in a handoff summary is not the decision itself but the alternatives that lost.

Hand a new chat "we're using JWT" and Claude will helpfully suggest Auth0 again. You then relitigate the same comparison, and the chat you just shortened starts growing back. I burned that round trip repeatedly before the pattern registered.

The fix is a single extra line.

Considered and rejected: Auth0 (monthly cost and dependency weight not worth it here)

With a short reason attached, Claude inherits the criterion and comes back from a different angle instead of the same one. The point of a summary isn't to cut word count — it's to compress the history of your judgment. Reframing it that way made my handoffs stop failing.

Technique 3: Attach only the relevant slice of long documents

Before dragging in a 200-page PDF or an entire source file, spend two extra minutes narrowing it down. This is the technique I see skipped the most, and it's also where the biggest wins hide.

For a large technical spec, my workflow is:

1. Paste just the table of contents and ask Claude which sections look relevant
2. Use Claude's pointers to locate the right chapters
3. Attach only those chapters for the actual conversation

The overhead is trivial, and the token savings are often tenfold. The same principle applies to code — a single function usually gets a better answer than "here's the whole file." If Claude needs more context, it will ask, and you can hand over exactly what's needed.

There's a quality benefit too. When you attach an entire source tree, Claude has to guess which parts you care about and sometimes latches onto the wrong one. Narrow inputs lead to narrow answers, which is what you want when you're debugging a specific behavior rather than asking for an architecture review.

A useful mental model: treat attachments like you would when briefing a skilled contractor. You wouldn't hand them the whole codebase and say "find the bug" — you'd show them the five files you suspect and describe the symptom. Claude works the same way.

Technique 4: Push repeated preamble into Project custom instructions

Claude Pro Projects let you define instructions once per project instead of repeating them in every conversation. This compounds quietly but meaningfully.

My app-development project has something like:

- Target: iOS 18.0+ / Android 14+
- UI framework: SwiftUI / Jetpack Compose
- Primary audience: Japanese users — propose UI copy in Japanese first
- Add Japanese comments to code snippets
- Prefer Result types over try/catch

Those five lines no longer appear in any of my prompts — they live on the project. Every prompt gets shorter, and so does every reply's re-read of the thread. I used to paste the same preamble dozens of times a day without realizing how much of my daily token budget I was spending on it.

A good heuristic for when to split a project is "would a new teammate need a different onboarding doc for this?" Side projects, client work, and personal writing each warrant their own project. I also keep a "sandbox" project with no custom instructions at all, for quick questions that don't belong anywhere else.

One caveat: keep the custom instructions tight. A page of rules is worse than five focused lines, because every rule you add is a rule Claude has to weigh against every reply. Prune aggressively — if you haven't needed a rule in two weeks, delete it.

How much does this actually save?

"It feels lighter" is not enough to build a habit on. Here are the numbers.

Simplify the model: each turn costs 200 tokens of your input and 600 tokens of Claude's reply. Because the model re-reads the whole transcript every time, the input on turn n is everything before it plus your new message.

Triple the turn count from 20 to 60 and the cumulative total grows more than ninefold. Growth is quadratic, so by the time a chat merely feels sluggish, each exchange already costs several times what it did at the start.

Now split those same 60 turns into three chats of 20, carrying a 150-token summary forward as in Technique 2. The cumulative total drops from 1,428,000 to 474,000 tokens — roughly a third. Even splitting 40 turns into two chats halves it, from 632,000 to 315,000.

Here is the code behind the table, so you can substitute your own numbers.

U, A = 200, 600  # your input / Claude's reply, per turn
 
def total_input(turns, carry=0):
    """Cumulative input tokens over `turns`. `carry` is the handoff summary."""
    total, history = 0, carry
    for _ in range(turns):
        history += U
        total += history   # the model re-reads everything so far
        history += A
    return total
 
single = total_input(60)
split = total_input(20) + 2 * total_input(20, carry=150)
print(single, split, f"{split / single:.0%}")  # 1428000 474000 33%

Raise U if you paste long code blocks — the payoff from Technique 3 grows sharply as that number climbs.

One caveat: this is a structural estimate derived from how conversations accumulate, not a claim about how Claude Pro meters your usage. The internal accounting for each plan isn't published. As a sense of scale for "long chats cost more per turn," though, I've found it a reliable guide.

When you can't split the conversation

Not every task divides cleanly. A refactor spanning several days is a case where the context itself is the deliverable.

For those, I put the memory outside the conversation rather than inside it.

• Decisions go into a file, not a chat, and the file lives in Project knowledge
• Design notes get written out by Claude as Markdown and committed to docs/ in the repo
• The next chat opens with one line: "assume the design note in knowledge as given"

Conversations flow past; files stay. Rather than fighting to keep one long thread alive, I let an external memory be re-read each time — faster, cheaper, and far easier to pick up again later. Running several apps in parallel as an indie developer, that shift in framing helped me more than any single technique here.

Common pitfalls to watch for

A few patterns that quietly eat tokens:

• Re-uploading the same file in a long chat. Each re-upload counts. Reference the prior attachment by name instead.
• Asking Claude to "start over" inside the same chat. The prior history still travels. Open a new chat instead.
• Building a huge "system prompt" at the top. If it's reusable, move it to Project instructions. If it's one-off, keep it minimal.
• Letting Claude re-explain earlier answers. When Claude offers to "summarize what we've covered so far," that summary also costs tokens. Accept it only if you'll actually use it.

None of these are disastrous in isolation — it's the accumulation across a day that makes the difference.

Where to start

You don't need to adopt all four techniques at once. From experience, this order sticks the easiest:

1. Practice Technique 1 (new chat per topic) for a week
2. Add Technique 2 (three-line handoff) once that's natural
3. If you already use Projects, Technique 4 is a fast win from day one
4. Pull in Technique 3 the next time a bulky attachment comes up

Technique 1 alone usually drops the rate at which people hit the usage ceiling. Everything else is accelerant.

What to do next

If a conversation you're in right now is starting to feel heavy, ask Claude to "summarize our conclusions in three lines." Open a new chat, paste the summary, and you've just applied Techniques 1 and 2 together. It's a two-minute habit, and you'll feel the difference by tomorrow.