Lost in Context Compaction: When LLM Systems Drop Side Constraints
When a long session is replaced by a summary, does the summary keep the rules the user set, and does the model still follow them?
key idea what the paper found what is lost, or a limit
chapter 1
The question in one picture
Figure 1 from the paper Figure 1 open full size
The user asks for suggestions and adds a rule: “Don't act until I tell you to.” The agent follows it.
The session gets too long, and a summary replaces it. The summary keeps the goal.
The rule is not in the summary.
The user says “continue”. The agent deletes 10 emails without asking.
A user asks an agent to go through their inbox and suggest what to delete. They add one rule: “Don't act until I tell you to.” The agent follows it. §2
As the session grows long, the system replaces it with a summary so the agent can keep working. This summary keeps the goal. The rule is gone. When the user says “continue”, the agent deletes emails. Figure 1
The answer, in short
The authors ran the inbox task 100 times. Before the summary, the agent deleted email without approval in 0 sessions. In how many sessions do you think it did so after the summary?
The part below opens after your guess.
After the summary, it deleted email without approval in 30 of 100 sessions. In 28 of those 30, the summary had dropped the rule. §2 Restating the rule after the summary cut this to 13 sessions. Table 1
The paper then tests this on a larger scale. Summaries kept 17% of the planted rules on average. A small fix, kept apart from the summary, keeps over 90% of them. Abstract
The summary in the picture is accurate about the task. Why does the agent still go wrong?
The summary keeps the goal and drops the rule about how to reach it. The agent can keep working without the rule, so the loss does not show until it acts. §1
Restating the rule right after the summary cut deletions from 30 to 13 sessions. What does that suggest?
That the missing rule explains much of the harm, though not all of it. The rest went wrong even with the rule restated. §2
chapter 2
What you need first
1. A model can only read so much at once
A model's context window is the most text it can read at once. Agents that use tools fill it fast, because each tool result is added to the session. §1
When a session nears that limit, many systems use context compaction: a compactor writes a summary, and the summary replaces the history. The summary is far shorter, so what it keeps matters. §1
2. Summaries are built to keep the task going
Compactors focus on task continuity: the goal, the work so far, and the next steps. §1 Users also give rules about how the work should go. The paper calls such a rule a Side Constraint. It keeps applying for the rest of the session, until the user changes it. §3
“Show me the draft before sending anything from now on” is a Side Constraint. Dropping it leaves the task intact. It changes which actions are acceptable. §3
3. A model can grade text
Checking thousands of summaries by hand is slow. The paper uses LLM-as-a-judge: a strong model reads each summary and says whether the rule is still there. §4.4 A person checked 50 of its calls and agreed with all 50. Limitations
Why might a summary keep the goal but drop a Side Constraint?
Name a Side Constraint that is not a ban on an action.
Many fit. One from the paper: “Always do a web search before answering.” It controls how the model reaches an answer. §3
chapter 3
What the paper does
The paper builds ConPACT, a test set for SCs under compaction. §1
Figure 2 from the paper Figure 2 open full size
Five kinds of SCs: Action, Information, Process, Preference and Output. There are 15 example rules, three of each kind.
Each rule can get extra words: “This is an important constraint” and “For the rest of this session”.
The rule is planted in the first, middle or last user turn of a long session, or in several turns.
After the summary is written, two checks: is the rule still in it, and does the model still follow it?
A second source has no planting: real rules written in GitHub issues.
The authors wrote 15 rules, three of each of five kinds. Each rule is planted in a long session of about 100K tokens. §4.2 §4.3 The settings are real chats (WildChat), an agent using tools (Hermes Agent), and long web research (OpenResearcher). §4.2
The paper varies two things about the rule. Its injection location is the first, middle or last user turn, or several turns. §4.3 Its framing adds “This is an important constraint” or “For the rest of this session”. §4.3 A second source, SWE-Natural, uses 126 real rules from GitHub issues, with the agent sessions that resolved them. §4.2
Two scores
Retention asks whether the summary still contains the rule, in any wording. A model grades it. §4.4
Compliance asks whether the model still acts by the rule. After the summary, the model gets a probe: a request with one answer that keeps the rule and one that breaks it. §4.4
The paper runs the same probe on four versions of each session. The upper bound is the summary with the rule pasted right after it. §4.4
Four versions of the same session, one test request §4.4
The model reads a context, then gets a probe: a request with one answer that keeps the rule and one that breaks it.
Without the rule, the model still picks the rule-keeping answer some of the time. That is the floor.
The real case: the rule was in the session, then the summary replaced the session.
The best case: the summary, with the rule pasted right after it. That is the ceiling.
The paper combines three of these results into one number, effective retention. It is 1 when the summary keeps the rule's full effect on behavior, and 0 when it keeps none. §4.4
The formula, in words
Take the rate of rule-keeping answers after the summary. Subtract the rate with no rule at all. Divide by the same gap for the upper bound: its rate minus the no-rule rate. §4.4
Subtracting the no-rule rate removes answers that keep the rule by chance. Dividing by the upper bound gap compares the summary with the best it could do. §4.4
Why measure compliance and not only retention?
Why subtract the no-rule run in effective retention?
Without the rule, the model still picks the rule-keeping answer some of the time. Subtracting that rate counts only the rule's own effect. §4.4
chapter 4
What they found
Summaries keep few rules
Across all the summarizers and settings the paper tested, what share of planted rules do you think the summaries kept, on average?
The part below opens after your guess.
The summaries kept 17% of the planted rules on average. Abstract The tests compared six methods. Two are simple: keep only the last five turns, or drop less useful words. Four ask an open model, such as gpt-oss-120b, to write the summary with a published prompt such as the Pi prompt. One paid model, GPT-5.4-mini, was tested on longer sessions. §5
Figure 4 from the paper Figure 4 open full size
Left: the share of rules still in the summary. Keeping only the last five turns, or a tool that drops single words, keeps almost none.
In the chat setting, the open models keep at most 3.3%.
The strongest summarizer, GPT-5.4-mini with the Pi prompt, ranges from 98% in one setting to 6.7% in another.
Right: effective retention. No open summarizer gets above 27.8% of the possible effect.
The real rules from GitHub fared a little better. Still, no summarizer kept more than 28.6% of them. §5.1 In some sessions the agent had repeated the rule while working, so it appeared again later. §5.1
Where the rule sits matters
A rule is planted in the first, middle or last user turn before the summary. Where do you think it is kept most often?
The part below opens after your guess.
For most summarizers, a rule in the last user turn was kept most often. §5.3
Figure 7 from the paper Figure 7 open full size
Top row: the rule is in the first user turn. Most summarizers keep almost none of these.
Bottom row: the rule is in the last user turn. Most summarizers keep it more often.
Keeping the last five turns keeps a last-turn rule in chat every time, because the rule falls inside those five turns.
The authors suggest a reason. The summary instruction comes right after the session. A rule near the end sits closest to that instruction. §5.3 This differs from earlier reading tests, where facts in the middle were found least often. §5.3
Length, framing and kind of rule
- Length. Shorter sessions kept more rules. One setting reached about 90% at 10K tokens and fell as sessions grew. §5.2
- Framing. “This is an important constraint” helped more than “For the rest of this session”. Using both added about 1.3% on average over one alone. §5.3
- Kind. Rules about how to reach an answer were kept least often. Even the best case lost nearly two thirds of the rules. §5.3
A rule list kept outside the summary
The fix leaves the compactor alone. A small model reads each user message and copies any rule into a list. It does not read the agent's turns or tool output. At compaction, the list is placed after the summary. The paper calls this the SC extractor, and the list the SC registry. §5.4
The SC extractor, beside the summary §5.4
The usual path: a compactor turns the long session into a summary.
A separate small model reads only the user's messages. When one holds a rule, it adds the rule to a list.
At compaction, the list is placed after the summary. The compactor itself is unchanged.
The SC registry kept 90.3% to 95.1% of rules across the three settings. Averaged over the six methods, the summaries alone kept 1.1% to 11.6%. Table 4 With the list added, compliance rose to 93.4% to 96.3%, close to the upper bound. §5.4
The SC extractor needs no training. On the chat setting, with many user turns, it took at most 12.93 seconds per 100K tokens. §5.4
Why might a rule in the last user turn survive more often?
The summary instruction comes right after the session, so a late rule sits closest to it. The authors support this with a shorter-session test, but they call it a hypothesis. §5.3
The SC extractor reads only user messages. Why does that help, and what can it not see?
User messages are few and short, so the scan is fast and focused. It cannot see rules that appear only in the agent's own turns or in tool output. §5.4
chapter 5
What this does not show
The paper states these limits itself. Limitations
- One event at a time. Each test measures a single summary. Shorter sessions kept more rules, but summarizing earlier means summarizing more often. The paper does not test that trade-off over a whole session.
- Large windows are untested. The paid model could not be run near its full window; the service returned errors. One run at 220K tokens cost about 800 USD.
- Missing scores. Effective retention needs a run with the full session and no rule. It is missing for the paid model and for SWE-Natural, where the sessions were made with the rule present.
- Kept is not followed. The conclusion notes that keeping a rule in the prompt does not guarantee the model will follow it. §7
How the scores were checked
The SC extractor only reads user messages. In a coding session, a rule can come from a file the agent opens, such as a project's instructions. How would those rules fare? This is not from the paper.
The paper tests one summary at a time. Why might a real session be worse?
A long session may be summarized several times. A rule dropped once does not come back unless someone repeats it. The paper does not test repeated summaries. Limitations
Is a rule kept in the summary enough? What does the paper say?
No. Keeping it as text does not guarantee the model follows it. The authors name this as future work. §7
keep it
This page has 10 check-yourself questions. The review page asks them again after 1, 3, 7 and 21 days, one at a time. You can also download them for Anki.
chapter 6
Words to know
Hover or tap any underlined word on the page to see its entry. These are the terms this page uses, in the order it introduces them.
- context window
- The most text a model can read at once. A long session can fill it."But open-weight models and API services specify a maximum context window, and when a session approaches that limit, a common approach is to compact the prior context" (§1)
- context compaction
- Replacing a long conversation with a short summary, so the session can keep going."A compactor takes the conversation history as input and produces a summary that replaces it, reducing context pressure while preserving context for subsequent turns" (§1)also called in the paper: context compression
- compactor
- The method, usually a model with a prompt, that writes the summary."A compactor takes the conversation history as input and produces a summary that replaces it" (§1)
- task continuity
- What a summary usually keeps: the goal, what has been done, and what to do next."However, compactors prioritize task continuity, preserving objectives, working state, and next steps" (§1)
- Side Constraint (standing rule)
- A rule the user gives about how to do the task, which keeps applying for the rest of the session."We define a Side Constraint (SC) s as a user-issued requirement or preference that governs how an LLM system carries out a task and remains applicable to subsequent relevant responses or actions within the session." (§3)
- LLM-as-a-judge
- A language model asked to grade something, here whether the summary still holds the rule."we prompt GPT-5.4 as LLM-as-a-judge to compute" (§4.4)
- ConPACT
- The paper's test set: rules planted in long sessions, then checked after the summary is written."To quantify this loss, we introduce ConPACT, an evaluation suite organized along four orthogonal axes" (§1, §4)also called in the paper: CompInt
- injection location
- Where in the long session the rule is planted: first turn, middle turn, last turn, or several turns."We instantiate four controlled injection conditions that vary the location and multiplicity of s in the context" (§4.3)
- framing
- Extra words around the rule: “This is an important constraint” (Strict) and “For the rest of this session” (Direct)."For injected SCs, we vary each example along two binary framing attributes" (§4.3)
- SWE-Natural
- Real rules written by people in GitHub issues, with the coding-agent sessions that fixed those issues."SWE-Natural: 126 naturally occurring constraints from GitHub issues, paired with the 90K–110K-token coding-agent trajectories that resolved them." (§4.2)
- retention
- Whether the summary still contains the rule, in any wording."where 1 indicates s is semantically present in the compacted context" (§4.4)
- compliance
- Whether the model still acts by the rule when a later request tests it."Beyond evaluating the semantic presence of SC in the output context, we further assess its behavioral compliance." (§4.4)
- probe
- A later request that tests the rule, with two answers: one that keeps the rule and one that breaks it."For each injected SC, we manually construct a probing question-answer pair formatted as a multiple-choice question (MCQ)" (§4.4)
- upper bound
- The test where the rule is pasted right after the summary: the best a summary could do."the SC is appended after the compacted context, immediately before the probing query, establishing the maximum compliance attainable under the compacted-context setup" (§4.4)
- effective retention
- How much of the rule's effect on behavior survives the summary, from 0 (none) to 1 (all)."we baseline-correct the Compacted compliance by the Uncompacted w/o SC compliance and normalize against the upper bound, yielding effective retention" (§4.4)
- SC extractor (rule keeper)
- A small model that reads each user message, copies any rule into a list, and adds the list after the summary."We propose an online SC extractor for LLM systems. We decompose a long context into turns and only extract SC from user turns" (§5.4)
- SC registry (rule list)
- The running list of rules the extractor has found."employing a Small Language Model (SLM), Qwen3.5-9B, as the extractor E that maintains an SC registry" (§5.4)
- WildChat
- Real chats between people and ChatGPT. The paper's chat setting."WildChat: anonymous conversations between online users and ChatGPT (GPT-4 and GPT-3.5 variants, without tool use or reasoning), serving as the multi-turn chat scenario" (§4.2)
- Hermes Agent
- Recorded sessions of an agent using tools. The paper's tool-use setting."Hermes Agent: trajectories of the Hermes Agent on tool-calling, multi-step reasoning, and coding tasks, serving as the multi-turn tool-use scenario." (§4.2)
- OpenResearcher
- Long web-research sessions with one user request. The paper's research setting."OpenResearcher: long-horizon deep research trajectories with a minimal browser tool set (search, open, find), serving as the long-horizon research scenario" (§4.2)
- gpt-oss-120b
- An open-weight model from OpenAI. The paper uses it as the inbox agent and as a summarizer."We prompt a gpt-oss-120b agent to review the inbox and suggest deletions" (§2, §5)
- Pi prompt
- The summary prompt of Pi, an open-source coding agent. The paper also uses Anthropic's prompt."We use the Pi compaction prompt with gpt-oss-120b, consistent with the email-deletion incident." (§2, §5)
- GPT-5.4-mini
- A paid OpenAI model, the strongest summarizer the paper tests."We additionally evaluate GPT-5.4-mini on 220K-token contexts (N=300)." (§5)