--- title: More replies below (a count of what you have not read yet) --- # More replies below indicator ## 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](../../src/renderer/src/features/sessions/session-scroll-math.ts); the bottom-of-viewport sense is `getDomBottomMessageIndex` in [scroll-adapter.ts](../../src/renderer/src/features/sessions/scroll-adapter.ts) (the symmetric twin of the existing top-of-viewport sense). - [useSessionScroll.ts](../../src/renderer/src/features/sessions/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](../../src/renderer/src/features/sessions/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](../../src/renderer/src/features/sessions/session-scroll-math.ts), wired in [useSessionPanel.ts](../../src/renderer/src/features/sessions/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](../../.claude/memory/contracts/session-scroll-contract.md) § "More replies below signal". ## Related ### Related - [scroll-position-memory.md](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](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.