perf(web): coalesce streaming Markdown renders

[nateEc]

Closes#4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI-only throttling in chat markdown rendering with immediate flush when streaming stops; no auth, data, or API changes.

Overview
Coalesces assistant Markdown updates during streaming so ChatMarkdown re-parses and re-renders at most once every 50ms, instead of on every token delta.

Adds useStreamingMarkdownText and a small streamingMarkdownRenderDelay helper (with unit tests). While isStreaming is true, visible source and derived work (link/meta extraction, task-list marker offsets) follow the throttled renderedText; when streaming ends, the hook flushes immediately to the latest text. The ReactMarkdown tree is also memoized on renderedText so component identity stays steadier between batched updates.

Behavior: live output can lag the incoming stream by up to ~50ms; completed messages should match prior semantics.

^{Reviewed by Cursor Bugbot for commit 6497047. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized 6497047.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge@mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?

[nateEc]

Closes#4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI-only throttling in chat markdown rendering with immediate flush when streaming stops; no auth, data, or API changes.

Overview
Coalesces assistant Markdown updates during streaming so ChatMarkdown re-parses and re-renders at most once every 50ms, instead of on every token delta.

Adds useStreamingMarkdownText and a small streamingMarkdownRenderDelay helper (with unit tests). While isStreaming is true, visible source and derived work (link/meta extraction, task-list marker offsets) follow the throttled renderedText; when streaming ends, the hook flushes immediately to the latest text. The ReactMarkdown tree is also memoized on renderedText so component identity stays steadier between batched updates.

Behavior: live output can lag the incoming stream by up to ~50ms; completed messages should match prior semantics.

^{Reviewed by Cursor Bugbot for commit 6497047. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized 6497047.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge@mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?

[nateEc]

Closes#4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI-only throttling in chat markdown rendering with immediate flush when streaming stops; no auth, data, or API changes.

Overview
Coalesces assistant Markdown updates during streaming so ChatMarkdown re-parses and re-renders at most once every 50ms, instead of on every token delta.

Adds useStreamingMarkdownText and a small streamingMarkdownRenderDelay helper (with unit tests). While isStreaming is true, visible source and derived work (link/meta extraction, task-list marker offsets) follow the throttled renderedText; when streaming ends, the hook flushes immediately to the latest text. The ReactMarkdown tree is also memoized on renderedText so component identity stays steadier between batched updates.

Behavior: live output can lag the incoming stream by up to ~50ms; completed messages should match prior semantics.

^{Reviewed by Cursor Bugbot for commit 6497047. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized 6497047.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge@mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?

[nateEc]

Closes#4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI-only throttling in chat markdown rendering with immediate flush when streaming stops; no auth, data, or API changes.

Overview
Coalesces assistant Markdown updates during streaming so ChatMarkdown re-parses and re-renders at most once every 50ms, instead of on every token delta.

Adds useStreamingMarkdownText and a small streamingMarkdownRenderDelay helper (with unit tests). While isStreaming is true, visible source and derived work (link/meta extraction, task-list marker offsets) follow the throttled renderedText; when streaming ends, the hook flushes immediately to the latest text. The ReactMarkdown tree is also memoized on renderedText so component identity stays steadier between batched updates.

Behavior: live output can lag the incoming stream by up to ~50ms; completed messages should match prior semantics.

^{Reviewed by Cursor Bugbot for commit 6497047. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized 6497047.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge@mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?

[nateEc]

Closes#4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI-only throttling in chat markdown rendering with immediate flush when streaming stops; no auth, data, or API changes.

Overview
Coalesces assistant Markdown updates during streaming so ChatMarkdown re-parses and re-renders at most once every 50ms, instead of on every token delta.

Adds useStreamingMarkdownText and a small streamingMarkdownRenderDelay helper (with unit tests). While isStreaming is true, visible source and derived work (link/meta extraction, task-list marker offsets) follow the throttled renderedText; when streaming ends, the hook flushes immediately to the latest text. The ReactMarkdown tree is also memoized on renderedText so component identity stays steadier between batched updates.

Behavior: live output can lag the incoming stream by up to ~50ms; completed messages should match prior semantics.

^{Reviewed by Cursor Bugbot for commit 6497047. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized 6497047.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge@mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?

[nateEc]

Closes#4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI-only throttling in chat markdown rendering with immediate flush when streaming stops; no auth, data, or API changes.

Overview
Coalesces assistant Markdown updates during streaming so ChatMarkdown re-parses and re-renders at most once every 50ms, instead of on every token delta.

Adds useStreamingMarkdownText and a small streamingMarkdownRenderDelay helper (with unit tests). While isStreaming is true, visible source and derived work (link/meta extraction, task-list marker offsets) follow the throttled renderedText; when streaming ends, the hook flushes immediately to the latest text. The ReactMarkdown tree is also memoized on renderedText so component identity stays steadier between batched updates.

Behavior: live output can lag the incoming stream by up to ~50ms; completed messages should match prior semantics.

^{Reviewed by Cursor Bugbot for commit 6497047. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized 6497047.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge@mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?

[nateEc]

Closes#4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI-only throttling in chat markdown rendering with immediate flush when streaming stops; no auth, data, or API changes.

Overview
Coalesces assistant Markdown updates during streaming so ChatMarkdown re-parses and re-renders at most once every 50ms, instead of on every token delta.

Adds useStreamingMarkdownText and a small streamingMarkdownRenderDelay helper (with unit tests). While isStreaming is true, visible source and derived work (link/meta extraction, task-list marker offsets) follow the throttled renderedText; when streaming ends, the hook flushes immediately to the latest text. The ReactMarkdown tree is also memoized on renderedText so component identity stays steadier between batched updates.

Behavior: live output can lag the incoming stream by up to ~50ms; completed messages should match prior semantics.

^{Reviewed by Cursor Bugbot for commit 6497047. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized 6497047.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge@mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?

[nateEc]

Closes#4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI-only throttling in chat markdown rendering with immediate flush when streaming stops; no auth, data, or API changes.

Overview
Coalesces assistant Markdown updates during streaming so ChatMarkdown re-parses and re-renders at most once every 50ms, instead of on every token delta.

Adds useStreamingMarkdownText and a small streamingMarkdownRenderDelay helper (with unit tests). While isStreaming is true, visible source and derived work (link/meta extraction, task-list marker offsets) follow the throttled renderedText; when streaming ends, the hook flushes immediately to the latest text. The ReactMarkdown tree is also memoized on renderedText so component identity stays steadier between batched updates.

Behavior: live output can lag the incoming stream by up to ~50ms; completed messages should match prior semantics.

^{Reviewed by Cursor Bugbot for commit 6497047. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized 6497047.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge@mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?