Problem
Aider supports --notifications-command, which is useful after a model response finishes and Aider is ready for the next user input. It does not expose a documented lifecycle signal when an interactive prompt is submitted or when the model begins generating.
Terminal supervisors and orchestration tools therefore cannot reliably distinguish working from waiting for input without parsing streamed terminal output. That output is model-, theme-, and version-dependent, so it is not a stable integration contract.
Proposal
Add optional lifecycle command settings, analogous to --notifications-command:
--prompt-submitted-command COMMAND - run immediately after an interactive message or slash command is accepted for processing.--response-started-command COMMAND - run immediately before the LLM response begins.--response-finished-command COMMAND - run once processing is complete and Aider returns to its input prompt.
Environment/config-file equivalents would make these usable in managed launchers.
Commands could receive a small stable context payload through environment variables or arguments, for example the event name and current chat mode. No prompt contents need to be exposed.
Use case
Agent Orchestrator already integrates Aider notifications to mark a session as needing input. Explicit lifecycle commands would let it track working and needs_input accurately, without token-stream parsing or intercepting user keystrokes. This would also help status bars, terminal multiplexers, IDE launchers, and remote session monitors.
Compatibility
All commands can be opt-in and best-effort: failures should be ignored or logged at debug level so existing Aider workflows are unaffected.
Problem
Aider supports
--notifications-command, which is useful after a model response finishes and Aider is ready for the next user input. It does not expose a documented lifecycle signal when an interactive prompt is submitted or when the model begins generating.Terminal supervisors and orchestration tools therefore cannot reliably distinguish
workingfromwaiting for inputwithout parsing streamed terminal output. That output is model-, theme-, and version-dependent, so it is not a stable integration contract.Proposal
Add optional lifecycle command settings, analogous to
--notifications-command:--prompt-submitted-command COMMAND- run immediately after an interactive message or slash command is accepted for processing.--response-started-command COMMAND- run immediately before the LLM response begins.--response-finished-command COMMAND- run once processing is complete and Aider returns to its input prompt.Environment/config-file equivalents would make these usable in managed launchers.
Commands could receive a small stable context payload through environment variables or arguments, for example the event name and current chat mode. No prompt contents need to be exposed.
Use case
Agent Orchestrator already integrates Aider notifications to mark a session as needing input. Explicit lifecycle commands would let it track
workingandneeds_inputaccurately, without token-stream parsing or intercepting user keystrokes. This would also help status bars, terminal multiplexers, IDE launchers, and remote session monitors.Compatibility
All commands can be opt-in and best-effort: failures should be ignored or logged at debug level so existing Aider workflows are unaffected.