How to Detect Claude Context Loss (The Nickname Trick)

Claude context loss is when the model silently stops following your CLAUDE.md instructions as a conversation grows. There’s no progress bar, no warning, no “context 78% consumed” indicator. The model simply gets worse, and you won’t notice until the damage is already in your diff.

That should bother you more than it does. You’re working inside a tool that reads a configuration file on boot, loads your project context, accepts your request, and begins generating code, all while silently degrading its adherence to your rules. Unless you’re paying close attention to the output quality, the drift is invisible.

I found a fix for this on Hacker News a few months ago, and I’ve been using it ever since. It takes two sentences to implement. The implications, however, go deeper than the trick itself: they point to a fundamental constraint of how context windows actually work, and why most developers are managing them wrong.

The Trick

Add this line to your CLAUDE.md:

Always address me as [your nickname] when responding.

That’s it. When Claude stops using your nickname, it has lost your CLAUDE.md context. Binary signal: nickname present means instructions are loaded; nickname absent means they’ve fallen out of the effective reasoning window.

I use my old Twitter handle (Sheminsky) as the canary. When Claude responds with “Sure, Sheminsky, I’ll refactor that module,” I know the configuration file is still active. When it responds with a generic “Sure, I’ll refactor that module,” I know the instructions have degraded. No ambiguity. No guessing. The cost is one instruction slot out of your roughly 150 to 200 budget.

I shared this on the show and Dan’s immediate response was “What?”, followed by asking what my nickname was, which I think tells you something about the unexpectedness of the approach. It’s a parlor trick that happens to solve a real instrumentation problem.

Why It Works: The Context Window Is Not What You Think

The trick works because it exploits a property of large language models that most users misunderstand: the context window isn’t a hard cutoff. It’s a gradient.

Claude’s context window holds roughly 128,000 to 200,000 tokens, depending on the model. A token averages about three characters, so you’re looking at somewhere in the range of 400,000 to 600,000 characters of conversation history. That sounds like a lot. It isn’t, or rather, the raw capacity isn’t the constraint. The constraint is effective utilization.

According to an analysis of LLM anti-patterns that we covered in Episode 4, model performance begins degrading when approximately 13% of the context window remains. Not at zero. Not at 5%. At 13%, roughly one-eighth of the total capacity still available, and the model is already producing measurably worse output. That’s because the model’s attention mechanism doesn’t weight all tokens equally. Instructions near the beginning of the context (your CLAUDE.md) compete with the growing volume of conversation, tool outputs, and generated code for the model’s limited attention budget.

Think of it less like a hard drive filling up and more like a crowded room where everyone is talking. Your CLAUDE.md instructions are the person who spoke first. They were heard clearly when the room was empty. As the conversation grows (more code generated, more tool calls, more back-and-forth) the room gets louder. Your instructions are still technically present in the context. The model can still “see” them. But they’re being drowned out by everything that came after.

The nickname is the canary in this coal mine. It’s a low-stakes, easily verifiable instruction that degrades at roughly the same rate as your higher-stakes instructions. When the canary dies, so has your “always use TypeScript strict mode” and your “never modify the authentication middleware directly.”

The Three Stages of Context Degradation

Borrowing from signal detection theory (the study of how observers detect signals in noise), context degradation follows a predictable progression. Knowing the stages helps you intervene at the right time rather than after the damage.

Stage 1: Full fidelity. The model follows your CLAUDE.md instructions consistently. Nickname present. Architectural constraints respected. Code style matches your conventions. This is the easy part, and it’s where most sessions start.

Stage 2: Selective drift. The model begins dropping lower-priority instructions while still following the most prominent ones. You might notice code style slipping before architectural rules break. The nickname may still appear intermittently, sometimes present, sometimes absent in the same response. This is the stage most developers miss entirely, because the output still looks mostly correct. It’s also the stage where the highest-leverage intervention happens: start a new session now, and you lose ten minutes of re-orientation. Wait, and you lose an hour of debugging subtly wrong code.

Stage 3: Cognitive bankruptcy. The model has effectively lost your configuration context. The nickname is gone. Architectural invariants are violated. The model may still produce syntactically correct code (it is, after all, still a capable language model) but it’s operating without the project-specific guardrails you set up. This is where developers notice “Claude is acting weird” and start a new session. By this point, the last several exchanges may contain code that needs to be reviewed against your original constraints.

The nickname trick converts Stage 2 from an invisible problem into a visible one. That’s the real value: not detecting Stage 3, which is usually obvious, but catching the transition from Stage 1 to Stage 2 before the subtly-wrong code starts accumulating.

What Accelerates Context Consumption

Not all conversations consume context at the same rate. Certain patterns eat through your window faster than others, and knowing which ones helps you stay in Stage 1 longer.

Repeating context the model already has. This was the first anti-pattern in the instaVM analysis: telling the model something you already told it. Every time you paste the same error message, re-explain the same requirement, or say “as I mentioned earlier,” you’re burning tokens on duplicate information. The model already has it in context. You aren’t refreshing its memory; you’re crowding the room.

Large tool outputs. When Claude reads a file, runs a test suite, or executes a shell command, the entire output enters the context window. A single cat of a 500-line file is roughly 3,000 to 5,000 tokens, and unlike your instructions, this raw output sits in the most recent portion of the context, where the model’s attention mechanism gives it disproportionate weight. Your CLAUDE.md instructions get pushed further into the background with every tool invocation.

Asking the model to do things outside its training. The “asking a fish to climb a tree” anti-pattern, as the article put it. When you ask a model to do something it can’t do well (counting characters, generating specific random strings, reasoning about events after its training cutoff) it doesn’t fail gracefully. It generates plausible-looking but wrong output, and then you spend follow-up messages correcting it, each correction consuming more context on a fundamentally unproductive exchange.

Not starting new sessions. This one is obvious in retrospect but hard to internalize: there’s no reward for long conversations. A fresh session with a clear prompt will almost always outperform a degraded session with accumulated context. The model doesn’t get smarter as the conversation grows. It gets noisier.

What To Do About It

The nickname trick is detection, not prevention. Here’s the response protocol, what to do once the canary signals degradation.

When the nickname starts flickering (Stage 2): Finish your current discrete task. Don’t start new work. Commit what you have, note where you are, and begin a new session. The temptation is to push through (“just one more feature”) and that temptation is almost always wrong. The code generated in a degraded context is the code you’ll be debugging later.

When the nickname disappears (Stage 3): Stop immediately. Review the last three to five exchanges against your CLAUDE.md constraints. Start a fresh session. If you’re using a task-tracking approach (Anthropic’s own engineering team uses JSON feature lists for exactly this reason) your progress is preserved outside the context window and can be picked up by the new session.

Structurally, build sessions to be short-lived. The Anthropic harness engineering article describes a two-phase agent approach: Phase 1 sets up the environment and creates a complete feature list; Phase 2 implements features with progress tracking. The critical insight is that the feature list lives in a file, not in the conversation context. When the session dies (and it will) the progress survives. The two-phase approach is explicitly designed around the assumption that context will be lost.

Use progressive disclosure in your CLAUDE.md. Don’t front-load every instruction into the primary file. Point to detailed sub-documents (“for test conventions, read docs/testing.md”) that the agent pulls in only when relevant. This keeps your core instruction set small and maximizes the ratio of signal to noise in the early, high-fidelity portion of the context. We discussed this technique in the same episode, and it’s the single highest-leverage structural change you can make to extend your effective session length.

The Uncomfortable Implication

There’s a broader point here that the nickname trick makes uncomfortably concrete: we’re building production workflows on top of a system that silently degrades without warning. The model doesn’t know it has lost your context. It doesn’t know it’s in Stage 2. It will continue generating code with the same confidence at 13% remaining context as it did at 100%. The failure mode isn’t a crash; it’s a quiet drift toward mediocrity.

This is why the HumanLayer article on CLAUDE.md emphasized that models can follow about 150 to 200 instructions, not because the context window can’t hold more tokens, but because the effective instruction-following capacity is a fraction of the raw context size. Your instructions are competing with the system prompt, the conversation history, and every tool output for a finite attention budget. The nickname trick doesn’t change any of that. It just makes the degradation visible.

And visible is better than invisible. A problem you can detect is a problem you can manage. A problem you cannot detect is a problem that ships.

The implementation takes thirty seconds: one line in your CLAUDE.md, one nickname you’ll recognize. The context management discipline it reveals (short sessions, progressive disclosure, external state, deliberate context hygiene) takes longer. But the first step is knowing when the room has gotten too loud for your instructions to be heard.

Add the nickname. Watch for when it disappears. Start a new session before you wish you had.