Try this first

Have a long conversation with Rover — twenty turns of genuine back-and-forth, not just tool
calls.

Now clearing will not save you. There are no large tool results left. The conversation itself
is the bulk, and every turn of it might matter.

What compaction does

It replaces the earlier part of the conversation with a summary of that part, written by the
model, and keeps going.

You can do this yourself — and in a moment we will argue you usually should. Some providers
also offer it as a feature that triggers automatically as the conversation grows.

If your provider offers it, read the rules carefully

Automatic compaction is convenient and it has a sharp edge, which is worth seeing once even if
you never use the feature.

When compaction happens, the provider’s reply contains more than text — there is a marker
recording what the compacted history was replaced with, and it has to go back on the next
request. Keep only the text and you silently throw the marker away. The conversation then
appears to forget everything from the compacted section, with no error.

That is the same failure shape as Lesson 2.6 and the same fix as Lesson 1.6: append what
came back, not a piece of it. Any time a provider puts state in its reply, extracting one
field and discarding the rest will break something three turns later.

Because these features are provider-specific, versioned, and move faster than anything else in
this course, look up your own provider’s current documentation rather than trusting a code
sample — including one printed here.

What compaction costs you

It is not free, in two ways.

A model call. Something has to write the summary.

Detail, chosen by someone else. A summary is lossy by definition, and you do not control
what survives. The exact error message from turn four, the specific file path, the thing the
user said not to do — any of them can be summarised away.

That is the real risk. Not that it forgets everything, but that it forgets the one constraint
that mattered while remembering the general shape of the work.

Compact deliberately instead

Because of that, hand-rolled compaction is often better for a specific agent. You know what
matters in your domain; the summariser does not.

You already wrote this in Lesson 4.6:

messages.append({"role": "user", "content":
    "Summarise this session for a fresh start. Include: the original task, "
    "files changed and how, what failed and why, and constraints the user gave. "
    "Be specific about file names and error messages."})

That prompt names what must survive. It is the difference between a summary that keeps the
useful things and one that keeps the readable things.

Then rebuild the list with the summary at the front and the last few turns intact:

messages = [
    {"role": "user", "content": f"Earlier work on this task:\n\n{summary}"},
    *messages[-4:],
]

Keeping the recent turns verbatim matters. The summary carries the history; the last few turns
carry exactly where you are.

Which to use

Compaction trades detail for room, and you do not choose what is lost. When you know what
must survive, say so yourself.

Try this before the next lesson

Run a long session with automatic compaction on. Afterwards, ask about a specific detail from
early in the conversation.

Note what survived and what did not. Then do the same with your own summary prompt naming that
detail as important. The difference is the argument for writing your own.