wip

idle-detection.md

@@ -0,0 +1,26 @@
+# Idle Detection
+
+Solo does idle detection to show which agents are running, but this can also allow sub-agents to read state and/or trigger timers/actions based on idle state. This is important for things like permission checks. If an agent becomes idle, the orchestrator needs to know so it can approve permissions etc.
+
+<solo-idle-detection-docs>
+Agent idle detection
+Solo tracks agent state so you can tell which agents are working, idle, waiting for permission, or blocked by an error.
+
+How it works#
+Solo uses a mix of signals:
+
+First-party terminal agents use provider-specific activity strategies. Claude and OpenCode use visible output, Codex and Amp use OSC title stability, and Gemini uses OSC title status.
+Auto-summarization can return one of IDLE, PERMISSION, THINKING, WORKING, or ERROR, and Solo stores that classification when available.
+Summary timing#
+For summaries, Solo waits until a process has had human input and then watches output activity. A brief quiet window can trigger a summary after output stops. Continuously busy processes can also trigger summaries after a longer busy window.
+
+The summary cadence setting is still enforced per process, so repeated activity does not produce unlimited summary attempts.
+
+Timers#
+Agents can also have timers through Solo's agent-channel tools. Timer indicators show the nearest active or paused timer on the process row. Clicking the timer lets you view its message, cancel it, fire it now, or pause/resume it.
+
+When a timer fires, Solo delivers the timer message back to the owning process.
+
+Limits#
+Idle detection is a heuristic. Some agents pause between steps before continuing on their own, and a quiet terminal is not always the same thing as completed work.
+</solo-idle-detection-docs>