summary

How many lines, of what severity, from where, and which messages repeat — the shape of the noise before you go looking inside it. Also the cheapest check for whether anything went wrong.

Takes the same filters as search, origin and caller among them, so it can describe a slice as well as the whole ring. It answers in counts rather than lines, so order, context and group, which shape a list of lines, are refused rather than ignored.

Returns

field	meaning
matched	lines the filter selects
buffered	lines the ring currently holds
capacity	how many it can hold
dropped	lines evicted for capacity since the last clear
cursor	highest seq assigned — hand back to search as since
engine_cursor	the same, with your own tool traffic left out
mcp	held lines recording your own tool calls
counts	lifetime errors and warnings, which survive eviction
by_level	lifetime count per severity
by_type	count per subsystem
by_entity	count per entity, for the lines a script logged
repeated	the most-repeated message templates, most frequent first

by_type, by_entity and repeated are computed over the lines the filter selects, bounded by limit (default 2000). The lifetime counts and the ring figures come from the engine's own counters and are not bounded that way.

cursor is what makes incremental reading work: read it before an action, hand it back as since afterwards, and you see only what that action logged. engine_cursor excludes your own calls, so it stands still on an engine whose loop has stopped, however many times you poll it — which cursor does not, since the act of asking is itself logged.