Behavioral Anti-Patterns That Waste Tokens

Every token you send costs money and eats context window space. When the context fills up, Claude's performance degrades. It forgets instructions, misses details, makes worse decisions. Most of that waste doesn't come from hard problems. It comes from habits.

Bad habits, specifically.

The Kitchen Sink Session

You start a session to refactor a React component. While Claude is working, you remember you also need to fix a typo in the README. Then you ask it to check why your Docker build is failing. Then you go back to the React component.

Stop. Your context window is now stuffed with three completely unrelated tasks. Claude is holding Docker error logs, README content, and React component state simultaneously. None of that cross-contamination helps. All of it hurts.

The fix is dead simple. One session, one task.

# Bad: cramming everything together
claude
> "Refactor the UserCard component to use shadcn"
> "Also fix the typo in README"
> "Why is my Docker build failing?"
 
# Good: one task per session
claude
> "Refactor the UserCard component to use shadcn"
> /clear
> "Fix the typo in README.md line 42"
> /clear
> "Diagnose why the Docker build fails on the npm install step"

When you finish a task, run /clear. If you realize mid-task that something unrelated needs doing, jot it down and handle it later. Resist the urge. That urge is expensive.

The Correction Spiral

This one is sneaky because it feels productive.

Claude does something wrong. You tell it to fix it. The fix introduces a new issue. You correct that. Now the context contains the original bad code, the first failed fix, your correction, the second attempt, your second correction, and whatever comes next. Six rounds of noise for one task.

Each failed attempt pollutes the context with approaches that didn't work. Claude is now reasoning through a minefield of bad examples alongside your actual goal.

Rule of thumb: if you've corrected Claude twice on the same issue and it's still wrong, stop. Don't send a third correction. Run /clear and start fresh with a better prompt. You now know what went wrong. Put that knowledge into the initial instruction.

# After two failed corrections, don't keep going
> /clear
 
# Write a new prompt that incorporates what you learned
> "Refactor the auth middleware. Important constraints: keep the
  existing rate-limit logic in the same middleware chain, do not
  move it to a separate file, and preserve the req.user type
  from the existing interface in types/auth.ts"

A clean session with a better prompt beats a long session with accumulated corrections. Every time.

The Trust-Then-Verify Gap

Claude produces a function that looks right. Variable names make sense. Logic reads well. You accept it and move on. Three days later, you discover it doesn't handle null inputs, blows up on empty arrays, or silently drops errors.

Claude is excellent at producing plausible-looking code. That's both its strength and its trap. If you can't verify the output, don't ship it.

# Don't just accept the implementation
> "Add input validation to the signup form"
 
# Verify immediately
> "Now write unit tests for the validation logic, covering empty
  strings, strings over 255 chars, and special characters"
 
# Or ask for edge case analysis
> "What edge cases does this validation miss?"

Catching problems in the same session is cheap. The context is fresh, Claude remembers what it just did. Catch them three days later in a new session and you're paying full price to rebuild all that context from scratch.

The Infinite Exploration

You ask Claude to "investigate the authentication flow" without scoping it. Claude starts reading files. The auth middleware. The user model. The session store. The database schema. The migration files. The test fixtures. The config files. Your context window is packed with hundreds of lines of file contents, and Claude still hasn't done anything useful.

Open-ended investigation is the fastest way to torch your context window. Claude is thorough by default. Tell it "investigate" and it'll investigate everything it can find.

Scope your investigations. Tell Claude exactly what you want to know and where to look.

# Bad: open-ended exploration
> "Investigate the authentication system"
 
# Good: scoped and specific
> "Read the auth middleware in src/middleware/auth.ts and tell me
  how it validates JWT tokens. Don't read other files unless
  the middleware imports them directly."

For genuinely broad investigations, use subagents. The exploration happens in a child context that gets summarized and returned. Your main context stays clean.

> "Use a subagent to map out all the API routes in this project
  and return a summary of each route's purpose and auth
  requirements"

Try It: Audit Your Last Session

Think about your most recent Claude Code session. Be honest.

1. Did you work on more than one unrelated task without running /clear?
2. Did you correct Claude more than twice on the same issue?
3. Did you accept generated code without running tests or checking edge cases?
4. Did you ask Claude to "look into" something without scoping what files to read?

If any of those hit, try this: take the task that went sideways and write a single clean prompt that gives Claude everything it needs in one pass. Start fresh and run it.

claude
> /clear
> "Your concise, well-scoped prompt here"

Compare the results. The difference in speed and accuracy when the context isn't polluted is stark.

Session Discipline

All these anti-patterns share one root cause: treating the context window as infinite. It's not. Every message, every file read, every failed attempt takes up space and degrades quality.

• Clear between tasks. One task, one context. /clear aggressively.
• Course-correct early. Press Esc to stop Claude mid-action if you see it going wrong. Use /rewind to restore the previous state.
• Start fresh when stuck. Two corrections and still wrong? Clear and rewrite the prompt.
• Scope everything. Which files to read, which constraints to follow, what "done" looks like.

The cost of bad habits isn't just money. A model reasoning over clean, focused context produces noticeably better results than the same model drowning in failed attempts and irrelevant file contents. Guard your context window the way you guard your production database.

The Recap

Kitchen sink sessions waste context by mixing unrelated tasks. /clear between them. Correction spirals pollute context with failed approaches, so two strikes means start fresh with a better prompt. Always verify output with tests, build checks, edge case analysis. Plausible-looking code isn't correct code. And scope your investigations narrowly, or use subagents for the broad ones.

If there's one habit that improves everything else, it's context hygiene.