Repository navigation
[FEATURE]: On-idle background processing #5895
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
It happens quite offen that the TUI becomes idle as it waits for the user to return and follow up.
If open ("ready") beads exist of some chore-like "unattended processing is desired", there shall be an option so that the system should start processing them in background and commit local change requests upon success which could be reviewed on later time.
One important component for doing so exists already, like the beads (bd) local issue storage.
This would streamline productive work and establish users' well being due to UX risk research.
Note: the following content is AI sourced.
What is possible as a workaround
OpenCode “timing awareness” and background tasks (practical view)
OpenCode does not automatically “notice” you stepped away and then proactively run work; by default it runs when you trigger a prompt/command/tool action (SST et al., n.d.). However, OpenCode exposes enough lifecycle and API surface that you can implement small background tasks during “waiting” states (SST et al., n.d.).
1) In-process option: plugin events (e.g., session.idle)
- OpenCode plugins can subscribe to session lifecycle events (including an idle signal) and can execute local commands from the plugin runtime (SST et al., n.d.).
- This supports “cheap” background tasks such as: quick linters, formatting checks, small unit-test subsets, index refresh, or generating a short status summary while you are away (SST et al., n.d.).
Operational caveat: In practice, an “idle” event may not always mean “the agent is fully done and waiting for user input.” Some reports/requests indicate timing semantics can be ambiguous and a stronger “finished” signal may be desirable (SST et al., n.d.).
2) Out-of-process option: server mode + event stream + async dispatch
- OpenCode can run as a server (
opencode serve) exposing an HTTP API and event streams (SST et al., n.d.). - A sidecar/controller can subscribe to the server’s event stream(s) and, upon “idle” (or a more conservative composite condition), trigger:
- local tasks in your environment, and/or
- an asynchronous LLM job via an async prompt endpoint (SST et al., n.d.).
- This pattern is well-suited for throttling, budgeting, and observability (you can decide “only run X when idle for >N seconds,” “only run once per commit,” etc.) (SST et al., n.d.).
3) MVP guidance (low risk)
- Start with plugin-driven background tasks that are deterministic and fast (lint/format/quick tests) on an idle-style signal (SST et al., n.d.).
- If you want LLM work while you are away, prefer a sidecar using server mode + async prompt dispatch so you can rate-limit and avoid surprising interactive UX behavior (SST et al., n.d.).
- Design tasks to be idempotent and safe to re-run because “idle” semantics may not be perfectly aligned to “finished” in every integration (SST et al., n.d.).
4) Related execution mode: CI/workflow triggers
OpenCode can also be invoked in GitHub workflow contexts (triggered explicitly by comments/events rather than inferred “user absence”), which is another way to “run in the background,” but it is not the same as session-idle opportunistic work (SST et al., n.d.).
References
- SST et al. (n.d.). OpenCode Plugins Documentation. Retrieved on 2025-12-21 from https://opencode.ai/docs/plugins/
- SST et al. (n.d.). OpenCode Server (HTTP API & Events) Documentation. Retrieved on 2025-12-21 from https://opencode.ai/docs/server
- SST et al. (n.d.). OpenCode SDK Documentation. Retrieved on 2025-12-21 from https://opencode.ai/docs/sdk/
- SST et al. (n.d.). OpenCode GitHub Integrations / Workflows Documentation. Retrieved on 2025-12-21 from https://opencode.ai/docs/github/
- SST et al. (n.d.). OpenCode GitHub Issue: idle/finished event semantics discussion. Retrieved on 2025-12-21 from What is the deterministic way to monitor a session is completed #3815
- SST et al. (n.d.). OpenCode GitHub Issue: event/lifecycle request (finished signal). Retrieved on 2025-12-21 from feature request: "agent.finished" plugin event #2021
- SST et al. (n.d.). OpenCode GitHub Issue: additional event semantics/behavior discussion. Retrieved on 2025-12-21 from "Session went idle" text #3534
- Boud, C. (n.d.). Coding Agents Internals: OpenCode Deep Dive (blog). Retrieved on 2025-12-21 from https://cefboud.com/posts/coding-agents-internals-opencode-deepdive/
- SST et al. (n.d.). opencode-sdk-python (repository). Retrieved on 2025-12-21 from https://github.com/sst/opencode-sdk-python
- SST et al. (n.d.). opencode-sdk-go (repository). Retrieved on 2025-12-21 from https://github.com/sst/opencode-sdk-go
UX Risks in Agentic Coding Workflows Under Variable Turnaround Time — Compiled Insights
Why this is not just subjective
-
Delay and delay-variability degrade perceived control and satisfaction.
Interactive systems research shows users form strong expectations about response time; unpredictable delays reduce perceived control and can increase frustration and error likelihood. (Shneiderman 1984; Nielsen 1993; Kohrs et al. 2014) -
Interruptions impose measurable cognitive “resumption costs.”
When you switch away during an agent run, you later pay a context reconstruction cost; interruptions are associated with increased stress/frustration even when people compensate by working faster. (Mark et al. 2008; Parnin & Rugaber 2009) -
Developer work is already fragmented; agent latency variance compounds it.
Empirical software engineering studies indicate frequent task switching and coordination overhead in real developer days; adding irregular “wait → return → verify” loops increases fragmentation. (Meyer et al. 2017; Meyer et al. 2019) -
AI coding assistance can shift time into prompting, waiting, and verification.
Evidence is mixed: some controlled results show speedups, while other rigorous evaluations report slowdowns for experienced developers in familiar codebases, with contributors including overhead and verification. (Peng et al. 2023; Becker et al. 2025; METR 2025; Reuters 2025) -
Proactive/agentic designs are explicitly a trade-off between assistance and disruption.
Work on proactive programming support highlights that assistance can disrupt flow unless users get clear signals, context, and control mechanisms (e.g., progress/presence indicators). (Pu et al. 2025)
The failure mode you described (canonical loop)
- You delegate intent to the agent (prompt).
- The agent returns after variable delay (sometimes 1 minute, sometimes 6).
- You either wait (costly) or context-switch (also costly).
- When output arrives, you must rebuild context, interpret changes, verify correctness, decide next steps.
- Net result: attention fragmentation + stress + lost follow-up windows, especially under time pressure. (Mark et al. 2008; Parnin & Rugaber 2009; Shneiderman 1984)
Known scenarios that predictably worsen the experience
- High variance turnaround time (not just “slow,” but unpredictable) → planning attention becomes hard. (Shneiderman 1984; Nielsen 1993)
- Long multi-step agent runs without intermediate checkpoints → all-or-nothing waiting. (Pu et al. 2025)
- Large diffs / high verification burden → time shifts from implementation to review/rework. (METR 2025; Becker et al. 2025)
- High time-pressure contexts → missed follow-ups feel costly; stress increases. (Mark et al. 2008; Kohrs et al. 2014)
Compact mitigation playbook (patterns that map to the mechanisms)
A) Make waiting predictable and actionable
- Short checkpoints over long runs: split work into staged outputs (plan → patch → tests → finalize). (Pu et al. 2025)
- Visible progress/presence cues: treat “what stage is it in” as first-class; reduces disruption in proactive designs. (Pu et al. 2025)
- Explicit “return points”: decide in advance when you will check back (e.g., after unit tests), to avoid constant vigilance. (Nielsen 1993)
B) Reduce iterations by raising prompt specificity and acceptance criteria
- Predefine verification contract: required tests, lint, acceptance criteria, performance constraints.
- Constrain diff surface: specify files/modules, boundaries, and “do not touch” areas to reduce review load. (METR 2025; Becker et al. 2025)
C) Optimize for lower variance (not only lower mean latency)
- Stabilize runtime: warm caches, consistent model/tool selection, avoid unpredictable tool chains.
- Deterministic decomposition: prefer predictable sub-steps with explicit stop conditions when uncertain.
D) Use agents selectively by task type
- Delegate bounded/mechanical tasks (boilerplate, repetitive refactors, test scaffolds) where benefits are more consistent. (Peng et al. 2023)
- Be cautious delegating high-context work in familiar repos if verification/rework is likely to dominate. (METR 2025; Becker et al. 2025)
Practical operating modes (choose deliberately)
-
Tight-loop mode (time pressure):
- Keep runs short; require checkpoints; stop on uncertainty; decide quickly per checkpoint.
- Goal: minimize resumption lag and missed follow-up windows. (Parnin & Rugaber 2009; Mark et al. 2008)
-
Batch mode (low time pressure):
- Allow longer runs, but schedule explicit return points and do only low-context parallel tasks.
- Goal: avoid expensive context switches.
References
- (Becker et al. 2025) Becker, J. and others. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089.
- (Kohrs et al. 2014) Kohrs, C., Hrabal, D., Angenstein, N., Boucsein, W. Delayed system response times affect immediate physiology and the dynamics of subsequent button press behavior. Psychophysiology, 2014.
- (Mark et al. 2008) Mark, G., Gudith, D., Klocke, U. The Cost of Interrupted Work: More Speed and Stress. CHI 2008.
- (METR 2025) METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Blog post, retrieved on 2025-12-21.
- (Meyer et al. 2017) Meyer, A. N. et al. The Work Life of Developers: Activities, Switches and Perceived Productivity. IEEE TSE, 2017.
- (Meyer et al. 2019) Meyer, A. N. et al. Today Was a Good Day: The Daily Life of Software Developers. IEEE TSE, 2019.
- (Nielsen 1993) Nielsen, J. Response Times: The 3 Important Limits. Nielsen Norman Group, retrieved on 2025-12-21.
- (Parnin & Rugaber 2009) Parnin, C., Rugaber, S. Resumption Strategies for Interrupted Programming Tasks. ICPC 2009.
- (Peng et al. 2023) Peng, S. et al. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590.
- (Pu et al. 2025) Pu, K. et al. Assistance or Disruption? Exploring and Evaluating the Design and Trade-offs of Proactive AI Programming Support. arXiv:2502.18658.
- (Reuters 2025) Reuters. AI slows down some experienced software developers, study finds. retrieved on 2025-12-21.
- (Shneiderman 1984) Shneiderman, B. Response Time and Display Rate in Human Performance with Computers. ACM Computing Surveys, 1984.
Activity
github-actions commentedon Dec 21, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
synergiator commentedon Dec 22, 2025
TWIMC - after some iterations, I have now something I can work with, though I think that on long term we should aim to have an opencode bot to do chores inside CICD just like the renovate bot.
This opencode plugins allows to process open beads in background.