The context-window mistake most consultants make with Claude

A conversation started fresh on Monday morning produces great work on a client deliverable. By Wednesday afternoon, in the same conversation, the drafts are weaker: earlier mistakes come back, things settled on Monday get contradicted, and the voice rules slip. By Friday, it feels stuck, and a new conversation gets started.

The model didn't get worse. The conversation went past its useful capacity. Claude has a context window, the total amount of conversation, files and instructions it can hold and reason over at once. Today's is very large, but it isn't infinite, and a long engagement run in one conversation gets to the limit of what's useful long before it reaches the hard cap.

This article is what the context window actually is in practice, the three failure modes that produce muddled output, and the discipline that keeps long workflows sharp.

What the context window actually is

The simplest mental model: every Claude conversation has a fixed-size working memory. Everything in it (your messages, Claude's replies, files you uploaded, instructions and skills) counts against that memory. When a conversation gets very long, Claude now summarizes the earlier messages automatically so it can keep going, at least when code execution is turned on. That's convenient, but a summary isn't the original, and conversations long enough to trigger it use more of your plan's usage.

The ceiling is high. On paid plans, the newest models handle up to a million tokens in one conversation, which is hundreds of thousands of words. You'll rarely hit it. The trouble starts much earlier.

The real problem isn't reaching the cap; it's passing the useful capacity, which is much lower. Claude can hold everything in a very long conversation, but it doesn't reason over all of it equally well. Important earlier instructions get blended with later context; nuance from early in the conversation degrades into approximation; the model starts confabulating connections between unrelated parts of the history.

The threshold where this starts is well before the absolute limit. The threshold where it gets bad is roughly when the conversation contains more accumulated context than the specific task in front of you requires.

The three failure modes

Failure mode 1: One long conversation for an entire engagement. The consultant starts a Claude conversation on day 1 of the engagement and keeps using it for everything related to that client — discovery debrief, scope work, weekly updates, deliverable drafts, meeting summaries. By week three, the conversation is a soup of unrelated tasks. Claude pulls phrasing from the discovery debrief into the deliverable draft. The weekly update accidentally references context from a meeting summary that's six weeks old. Outputs get fuzzier without obvious cause.

Failure mode 2: Re-pasting context that's already in the conversation. The consultant re-pastes the kickoff brief at the top of every new task because they don't trust the conversation to remember it. The kickoff brief now appears three or four times in the same conversation. Claude weights it more heavily than it should; the brief crowds out more recent context that matters more. Earlier paste also makes the conversation longer overall, accelerating the slide into muddled output.

Failure mode 3: Carrying conversations across days that should have been new. The consultant pauses a conversation on Friday and resumes it on Monday with "OK, where were we?" All of Friday comes along, and Monday's fresh work has to share working memory with it, even though most of it doesn't matter for Monday's task. Outputs are slightly worse than they would be in a fresh conversation, even though Monday's task is independent.

All three failure modes share a root cause: treating the Claude conversation as a notebook (persistent, append-only, everything in one place) when it's actually closer to a working memory (sized for the immediate task, expensive to keep loaded).

The discipline that keeps it sharp

The fix is about habits, not settings. Three of them do most of the work.

Habit 1: One conversation per task, not per engagement. A discovery debrief is its own conversation. The weekly client update is a fresh conversation each Friday. The deliverable draft is its own conversation, separate from the meeting summaries that informed it. The engagement itself lives in a Project (or a folder of saved outputs); each task gets a clean conversation that ends when the task ends.

It can feel wasteful, but it works. Fresh conversations get better outputs because the working memory is sized for the immediate task. The cost of "starting over" is paying ~30 seconds of context-paste at the top of each new conversation. The benefit is consistently sharp output across weeks of work.

Habit 2: Persist context outside the conversation, not inside it. The engagement's accumulated context (the kickoff brief, the client's industry notes, the running list of open items) lives in a file or a Project. You reference it as needed by uploading or pasting the relevant chunk at the start of a new conversation. You don't carry it forward by leaving it in an open conversation.

The mistake is treating the conversation itself as the place the engagement lives. The engagement lives in clients/<name>/ (a folder of Markdown files) or in a Claude Project (with uploaded files). The conversation is the working surface for one task.

Habit 3: When the conversation feels muddy, start a new one. This is the most valuable habit and the hardest to build. The instinct when output gets weak is to push back — "that's not quite what I meant, try again." The right move when output gets weak is to open a fresh conversation, paste the minimum context for the task, and try again with a clean working memory. The output usually improves immediately.

The signal that a conversation has gone muddy: Claude repeats mistakes you've corrected, contradicts instructions you set up earlier, or produces output that feels generic when the conversation started sharp. Any of those, start fresh. Don't try to fix the conversation; replace it.

What "muddy" actually looks like in practice

It helps to have concrete signals for when a conversation has gone past its useful capacity. Five of them, in roughly the order they appear:

The model contradicts an instruction you established earlier. You told it on Monday to keep outputs under 300 words. By Wednesday, it's producing 600-word drafts. The instruction is still in the conversation; it's just no longer weighted strongly enough to influence output. Start fresh.

The model invents details that weren't in the inputs. A meeting summary contains action items nobody assigned. A scope draft includes a deliverable the client never mentioned. This is confabulation, and it almost always means the conversation has accumulated enough context that the model is reaching for plausible-sounding completions instead of grounded ones.

The model becomes oddly formal or oddly casual. Voice drift in either direction is a context-window signal. Your skill or initial prompt established a voice; if Claude's outputs are drifting away from it, the voice rules have been crowded out by accumulated content.

Re-asking a question produces a different answer. You asked Claude on Tuesday for a take on the engagement's biggest risk; you ask again Thursday in the same conversation and get a different risk, with different reasoning. The model is sampling from a muddled state.

You find yourself adding "as I mentioned earlier" qualifiers to your prompts. This is the consultant's tell. If you're working around the model's memory by re-establishing things you already said, the conversation has reached the point where its working memory is less efficient than starting fresh.

When two or more of these signal at once, the cost of starting a new conversation is lower than the cost of continuing the current one.

When persistent state actually is the right call

There's one exception worth naming. Some workflows genuinely benefit from a single long-running conversation: workflows where the back-and-forth itself is the point, like working through a strategy problem with Claude as a sounding board, or iterating on a deliverable where each draft builds on the previous one's feedback.

For those, a long conversation is correct. The accumulated context is the work product. The signal is whether the earlier conversation directly informs the next move. If yes, keep going. If the next move is a different task that just happens to be on the same engagement, new conversation.

The picking question echoes the Claude Projects vs. skills vs. prompts decision: persistent state in one place, independent tasks in another. A six-week engagement is persistent. The weekly status update inside that engagement is independent. Mixing those is what creates the context-window failure modes above.

Five small mistakes that compound

Beyond the three failure modes, five smaller habits add up to the same outcome.

Pasting transcripts in full when you only need the relevant excerpt. A 45-minute meeting transcript is 6,000+ tokens. If you only need the part where the CEO mentioned the Q3 target, paste those five sentences. The rest is noise the model has to reason around.

Asking Claude to summarize the conversation so far. Sometimes useful. Most of the time, it just creates another summary that now also lives in the conversation, doubling the relevant tokens.

Leaving the system prompt or skill instructions unchecked. If the skill activated at the start of the conversation has 2,000 tokens of instructions and the conversation is now about a different task, those instructions are still loaded. Start a new conversation; the skill will only re-activate if its triggers match the new task.

Treating Claude like it has perfect recall of everything you said. It doesn't. If something earlier in the conversation is load-bearing for the current task, paste it again — but only that, not the whole earlier exchange.

Working in giant conversations because there's room. There is room, but quality slips long before the cap, very long conversations use more of your plan's usage, and you usually only notice the drop in hindsight.

Where this connects to the rest of the practice

One related change: Claude's memory, now on by default for individual accounts, carries some facts between conversations. It's useful, but Claude decides what to keep, so it doesn't replace the engagement files you control.

The discipline above is one piece of the broader operating model — what "AI-native" actually means in practice: AI is part of the work, but the work itself is yours. The Solo Consultant's AI Playbook covers the broader frame — when to reach for AI, when to keep it out, how to structure the work so AI is leverage instead of friction. The context-window discipline is the version of that principle applied to one specific tool.

The practical move this week: pick the longest-running Claude conversation you have. Look at how many distinct tasks it covers. If the answer is more than three, that conversation is doing too many jobs. Start fresh conversations for the next round of tasks. Move accumulated engagement context into a clients/<name>/ folder or a Claude Project. Watch the next week's drafts sharpen.

Everything we make for setting Claude up to do client work is on one page: Claude for Solo Consultants.

Keep each conversation for the task in front of you, and keep the engagement itself in the folder or the Project, where it doesn't wear out.