Even 1M-token context windows need checkpoints — long context is not the same as good retrieval

There's a quiet expectation that bigger context windows will end the workflow-overhead conversation. "With a million tokens we can just stuff the whole codebase in and be done." "Why are we still talking about context management when models can hold so much?"

Then you actually run a long session with one of these models and the disappointment lands. The model holds the context. It just doesn't use the right parts of it at the right moments. Important early decisions get diluted by later noise. The model confidently asserts something at hour three that contradicts something it agreed to at hour one. The signal-to-noise problem turned out to be more interesting than the window size problem.

The model can read the whole window. It cannot equally weight every piece. Retrieval drift sets in. The fix isn't "more tokens" — it's checkpointing.

What "retrieval drift" actually looks like

A few concrete examples from real long-context coding sessions:

Style drift. Early in the conversation, the user explained that the codebase uses tabs and a particular indentation pattern. Five hours later, when the model is editing a different file, it switches to spaces because a more recent code block in the window happened to use spaces.

Decision drift. Early in the conversation, the team decided not to migrate to library v4 because of a known issue. Many turns later, the model suggests an approach that requires v4, having effectively forgotten the earlier decision.

Naming drift. A custom function was defined at the start of the session. By the end, the model is calling it by a slightly different name, or has invented a new function with overlapping behavior.

Scope drift. The user asked the model to focus on file X. Over the course of many turns, the model's attention spreads to files Y and Z that came up in passing.

In each case, the model technically has the right information in its window. But the prior, weighted by recency and proximity, is pulling the model away from the user's actual intent. The model is being faithful to its context — just not to the parts that should have been load-bearing.

Why bigger windows make drift worse, not better

Intuitively, more context should help. In practice, more context tends to increase drift because:

More tokens means more competing signal. The early decisions are still there, but they're surrounded by hours of other content. Their relative weight decreases.

Recency bias amplifies. Most models give more weight to recent context. Long sessions push the load-bearing decisions further back in the window.

Noise accumulates. Quick tangents, exploratory code, abandoned approaches — all stay in the window. The model can't tell which were authoritative and which were experiments.

Self-references multiply. As the model writes more in the conversation, its own earlier outputs become the dominant signal in some retrieval situations. The model starts conforming to itself rather than to the user.

The pattern is robust. Pure window growth past a threshold makes long-running sessions less reliable, not more.

What checkpointing does

A checkpoint is a deliberate summary, written at a moment in the session, that captures what is still load-bearing. Not the full history — just the decisions, conventions, and constraints that should govern everything after.

A typical checkpoint reads like:

Status as of turn 30:

• Stack: Next.js 14, Postgres, Drizzle ORM. Do not introduce other ORMs.
• Style: tabs, 2-wide; no semicolons in TS.
• Decision: defer the v4 migration; current code targets v3.
• Names: formatCurrency (helper in lib/format.ts), useReleases (hook in app/lib/hooks).
• Out of scope this session: anything in /admin/.

The checkpoint is then either dropped into the conversation as the next turn or saved into the user's context substrate (a vault, a project file). When the model uses the checkpoint as recent context, it correctly anchors against the load-bearing facts even when the surrounding hours of dialogue are noisy.

Checkpointing is essentially re-promoting the important parts to recent positions in the window, where the model's attention is naturally higher.

When to checkpoint

The right cadence depends on the work. A few useful triggers:

After a decision. As soon as the team decides not to migrate to v4 (or any decision of comparable weight), checkpoint it. The decision will get forgotten in noise otherwise.

After a long debugging detour. When the conversation has spent two hours exploring an issue and resolved it, summarize the conclusion so the next phase isn't shaped by the detour.

Before switching scope. When the user is about to ask the model to work on a different file or feature, checkpoint the current state so context for the next phase is clean.

Every N turns. A regular cadence — every 30 or 50 turns — catches drift before it gets acute, even when no obvious trigger has fired.

The specific cadence matters less than the discipline. A session that checkpoints occasionally stays useful for hours; a session that never checkpoints starts producing worse outputs by hour three regardless of window size.

Where checkpoints live

There are two reasonable homes for checkpoints, and they're not exclusive.

In the conversation itself. Drop the checkpoint as a turn. Cheap, immediate, and the model uses it as recent context.

In a vault or project memory. Save the checkpoint to a persistent substrate. The next session — possibly with a different tool — starts with the checkpoint in scope. This is where checkpointing connects to the broader vault-shaped context-management story.

For a single long session, in-conversation checkpoints are sufficient. For multi-session work, vault-stored checkpoints are what makes the practice sustainable. You write a checkpoint at the end of today's session; tomorrow's session opens with that checkpoint already loaded, regardless of which tool you're using.

What checkpoints don't solve

It's worth being honest about the limits.

They don't replace the model's attention. A checkpoint helps the model anchor on the right things; it doesn't make the model smarter.

They don't prevent the user from contradicting the checkpoint. If you ask the model to do something that violates a checkpointed constraint, the model may follow you instead of the checkpoint. That's usually correct behavior, but it's something to be aware of.

They don't help if the model has fundamentally misunderstood the project. Checkpoints anchor against what's already been agreed. They don't fix bad initial framing.

They add a small ongoing cost. Writing checkpoints takes attention. The cost is worth it for long sessions; for a quick five-turn interaction, skip them.

Used appropriately, checkpoints multiply the useful working time of a session. They don't change the model's ceiling.

How to write a good checkpoint

A few rules of thumb:

• Use plain language. "We decided not to use v4" beats "DEPENDENCY_VERSION_DECISION = v3".
• Lead with the decision, then the reason. The model uses the decision; the reason helps the user remember.
• Include negative constraints. "Don't introduce X" is often more load-bearing than "do Y."
• Keep it short. A checkpoint that's too long becomes more noise. Aim for the ten most important facts.
• Date or turn-stamp it. When you're stacking multiple checkpoints, the order matters.

With practice, writing a checkpoint takes a minute or two. The yield is the rest of the session staying coherent.

What this means for tool builders

If you're building a coding assistant or an AI tool with long sessions, supporting checkpointing as a first-class operation is a high-leverage move.

The surface can be simple: a slash-command, a button, or an automatic suggestion at appropriate moments. The behavior is to produce a structured summary of the session's load-bearing facts and persist it where the next session can find it.

A tool that ships this well makes long sessions feel coherent in a way that no amount of context window growth can. The user's experience is "this tool remembers what matters" — even though the underlying model is doing the same thing it always does.

What this means for users

For users running long AI coding sessions today, the practical move:

1. After every major decision, write a one-line checkpoint into the conversation.
2. After every long detour, write a one-line summary of the conclusion.
3. Every 30-50 turns, write a broader checkpoint capturing the current load-bearing facts.
4. At the end of a session, write a final checkpoint and store it in your vault or a project notes file.
5. At the start of the next session, paste the checkpoint into the new conversation's opening turn.

This is a discipline, not a tool. Done consistently, it makes long sessions usable. Skipped, it makes long sessions drift no matter how big the model is.

The summary

Larger context windows don't fix retrieval drift. They sometimes make it worse, because important early signal gets diluted by recent noise. Checkpointing — periodic re-promotion of load-bearing facts — keeps long sessions coherent. It's a small discipline with a large yield, and it's the part of context management that bigger windows haven't replaced and probably won't.