Feature Request: Add execution timing to status line

Resolved 💬 3 comments Opened Oct 20, 2025 by oravecz Closed Oct 24, 2025

Feature Request: Display Execution Timing in Status Line

Summary

Add conversation/prompt execution timing as a configurable status line element to help users monitor performance and understand how long operations take.

Motivation

When running complex workflows with multiple agent delegations (like spec implementation workflows), it's valuable to see execution timing automatically without having to manually track time. This helps with:

  • Performance monitoring: Understanding which operations are slow
  • Workflow optimization: Identifying bottlenecks in multi-agent workflows
  • User feedback: Providing clear indication of progress and completion
  • Debugging: Correlating slow responses with specific operations

Current Limitation

The status line API currently provides these variables:

  • session_id, transcript_path, cwd, model, workspace, version, output_style

But does not include execution timing data such as:

  • Last response time
  • Current operation elapsed time
  • Average response time for session

Proposed Solution

Add execution timing variables to the status line API:

{
  // Existing variables
  "session_id": "...",
  "cwd": "...",
  "model": "...",
  
  // New timing variables
  "last_response_time_ms": 2341,      // Time for last prompt execution
  "current_elapsed_ms": 1205,          // Time elapsed for current execution (if running)
  "session_avg_response_ms": 1876      // Average response time for session
}

Example Status Line Configuration

Users could then configure their status line to show timing:

{
  "left": [
    {"text": "{{model}}", "dim": true},
    {"text": "{{cwd}}", "dim": true}
  ],
  "right": [
    {"text": "{{last_response_time_ms}}ms", "color": "blue"},
    {"text": "{{token_usage}}", "dim": true}
  ]
}

Use Case Example

In a recent workflow that implemented a spec through 8 phases with multiple agent delegations, having automatic timing visibility would have helped track:

  • Total workflow duration (~10-15 minutes estimated)
  • Individual phase execution times (1-4 minutes each)
  • Performance comparison between different agents

Alternatives Considered

  1. Transcript parsing - Could parse transcript file timestamps, but:
  • Adds overhead to status line rendering
  • Only provides approximate times (file modification times)
  • Doesn't reflect true internal execution metrics
  1. Manual timing - Users can track manually, but:
  • Requires extra effort
  • Easy to forget or miss
  • Not integrated into the UI

Additional Context

  • Status line is configurable via statusline-setup agent
  • Timing data already exists internally (visible in some UI contexts)
  • Would be purely opt-in via status line configuration
  • No performance impact if not configured

Priority

Nice to have - Would significantly improve UX for power users running complex workflows, but not blocking for basic usage.

---

Generated via Claude Code while implementing multi-phase spec workflows with agent delegation.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗