{"post":{"slug":"context-compaction-explained-2026","title":"Context Compaction Explained: Surviving Long Agent Sessions","excerpt":"An agent that runs for hours will outgrow any context window. Compaction summarises the history in place so the session keeps going. Here is how it works and where it loses things.","category":"ai","date":"August 12, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">A</span>n agent that answers one question never has a context problem. An agent that spends four hours refactoring a codebase has nothing but context problems. Every tool call adds output, every file read adds content, every reasoning step adds tokens, and the window — however large — eventually fills. What happens at that boundary determines whether your agent degrades gracefully or falls over.\n\nCompaction is the mechanism that handles it. When the conversation approaches a threshold, earlier history gets replaced by a summary of itself, freeing room while preserving the thread. The session continues. The details, some of them, do not.\n\n## What changed in 2026\n\n- **Compaction moved server-side.** It used to be something you implemented yourself — track token counts, call a summarisation prompt, splice the result back into the history. Providers now offer it as a request parameter, which removes the fiddly part and adds a subtle new failure mode.\n- **Thresholds became configurable rather than fixed.** Triggering at a set token count lets you tune when the quality cost of summarising is worth paying, instead of accepting a vendor default.\n- **The distinction from context editing hardened.** Two different operations, frequently conflated: one summarises, one deletes. Teams that use both deliberately get considerably better results than teams that reach for whichever they heard of first.\n- **Million-token windows did not make it obsolete.** They raised the ceiling and made long sessions economically painful well before they became technically impossible. Compaction is now as much a cost control as a capacity one.\n\n## Compaction vs context editing\n\n| | Compaction | Context editing |\n| --- | --- | --- |\n| Operation | Summarises earlier turns | Clears specific blocks outright |\n| What survives | A condensed account of everything | Everything except what you targeted |\n| Best for | Long conversational or reasoning history | Bulk tool results that are no longer relevant |\n| Loses | Detail and specificity | The cleared content entirely, by design |\n| Cost | A model call to produce the summary | Effectively free |\n| Reversible | No | No |\n\nThe rule of thumb worth internalising: if the content had a purpose that is now finished — a file you already read and acted on, a search result you already used — clear it. If it carries reasoning or decisions the agent still needs to honour, compact it. Deleting decisions produces an agent that contradicts itself; summarising bulk output wastes a model call to compress something you should have thrown away.\n\n## Wiring it up without losing state\n\nThe single most common implementation bug is subtle enough to survive code review. When compaction is active, the response comes back carrying compaction blocks alongside the usual text. Those blocks are how the provider represents the compressed history, and they must go back in your next request.\n\nIf your code does something like `messages.push({role: \"assistant\", content: response.text})` — extracting just the string, which is the natural thing to write — you have discarded the compaction state. Nothing errors. The conversation continues. The context simply grows as though compaction never ran, and you find out when you hit the wall you were trying to avoid.\n\nAppend the full content array instead. The same discipline applies to thinking blocks and tool-use blocks; treating a model response as \"the text it produced\" rather than \"the structured content it returned\" is a recurring source of quiet breakage. The observability practices in [LLM observability](/blog/llm-observability-2026) will surface it faster than reading code will — a token count that keeps climbing past your threshold is the giveaway.\n\n## What compaction reliably loses\n\nSummarisation compresses toward meaning, which means it discards precision first. In practice the casualties are consistent:\n\n**Exact identifiers.** File paths, ticket numbers, commit hashes, variable names. A summary says \"updated the authentication middleware\"; it does not say `src/middleware/auth.ts:142`.\n\n**Numbers.** Specific values get rounded, generalised, or dropped. If the agent measured something in turn 12 and needs the figure in turn 90, it may confidently recall a different one.\n\n**Negative constraints.** \"Do not touch the billing module\" is easy to summarise away, because summaries prioritise what happened over what was prohibited. This one causes real damage.\n\n**Ordering.** The sequence of events compresses into a narrative, and narratives smooth over the order in which things actually occurred.\n\nThe defence is to keep load-bearing facts outside the conversation entirely. A scratchpad file, a memory store, or a system-level instruction survives compaction because it is not part of the compacted history. Anything the agent must not forget belongs there, not in a message you hope the summariser respects. This is the same argument that motivates [context engineering](/blog/context-engineering-explained-2026) generally: what you put in the window matters less than what you keep out of it.\n\n## Common mistakes\n\n- **Appending only the text of the response.** The compaction blocks vanish and compaction silently stops working. Append full content.\n- **Compacting too early.** Every compaction costs a model call and loses detail. Triggering at 20% window utilisation burns both for no benefit.\n- **Compacting too late.** Waiting until you are one message from the ceiling means the summarisation itself may not fit. Leave headroom.\n- **Assuming the summary is faithful.** It is a model output, with the usual properties of model outputs. Critical constraints need to live somewhere else.\n- **Using compaction where editing belongs.** Paying a summarisation call to compress a 40KB tool result you will never reference again is pure waste.\n- **Never testing a compacted session.** Most agents are tested on short interactions and deployed on long ones. Run a session past the threshold deliberately and check what the agent still knows.\n\n## FAQ\n\n**Does compaction reduce my token bill?**\nIndirectly, and it depends. You pay for the summarisation call, then pay less per subsequent request because the history is smaller. On a long session that is a clear win; on a medium one it can be a wash. Combine it with [prompt caching](/blog/prompt-caching-explained-2026) carefully — compaction rewrites the prefix, which invalidates the cache at the moment it fires.\n\n**How is this different from an agent's memory?**\nCompaction is about fitting a single session into a window. Memory is about carrying knowledge across sessions. They solve adjacent problems and are often used together — [AI agent memory](/blog/ai-agent-memory-2026) covers the persistent side.\n\n**Can I control what the summary preserves?**\nSome implementations let you steer it with an instruction. Where available it is worth using, and the highest-value instruction is usually to preserve constraints and identifiers verbatim rather than to summarise them.\n\n**What happens if compaction fails mid-session?**\nYou get an error or a truncated context, depending on the provider. Long-running agents should treat it as a recoverable failure — checkpoint enough state outside the conversation that you can restart the session rather than lose the work.\n\n## Where to go next\n\nIf you are building agents that run long enough to need this, [AI agent observability](/blog/ai-agent-observability-2026) covers the traces that make compaction behaviour visible, and [agent token budgets](/blog/agent-token-budgets-2026) covers pacing the spend that long sessions generate. For the upstream question of what should be in the window in the first place, start with [context engineering](/blog/context-engineering-explained-2026).","hue":206,"metaTitle":"Context Compaction Explained: Long Agent Sessions","metaDescription":"How context compaction keeps long-running AI agent sessions alive, how it differs from context editing, and what information it reliably loses along the way.","keywords":["context compaction","llm context compaction","long running agent sessions","context window management","agent conversation history","context editing vs compaction","llm context overflow","agent memory management 2026"],"tldr":["**Compaction summarises old context instead of dropping it** — the model keeps a condensed record of earlier turns rather than hitting a hard wall or silently truncating.","**It is not the same as context editing** — editing *clears* stale tool results outright; compaction *compresses* them. Different tools for different waste.","**Server-side compaction requires you to pass the blocks back** — append the full response content, not just the text, or you silently lose the compacted state.","**Every compaction is lossy** — specific identifiers, exact numbers, and file paths are what disappear first, so pin anything load-bearing outside the conversation.","**Skip:** compaction for short request-response work. Under a few thousand tokens of history it adds a summarisation cost and solves a problem you do not have."],"readTime":"5 min read","wordCount":1200},"related":[{"slug":"context-compression-2026","title":"Context Compression: Keeping Long Runs Coherent","excerpt":"Agent conversations grow until quality drops and cost climbs. Here is how to compact context without losing what matters, and when to compress versus retrieve.","category":"ai","date":"July 11, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":218},{"slug":"context-engineering-explained-2026","title":"Context Engineering Explained 2026: Beyond Prompt Writing","excerpt":"Context engineering is the practice of deciding what information a model sees at inference time, not just how a prompt is phrased. Here is what it covers and why it now matters more than prompt wording alone.","category":"ai","date":"July 1, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":320},{"slug":"ai-token-limits-explained-2026","title":"AI Token Limits Explained in 2026: Context Windows and Costs","excerpt":"Token limits define how much text a model can read and write at once. This 2026 guide explains what tokens are, how context windows work, and how to manage both.","category":"ai","date":"July 5, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":305}],"sameCategory":[{"slug":"agent-cost-attribution-2026","title":"Agent Cost Attribution: Finding Where the Tokens Went","excerpt":"A single monthly API bill tells you that agents are expensive. It does not tell you which feature, which customer, or which retry loop is responsible. That gap is fixable.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":220},{"slug":"human-in-the-loop-agents-2026","title":"Human-in-the-Loop Agents: Where to Put the Approval Gate","excerpt":"Approve everything and the agent is a slow autocomplete. Approve nothing and you have handed irreversible actions to a system that can be talked into things.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":197},{"slug":"reasoning-effort-controls-2026","title":"Reasoning Effort Controls: Tuning How Hard a Model Thinks","excerpt":"Fixed thinking budgets gave way to effort levels, and the default is rarely the right setting. Here is how the dial behaves and where each level actually belongs.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":210},{"slug":"retrieval-metrics-explained-2026","title":"Retrieval Metrics: Measuring the Half of RAG That Fails","excerpt":"When a RAG system answers badly, the retrieval usually failed before the model ever spoke. Measuring generation quality alone hides that entirely.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":215}],"newer":{"slug":"config-as-code-explained-2026","title":"Config as Code: Getting Past YAML Sprawl","excerpt":"Configuration outgrew static files and templating produced a mess. Here is how typed and programmable config languages help, and when plain files are still right.","category":"code","date":"August 12, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":310},"older":{"slug":"crypto-tax-lots-2026","title":"Crypto Tax Lots: Why Your Basis Records Matter More Now","excerpt":"Which specific units you sold determines your gain, and reporting rules have tightened around how lots are tracked. Here is what to keep and why.","category":"finance","date":"August 12, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":292}}