AI context is like milk: it is best served fresh and condensed. The longer a conversation runs, the more old material Claude has to carry, and the more its answers tend to slip.
This is part two of a series that walks through all 50 Claude Code tips in YK Sugi's claude-code-tips repo. It groups the four tips about context: numbers 5, 8, 12, and 21. Together they answer a practical question: once a session has grown long, how do you keep your progress and still give Claude a clear head?
There are four tools for that, in rising order of control: let Claude auto-compact, compact by hand, write a handoff document, or cut the conversation in half with half-clone.
Why does a fresh conversation work best?
A newly opened Claude Code session performs best because it has no accumulated context from earlier turns to process. The longer you talk, the longer the context gets and the more performance tends to drop. The rule that follows is short: every new topic gets a new conversation, and so does any moment when you notice the quality sliding.
The milk image sticks because it has two halves. "Fresh" means don't stretch one conversation across unrelated work; this morning's login-bug discussion does nothing for this afternoon's migration. "Condensed" means that when you do need to carry information into a new session, carry the distilled version, not the whole transcript.
Switching sessions has a cost, though: you lose everything Claude had worked out about the task. The next three sections are three ways to keep that understanding at the lowest context cost. If you want the mechanism behind quality decaying with conversation length, the article on the compact command and context rot explains it.
Should you let Claude compact on its own?
Claude Code has a /compact command that summarizes the conversation to free up context space. Compaction also happens automatically when the context fills up, and you can make it run earlier with /autocompact. Even so, the repo's advice is to compact proactively and tune it by hand rather than leave it to the automatic mechanism.
The repo author switched auto-compact off entirely in /config to decide when and how compaction happens. The reasoning is easy to follow: an automatic summary does not know what matters to you. It can keep a settled argument and drop a small constraint you only mentioned once.
Turning auto-compact off does not mean never compacting. It means you pick the moment, usually right after a milestone, and you pick what survives. The most effective way to make something survive is not a summary but a handoff document.
How do you write a HANDOFF.md?
Instead of compacting, ask Claude to write a handoff file before you start a new session. It records the goal, what was tried, what worked, what didn't, and the next steps, so that an agent with an empty context can read that one file and carry on. The prompt from the repo:
Put the rest of the plan in the system-prompt-extraction folder as HANDOFF.md. Explain what you have tried, what worked, what didn't work, so that the next agent with fresh context is able to just load that file and nothing else to get started on this task and finish it up.
In the example, Claude writes a 129-line file that opens with the goal "Reduce Claude Code's system prompt by ~45% (currently at 11%, need ~34% more)", followed by progress and the scripts written so far. Don't open the new session the moment the file lands. Skim it, and if something is missing, ask, for example: "Did you add a note about iteratively testing instead of trying to do everything all at once?" A question like that often saves the next session an afternoon.
In the new session, paste the file path and nothing else:
> experiments/system-prompt-extraction/HANDOFF.md
In later sessions, have the agent update that same file for whoever comes next. The repo ships a /handoff skill that automates this: it checks for an existing HANDOFF.md, reads it if present, then creates or updates the goal, progress, what worked, what didn't, and next steps. It lives in the repo's skills/handoff folder and in the dx plugin (part eight covers the plugin). I prefer this to compaction for one reason: a handoff file is something you can read, edit, and commit, while a compaction summary sits out of sight inside the conversation.
Forking a conversation with /branch and --fork-session
Sometimes you want to try a different approach from a specific point without losing the original thread. Claude Code supports this natively: type /branch inside a conversation to branch from the current point, or pass --fork-session with --resume or --continue at launch, for example claude -c --fork-session. The original conversation stays intact, and /resume takes you back to it.
--fork-session has no short form, so the repo suggests a shell function that wraps claude and expands --fs into --fork-session:
claude() {
local args=()
for arg in "$@"; do
if [[ "$arg" == "--fs" ]]; then
args+=("--fork-session")
else
args+=("$arg")
fi
done
command claude "${args[@]}"
}It intercepts every claude call, swaps --fs for --fork-session, and passes everything else through unchanged. It works with the aliases from part one, so c -c --fs and ch -c --fs are both valid. Forking fits best when you are torn between two approaches: try the first on a branch, and if it fails, return to the fork point without re-explaining the background.
How does half-clone cut context?
Half-clone is a script that turns an overlong conversation into a copy holding only its later half. You shed tokens while keeping your most recent work, because the later half is usually where the current state of the task lives. The copy's first message is tagged like [HALF-CLONE Jan 7 14:30] so you know which version you are in.
If half is still too much, a quarter-clone variant (the --quarter flag, or the quarter-clone skill) keeps only the last quarter, tagged [QUARTER-CLONE <timestamp>]. To install it by hand, symlink the script and both skills:
ln -s /path/to/this/repo/scripts/half-clone-conversation.sh ~/.claude/scripts/half-clone-conversation.sh
ln -s /path/to/this/repo/skills/half-clone ~/.claude/skills/half-clone
ln -s /path/to/this/repo/skills/quarter-clone ~/.claude/skills/quarter-cloneInstalling through the dx plugin skips the symlinks. The script has to read ~/.claude (where conversation files and history live), so to avoid permission prompts in every project, add this to your global ~/.claude/settings.json:
{
"permissions": {
"allow": ["Read(~/.claude)"]
}
}Unlike compaction, half-clone summarizes nothing. It keeps your messages and Claude's verbatim and only drops the older part. You lose the start of the conversation, but what remains is never reinterpreted.
Auto-suggesting half-clone with a Stop hook
You can use a hook to have Claude Code trigger /half-clone on its own once the context gets too long. The repo's check-context.sh runs after every Claude response and checks context usage; above 85%, it blocks Claude from stopping and tells it to run /half-clone, which creates a new conversation with only the later half so a fresh agent can continue there.
Copy the script into your scripts folder:
cp /path/to/this/repo/scripts/check-context.sh ~/.claude/scripts/check-context.sh
chmod +x ~/.claude/scripts/check-context.shThen register a Stop hook in ~/.claude/settings.json:
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "~/.claude/scripts/check-context.sh"
}
]
}
]
}
}One condition is mandatory: auto-compact must be off (/config > Auto-compact > false), or Claude Code may compact before the hook gets a chance to fire. Compared with auto-compact, this approach is deterministic and fast: the same conversation always cuts to the same result, and your real messages stay intact instead of being summarized.
Where do old conversations live?
Claude Code keeps your entire conversation history on your own machine, in ~/.claude/projects/. Each project gets a folder named after its path, with / turned into -. For example, a project at /Users/yk/Desktop/projects/claude-code-tips stores its history in:
~/.claude/projects/-Users-yk-Desktop-projects-claude-code-tips/
Each conversation is a .jsonl file, so basic bash is enough to search them:
# Find all conversations mentioning "Reddit"
grep -l -i "reddit" ~/.claude/projects/-Users-yk-Desktop-projects-*/*.jsonl
# Find today's conversations about a topic
find ~/.claude/projects/-Users-yk-Desktop-projects-*/*.jsonl -mtime 0 -exec grep -l -i "keyword" {} \;
# Extract just the user messages from a conversation (requires jq)
cat ~/.claude/projects/.../conversation-id.jsonl | jq -r 'select(.type=="user") | .message.content'The lazier route is to ask Claude Code directly: "What did we talk about regarding X today?" and it will search the history for you. Everything above leans on this tip: because old conversations never disappear, you can start new sessions freely without fear of losing track.
Which option fits when the context is nearly full?
| Option | What survives | Fits when |
|---|---|---|
/clear, new session | Nothing | You are switching to an unrelated topic |
/compact | A summary Claude writes itself | You need room fast and the details matter less |
HANDOFF.md | A handoff document you reviewed | A long task with dead ends worth recording |
/branch, --fs | The full conversation up to the fork | You want to try another direction without losing the thread |
| Half-clone | The later half (or quarter), verbatim | A long conversation where the newest part matters most |
If you adopt only one habit, make it the handoff file. It forces you and Claude to state plainly where the task stands, and that is exactly what a fresh context needs to do well.