Feature Request: Stream reasoning summaries incrementally to improve perceived responsiveness

Resolved 💬 3 comments Opened Dec 17, 2025 by eric-distyl-ai Closed Mar 26, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Problem

Codex appears frozen/unresponsive during reasoning - users see nothing happening for extended periods (30+ seconds) while the model thinks, leading to poor perceived latency and user frustration.

This has driven complaints on social media that "Claude Code feels faster" regardless of actual response times. The perception issue is significant enough to affect user adoption and retention.

Root Cause

Reasoning content is currently accumulated silently in a buffer and only displayed after reasoning completes. Users stare at a static screen with no feedback, creating the impression that the tool has hung or is much slower than competitors.

Proposed Solution

Flush reasoning summary blocks to the UI immediately as they arrive rather than batching them until the end. This would provide continuous visual feedback during long thinking periods.

Key changes would include:

  1. Incremental display: Flush reasoning sections to history on section breaks instead of accumulating in a buffer
  2. Status header consistency: Extract bold header before flushing so status doesn't flash to "Working" between sections
  3. Default visibility: Show reasoning summaries in main chat view by default (currently hidden unless format is Experimental)

Prior Art & Related Issues

Research shows this has been a recurring pain point:

Related PRs (for context)

  • #3432 (CLOSED, never merged) - "Fix missing first reasoning summary header in main TUI" - Attempted to fix reasoning only appearing in transcript mode
  • #3071 (MERGED) - Introduced the Experimental reasoning summary format
  • #3138 (MERGED) - Added fallback behavior for reasoning summaries
  • #7845 (MERGED) - "fix: omit reasoning summary when ReasoningSummary::None"

Related UI Responsiveness PRs

  • #4864 (CLOSED) - "keep status indicator visible during streaming"
  • #5504 (CLOSED) - "pending message while streaming final response"

User-Reported Issues

  • #7076 - "Taking too long for a single reasoning step (>30 minutes)" - Multiple users reported feeling like nothing was happening
  • #7090 - Users wanting to control reasoning visibility

Impact

The transcript_only: true default for non-Experimental formats appears to cause reasoning to be hidden from the main view for many model configurations. Users experience "long periods where it feels like nothing is happening at all" - a commonly cited reason for preferring competitor tools.

Fixing this would:

  • Dramatically improve perceived responsiveness without changing actual performance
  • Provide users with insight into model reasoning progress
  • Reduce support burden from "is it frozen?" questions
  • Close the UX gap with competing tools

Affected Files

Based on analysis, changes would likely touch:

  • codex-rs/tui/src/chatwidget.rs
  • codex-rs/tui/src/history_cell.rs
  • codex-rs/tui2/src/chatwidget.rs
  • codex-rs/tui2/src/history_cell.rs

---

I'd be happy to contribute a PR implementing this if the team agrees this fits the roadmap. A prototype implementation exists in #8166 that demonstrates the approach.

View original on GitHub ↗

3 Comments

eric-distyl-ai · 8 months ago

Visual Comparison

Here's a side-by-side comparison showing the same prompt at the same elapsed time, demonstrating the difference between current behavior and the proposed streaming approach:

Current TUI (buffered - appears frozen):

<img width="1800" alt="Current TUI showing blank screen during reasoning" src="https://github.com/user-attachments/assets/2cceef67-ebb1-4951-8c77-69a67b58c221" />

Proposed TUI (streaming - shows progress):

<img width="1800" alt="Proposed TUI showing incremental reasoning output" src="https://github.com/user-attachments/assets/717a83f6-9079-4f4d-b768-b1531590cae8" />

Test Prompt Used

Can you think about this problem? Don't look up the solution.

Let πe(G) denote the set of orders of elements of a group G, and h(Γ) the
number of non-isomorphic finite groups G with πe(G) = Γ. Do there exist two finite
groups G1, G2 such that πe(G1) = πe(G2), h(πe(G1)) < ∞, and neither of the two
groups G1, G2 is isomorphic to a subgroup or a quotient of a normal subgroup of the
other?

The difference in user experience is stark - in the current version users see nothing happening, while the proposed version shows continuous reasoning progress.

github-actions[bot] contributor · 8 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #7998
  • #7827

Powered by Codex Action

etraut-openai contributor · 5 months ago

This feature request hasn't received enough upvotes in the past three months, so I'm going to close it.