If you've spent more than a few hours with Claude Code, you've probably run into this: you ask it to modify a function you discussed earlier, and it acts like that conversation never happened. Or the code quality suddenly drops. Or responses start crawling. These aren't random bugs — they're symptoms of a context window that's full or polluted with noise.
This post walks through what's actually happening inside that context window and five concrete strategies I've settled on for keeping it clean through a full workday.
1. Why This Matters Now
Claude Code runs on a 200K token context window. That sounds enormous until you realize that a real working session eats through it faster than you'd expect.
Every file Claude Code reads, every error log it processes, every back-and-forth exchange — all of it lands in one long text that the model reads from the beginning every single time it responds. Claude doesn't "remember" your session the way a human colleague would. It re-reads the entire conversation on each turn.
The moment that accumulated text grows too large, one of two things happens: Claude Code silently truncates the oldest content (not always the least relevant), or performance degrades as the model struggles to reason across thousands of tokens of noise. Either way, you lose coherence without any obvious warning.
For a typical session — a few files read, some error output pasted in, iterative back-and-forth on a feature — you can burn through 50–70% of a 200K window in under an hour. When you hit that wall mid-task, the results get unpredictable fast.
2. The Core Idea
Context management is not a technical setting you configure once. It is a working habit you apply deliberately throughout a session.
The simplest mental model: treat each Claude Code session like a whiteboard. You wouldn't write an entire sprint's worth of notes on one whiteboard and then try to keep working — you'd erase it between tasks. The /clear command is your eraser, CLAUDE.md is your persistent reference sheet posted on the wall, and scoped file references mean you're only writing what you actually need on the board.
Here's the rough cost of common operations:
| Action | Context impact |
|---|---|
| Pasting 500-line file into chat | High — stays in context permanently |
| Asking Claude to "analyze the whole project" | Very high — reads many files |
| Referencing a file by path | Low — Claude reads only what's needed |
| Long, multi-feature conversation | Compounds over time |
Starting with /clear between tasks |
Resets to zero |
The goal is not to minimize all context usage — it's to make sure what's in context is relevant to the current task.
3. How to Implement It
Clear between tasks
The most impactful habit is also the simplest. When one unit of work is done, run /clear before starting the next one.
/clear
That's it. The entire conversation history resets. Claude starts fresh with no baggage from the previous task.
The key is timing. Run it after a task completes and before the next one begins. If you clear mid-task, you lose the thread you were following. If you never clear, context pollution accumulates and you get the degraded behavior described above.
Reference files by path, not by pasting
The most common mistake I see in early Claude Code usage is pasting code directly into the chat.
# What not to do
"Here's my auth module: [pastes 400 lines of TypeScript]
Now fix the token validation logic."
# What to do instead
"In src/api/auth.ts, fix the token validation logic in the login() function."
Claude Code reads files directly from your filesystem. You don't need to paste them. Give it a path and a scope — it'll read exactly what it needs, and only what it read goes into context rather than the full paste staying there for the rest of the session.
Set up CLAUDE.md once, stop re-explaining forever
If you find yourself typing "this project uses Next.js 14, TypeScript strict mode, pnpm, and Vitest" at the start of every session, you're burning context on boilerplate. Create a CLAUDE.md file in your project root:
# Project Context
## Stack
- Next.js 14, App Router
- TypeScript (strict mode)
- Package manager: pnpm
- Testing: Vitest + Testing Library
- Styles: Tailwind CSS
## Conventions
- Functional components only
- State: Zustand
- Data fetching: React Query
- No `any` types
- No `console.log` in commits
## Architecture notes
- API routes live in src/app/api/
- Shared types in src/types/
- Custom hooks in src/hooks/
Claude Code reads this file automatically at the start of every session. You write it once, and the project context is always available without consuming conversational context on repetitive setup. Keep it updated as your stack evolves.
Scope your requests to one task at a time
Broad requests like "build the entire login system — UI, API, database, error handling, and tests" are context disasters. Each subtask compounds the context used by the previous ones, and by the time you get to tests, Claude Code is reasoning over a conversation full of UI decisions and API debates that are no longer relevant.
Break it up:
# Session 1
"Create the POST /api/auth/login endpoint.
Handle JWT generation and return 401 for invalid credentials."
→ Done → /clear
# Session 2
"Create the LoginForm component in src/components/auth/.
It should POST to /api/auth/login and redirect on success."
→ Done → /clear
# Session 3
"Write Vitest tests for the login endpoint in src/api/auth/login.test.ts.
Cover success, wrong password, and missing fields."
→ Done → /clear
Each session stays focused. The context contains only what matters for that unit of work. The output quality is noticeably higher.
Narrow the file scope explicitly
When you do need Claude Code to understand existing code, be specific about which files matter.
# Vague — causes Claude to read many files
"Understand how our project handles authentication."
# Scoped — reads only what's needed
"Look at src/auth/ only. How is session state managed?
I need to add a remember-me flag."
The scoped version reads fewer files, uses less context, and gets to a useful answer faster. The broad version often results in Claude reading unrelated files — config files, test files, components that happen to import an auth hook — none of which help answer your actual question.
Watch the usage indicator
Claude Code displays context usage at the bottom of the screen. Once you're past 70%, you're in the warning zone. Responses may start feeling slightly off — less precise, occasionally contradicting earlier decisions in the same session.
At 70%, plan to finish your current task and then run /clear. Don't push to 95% hoping it holds together.
4. What to Watch in Production
CLAUDE.md scope matters. Claude Code looks for CLAUDE.md in the project root and in subdirectories. If you work on a monorepo, consider adding CLAUDE.md files in individual package directories. The root one sets global conventions; the package-level ones add local context without polluting every session with the whole monorepo's history.
Clearing loses in-session decisions. If you made architectural decisions during a conversation — "we decided to use UUIDs instead of auto-increment IDs" — write those into CLAUDE.md or a doc file before you /clear. They won't survive the reset otherwise, and Claude Code may contradict them in the next session.
Long error logs are particularly expensive. A full stack trace with 50 frames and all the local variable state can eat thousands of tokens. Trim logs before sharing — pass only the relevant frame range, not the entire output. Or reference the log file by path and tell Claude which lines to focus on.
The 200K limit feels different on different tasks. A refactoring session where Claude reads many files will hit the limit much faster than a session where you're just writing new code. Calibrate your /clear frequency accordingly. For heavy refactoring work, I clear after every two or three file changes, not just every feature.
Context management is the part of Claude Code that nobody explains in the getting-started docs, but it's what separates sessions that feel coherent from sessions that go sideways. The habit of clearing between tasks, referencing by path, and keeping a maintained CLAUDE.md will make your sessions meaningfully more consistent.
Next up in this series: how to structure CLAUDE.md for multi-developer teams without turning it into a sprawling wiki nobody reads.
🐦 Faster updates on X: @baegseungh7061
📚 More in this series: Code Intro
💌 Subscribe: Follow on X or grab the RSS
댓글
댓글 쓰기