I corrected Claude in a debugging session. It said "you're right."

Then it spent the next 20 messages quietly building on the bug I had just disproved.

The bug wasn't in the model. It was in how I was using context.

Most developers I know use Claude Code like a chat window. One terminal, one session, all day long. Backend question in the morning, frontend bug after lunch, a quick "what should I order for lunch" mixed in somewhere, and an architecture decision around 4pm.

By the end of the day, Claude is unhelpful in subtle ways. It mixes the codebases up. It forgets corrections you made an hour ago. The answers get longer, the relevant parts shorter. And you're closer to your weekly rate limit than you should be — or, if you're on API access, your bill is bigger than yesterday — for the same amount of actual work.

None of that is a model problem. It's a context problem. The window is not memory — it's a working surface, and you have to manage it like one.

The three symptoms

1. Cross-topic confusion

A long session has no concept of "topic." Every new message ships the entire prior conversation to the model. If auth.users appeared in your prompt at 10am, it's still in the prompt at 4pm — even if you've been working in a completely unrelated repo for the last three hours.

So when you ask "should we cache this with Redis?" at 4pm, you're not asking a clean question. You're asking a question against a 4-hour-old soup of:

• The 10am backend table schema
• A 12pm offhand mention of a deadline
• The 2pm frontend stack discussion
• That weird tangent about your dev container at 3pm

The model answers based on the whole soup. It pulls patterns from one task into another. It references functions that exist in a different repo. It gets confidently wrong because it has too much context, not too little.

You can write better prompts forever — it won't fix this. The fix is realizing the surface itself is dirty.

2. Post-correction persistence — the "you're right" trap

This is the one that costs me the most time.

I was debugging a component that re-rendered three times on every keystroke last week.

First hypothesis: the parent was re-rendering on each state change. I asked Claude to look at the parent. It agreed — confirmed parent re-renders, here's a fix wrapping the parent in React.memo.

I opened React DevTools Profiler. The parent wasn't re-rendering at all. The child was re-rendering on its own — because a useEffect inside it had an inline object as a dependency:

useEffect(() => {
  fetchData(filter);
}, [{ filter, sort }]);

That object is recreated on every render. The effect "depends on" a brand new reference every time, so it fires every render, which sets state, which re-renders the child. Classic React footgun.

Me: Parent's not rendering — check the profiler. The child has a useEffect with an inline object in its deps. New reference every render.

Claude: You're right. Sorry for the confusion. The cause is the inline object in the useEffect dependency array.

Moved on. Asked for the fix.

const Parent = React.memo(({ filter, sort, items }) => {
  // ...
});

The fix Claude wrote was wrapping the parent in React.memo. The hypothesis we had ruled out two messages earlier.

I corrected it again. "It's the inline object inside the child's useEffect, not the parent."

Claude: Right, the inline object. Sorry.

Then it proposed the same fix. React.memo on the parent.

I /clear'd the session. Started over. Pasted only the child component and the profiler screenshot. New session caught the inline-object dependency in the first answer and proposed the correct fix: pull the object out with useMemo, or destructure into primitive deps.

Why this happens

Look at what's actually in the context window at the moment Claude proposes the wrong fix for the second time:

1. System prompt with tool definitions (~10k tokens)
2. My first message: "this component re-renders three times on every keystroke"
3. Claude's confident first hypothesis: parent re-render — explained over a paragraph
4. My correction with the profiler output
5. Claude's "you're right, it's the inline object" — one sentence
6. A few intermediate messages
7. My request: "give me the fix"

Item 3 is still in the prompt. It's longer than item 5. It's more confidently argued than item 5. When the model generates the next answer, it weighs everything in the prior turns. The parent-re-render framing wins because there's more of it.

The apology doesn't delete the wrong answer. It adds a short retraction at the end of a long argument. The argument keeps winning.

You can think of it like this: in a long enough conversation, your correction is a sticky note attached to a 10-page memo. The model reads the whole memo every time. The sticky note doesn't always get noticed.

Three signs you're in a "you're right" loop

• You corrected the model and it agreed.
• Two or more turns later, the original wrong claim resurfaces.
• You correct again. It agrees again. It does it again.

When you see this pattern, don't reason with it. Don't write a longer correction. Don't paste the same evidence twice. /clear. Start over with the corrected version as your starting prompt.

The reminder you're tempted to write will just be one more short message in a long polluted history. The history already lost that argument once.

3. The token tax

Most developers using Claude Code today are on a subscription — Claude Pro, Claude Max. Your bill doesn't grow at the end of the month. Instead, your weekly quota burns out faster than it should. You hit the rate limit on Wednesday afternoon and wait until Friday to keep working. If you're on API access, the same pressure shows up as a growing invoice. Either way, you pay the same tax — just in a different currency.

Here's where the tax comes from. Every Claude Code request includes, on every single turn:

• The system prompt with MCP tool definitions (~10k tokens)
• The full prior conversation
• Your new message
• The response it generates

Prompt caching helps for a few minutes if you're sending similar prefixes. After the cache TTL expires, the full content is recomputed.

After 50 messages of about 500 tokens each, you've accumulated ~25k tokens of history. Plus ~10k of system prompt. Every new request you send ships 35k input tokens before you've even typed your actual question. On a subscription, those tokens come out of your weekly allowance. On API, they come out of your wallet.

A back-of-the-envelope calculation on Anthropic's published pricing (Sonnet around $3 per million input tokens, Opus roughly 5× that):

These are model calculations from Anthropic's published pricing, not a billing screenshot. Plug your own usage in — the ratio is what matters. You can do the same work for less than half the token cost just by clearing the surface. You can do it with a better model for a third of the cost by splitting the workload.

If you're on a subscription, divide your weekly token allowance by these numbers. The "Claude Max ran out by Wednesday" feeling has a real cause — and it's not your workload, it's your session length.

A long messy session quietly burns through your quota — or your wallet — in the background. The rate-limit message at 4pm Wednesday looks like a usage problem. It's a hygiene problem.

The three rules

Rule 1 — /clear is hygiene, not panic

Treat /clear the way you treat closing a browser tab. It's not failure. It's not "starting over." It's normal.

Things I clear on:

• Switching from backend to frontend (different mental model).
• Switching from designing something to implementing it (different decision style).
• After any "you're right" loop, no matter how confidently the apology was phrased.
• After a long debugging detour that didn't pay off — clear, restart with what I learned, not with the failed attempts.
• At the end of any session that lasted more than an hour.

If you have two parallel tasks, open two terminals, not two threads in one session. The model doesn't have tabs. The window doesn't.

The cost of clearing is zero. The cost of not clearing accumulates linearly in tokens and nonlinearly in quality.

Rule 2 — Context lives on disk, not in the window

The window is volatile. It gets polluted, it gets long, you /clear it, it's gone.

The disk is durable. A markdown file you wrote yesterday is still there today, exactly as you left it.

So after every non-trivial research session, I write the conclusions out. A plan into plans/, an architecture decision into docs/adr/, a set of patterns into docs/component-patterns.md. The next session reads the file as ground truth. The previous chat history is not invited.

This is the most underrated habit in Claude Code, and it's also the cheapest. A 2k-token markdown file in your context replaces a 25k-token conversation history that the model would otherwise be re-shipping on every turn.

A practical example: I keep a file that lists the patterns used in my codebase — what to do, what we've already tried and abandoned, what's idiomatic here. Every Claude Code session that touches the frontend reads that file first. Without it, the model invents patterns from training data — usually fine, sometimes wrong, occasionally suggesting a component I built six months ago as if it's a new idea. With it, the model is grounded in the codebase as it exists today.

Disk-based context also survives /clear. Window-based context doesn't. That asymmetry is the whole game.

Rule 3 — Use the right model for the right phase

Opus is the deep, expensive model. Sonnet is the fast, cheap one. Opus is roughly 5× the price of Sonnet per token.

The instinct is to pick one and use it for everything. That instinct is wrong for two reasons:

1. If you pick Opus for everything, you pay Opus rates for the long tail of formatting fixes, lint errors, file shuffling, and "rename this variable." None of that benefits from Opus reasoning.
2. If you pick Sonnet for everything, your research phase produces a plan that's almost right, you implement it, you hit a wall, you back up, you re-research, you implement again. The cost is real but invisible — it's the rework, not the line items on your bill.

The pattern that wins: research and plan on Opus, then write the plan to disk, then /clear and start a fresh Sonnet session that reads the plan.

In numbers: a research-heavy task done entirely on Opus might run around $15. The same task split — Opus for research, written to a markdown file, Sonnet reading the file and executing — runs around $5. And the execution is better, because the plan is correct on the first try.

The split takes one extra step: writing your conclusions to a file. That step pays for itself in the first task.

What I clear and what I keep

To make this concrete, here is what I throw away and what I keep across the boundary of a /clear:

Thrown away (in the window):

• The chronological back-and-forth.
• All the wrong hypotheses I explored.
• Claude's apologies for being wrong.
• Long tool outputs I needed once.

Kept (on disk):

• The final correct plan.
• The architecture decision with the reasoning.
• The patterns I want the next session to know about.
• Any "do not do X again" notes from this session.

When I open a new session, the window starts at zero. The disk hands me a clean version of what I learned. The two together are stronger than any long conversation.

Closing

You don't get better answers from Claude by holding a longer conversation with it. You get better answers by managing the surface it works on — what's in it, what's gone from it, and which model is reading it now.

The long session feels productive because the model still talks back. But it's slowly losing the thread, weighing wrong hypotheses against your corrections, and burning through your quota — or your wallet — for the privilege.

/clear. Write things to disk. Switch models on purpose. Treat the context window like a workbench, not a journal.

Context isn't memory. It's a working surface. Keep it clean.