zai-org / zai-org/feedback

[建议 / Feature] Per-task elapsed-time accounting + live running timer (to tell productive work from a silently hung task)

Open
#135 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

priority: P2
Dominant language
No language data
Stars
22
Forks
1
PR merge metrics
No merged PRs in 30d

Description

提交前确认 · Pre-submission checklist

  • I searched existing issues and confirmed this isn't a duplicate.
  • I've read CONTRIBUTING.md.

ℹ️ The dropdown fields below could not be set programmatically. Please select them manually when reviewing:

  • Category: 对话 / Agent 交互 · Agent chat / interaction
  • Agent framework: ZCode Agent(自研)

使用场景 · Use case

When the agent works on a task (a tool call, a sub-task, an editing step, or a full turn), there is currently no per-task elapsed-time accounting. The UI shows token counts and cost, but not how long the task actually took.

This is important in practice for several reasons:

  1. Knowing whether the system is stalled. A common real-world situation: you send a request, then wait — and it's unclear whether the agent is productively working (e.g. a slow tool call, a long reasoning pass) or whether it has silently hung / stalled (network drop, stuck MCP server, dead subprocess). A live elapsed timer per step is the fastest way to tell. Today the only signal is "nothing is happening", which is indistinguishable from "still working on something slow".

  2. Understanding where time goes. When a task takes noticeably long, you want to see which step consumed the time — e.g. a Bash command that blocked for 40s, an MCP tool that was slow, or a long model inference. Per-step timing makes bottlenecks visible.

  3. Planning & cost-vs-time awareness. I already see tokens and cost; pairing them with wall-clock duration gives a complete picture of a task.


建议方案 · Proposal

Track and surface wall-clock elapsed time for each unit of work the agent performs:

1. Per-step timing (the core ask)

For every tool call / step the agent runs, show its start time → end time → elapsed duration (e.g. Bash · 12.4s, Edit · 0.3s, WebSearch · 8.1s). This makes both individual slow steps and a stuck step immediately obvious.

2. Live "running" timer

While a step is in progress, show a live ticking timer (e.g. running… 7s 12s 18s). If a single step crosses a threshold (configurable, e.g. 60s), give a stronger visual cue (amber/red) — this is the "is it hung?" signal.

3. Turn / task roll-up

At the end of a turn or task, show the total wall-clock duration alongside the existing token/cost summary (e.g. 3 steps · 45.2s · 18.4k tokens).

4. (Optional) Stalled-step detection

If a step produces no progress/events for N seconds, flag it with something like ⚠ no activity for 30s — still waiting? so the user can decide to interrupt. This directly addresses the "is the system stopped?" need.

Suggested UI placement
  • Inline next to each step's result (duration badge).
  • In the step header while running (live timer).
  • In the turn summary (total duration).

This mirrors what mature task/CI tooling already does (per-step + total duration), and it's low-risk to add since the data (step start/end) is already known internally.


🙏 Thank you! This would meaningfully improve day-to-day confidence that a task is progressing vs. silently hung.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Start by locating the agent step lifecycle and the UI components for step results and turn summaries; done means per-step elapsed times, a live running timer, and a turn-level total are visible, with any optional stalled-step warning defined and verified.

Written by the indexing model from the issue text.

Assessment

Domain
frontend, observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.