Lossy compaction

Lossy compaction is shrinking an LLM's context window by summarizing its contents, intentionally discarding detail to preserve salient information. Think of it like saving a high-resolution photograph as a JPEG. You get a smaller file, but some original pixel data is gone forever, unrecoverable. In Claude Code, when conversation history, file reads, tool outputs, and other injected data overwhelm the model's working memory, lossy compaction condenses that sprawling narrative into a tight summary. This summary replaces the original, verbose history, freeing up valuable token space. It is a pragmatic trade-off: you sacrifice verbatim recall and granular specifics for continued conversation flow and reduced token costs. The goal is to keep the model focused on the current task without getting bogged down by every single word exchanged. This process is a core mechanism in Claude Code, where `/compact` explicitly triggers it, or it happens automatically when the context window nears capacity. The "lossy" part is key: information is not merely reordered or compressed without alteration; it is actively interpreted, distilled, and permanently left behind. It is a form of intelligent data reduction, where the LLM decides what is most relevant based on its heuristics and your explicit instructions. For instance, debugging a complex system, a lossy compaction might retain the core problem, the last few attempted solutions, and the current error message, while discarding verbose print statements from an hour ago or an initial, incorrect hypothesis. This allows the conversation to continue, but with a streamlined, less detailed memory of its past.

Lossy compaction is not lossless compression. It is not zipping up a folder of documents where every byte can be perfectly restored. Unlike a PNG image, which retains all its original data, a lossy compaction is more akin to a JPEG: once compressed, original, perfect detail is gone. You cannot "uncompact" to retrieve the exact wording of a previous error message, the precise sequence of steps you tried an hour ago, or the full output of an earlier tool invocation. It is also not a perfect memory. An LLM's summary is an interpretation, a best guess at what is important, filtered through its current understanding and biases. It will not remember every nuance, every side comment, or every specific line of code you pasted if it deems that information less critical to the overarching task. It is a generalist's recollection, not a court transcript. Furthermore, lossy compaction is not a substitute for starting fresh. If you are done debugging the authentication system and moving on to building a new feature, `/compact` is the wrong tool. Dragging a summarized history of the auth bug into a new feature build is inefficient and pollutes the new context with irrelevant historical baggage. It is also not a magic wand for infinite context. While it buys you more conversational runway, it does not eliminate the fundamental constraint of a finite context window. It just pushes the wall back a bit, at a cost. It is a tactical maneuver, not a strategic solution to context management. It will not fix a bloated context caused by massive MCP server definitions or skill bodies; it only addresses the conversation history itself. If your `/context` command shows your problem is primarily due to large skill definitions or extensive file reads, compacting the chat will offer minimal relief.

Imagine you are deep into a Claude Code session, fixing a tricky authentication bug in a React application. You have been at it for two hours. You have pasted five different error logs, tried three API calls, read `auth.js` and `user-model.ts`, and had a dozen back-and-forth exchanges with Claude. Your context window, visible with `/context`, is glowing red. If you just type `/compact`, Claude will take that entire sprawling history, error logs, code snippets, verbose explanations, its own detailed suggestions, and distill it into a concise summary. It might say, "User was debugging an auth bug in React. Initial attempts involved checking API calls and user models. Current focus is on JWT validation issues and token expiration." What is lost? The exact stack trace of the first error, the specific `fetch` call that failed, the precise wording of Claude's initial, incorrect suggestion. What is retained? The core problem, the general area of investigation, and the current hypothesis. This is lossy compaction in action.

A more controlled example: you are working on a database schema refactor. You have discussed table structures, foreign keys, and migration strategies for an hour, including specific SQL snippets and data type considerations. Before the context fills, you run `/compact keep the database schema and migration plan, specifically the changes to the 'users' and 'orders' tables`. Claude will prioritize retaining details about the schema and migration, potentially sacrificing less critical conversational detritus about your lunch break or a tangential discussion about ORM choices. This is like a photographer using a JPEG compression tool but specifically telling it to preserve skin tones at the expense of background detail. The loss is guided, but it is still loss. The specific `ALTER TABLE` commands discussed earlier might be summarized into "discussed table alterations," losing exact syntax. This is why a handoff to a markdown file, as suggested in the Brainy Papers article, is often safer for critical details.

You use lossy compaction, specifically Claude Code's `/compact` command, when you must maintain continuity within a single, ongoing task but your context window is getting tight. Think of a marathon debugging session where history of what you have tried and learned is essential for the next step, but the verbatim transcript is too much. If you are tracking a subtle memory leak in a large codebase, and you have been through dozens of file analyses and Claude's suggestions, `/compact focus on memory allocation patterns and garbage collection issues` is your friend. It keeps the core thread alive without forcing you to start from scratch. This is useful in long-running projects where context accumulates over hours. Proactive compaction is also smart. Hyperdev.matsuoka.com, for instance, found that compacting around 60% capacity, rather than waiting for 95%, led to better performance and reduced model "hallucinations." It is like trimming a bonsai tree regularly instead of letting it become an overgrown bush. The Claude Code team, through @trq212, advocates for `/clear` as the default, but acknowledges `/compact` has its place when "continuity matters."

However, never use lossy compaction when starting a new, unrelated task. That is what `/clear` is for. Do not drag the ghost of yesterday's database refactor into today's UI component build. It is inefficient and pollutes the new context. Avoid it when verbatim detail is non-negotiable. If you need to document a precise bug reproduction sequence, including exact error messages, specific code lines, and tool outputs, `/compact` will destroy that fidelity. In those cases, `/export` your conversation to a markdown file first, then `/clear`. Furthermore, if your `/context` command shows your window is mostly filled by MCP server definitions, skill bodies, or project CLAUDE.md files, compacting the chat history is like bailing out a sinking ship with a thimble while the hull is breached. It will not solve the real problem. Lossy compaction is a scalpel for conversation bloat, not a sledgehammer for systemic context issues. Never use it blindly without instructions if you care about specific details; a generic `/compact` lets Claude decide what is important, and its priorities might not be yours. For example, a blind compact might summarize a critical security vulnerability discussion into "discussed security issues," losing all actionable detail.

Lossy compaction trades granular detail for conversational momentum, making it a necessary evil for long tasks but a liability for precision.