# Feed Claude the right context, not everything

Put in the prompt exactly what the task touches: the goal, the rules it must obey, and the one or two files it reads or changes. Leave out the rest. More text does not produce a better answer. It dilutes the signal and makes the relevant lines harder for Claude to find.

This guide is about that judgement call: what goes in, what stays out, and how to load it with the Claude Code CLI so you do not paste the same thing twice.

## Why is sending everything the wrong default?

A reflex when Claude gets something wrong is to add more: paste another file, paste the whole module, paste the README again. That reflex is backwards. The model reads every token you send, on every turn. When the request that matters sits inside 200,000 tokens of unrelated code, it competes with all of it for attention.

Three concrete costs come with stuffing the window:

- **Attention dilutes.** A precise instruction buried in a wall of files is easier to miss than the same instruction in a tight prompt.
- **Cost rises.** You pay per input token, every turn. A bloated context that repeats across a 30-turn session multiplies that bill.
- **Contradictions creep in.** Two stale files that disagree force Claude to pick one, and you do not control which.

The skill is selection. A context window is a budget, and you are the one deciding how to spend it.

## The three questions

Before you send a prompt, run each candidate piece through three questions.

1. **Does the task touch this?** If Claude is fixing a login bug, the billing module does not belong in the window. The file being edited, the function being called, the error being chased: those touch the task.
2. **Must Claude obey this?** Rules, type signatures, an API contract, the exact output format. Constraints belong in the window even when they are not "code," because breaking them is the most expensive kind of wrong answer.
3. **Will Claude fail without this?** A schema it must match, a sibling file that defines the interface, the full error trace. If the answer depends on it, include it. If the answer would be identical without it, cut it.

If a piece fails all three, it is noise. Leave it out.

## What belongs in the context window?

Everything outside these four is a candidate for the cut: unrelated files, abandoned ideas from earlier in the chat, generated lock files, a README that repeats what the code already says.

### Include, conditionally include, exclude

| Tier | What it is | Examples |
|---|---|---|
| Always include | The task and its hard constraints | Goal, rules, type signatures, output format |
| Include when relevant | Things that disambiguate or prove a failure | One or two example input/output pairs, the full stack trace, the failing test |
| Exclude | Anything the answer does not depend on | Unrelated files, abandoned directions, lock files, duplicated docs |

## Be specific, not exhaustive

Vague prompts make Claude guess, and guessing pulls in more than you need. Name the file. Name the function. State the rule. Compare these two requests for the same task.

A vague request that forces Claude to explore the whole project:

Something is wrong with the login flow. Can you look into it?

A precise request that points at exactly what the task touches:

```text
The login form in src/auth/login-form.ts submits but the session never sets. Read src/auth/session.ts and src/auth/login-form.ts. The bug is in how the token is stored. Do not change the public function signatures.
```

The second prompt names two files, states the symptom, and sets one constraint. Claude reads those two files and nothing else. The window stays tight and the answer stays on target.

## How do I load files into Claude Code without copy-paste?

Pasting file contents into the chat works, but it is slow and it gets stale the moment you edit the file. Claude Code gives you cleaner tools.

### @-mention the files the task touches

Typing `@` followed by a path in your message loads that file into the context for that turn. Mention only the files the task reads or changes.

```text
@src/auth/session.ts @src/auth/session.test.ts The test on line 40 fails. Fix the session logic. Do not change the test.
```

This loads two files. It does not load the rest of the directory, and it does not ask Claude to go hunting. You decided the scope; Claude works inside it.An @-mention loads the file as it was at that turn, not a live link. If Claude edits it ten turns later, your original mention is now a stale copy, so re-mention the file after a big change to refresh the window with the current text.

### Let Claude retrieve instead of pre-loading

When you know the subsystem but not the exact file, do not dump the folder. Ask Claude to find it. Claude Code runs grep and file reads as tool calls and pulls in only the lines that match.

```text
Find every place we call createSession and list the file paths and line numbers. Read nothing else yet and change nothing.
```

Only the matching excerpts land in the window. This is [retrieval over stuffing](/guides/context-injection-vs-stuffing): search for the signal, do not import the haystack.

### Choose the loading method by what you know

| What you know | What to do |
|---|---|
| The exact file | @-mention it directly |
| The subsystem, not the file | Name it and ask Claude to grep |
| A small project, under a few thousand lines | Let Claude read it all |
| A large project, one narrow task | @-mention the contract or interface file only |
| Live data, such as logs | Paste the relevant excerpt, not the whole log |

## Where do durable rules belong?

Some context is not about one task. It is the same on every task: your coding conventions, the build command, where handlers live. Pasting that into every prompt wastes your time and the window. Put it in a [`CLAUDE.md` memory file](/guides/rules-and-memory-files) instead.

A `CLAUDE.md` at the project root is loaded at the start of every session, so the rules are present without you re-typing them. Keep it to facts that apply every time.

```markdown
# Project rules

- Run `npm test` before every commit.
- API handlers live in `src/api/handlers/`.
- Use 2-space indentation.
- Co-locate tests with source as `*.test.ts`.
```

The official guidance is to keep each `CLAUDE.md` under 200 lines. Longer files consume more context and Claude follows them less reliably, so write specific rules and delete ones that no longer apply. A vague rule is noise that still costs tokens.

For instructions that only matter in part of the codebase, scope them to a path with a rule file under `.claude/rules/` so they load only when Claude works with matching files:

```markdown
---
paths:
  - "src/api/**/*.ts"
---

# API rules

- Every endpoint validates its input.
- Use the standard error response format.
```

This keeps the always-on `CLAUDE.md` lean while still giving Claude the right context when it opens an API file.

## What this looks like end to end

The stable layer loads itself. You add only the task-specific files. You name the goal and the rules. Claude fetches anything else on demand. At no point do you paste the whole project.

## Watch and trim a long session

A long session accumulates history fast. Tool calls, file reads, and earlier answers pile up, and old turns about a direction you abandoned become pure noise.

### See where the window is going

Run `/context` to see current usage as a grid, with suggestions for context-heavy tools and warnings as you approach capacity.

```bash
/context
```

Run `/cost` (an alias for `/usage`) to see what the session has cost and how usage breaks down.

```bash
/cost
```

Check these before starting a large task. If the window is already full of stale work, clear or compact it first.

### When should I use /compact versus /clear?

When the conversation grows long but you are still on the same task, run `/compact`. It replaces the raw history with a summary and frees the window while keeping your direction.Do not run `/compact` right after loading a file or error trace you still need Claude to work from verbatim. The summary is lossy, so the exact line numbers, the schema, or the failing assertion can get paraphrased away, and Claude then edits against a blurred memory of the code. Compact first, then @-mention the files for the next step so the real text is fresh in the window.

```bash
/compact
```

When you switch to an unrelated task, run `/clear`. It starts a fresh conversation with an empty window while keeping your [project memory](/guides/how-claude-code-memory-works), so old auth-debugging turns do not leak into a new layout task.

```bash
/clear
```

The rule of thumb: `/compact` to stay light inside one task, `/clear` between tasks. A project-root `CLAUDE.md` survives both. After `/compact`, Claude re-reads it from disk and re-injects it, so your rules persist.

## Common mistakes

| Mistake | Do this instead |
|---|---|
| Pasting the whole repo "to be safe" | @-mention the one or two files the task touches |
| Summarising the error before pasting it | Paste the full trace; the line that matters is often the one you trimmed |
| Re-pasting rules every prompt | Put durable rules in `CLAUDE.md` once |
| Carrying a 40-turn chat into a new task | Run `/clear` and start fresh |
| Pasting a screenshot for its text | Extract the text and paste that; images cost more tokens than the words in them |
| Cramming every rule into one giant `CLAUDE.md` | Path-scope niche rules under `.claude/rules/` |

## A checklist before you hit enter

- Does every piece in the prompt touch the task, gate it, or prove a failure?
- Have I named the files instead of dumping the folder?
- Have I stated the goal and the constraints in plain words?
- Are durable rules in `CLAUDE.md`, not re-pasted?
- If the session is long, have I run `/context` and then `/compact` or `/clear`?
- Am I sending a full file when Claude only needs one function?

A prompt that passes this list is cheaper, faster, and more accurate than one assembled by reflex. For the deeper mechanics of the window itself, read [Context Engineering](/guides/context-engineering). For loading external tools and data without bloat, see [MCP fundamentals](/guides/mcp-fundamentals).