Type
Bug
Problem / Value
When a user manually condenses a conversation after a task completes and then sends a new message, the condensation silently reverts. The full, non-condensed conversation history is sent to the API on the next request, even though the UI still shows the conversation as condensed. This causes token costs to escalate continuously, especially in auto mode where many sequential API calls are made against the un-condensed history.
Context
Affects all users who rely on manual condensation to manage long-running conversations. The issue occurs specifically when a task ends (e.g., after attempt_completion), the user triggers condensation, and then resumes the conversation. The UI correctly shows the condensation summary and allows expanding to view condensed content, giving the false impression that condensation is active. However, the underlying API conversation history has silently lost its condensed state — all original messages are restored and sent to the model on every subsequent request.
The root cause is in the task resume flow. After condensation, the summary message is the last message in history and has a "user" role (by design — the "fresh start" model). When the task is resumed, the resume logic strips the last user message to merge it with the new user's input. Because the summary IS the last user message, this removes it and creates a new regular user message without the condensation metadata. All previously condensed messages then become "orphaned" (their parent summary no longer exists), so the history filtering logic correctly restores them to active status — effectively undoing the condensation.
Reproduction
- Start a task that involves multiple tool calls and a meaningful conversation
- Let the task complete (e.g., via attempt_completion)
- Manually trigger "Condense Context" from the UI
- Observe the condensation summary appears in the UI (this works correctly visually)
- Send a new message to resume the conversation
- Expected: The API request uses only the condensed summary plus the new message
- Actual: The API request includes the entire original conversation history — all condensed messages are restored, token usage jumps back to pre-condensation levels
Constraints/Preferences
The fix should preserve the "fresh start" model where the summary is a user-role message, while ensuring the resume flow recognizes and preserves summary messages instead of stripping them. The solution should also handle edge cases like resuming when the last message after condensation is an assistant message (if post-condensation messages exist before resume).
Type
Bug
Problem / Value
When a user manually condenses a conversation after a task completes and then sends a new message, the condensation silently reverts. The full, non-condensed conversation history is sent to the API on the next request, even though the UI still shows the conversation as condensed. This causes token costs to escalate continuously, especially in auto mode where many sequential API calls are made against the un-condensed history.
Context
Affects all users who rely on manual condensation to manage long-running conversations. The issue occurs specifically when a task ends (e.g., after attempt_completion), the user triggers condensation, and then resumes the conversation. The UI correctly shows the condensation summary and allows expanding to view condensed content, giving the false impression that condensation is active. However, the underlying API conversation history has silently lost its condensed state — all original messages are restored and sent to the model on every subsequent request.
The root cause is in the task resume flow. After condensation, the summary message is the last message in history and has a "user" role (by design — the "fresh start" model). When the task is resumed, the resume logic strips the last user message to merge it with the new user's input. Because the summary IS the last user message, this removes it and creates a new regular user message without the condensation metadata. All previously condensed messages then become "orphaned" (their parent summary no longer exists), so the history filtering logic correctly restores them to active status — effectively undoing the condensation.
Reproduction
Constraints/Preferences
The fix should preserve the "fresh start" model where the summary is a user-role message, while ensuring the resume flow recognizes and preserves summary messages instead of stripping them. The solution should also handle edge cases like resuming when the last message after condensation is an assistant message (if post-condensation messages exist before resume).