More replies below (a count of what you have not read yet)

What it is

What it does

When you reopen a session that has produced several messages since you last looked, Omniscio auto-scrolls you onto the most important unread reply (the "buried real reply" the scroll picker chooses). Below that landing point there are often MORE real replies — but some of them sit under collapsed, muted one-line markers ("Waiting on a background process", "Background check-in", and woken "nothing to do here" no-ops). Those muted markers look like the end of the thread, so it is easy to stop scrolling and miss real replies further down — including a decision the agent is blocked waiting on.

The more-replies-below indicator is a quiet pill that fixes this. It sits in the session's bottom-right scroll controls (the same cluster as the up-arrow and the jump-to-bottom arrow) and shows a downward arrow with a count — e.g. "↓ 3 more replies" — whenever real replies are hidden below your current scroll position. It appears even when the only thing visible at the bottom of the screen is a wall of muted markers, so the collapsed markers can no longer masquerade as the end of the conversation.

Where to find it

At the bottom of a session's message view, just above the usual jump-to-bottom arrow. It is on by default and can be turned off in Settings → Sessions → "Show 'more replies below' indicator".

How it behaves

What counts (and what doesn't)

The count is real replies only. Omniscio already classifies each agent turn as either a substantive reply (a genuine answer you would read) or muted filler — background check-ins, auto-wait notices, "waiting on a background process" sentinels, and woken "nothing to do here" no-ops. The indicator counts ONLY the substantive replies that sit below where you are looking. So:

• A run of muted markers below the fold never triggers the pill and never inflates the count.
• The reply you are currently looking at is not counted — only replies further down.
• As you scroll down past each real reply the count ticks down; when none remain below, the pill disappears.

Because Omniscio keeps no per-message "read / unread" memory for a session, "below" is positional: it means real replies below your current scroll position, recomputed live as you scroll and as new replies arrive — not a stored unread count.

Clicking it

A single tap scrolls you to the top of the next real reply below — reading forward, one reply at a time — rather than jumping straight to the very bottom (which would skip past the buried replies you are trying to reach). Repeated taps walk you down through them in order; on the last one it lands at the bottom and the pill goes away.

If you'd rather skip straight to the latest message, the pill also takes a deliberate jump gesture (added 2026-08-04): press-and-hold it (mouse or finger — the desktop mouse hold was fixed 2026-08-24), double-tap it quickly, or on a computer Shift/Ctrl/Cmd-click it — any of those glides you straight to the newest message. This mirrors how the up-arrow's press-and-hold already jumps to the top of the thread. A normal reading pace (a tap every few seconds as you read each reply) never triggers the jump — only a fast double-tap does — so tapping to read forward and holding/double-tapping to leap to the end stay cleanly separate.

When the only content below the fold is muted filler (no real replies), the pill does not show — the plain jump-to-bottom arrow you already had takes over as usual.

The setting

On by default. Turn it off in Settings → Sessions → "Show 'more replies below' indicator". With it off, the session view is byte-identical to before: you get the plain jump-to-bottom arrow and nothing else.

For agents

Where it lives in code

• The count math is the pure, unit-tested helper computeBelowSignal in session-scroll-math.ts; the bottom-of-viewport sense is getDomBottomMessageIndex in scroll-adapter.ts (the symmetric twin of the existing top-of-viewport sense).
• useSessionScroll.ts folds the count into the existing throttled scroll handler (read-only — it never moves your scroll on its own) and exposes the click action; ScrollNavButtons.tsx renders the pill.
• The "which replies are real" set comes from collectSubstantiveFinalReplyIds — the same classifier the auto-scroll picker uses — then intersected with the replies that actually render a bubble (renderedAnchorIds, the collapse-aware fold output) and mapped to on-screen positions by the pure buildBelowReplyTargets helper in session-scroll-math.ts, wired in useSessionPanel.ts. That intersection is what guarantees a reply the view folds into a muted marker (a "Background check-in", an "Auto-waited" notice, a woken no-op) is never counted — the count follows the render fold directly, so the two can never drift.
• The setting is moreRepliesBelowIndicatorEnabled. Full mechanics + the virtualization-safety reasoning: session-scroll-contract.md § "More replies below signal".

Related

Related

• scroll-position-memory.md — how Omniscio decides WHERE to drop you when you reopen a session (the auto-scroll onto the key reply that this indicator complements, and never changes).
• interrupted-sessions-section.md — the background / interrupted work whose "Background check-in" and "Waiting on a background process" markers are exactly the muted rows this indicator sees past.