If you build apps as a solo developer, there are days when you spend six, eight, even ten hours inside the same Claude Code session. The morning feels sharp. By late afternoon something has shifted. Instructions land sideways. Claude forgets a convention it respected two hours earlier. I have lost count of how many times I have hit this wall.
This article is about refusing to leave that moment to chance. We will walk through how to detect context decay before it bites you, how to design session boundaries so the cutover is smooth, and how to run a quick mid-flight diagnostic when something feels off. Everything here comes from running my own app development workflow against Claude Code day after day, so some of the signals are ones you will not find in the official documentation.
Why long sessions lose accuracy
Claude Code's context window is large but not infinite. More importantly, effective degradation begins well before you hit the hard limit. Effective degradation means the model can still see the entire context but gets pulled off target by loosely related information, so its judgment becomes less reliable.
In my own runs I start to see the first signals after about forty file reads in a session, and by around one hundred the behavior stops matching where it was in the first hour. This is not a pure token count problem. It is a matter of information density and relevance.
Auto-compaction does reset the visible token count, but compression itself loses detail. Key context gets summarized away, and occasionally that summary is where an important constraint disappears. Auto-compaction is a tool, not a cure.
The warning signals I watch for
After many sessions, here are the signs I have learned to treat as a five-minute warning. If you see two or three at once, treat it seriously.
Inconsistent naming. A type you have referred to as UserProfile for an hour starts showing up as userProfile or User. Naming consistency is how you can tell whether the model is still tracking the design you agreed on. Once that slips, other suggestions degrade with it.
Repeated questions about things already answered. If Claude asks again where a file lives, or which test framework the project uses, that answer is being drowned out by newer context. The facts are still in the window, but they are not being retrieved reliably.
Suggestions that ignore recent edits. You rewrote a function in async/await five minutes ago, and now Claude proposes rewriting it again using .then() chains. This means the tail of the context is losing weight against earlier state.
Loss of "ask before destructive" instinct. Early in a session Claude will say "just to confirm before I delete this." Later in a long session it will skip that confirmation step on similar operations. The cautionary framing from your original instructions has faded.
Designing session boundaries in advance
Once the signals appear, ending a session without losing work is stressful. The answer is to design boundaries before the day starts.
Split the work, then match sessions to the splits
I break a feature into roughly four natural stages: implementation, tests, review, and release prep. Each seam is a natural session boundary. Even if I never feel decay, I switch sessions at those seams by default. This keeps me ahead of the curve instead of reacting to it.
Use a single handoff file
Before a session ends, I write everything the next session needs into a single Markdown file. I call mine SESSION_HANDOFF.md. The next session starts by reading this file first.
# Session handoff
## Current work
- Feature: API wiring for the user profile screen
- Done: basic endpoint call and happy path
- Not done: retry logic on error + test coverage
## Decisions worth remembering
- Auth must use the existing `useAuth` hook (do not create a new one)
- Error UI goes through the `ErrorBanner` component
- Retry: up to 3 attempts with exponential backoff
## Cautions
- `src/hooks/useProfile.ts` is used elsewhere — no breaking changes
- Add tests to `__tests__/profile.test.ts`A handoff like this puts the most important facts into the first few hundred tokens of the new session. Information density is everything when you want the model to stay accurate. A short, high-signal briefing beats a long drifting conversation every time.
Ask the model to help before you cut over
Right before ending a session I ask Claude: "what from this session do you want me to carry over, and what should I make sure you do not forget?" That list becomes the draft of the handoff file. It also surfaces items the model considers unfinished that I might not have noticed.
The mid-flight diagnostic
When a session is still live but something feels off, I run a three-step check.
Step 1: ask for a structural summary. "Describe the current project structure in three lines." If the answer is vague or generic, context awareness has softened. Concrete directories and their purposes should come out easily if the model still has a firm grip.
Step 2: ask for a recap of recent edits. "What did we change in the last thirty minutes, and why?" Time ordering and cause-and-effect should be clean. If those are fuzzy, intermediate reasoning has been displaced.
Step 3: run a gentle trap. Propose the opposite of a decision you already made together. A healthy session will push back: "we chose the current approach earlier because X." A degraded session drifts with whatever you suggest last.
If two of these three raise concerns, I end the session. Continuing is almost always slower than cutting over with a clean handoff.
Prompt habits that slow decay
You can also delay the onset of decay with a few prompt habits.
Consolidate constraints in one place. Decisions accumulate across a conversation — types chosen, naming rules, things to avoid. Periodically re-post a single "decisions so far" message. This is much easier for the model to reference than a trail of scattered comments.
Explain why you are about to read a file. Framing the intent ("I want to check that the error handler covers the edge case from earlier") helps the model extract just what it needs. Reading without intent pulls in noise.
Explicitly discard information that no longer matters. "The X issue is resolved; you can stop factoring it in." Even if the text stays in the window, giving it lower priority changes how much it affects judgment.
My own rhythm
Just as a concrete reference point, here is the rhythm I actually use.
- Morning: start by reading yesterday's handoff
- Before lunch: ask the session to self-assess
- After lunch: new session for afternoon work
- Evening: add extra confirmation steps when I am tired
- End of day: write tomorrow's handoff and close out
Since I started working this way, the "I did this at 10pm and it was off target when I read it back the next morning" frustration has almost disappeared. The trick is not to avoid long sessions. It is to design how they end.
One thing to try
If you want to take something away from this article, here is the single thing to try next. The next time you use Claude Code for more than two hours, stop once in the middle and ask for a three-line summary of the project structure. The answer you get back is the first data point in your own personal "when do I cut over" instinct.
Long sessions are not something to avoid. They are something to design. Find your rhythm, and working with AI day after day starts to feel less like guessing and more like a routine you can trust.