[FEATURE]: Show elapsed runtime per command / instruction in TUI + Replay #5872
Description
Feature request: Surface elapsed runtime for active work (and make retries easier)
Context
During normal usage, OpenCode frequently executes commands or agent actions that may run for an extended or variable amount of time.
While these operations are in progress, the TUI provides limited feedback about their state. Users are left to infer whether the system is actively working, waiting on an external dependency, or no longer making progress.
This lack of visibility makes it difficult to decide whether to continue waiting, interrupt execution, or retry the operation. The goal of this request is to reduce that uncertainty without adding unnecessary complexity.
Problem
When a command, instruction, or agent action is executing, the TUI provides no indication of how long it has been running.
Without a sense of elapsed time, users have to rely on intuition and guesswork to decide whether to:
- keep waiting,
- interrupt execution, or
- assume something has gone wrong.
This becomes more noticeable with:
- long-running agent chains
- tool or MCP calls
- network-bound operations
- shell commands that may block silently
Once execution is interrupted, restarting usually means reconstructing the same instruction manually.
Proposal
Two small affordances could significantly reduce this friction:
-
Elapsed runtime visibility
Show how long the currently active command or instruction has been running (e.g. in the status bar or alongside the active task).No progress estimation is needed — just elapsed time.
-
A simple way to retry the last instruction
After a task completes or is interrupted, provide a way to re-run the most recent instruction without retyping or rebuilding context.This could be exposed as a button, keybinding, or command — the exact form is flexible.
Why this helps
Elapsed time is a subtle but powerful signal. It lets users decide for themselves whether something feels normal or off, and whether waiting longer makes sense.
Combined with an easy retry path, interruption becomes less costly and less stressful. Users can stop work earlier when something feels wrong, knowing they can resume without friction.
Together, these changes:
- reduce hesitation during long-running tasks
- make interruptions feel reversible instead of destructive
- increase trust by making execution more observable
Notes
This request is intentionally scoped to visibility and ergonomics, not policy or automation. More advanced behavior (warnings, thresholds, hooks, etc.) may naturally suggest itself later once time becomes a visible signal.
Closing
This isn’t a large feature, but it addresses a common moment of uncertainty during real usage.
Curious whether others have felt the same hesitation while waiting — and whether making time visible would change how they interact with long-running work.