Pi /compact: what the summary replaces
The shared session A shorter active history
This example uses a deliberately written summary. No model generated it, and the displayed counts are messages and saved entries—not measured token savings.
There are six messages saved. If I compact the inline branch, do the old messages disappear?
Compaction adds a summary entry and retains recent history for the active context. The original entries stay saved. In this example, a summary stands in for the shared opening; the inline question and answer remain after it.
Read the history at three points
Each view is projected from the same seven-entry record: six messages and one later compaction entry.
- Summary
Authored summary: a wait-list form needs an inline confirmation.
- You
Keep it inline and make the confirmation readable without colour.
- Pi
Announce “Request received” in a polite status region. Keep keyboard focus on Submit.
A written summary plus 2 retained messages. All 7 entries remain in the saved record.
That summary is shorter, but how do I decide whether it preserved the right things?
Compare decisions, not just length
The written summary preserves the original requirement for inline confirmation. It does not restate the exact first prompt or mention the modal experiment. In this path, the retained answer still specifies “Request received,” a polite status region and focus on Submit.
Now imagine those details had appeared only in older messages that the summary replaced. “Add confirmation” would be too vague to preserve a decision about focus or wording. Before continuing, identify the particular requirement that must survive and check whether it appears in the retained history, the summary or an authoritative project file.
A useful next message would be: “Keep the chosen inline design. Show Request received, announce it once without moving focus, and verify the current implementation before changing it.” That gives the next task an explicit contract. It does not claim that the summary is a complete transcript.
What this example intentionally does not measure
The summary text, retained boundary and token-count field in the fixture are teaching data. The site does not evaluate a model's summarization quality, predict a context threshold or estimate your bill. A real summary may omit or distort a detail even though the original entry remains in the saved session.
Is that the same as the summary Pi offers when I leave another branch?
They solve different problems. A branch summary can carry relevant work from the path you leave into the path you enter. Compaction shortens the history used for the active context. Neither should be read as proof that a proposed file change was made.
Considered is not implemented
The packet's separate branch-summary example says: “The modal alternative was considered, not implemented.” That is a written account of a choice. Replacing it with “The modal is implemented” would change the claim without changing a single project file.
When moving between branches, preserve both the decision and its status: proposed, tried, inspected or actually deployed. If the conversation conflicts with the current files, inspect the files before asking the agent to build on the claim.
When compaction does not complete
In real Pi, /compact requests compaction manually and can include instructions about what to preserve. Automatic compaction normally handles growing context according to your settings. Turning off automatic compaction does not remove the manual command.
A provider failure can prevent the summarization request from completing. Resolve the reported provider problem before retrying. Do not treat a failed attempt as evidence that a usable new summary exists; inspect the active session and the result. This page supplies no provider connection and cannot diagnose that request.
Sources and offline reproduction
See the pinned Pi session guide and buildSessionProjection implementation. The browser executes extracted native projection functions against an authored fixture; it does not execute the compaction model call.
Download the fixture and verification script. After unzipping, node verify.mjs checks the two branches, compaction and the separate branch-summary example without network access. Source hashes and the MIT license are included.