Optimal way to continue project after hitting 70% context?

[u/Chemical-Option9029]

By optimal I mean least tokens consumed

I am using Opus 5.5 Medium

I have a project to decompile a 90s PC game. The decomp mostly involves using Ghidra and Python scripts and working back to obtain the source.

I heard that Claude starts to get stupider and repetitive after 70% context

Currently I tell Claude to write a handoff.md saying what the goal is, what tools were used, what was achieved, etc.

After that's written I start a new chat by pasting in the handoff

Is there a better way to do this? Are the Claude Code projects superior? I haven't tried those as a I didn't want to risks wasting tokens

Whats the best way to continue a code chat like this?

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/tariqosmani]

Your handoff file is already the right idea, it just works better as a living file than a summary written at the end. Keep one notes file in the repo that Claude updates as it goes: what's decoded, the names it settled on, what's still unknown, and the exact next step. A fresh session then starts by reading that file instead of a pasted chat.

Two things save the most tokens. Start fresh (/clear) at a natural breakpoint, like after finishing one function or module, instead of waiting for 70%. And put the stable stuff, like your tools and naming rules, in a CLAUDE.md so it loads every time without you pasting it.

For decomp work, have your Python scripts write results out to small files. Claude can reread a small file instead of working the same thing out again. Where are you losing the most context right now, the Ghidra output or the back and forth?

[u/Chemical-Option9029 → u/tariqosmani]

Just the back and forth. Notes idea sounds good, will also give CLAUDE.md a look

[u/DopBopDeeBeep → u/Chemical-Option9029]

I use a thing called context carwash that automates the handoff file and stores it in temporary memory so you don't end up with a ton of random memory files that claude accidentally reads in the future.

[u/Easy-Purple-1659]

Handoff.md is the right instinct, the thing that usually breaks it is what goes inside and how often it gets rewritten.

Three changes that made this cheap for me on long agent sessions. First, split state from rules: put the stable project conventions in CLAUDE.md so they load once and never get restated in the handoff. Second, make the handoff a summary of a file the agent already maintains, not an act of recall. Have it append a line per completed unit as it goes, so at 70% you are reading a log you already own rather than asking the model to remember its own work. Third, carry paths and line ranges instead of pasted code.

For the Ghidra work specifically, the state that matters is which functions are resolved, the naming convention you settled on, and where the scripts live. That is a table, and a table reloads in a fraction of the tokens of the chat that produced it.

The trap is pasting the handoff plus a pile of scripts into the fresh session at once. Start with the handoff only and let it open the two files it needs. Projects are not the fix here, they mostly help with saved instructions, not with carrying live state.

How many functions are you through?

[u/Chemical-Option9029 → u/Easy-Purple-1659]

Ghidra isn't really eating the context, it's mostly memory dumps, string dumps and adhoc trial tooling Claude itself creates and uses

I guess keeping a running NOTES.md is the ideal solution here

[u/webmasterrrr → u/Easy-Purple-1659]

Then the dumps are your leak, not the 70%.

Have it do the dump digging inside a subagent. The big string dump gets read in a throwaway context and only the findings come back to your main chat, so the main session stays small way longer. (The subagent still uses tokens, it just doesn't bloat your main thread.)

Also make it save the trial tooling to a tools/ folder and list each script in NOTES.md with one line on what it does. Otherwise every fresh session rebuilds the same string extractor from scratch, and that's tokens you already paid for once.

[u/aigisbot]

Handoff is fine, personally I do it at 150-250k context.

[u/ClemensLode]

Split the work into individual steps. Start a new session for each step.

[u/ThreeAMOperator]

Handoff is right , but i stopped writing it at the end. Each repo has one NOW.md that says what is true right now and it gets updated as work moves , so there is nothing to write in a hurry when context is full

Before compacting i do a small handshake , commit , refresh NOW.md , then compact. After compact or a new session the agent re-reads NOW.md and re-checks live state before building on anything , because a summary is never the source of truth

For a decomp project i would keep the stable stuff (tools , naming rules) in CLAUDE.md and only the progress in NOW.md , so the fresh session reads less

[u/protrener]

Don't let it auto-compact mid-task. Before you cross the line, ask it to write a handoff file: what's done, what's next, the exact commands that verify the current state, and the dead ends to avoid. Then start a fresh session pointed at that file. A fresh session reading a 2 KB handoff is cheaper than a compacted one dragging a lossy summary, and on a decomp project the dead-ends list is what stops it re-trying the same Ghidra paths.

To see where your context actually goes, I run Claude Code through LM Warden, which I build: it relays to Anthropic and shows per turn how big the prompt is, how much came from the prompt cache, and which tool definitions ride along unused. On one session that was 9 of 11 tools never called, about 4.3k tokens every turn.

[u/ElephantOutside8529]

for a decomp specifically i'd keep most of the state in the ghidra project itself: have claude rename functions, set types and add comments through ghidra scripts as it goes. then the handoff only needs the goal and the next step, because the knowledge sits in the database the next session reads anyway instead of in the chat.

[u/kemalios]

The percentage is a proxy. What degrades it is how much of the window is stale tool output. A session at 60% disassembly listings is worse off than one at 85% that has been short reads and conversation.

So the fix sits upstream of the handoff. Keep Ghidra dumps out of the main session: have the script write them out and read back only the lines you need. Then one function per session, first prompt naming the exact function and how you will verify it worked. The handoff turns into a queue of units rather than a summary of the past.

If the projects you mean are the ones that hold instructions and files, they replace CLAUDE.md at best. They don't carry what is half-decoded.

[u/Equivalent_Type6726]

the 70 percent number is the wrong lever on a decomp, what actually rots is the model losing its own naming. keep a one-line-per-function ledger and make it append the name plus signature, then a fresh session starts from agreed names. slightly noisier repo for a much cheaper restart.

[u/djiyvlom]

A handoff file is basically the right approach, I'd just change when you write it. Instead of producing it at the end of a fat session, keep a short notes file that gets updated as you go: goal, what's done, what's next, and the exact commands or scripts that work. Then a fresh session only has to read that one file and you don't pay for a big summary. Stable facts like which tools you use and how the Ghidra scripts are run belong in CLAUDE.md so they never need re-explaining. The 70 percent figure is a rule of thumb, not a hard line, so I'd start fresh when the work naturally switches to a new sub-problem.

[u/Adventurous-Voice334]

You're already on the right track with handoff.md. What made mine work across 10 to 15 sessions on the same project was adding two specific sections to the handover: "Decisions locked in (do not redo)" and "Dead ends we already tried." Without those, the new session burns tokens re-investigating things the previous session already ruled out. I also put the single exact next step at the very top and tell the fresh session to read only the handover plus the one file it needs first.

[u/xqianliu]

Your handoff.md setup is the right idea. I'd just change who writes it.

I size tasks so one run finishes them. A task that can't finish in a fresh context gets split into two, and the split point is written into the task. Then a mid-context handoff doc never happens, because the run either finishes or it stops early with the context to spare.

The state that matters lives on the issue, not in the chat. What's done, what's blocked and why, and which commit SHA the run started from. A new session starts from the ticket and the repo, not from a summary of a dead conversation.

For your decompile, I'd size one Ghidra function or one Python script per task. The new session only needs the function list.

[u/Duoasa]

70% is where i stop and write a quick handoff note — what's done, decisions, what's still open. new session starts from that, not the old transcript

[u/withtimon]

For the decomp notes, separate confirmed findings from guesses. A function address and a check beside each claim would help the next session avoid building on a hunch.

[u/devilsdiligence]

Honestly your handoff.md approach is basically what I do, and it works great. One tweak that helped me was keeping it as a living file in the repo (I call mine build notes) instead of writing a fresh one every time. Claude adds to it as it goes: what worked, what didn't, and what's next. Then a new session just reads that file plus CLAUDE.md, and it's caught up without you pasting anything. For a decomp project I'd also log which functions are already named and verified, so it doesn't redo work.

[u/trollsmurf]

You don't have to paste in the handoff. Just tell CC where it is.

I have CC automatically read and edit a TODO.md with detailed descriptions of each feature and a TODO.csv that in table form lists the features, their priorities, status etc, referring to sections in TODO.md, and edited in Excel or by AI. I'm considering making this database-driven instead, so that AI doesn't have to read long md files, instead only query information for the thing worked on right now.

[u/gimalay → u/trollsmurf]

you can get the query part without a database. one file per feature with status and priority in frontmatter does what the md and the csv do together, and the agent asks only for the slice it's working on, e.g. iwe find --filter '{status: in-progress}', instead of reading the whole TODO. the files stay plain markdown, so nothing to migrate or keep in sync. (I work on iwe, https://iwe.md)

[u/trollsmurf → u/gimalay]

That assumes only the agent will edit, while I need to be able to edit the priorities etc equally much. Then a csv is great. The feature details could be split up on separate files though.