Most people blame the model when a coding agent starts forgetting rules and inventing file paths. One r/PromptEngineering post argues the opposite: the model is fine, and the context around it is the problem. Fixing that is faster than waiting for a smarter model.
The key idea
A long Claude Code session usually breaks the same way. Around turn ten, the agent drops earlier constraints, makes up paths, and slips on basic edits. The author’s claim is that this is rarely a reasoning failure. It comes from how project state, tool output, and old memories are packed into the prompt. Treat the context window as something you design, not a bucket you keep filling.
Old way vs. new way
The old way: let the agent list whole directories, print every log line, keep the full transcript, and find out about the bloat when the monthly bill arrives.
The new way: keep the context small and inspect it as you go. Each habit below swaps one dump for one compact thing.
The 13 habits, grouped by what they fix
Keep memory small and findable
- Retrieve memory by path. Log project decisions into repo markdown files, index them in a local SQLite cache, and have retrieval return only file paths and one-line abstracts. The model reads a full file only when the task needs it. The author uses a tool called agent-memory for this.
- Verify after compaction. Right after a context compaction, make the agent restate the ticket constraints before it touches any files.
- Compress subagent reports. A subagent should hand back three bullets of facts, not its whole command history.
Keep tool output from flooding the window
- Cap exploration depth. Limit directory scans to two levels so the agent asks for specific subfolders and doesn’t swallow four thousand file names.
- Compact search results. After exploratory grep, have the agent write a five-row markdown table of what it found, then discard the raw noise before editing.
- Use scratch files. Write big JSON or transformed data to /tmp/scratch.json and read only the line ranges you need.
- Truncate command output. Wrap shell and compiler commands so they return the first 20 and last 30 lines. One stack trace shouldn’t wash out everything else.
Protect cost and cache
- Guard the cache breakpoint. Keep static context (system instructions, tool definitions) byte-identical across calls. Put a timestamp, session counter, or volatile file list at the top and the cache discount is gone, so each turn costs more.
- Look at requests, not invoices. The author runs a local proxy inspector called cost-xray to see how each request is assembled turn by turn, including what tool schemas, thinking tokens, and cache-miss rewrites eat.
Keep the agent steady and safe
- Tag checkpoints in git. Make a local tag after each finished sub-task. If the agent drifts, it can diff against the tag and reset cleanly.
- Teach with contrast pairs. A rule like “don’t write monolithic functions” fades over a long session. Show the bad pattern next to the approved one instead.
- Unlink destructive tools in planning mode. While the agent is only analyzing, remove shell and database mutation tools so it has no ambiguity about what it may do.
- Gate sensitive data. For agents touching production data or customer tickets, use rule-based sanitizers (the post names phi-boundary-gate) to scan and redact prompts, retrieval chunks, tool arguments, and memory stores before anything reaches an external model.
How to start without doing all 13
- Pick the one that matches your pain. Surprise bills? Start with 8 and 9. Agents getting lost in big repos? Start with 4, 5, and 7.
- Change one habit for a full session, then compare how many turns the agent stays sharp.
- Add a second habit only after the first one sticks.
A fair counterpoint
One commenter pushed back that these are prompt hygiene and don’t solve the deeper issue: you still lack a persistent, queryable state store that survives compaction. That’s a reasonable point. Habits 1, 2, and 10 are the closest thing here to a real state layer, and the rest mostly slow the decay. Another commenter said the cache mistake in habit 8 is one they see constantly, usually right before someone’s costs triple.
Your turn
Pick one habit from the list and try it on your next long session. Then tell us which one made the biggest difference, and what you do that isn’t on this list.
Source: r/PromptEngineering, post by u/Immediate_Zone_1920.
Frequently Asked Questions
Q: How often should you set a compaction checkpoint?
There is no magic number, though one reader runs a checkpoint about every 15 turns. The bigger lesson from the thread is what happens right after compression. Have the agent restate the active constraints and the file paths it plans to touch before it writes any code, and only continue once that summary matches your notes. If it still gets confused, checkpoint at task boundaries instead of on a fixed turn count.
Q: Should the checkpoint summary be a table or a paragraph?
Some users swear by a five-row markdown table because the grid forces the agent to cut what does not matter. Others prefer a single paragraph, which keeps the reasoning connected and reads more naturally. Try both on the same long session and keep whichever leaves fewer constraints forgotten two checkpoints later.
Q: Why do costs jump so much when the prompt cache breaks?
Prompt caching matches content from the start, so anything that changes early in the prompt, like a timestamp in the system prompt or reordered tool definitions, invalidates everything after it. Keep stable content such as the system prompt and tool schemas at the top, and put the things that change every turn at the end. A per-request token view like the cost-xray proxy from the post will show whether the cache is actually hitting.
Q: Do you need a real database, or are markdown files enough?
One commenter argues that prompt tricks are not enough and that state belongs in a queryable database that survives compaction. The original approach already sits partway there, since decisions live in repo markdown files with a SQLite index that the agent queries instead of re-reading the transcript. For a single project, that may be all you need. For many agents sharing state or heavy concurrent writes, a real database starts to earn its keep.
13 context engineering lessons learned from running long-term agents across large repos
by u/Immediate_Zone_1920 in PromptEngineering