[FEATURE] Turn Numbers and Speaker Attribution in Session Transcripts

Resolved 💬 6 comments Opened Mar 16, 2026 by cumberland-laboratories Closed May 27, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

The idea

Display conversation turns with sequential numbers and speaker labels — like a screenplay.

Current

> What if we moved the retry logic into the middleware
> instead of handling it per-endpoint?

That works. The middleware already sees the response
status, so it can intercept 429s and 503s before they
hit the handler. Sketch:

    app.use(retryMiddleware({ maxAttempts: 3, backoff: 'exponential' }))

You'd drop about 40 lines of duplicated try/catch
across the route files. Want me to draft it?

Proposed

28  [Alan]
    What if we moved the retry logic into the middleware
    instead of handling it per-endpoint?

29  [Claude Opus 4.6]
    That works. The middleware already sees the response
    status, so it can intercept 429s and 503s before they
    hit the handler. Sketch:

    app.use(retryMiddleware({ maxAttempts: 3, backoff: 'exponential' }))

    You'd drop about 40 lines of duplicated try/catch
    across the route files. Want me to draft it?

Why this matters

Turn numbers make conversations addressable. You can say "go back to turn 28" or "that approach from turn 14 was better." Right now you describe exchanges by content or recency — "the one where we talked about middleware" — which breaks down in long sessions.

Speaker labels with model version make conversations attributable. If you switch between Opus and Sonnet mid-session, or if a second person reviews the transcript later, you can see exactly which model produced which output. Today you'd have to remember, or check /model and mentally reconstruct the timeline.

Together, they turn a chat stream into a proper document — the kind of thing you can reference, review, and audit.

What this enables

  • Precise references: "Revert to the approach in turn 14" / "That error started in turn 22"
  • Session review: A second person (or a different model doing code review) can follow the transcript without guessing who said what
  • Model tracking: When you upgrade or switch models, the record shows which version produced which output — useful for debugging and reproducibility
  • Export quality: Session transcripts become useful artifacts rather than undifferentiated streams

Prior art

Screenplays, courtroom transcripts, and legislative records have used speaker labels and sequential numbering for centuries. IRC and chat logs use timestamps and usernames. Git blame provides line-level attribution for code. Conversations are becoming a primary authoring surface for software — they deserve the same basic addressability.

Scope

Two additions, both display-only:

  1. Turn number: Sequential integer, displayed at the start of each turn
  2. Speaker label: [Username] for the human, [Model Name Version] for the agent (e.g., [Claude Opus 4.6], [Claude Sonnet 4.6])

Optional but valuable: a persistent status line showing current repo, branch, and session metadata — the equivalent of a terminal multiplexer's bottom bar.

Notes

  • This is purely a display/UX change — no changes to the underlying conversation model
  • Turn numbers could also be exposed to the agent, enabling commands like "clip turns 12-15" or "strike turn 29"
  • The model version is already known internally; this just surfaces it per-turn

Proposed Solution

Prior art

Screenplays, courtroom transcripts, and legislative records have used speaker labels and sequential numbering for centuries. IRC and chat logs use timestamps and usernames. Git blame provides line-level attribution for code. Conversations are becoming a primary authoring surface for software — they deserve the same basic addressability.

Scope

Two additions, both display-only:

  1. Turn number: Sequential integer, displayed at the start of each turn
  2. Speaker label: [Username] for the human, [Model Name Version] for the agent (e.g., [Claude Opus 4.6], [Claude Sonnet 4.6])

Optional but valuable: a persistent status line showing current repo, branch, and session metadata — the equivalent of a terminal multiplexer's bottom bar.

Notes

  • This is purely a display/UX change — no changes to the underlying conversation model
  • Turn numbers could also be exposed to the agent, enabling commands like "clip turns 12-15" or "strike turn 29"
  • The model version is already known internally; this just surfaces it per-turn

Alternative Solutions

No alternatives. There is no way to say "I want to take back my instruction on turn 16, it was in error".

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

This comes up all the time with the agent misunderstanding the scope of a command line instruction. "Remember that work we did back ...?" ...agent has to guess about commits etc. Very dangerous.

Additional Context

28  [Alan]
    What if we moved the retry logic into the middleware
    instead of handling it per-endpoint?

29  [Claude Opus 4.6]
    That works. The middleware already sees the response
    status, so it can intercept 429s and 503s before they
    hit the handler. Sketch:

    app.use(retryMiddleware({ maxAttempts: 3, backoff: 'exponential' }))

    You'd drop about 40 lines of duplicated try/catch
    across the route files. Want me to draft it?

View original on GitHub ↗

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