Module log 

Condensing command output: keep what failed, drop what scrolled past.

Why this slicer earns its place first

Log output is the dominant term in the quadratic cost formula. A ten thousand line build log costs more tokens than every prompt in a flow put together, and almost all of it is noise — the same “Compiling” line four hundred times, with the three lines anyone cares about somewhere in the middle.

What is kept, in what order

The cap is spent in priority order, so that a small cap still produces something useful rather than the first n lines:

1. The command outcome. Exit status and timing, always, regardless of the cap. They cost a handful of tokens and they are the first thing anyone asks about a failed command. A slicer that dropped them to fit two more log lines would have optimised the wrong way.
2. A floor of head and tail lines. Failures cluster at both ends: what was invoked is at the top, the summary is at the bottom. A few of each are kept before anything competes for the budget.
3. Error lines, in the order they appeared.
4. Warning lines.
5. More head and tail, then anything else that fits.

Repetition is collapsed, not dropped

Consecutive identical lines become one line with a count. Consecutive rather than global, because collapsing repeats that were far apart would reorder the log and quietly imply the two occurrences were adjacent — and the gap between two identical errors is often the whole story.

What the model is told it did not see

Every count of what was dropped is reported. A model reading a condensate with no elision marker will reason as though it has the whole log; one that can see 9821 lines dropped knows to ask for the original, which is in the content store under Condensate::raw.

Structs

Dropped

What did not make it into the summary.

LogLine

One line of output, after consecutive repeats were collapsed.

LogSlicer

Condenses command and build output.

Enums

Level

How important a line looked.

Constants

LOG_SCHEMA

The schema a log condensate declares.