27 lines
1.7 KiB
Markdown
27 lines
1.7 KiB
Markdown
# 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>
|