# Atlas error: Compaction parent must be a user message > Fix "Compaction parent must be a user message" by anchoring compaction on a user message id, or by letting Atlas choose the parent automatically. Atlas fails with "Compaction parent must be a user message: " because session compaction anchors the compacted history on a user message, and the parentID you supplied resolved to an assistant message instead. The fix is to anchor compaction on a user message id, not an assistant one, or to let Atlas pick the parent automatically instead of passing one explicitly. A session that contains no user message at all cannot be compacted. ## Symptom Compacting a session in Atlas fails and prints: Compaction parent must be a user message: . The compaction does not run and the session history is left untouched. ## Cause Session compaction in Atlas anchors the compacted history on a user message. When the supplied parentID resolves to an assistant message, compaction refuses rather than producing an incoherent transcript. ## Fix 1. Anchor compaction on a user message id, not an assistant one. 2. If you are driving compaction through the API, re-read the transcript and pick the nearest preceding user message. 3. Let Atlas pick the parent automatically instead of passing one explicitly. 4. Retry compaction; a session with no user message at all cannot be compacted. ## Why does Atlas report "Compaction parent must be a user message" Atlas reports "Compaction parent must be a user message: " for exactly 1 reason: the parentID handed to compaction resolved to an assistant message. Atlas session compaction anchors the compacted history on a user message, so an assistant anchor is rejected outright. Compaction in Atlas rewrites a long session into a shorter transcript that the model can still reason over. The compacted history has to hang off a coherent starting point, and Atlas uses a user message as that anchor. If compaction accepted an assistant message as the parent, the resulting transcript would begin mid-turn, with a model reply that answers a question no longer present in the history. Rather than emit that incoherent transcript, Atlas refuses and names the offending id in the error. The message is a guard, not a bug: the parentID you passed simply points at the wrong kind of message. ## How to fix the Atlas compaction parent error Fixing the Atlas compaction parent error takes 1 change: pass a user message id as the compaction parent instead of an assistant message id. If you are driving compaction through the API, re-read the transcript and pick the nearest preceding user message before retrying. Walk the session transcript backward from the id you originally passed until you reach a user message, and use that id as the parent. The nearest preceding user message is almost always the anchor you actually wanted, because it is the turn that started the exchange the assistant message belongs to. Once the parent is a user message, compaction proceeds normally. Be honest about the caveat: correcting the id fixes the refusal, but it does not change what compaction summarizes away, so re-check that the anchor you chose is the point in the conversation you genuinely want to keep. ## How to let Atlas pick the compaction parent automatically The simplest fix for the Atlas "Compaction parent must be a user message" error is to stop passing a parent at all. Atlas will pick the parent automatically when you do not supply one explicitly, which removes the entire class of assistant-anchored parentID mistakes in 1 step. Explicit parent selection is useful when you want to compact from a specific point in a session, but most callers do not need it. Omitting the parentID lets Atlas choose an anchor that already satisfies the user-message rule, so the error cannot occur. Reach for an explicit parentID only when you have a concrete reason to compact from a chosen turn, and when you do, validate the message role before you send it. Automatic selection is the recommended default for scripts and integrations that compact sessions on a schedule. ## How to verify the compaction fix worked Verify the Atlas compaction fix by re-running compaction on the same session after switching the parentID to a user message id. Success means 1 thing: the Compaction parent must be a user message error is gone, and the session compacts without the parentID guard firing again. Re-run the compaction call with the corrected anchor and watch for the absence of the error string. If the same message reappears with a different parentID in the angle brackets, the new id also resolved to an assistant message, so walk further back in the transcript. If compaction still refuses and the session genuinely contains no user message, that session cannot be compacted at all, which is the documented limit rather than a failure you can configure around. Start a new session in that case and carry the work forward. ## When a session cannot be compacted at all An Atlas session that contains 0 user messages cannot be compacted at all. Atlas compaction anchors the compacted history on a user message, so a transcript with zero user turns offers no valid anchor, and retrying with a different parentID will never succeed for that session. The uncompactable case is rare but real, and it is worth recognizing quickly instead of retrying in a loop. If you have already walked the transcript and confirmed there is no user message to anchor on, no parentID value will satisfy the check. Atlas is a terminal-native AI coding agent that fans out work to subagents which can run in the foreground or in parallel background sessions, and machine-driven sessions are the ones most likely to lack a user turn. Treat those sessions as short-lived and let them end rather than trying to compact them. ## FAQ ### What does "Compaction parent must be a user message" mean in Atlas? The error means the parentID you passed to Atlas session compaction resolved to an assistant message. Atlas anchors compacted history on a user message, so it refuses an assistant anchor rather than producing an incoherent transcript. ### How do I fix the Atlas compaction parentID error? Pass a user message id as the compaction parent instead of an assistant message id. If you drive compaction through the API, re-read the transcript and pick the nearest preceding user message, then retry. ### Can I let Atlas choose the compaction parent for me? Yes. Let Atlas pick the parent automatically instead of passing one explicitly. Omitting the parentID avoids the assistant-message anchor problem entirely and is the safest default for scripts. ### Why does Atlas refuse to compact from an assistant message? Atlas compaction anchors the compacted history on a user message. Anchoring on an assistant message would produce an incoherent transcript that begins with a reply to a question no longer in the history, so Atlas refuses instead. ### Is the Atlas compaction parent error a bug? No. The check is a deliberate guard in Atlas session compaction. It fires when the supplied parentID resolves to an assistant message, and the fix is to supply a user message id or to let Atlas select the parent. ### What if my Atlas session has no user message at all? A session with no user message cannot be compacted at all. No parentID will satisfy the anchor rule, so stop retrying, and start a fresh session instead of trying to compact that one. ### Which user message should I use as the compaction parent in Atlas? Use the nearest preceding user message relative to the id you originally passed. Walk the Atlas transcript backward from the rejected assistant message until you reach a user turn, then use that message id. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/compaction-parent-not-user-message Source of truth: aeo_pages row `/resources/troubleshooting/compaction-parent-not-user-message` (segment: Troubleshooting) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.