[Bug] Fixes for daemon crashes and performance slowdown with >20 running sessions

[paralin]

Affected area

Agent core, coding agent, daemon, kernel lifecycle, providers, and CLI

What happened?

We run paralin/prime-agent against upstream main. The fork has been rebased onto e319a66d and its former 93-commit development history has been consolidated into 40 topic commits. Each linked commit is intended to be independently reviewable as an upstream change.

The highest-impact production problems were:

• Large RLM trees repeatedly launched overlapping full-tree summary scans. With 774 persisted children we observed more than 300% CPU, about 2.3 GB memory, and thousands of duplicate file descriptors. Summary refreshes are now coalesced and passive topology/transcript work is cached. (summary refresh)
• Large transcripts duplicated parsing, indexing, snapshot context, and provider compaction histories in memory. Session reads are incremental, passive catalogs avoid resident hydration, initial UI work is bounded, inactive children are passivated under pressure, superseded native compactions stay disk-backed, and completed child kernels hibernate without limiting child concurrency. (large-session runtime)
• Failed or stale daemon workers could remain registered and become unreopenable. Recovery now reclaims dead, unowned, and stuck-live workers and validates the worker launch environment. (worker recovery)
• Snapshot identity was request-timing-dependent. Daemon and supervisor snapshots now use content identity. (snapshot identity)
• Worker send backpressure could hide request timeouts. Send and response promises are observed immediately without unhandled rejections. (worker timeouts)

Clean upstreamable commit series

Model routing and multi-agent execution

• Add routed model-role configuration
• Coordinate role-based RLM children across providers
• Add per-spawn RLM service tiers
• Add shared-kernel, bounded nested Act delegation
• Keep model switching session-local
• Prefer messaging existing RLM agents over spawning duplicates

Sessions, compaction, and performance

• Add provider-native Codex V2 compaction
• Keep large session framing and fallback responsive
• Add scratch-handoff compaction fallback
• Admit typed external kernel events into sessions
• Hide event-only sessions from saved-session catalogs
• Coalesce daemon summary refreshes
• Reduce large-session CPU and memory overhead
• Bind RLM heartbeats to durable sessions
• Keep legacy event sequences out of resume cursors

Daemon, RPC, launchers, and kernels

• Add an isolated foreground RPC harness
• Restore durable session context behavior
• Attach bare launchers to recent sessions and preserve source launcher lifetime
• Reclaim dead and stuck daemon workers
• Key daemon and supervisor snapshots by content
• Skip idle eviction while mutations are in flight
• Recover unexpectedly exited kernels
• Keep worker request timeouts observable during send backpressure
• Restore versioned development snapshots

Providers and authentication

• Add OpenRouter session routing, attribution, and Responses transport
• Rotate configured Codex homes
• Add xAI Grok OAuth
• Support loopback Codex bearer tokens
• Cap provider retry delays
• Recover missing and empty terminal responses
• Add the Venice provider

Settings, goals, prompts, and UX

• Hot-reload settings files
• Pause autonomous goals while externally blocked
• Streamline prompts and bundled skills
• Add elapsed message timestamps
• Fold elapsed markers into tool status
• Remove the obsolete /update command

Fork maintenance

• Document fork source setup
• Streamline fork CI workflows
• Document fork publication policy

The rewritten tip is 6c4cfc25. npm run check passes on the resulting tree.

Prime Agent upstream base

e319a66d7351c75abe7f040d02d9a8d6e25028e9

Environment

macOS 27.0

[sankks11]

Independent 0.8.1 reproduction confirms the diagnosis here. I posted the detailed FD and I/O measurements on #1536: #1536 (comment)

The worker reached about 21,000 FDs, 7.5 GiB RSS, and four CPU cores while repeatedly scanning only a small set of child transcripts and display files. The user-visible impact included an attach timeout, a 7m26s rlm() admission, and a second admission blocked for more than 18 minutes.

I reviewed the proposed b62b5a88 changes. The active-only summary command, supervisor refresh coalescing, passive-topology cache, and in-flight readSessionInfo() sharing all target observed amplification points. Current upstream main still has the uncoalesced refresh boundary. PR #1845 removes a separate attach-time reconstruction but does not bound per-update worker-summary refreshes, so it does not fix this incident.

The admission delay is also important: rlm() awaits global name-availability/catalog construction before returning its promised immediate handle, so the same overloaded scan path blocks new child admission synchronously.