Compact, Clear or Hand Off? Running Long Agent Sessions Without Burning Your Limit

This article first appeared on Medium: https://medium.com/@r3dtuxedo/compact-clear-or-hand-off-running-long-agent-sessions-without-burning-your-limit-21c26def6bae

Compaction and "continue" both re-read your whole conversation. Treat agent sessions as disposable and keep the state in files.

TL;DR

• Every turn re-sends the whole conversation. Prompt caching keeps that cheap only while the cache is warm: your first message after a break longer than the cache lifetime reprocesses your full context.
• Compaction on a cold cache is a full-price pass over everything you're about to throw away. When you want a fresh start instead of continuity, /clear costs nothing.
• Before you walk away, have the agent write a handoff file while the cache is still warm, then start the next session from that file. Run multi-day work as a series of tickets that each fit in one fresh context window.

A thread in r/ClaudeAI this week put the problem better than I could. A new Claude Code user on the Pro plan described it like this: their usage had just reset to 0%, Claude suggested /compact, they ran it, and usage jumped to 11% "without actually getting any work done." Another time, after a limit interruption, typing "continue" took them from 0% to about 40% almost immediately.

Neither of those is a bug. Both follow directly from how agent sessions are billed. Once you see the mechanics, the fix is a habit and not a setting: stop treating a session as the place where your work lives. The session is scratch space. The state belongs in files.

This article is about the session lifecycle: when to compact, when to clear, when to hand off, and how to run a task that spans days without dragging one giant conversation along. I'm deliberately not covering what fills your context before you type anything (system prompt, MCP tool definitions, memory files). That gets its own article.

The session is scratch space. The state belongs in files.

Every turn re-reads everything

An agent has no memory between API calls. Each turn sends the system prompt, the tool definitions and the whole conversation so far, including every file it read and every test log it printed. Prompt caching is what keeps this affordable: if the start of the request matches what the provider processed recently, that prefix is billed at a steep discount.

The numbers, from the official docs as of today:

Anthropic. The prompt caching docs list a default cache lifetime of 5 minutes, refreshed for free each time the cache is used. A 1-hour lifetime is optional. Writing to the 5-minute cache costs 1.25x the base input price, the 1-hour cache costs 2x, and cache reads cost 0.1x. On Claude Opus 5.5 and Sonnet 5.5, reads are 0.05x. For Opus 5.5 that's $4 per million input tokens, $5 or $8 for a cache write, and $0.20 for a cache read.

Claude Code picks the lifetime for you. According to its prompt caching page, the main conversation gets the 1-hour cache on a Claude subscription within your plan's included usage. It drops to 5 minutes once you're drawing on usage credits, and 5 minutes is also the default on an API key or a cloud provider. Subagents and compaction requests get 5 minutes unless you change it.

OpenAI. The prompt caching guide says that on GPT-5.6 and later a cached prefix stays reusable for at least 30 minutes after its last use. Writes cost 1.25x, reads 0.1x, and reads are 0.05x on GPT-6.1 Sol. In Codex on a ChatGPT plan, the rate card charges GPT-6.1 Sol 50 credits per million input tokens against 2.5 for cached input, with no charge for cache writes.

Here's what that means for a 400k-token Opus 5.5 conversation on API pricing:

• Next turn with a warm cache: 400k x $0.20/M = $0.08 of input.
• Next turn after the cache expired, with Claude Code writing a 1-hour cache: 400k x $8/M = $3.20. With a 5-minute write it's $2.00.

The same message costs 25 to 40 times more depending on whether you sent it before or after a coffee break. Subscription plans don't bill in dollars, but the Claude Code cost docs say plainly that your first message after a break longer than the cache lifetime "misses the cache and reprocesses your full context." That's the 40% "continue." A 5-hour limit window is much longer than a 1-hour cache.

A 5-hour limit window is much longer than a 1-hour cache, and much, much longer than a 5-minute one.

What /compact actually costs

Compaction replaces your history with a summary. To write that summary, Claude Code sends a separate request with your full system prompt, tools and history, and appends a summarization instruction. So the model reads the entire conversation one more time.

The docs give the honest version. While the cache is warm, that read mostly hits the cache, and a mid-session /compact "costs a fraction of what the context size suggests." After a break, "there is no cache left to read, so the summarization request reprocesses the full history as uncached input. This is why /compact costs the most when you resume an old session." The cost page adds the line I'd tape to my monitor: "When you want a fresh start instead of continuity, /clear costs nothing."

So compaction isn't always expensive. Compaction on a cold cache is a full-price pass over everything you're about to throw away. That's the 11%.

There's a quality cost too, and no setting fixes it. A summary decides what mattered, and it decides on its own. Another r/ClaudeAI thread from a long-form fiction writer shows what that looks like: nuance, characterization and earlier decisions got stripped every time the conversation compacted. Claude Code re-injects your project CLAUDE.md from disk and re-reads up to five recently modified files after compaction. Everything else, including the reasons behind your decisions, survives only if the summary happened to keep it.

Compact, clear or hand off

This is the decision rule I use now.

Compact when you're mid-task, the cache is warm, and the history you'd drop is genuinely dead weight: exploration you've finished, logs you've read. Do it at a natural break, not when auto-compaction fires halfway through an edit. Pass a focus: /compact keep the failing test names and the migration plan.

Rewind instead of compacting if you went down a path you want to abandon. Claude Code's /rewind truncates back to a prefix that's already cached, so it doesn't build a new one.

Clear when the next task is unrelated. /clear my-feature names the old conversation so /resume can find it later, and the new session starts empty.

Hand off when the task continues but the session shouldn't. That covers stopping for the day, hitting a limit, the context getting long enough that the agent starts repeating itself, or any time you're about to walk away for longer than the cache lifetime. Ask the agent to write a handoff file while the cache is still warm, which is cheap because it's reading from cache. Then /clear, and start the next session from that file.

The trick is timing. The handoff costs a few cents written before you leave and a few dollars of re-reading if you try to resume afterwards. In Claude Code, /usage shows a prompt cache line telling you whether the cache is currently warm or cold and which TTL applies (v2.1.251 or later). Check it before you decide.

The decision rule as a chart. Check the cache before you pick.

One more Claude Code detail: if you leave a long conversation idle in the terminal on the 1-hour TTL, it can compact shortly before the cache expires. If you'd rather hand off yourself, set idleCompaction to false (v2.1.290 or later). /autocompact sets the threshold for automatic compaction.

A HANDOFF.md you can copy

The handoff file is not a transcript. It's what a competent colleague would need to pick up the work in five minutes. Here's the template I use:

# HANDOFF: <task name>
Updated: <date/time>  Branch: <branch>  Last commit: <sha>

## Goal
One or two sentences. What "done" means and how we will check it.

## State
- Done:
- In progress (exact point where I stopped):
- Not started:

## Decisions (and why)
- Chose X over Y because ...
- Do NOT do Z: tried it, failed because ...

## Ruled out
- Hypothesis / fix that was tried and did not work, with the evidence.

## Next step
The single next action, concrete enough to start without asking.

## Files that matter
- path/to/file: why it matters
(Reference plans, issues and ADRs by path. Do not paste them.)

## How to verify
Commands to run: tests, build, the reproduction.

## Open questions for the human

The prompt that fills it:

Write HANDOFF.md for a fresh session that has none of this conversation.
Use the template. Be specific: names, paths, commands, evidence.
Include what we ruled out and why. Under 400 words. No code dumps.

The "Ruled out" section is the one people skip, and it matters most. In a r/ChatGPTPro thread on long Codex iterations, one commenter asked exactly the right question: if every checkpoint is a fresh chat, something has to tell the next one what was already tried, "or it'll happily suggest the fix that failed two checkpoints ago."

What each section of the handoff is for.

If you want this packaged, my skills repository has a handoff skill that writes this kind of document for Codex and Claude Code. It references existing plans, issues and commits instead of duplicating them, and it redacts secrets. It saves to the OS temp directory by default, which is fine for a same-day handoff. For multi-day work I keep the file in the repo instead, as described next.

Multi-day tasks are a series of tickets

The thread that convinced me to write this was a r/codex post asking how to keep a model reliable "for long-horizon tasks spanning 4–7 days." My answer is that you don't run a 7-day session. You run thirty short ones that share a filesystem.

The structure:

1. Split the work into tickets that each fit in one fresh context window. That's the sizing rule in the to-tickets skill in the same repo: vertical slices, each one verifiable on its own, each with its blocking tickets listed. One file per ticket, numbered in dependency order.
2. One progress file per ticket, for example tickets/07-auth-refresh.progress.md, using the handoff template. The agent updates it at the end of every session and whenever something gets ruled out.
3. A fresh session per ticket. The opening prompt is always the same: read AGENTS.md, read ticket 07 and its progress file, continue from "Next step".
4. Close a ticket with evidence, then commit. Tests pass, progress file says done, commit. The git history becomes your checkpoint log.
5. Stable rules go in AGENTS.md (or CLAUDE.md), not in chat. Build commands, conventions, the "never touch this directory" list. These files are read at session start, so when you change one, start a new session to pick it up. Claude Code says so explicitly: CLAUDE.md edits apply on the next /clear, /compact or restart.

This also makes the cache work for you instead of against you. Every fresh session starts with the same stable prefix (system prompt, tools, AGENTS.md), and the variable part is a few hundred words of handoff instead of a day of accumulated tool output.

Notes per tool

Claude Code. Use /clear (aliases /reset, /new), /compact [focus], /rewind, /resume, /autocompact, and /usage for the cache-warmth line. Claude Code reads AGENTS.md if a repo has no CLAUDE.md. On a subscription the main conversation's cache lives for an hour. On usage credits or an API key it's 5 minutes unless you set promptCacheTtl.

Codex. Use /new for a new chat in the same CLI session, /clear to reset the screen and context together, /compact, /resume, /fork and /status, which shows remaining context. In config.toml, model_auto_compact_token_limit sets when auto-compaction triggers and compact_prompt overrides the summary instructions. Codex builds its AGENTS.md chain once per run and stops at project_doc_max_bytes (32 KiB by default), which is one more reason to keep it lean.

OpenCode. Use /compact (alias /summarize) and /new (alias /clear). The compaction block in opencode.json has auto (default true), prune for dropping old tool outputs (default false) and reserved, a token buffer so compaction itself doesn't overflow. It reads AGENTS.md and falls back to CLAUDE.md, so one instruction file can serve all three tools.

Open-weight models. A lot of "the model keeps looping" reports are really context truncation. Ollama's context length docs set the default by VRAM: 4k tokens below 24 GiB, 32k up to 48 GiB, 256k above that. They recommend at least 64k for agents and coding tools, and Ollama's Codex integration page says the same. When a conversation overflows, Ollama drops messages from the front and keeps the system messages and the latest one. A GitHub issue documents that this happens with no warning in the response. The model loses what it already did, so it does it again.

OLLAMA_CONTEXT_LENGTH=64000 ollama serve
ollama ps   # check the CONTEXT column

Over the API, set num_ctx in options. Ollama's cloud models default to their maximum context, so if you're on cloud and still looping, look at tool-call formatting and sampling settings next. Either way, the checkpoint structure above matters even more with these models, because a ticket that fits comfortably in the window never gets truncated.

The habit

What changed for me isn't a setting. I stopped asking "how do I keep this session alive?" and started asking "what would the next session need to know?" Before I walk away, the agent writes the handoff while the cache is warm. When I come back, I start clean from the file. I compact only mid-task, at a break, on a warm cache. "Continue" after a limit reset is the one message I don't send anymore.

Sessions are disposable. Files aren't.

---

If this was useful, subscribe to Agents in Practice for one practical note on AI coding agents a week. Helping your team adopt Claude Code or Codex safely and without the surprise bill? I consult on exactly that: https://andre-burgstahler-9n5.pages.dev/.

This article was written with AI assistance and reviewed by the author.

Comments

[pang]

Cold-cache compact burns the limit for nothing — hand off to a file while the cache is warm, then start clean.