"Wait, What Was I Doing?" or Why Your AI Starts Acting Like an Alzheimer's Patient

You’re four chapters in. The AI is producing output. The words are flowing. Nothing has crashed.

And something is wrong.

You can’t name it exactly. The chapter feels slightly off. A character sounds a little generic where they were specific before. A plot beat gets soft where the outline was clear. The session is still running. The model hasn’t flagged anything. It’s just... not quite right anymore.

That’s context window degradation. It doesn’t announce itself. It doesn’t throw an error. The session continues and the output continues and the wrongness accumulates quietly until you go back and read what you wrote and realize the model lost the plot somewhere around the third hour and kept going anyway.

An Alzheimer’s patient doesn’t know they’re forgetting. Neither does the model.

The Silent Failure

Context window degradation isn’t the model getting dumber. It’s the model losing track of what it was doing and filling the gaps with its defaults.

The mechanism is documented. A 2023 Stanford/UC Berkeley paper, Lost in the Middle: How Language Models Use Long Contexts, found consistent U-shaped performance across the models tested: models retain information at the start and end of the context, but information placed in the middle degrades significantly. In some test conditions, accuracy dropped 20 points or more from position alone. Morph’s analysis of the broader research landscape found the same pattern across 18 frontier models. Not a few. Not the weaker ones. All of them.

That’s the structural problem. Your chapter outline from early in the session is sitting in the middle of the context. Your character notes are in the middle. The setup you established in Step 2 is in the middle. The model is working from the edges while the substance is in the blind spot.

The failure modes for writers are specific. Tonal drift: the character starts sounding like the model’s default register instead of their own. Voice flattening: distinct characters converge toward a median. Plot logic softening: the model starts papering over gaps instead of surfacing them.

And the one that’s hardest to catch: the model begins re-asking questions it was already given the answers to. Character details established at session open. Location confirmed in the outline. Plot direction set before the first word was written. As context degrades, those anchors fade and the model starts filling the gaps with invented detail, or asking you to re-confirm things you already confirmed.

There’s also a second failure mode that’s easy to confuse with degradation but is actually distinct. Over-explanation, hedging, padding, restating what was just said in slightly different words: that’s a Claude fingerprint. It’s baked into the training as a default. The model qualifies. It hedges. It covers itself. That behavior is present in clean sessions too.

What context degradation does is amplify it. As the model loses its grip on what was established, it falls back harder on its defaults. The prose gets longer and softer at the same time, and the fingerprint gets louder. Writers notice “something feels off” before they can name it, because what they’re seeing is a failure mode they were already managing getting worse in a way that’s hard to distinguish from normal variation.

The session doesn’t stop. That’s what makes it dangerous. The model is still producing words. Plausible words. Words that don’t trip any obvious error condition. You get output that passes a surface read and fails a structural one, and the only way to catch it is to already know what the chapter was supposed to do.

The Advertised Window Is a Lie

The model you’re using probably advertises a 200,000 token context window. Maybe more.

Here’s what that number actually means in practice.

A Morph analysis of context degradation puts effective usable capacity at 60-70% of the advertised window. Not because the model stops accepting tokens (it doesn’t), but because reasoning quality degrades well before you hit the technical ceiling. You’re not getting 200,000 tokens of consistent, high-quality reasoning. You’re getting somewhere between 120,000 and 140,000, and then a degraded zone where the model is still running but running worse.

The degradation isn’t always gradual either. A 2025 study on context length and LLM performance found that reasoning capacity itself degrades as context grows, even with perfect information retrieval. The problem isn’t that the model can’t find the relevant text. It’s that the model’s ability to reason about what it found deteriorates. That’s a harder problem than retrieval. You can’t fix it by writing better prompts.

James Howard’s analysis of Context Degradation Syndrome puts a rough time estimate on it: by about 35 minutes of agentic work (roughly 80,000 to 150,000 tokens accumulated), reasoning quality measurably drops even in a 200,000 token window. That’s not deep into a session. That’s a normal working morning.

The vendor incentive problem here is straightforward: selling you a bigger context window is a product. Fixing the underlying architecture is hard, expensive, and gives your competitor the same benefit if they copy it. The bigger window is easier to market, easier to charge for, and quietly relies on you not running the numbers on what “200K tokens” actually delivers versus what it advertises. Everyone is arguing about whether 200,000 tokens is enough to hold a novel. The answer is you shouldn’t be trying to hold a novel. That’s the wrong unit of work, and the vendors are quietly happy you haven’t figured that out yet.

Restart Economics and the Architectural Fix

The naive fix is to restart more often. Fresh context, fresh session, problem managed.

That’s the right answer. It’s also useless if your only memory is the chat log.

If every important thing about your project lives in the conversation history (character details, plot progression, world rules, timeline, voice notes), then a restart means starting over. You have to re-explain everything. The restart cost is the cost of re-loading your entire project into a new context, which is the problem you were trying to solve.

The real fix is to externalize memory so the context window never has to hold the whole project.

I’ve been building toward this architecture since the start of the Vampires of Tucson series. The short version of the principle, at article scale, is in my CLAUDE.md project file:

Article prep and article writing are always separate context windows.
1. Run /article-prep to research and produce the brief (.md file)
2. Close that session
3. Open a new session and run /article-write with the brief as input

The brief is the handoff document. The write session gets a complete spec, not accumulated noise from the research session. Two sessions, clean context, restart cost near zero because the brief captures everything the write session needs.

Three Phases to Publish built out this principle at article scale. That piece gave you the workflow fix. The context window problem (this piece) is what happens when your project is nine books long and a fresh session alone doesn’t cut it.

At novel scale, the architecture looks like this. Before a single word of chapter prose is written, a structured initialization sequence fires:

SESSION VARIABLES
SESSION_BOOK =
SESSION_CHAPTER =
SESSION_PART =
SESSION_TASK =

STEP 1 - ESTABLISH CONTEXT
  get_current_time()
  [Ask user: which book and task?]

STEP 2 - LOAD NOTES AND BOOK SUMMARY
  read_notes(scope="cross-project")
  read_notes(scope=[book])
  get_book_summary([book])

STEP 3 - LOAD ESSENTIAL CANON
  read_canon_file("VAMPIRES_OF_TUCSON_AI_Summary.txt")
  read_canon_file("Vampires of Tucson - Vampire Physiology.txt")

STEP 4 - CHAPTER CONTEXT
  get_chapter(book, chapter, part)
    → returns: pov_char, cast, location
  get_multiple_characters(cast, fields=[species, humanity, voice, relationships])
  get_location_fields(location_id)
  [Character agent deployment for complex profiles]

None of this is in the context window when the session starts. All of it is queried from the canon database at session open. The context window receives a clean, targeted data package: the current chapter’s POV character, the cast members in this scene, the location, the relevant world rules, and the notes that matter for this session. Not the accumulated history of nine books. Not everything I’ve ever written. One chapter’s worth of context, precisely loaded.

The result: restart cost drops to near zero. When the session ends (one chapter maximum per session, always), nothing important lives in the context window that isn’t also in the database. Start fresh. Reload what matters. Write.

The specific tool here is an MCP (Model Context Protocol) server: a local database that the model can query directly for character profiles, location data, timeline entries, and session notes. Two-Phase Pipelines, Persistent Memory, and Why RSS Still Wins covers the architecture in more detail. The point for this piece is the principle, not the implementation: separate your memory layer from your working layer. Whatever tool you use, whatever stack you’re running, the architecture is the same. Memory that degrades is memory you can’t trust. Memory that lives outside the context window doesn’t degrade.

The realistic output for a prepared session on Claude Sonnet 4.6 is 2,000 to 3,000 words. Those are draft words. Raw material, not finished prose. Words don’t equal quality, they equal scale. What preparation buys you is consistency: a prepared session delivers reliably, every time. An unprepared session delivers less and worse. The model isn’t the variable. The preparation is.

557,522 words across the Vampires of Tucson series, May through December 2024. That number is not a boast about volume. It’s a data point about what it costs to build a working system. The rough drafts were the R&D. By the end of that run the workflow was proven, the canon database was proven, the session architecture was proven. The word count is what the iteration cost. Not a finish line. A starting gate.

You Are the Systems Engineer

Step 3 in the workflow isn’t editing. It’s an audit.

When you read the draft, you are not the editor looking for bad prose. You are the engineer reviewing the output of your own process. The question isn’t “how do I fix this sentence?” It’s “why did the process produce this sentence?”

A plot hole is not a writing problem. It’s a chapter outline problem: the outline didn’t specify something it needed to. A character inconsistency is not a voice problem. It’s a profile gap: the canon database is missing a detail. A logic error is not a hallucination to correct in the prose. It’s a signal that the prep was incomplete.

Every error in the draft points back to a specific failure in the system. Fix it there, not in the draft. Or it will happen again. The same outline gap will produce the same plot hole in the next chapter. The same profile gap will produce the same inconsistency. Patching the draft is treating symptoms. Fixing the process is curing the disease.

This is where the system improves: not through better prompting in the moment, but through better preparation upstream. You are not editing. You are debugging. The draft is the test output. The canon database and the chapter outline are the code.

The Wrong Debate

The context window debate is the wrong debate.

Writers aren’t asking the right question when they ask “is 200,000 tokens enough to hold a novel?” The right question is: “how much of my project does my AI actually need to hold at any one time?”

The answer, for a well-architected workflow, is: one chapter’s worth. That’s it. Everything else should live somewhere that doesn’t degrade.

Garbage In, Garbage Out is the oldest rule in computing and the one AI writing advice ignores most consistently. The context window doesn’t degrade your novel. A bad chapter outline does. A thin character profile does. An unprepared session does. Fix the inputs and the outputs fix themselves. The model is the least interesting variable in the equation.

You can spend the next year arguing with vendors about whether 200,000 tokens is enough. Or you can build a workflow where it doesn’t matter.