I spent a while on this one because the premise is good and I wanted to be sure before pushing back. Everything below is reproducible with one script against the code on this branch; it is included at the bottom.

First, the parts that hold up. I checked the three claims in the description against streamdown@2.5.0 in node_modules:

• The animate rehype plugin really does wrap every word regardless of duration and stagger. Its visitor splits text nodes unconditionally and duration 0 only sets --sd-duration: 0ms.
• The direct commit path really is gated on animated alone: t === "streaming" && !ge ? startTransition(...) : Tt(fe). Since ge is built inside Streamdown, filtering the plugin per block is the only place it can be removed. Setting animatePlugin: null on its own would not do it.
• remend and the block split really do re-run over the whole document each update, and remend is about 88% of that cost, so it is the right thing to attack.

So the diagnosis is right. My concern is with the incremental path itself. Three things.

1. The reply stops updating when the repaired tail repeats

IncrementalMarkdownCache.parseMarkdownIntoBlocks (streaming-render-schedule.ts:448-451) is a stable bound method whose result depends on mutable committedBlocks. That means the only prop that can tell React a commit happened is children (markdown-text.tsx:503).

Streamdown is memoised, and its comparator does not include parseMarkdownIntoBlocksFn:

(e,t)=>e.children===t.children&&e.shikiTheme===t.shikiTheme&&e.isAnimating===t.isAnimating&&
e.animated===t.animated&&e.mode===t.mode&&e.plugins===t.plugins&&e.className===t.className&&…

Every other compared prop is now a module constant thanks to the hoisting in this PR, so when children repeats the component does not render at all. Even if it did, fe = useMemo(() => h(Se), [Se, h]) inside would return the cached array for the same reason.

update() returns repairTail() of the tail after committing (:617-620), so when a frame's delta is exactly what got committed and the remaining tail is unchanged, the returned string is byte identical while committedBlocks grows. A reply that repeats a line, which is what a degenerate checkpoint produces, locks permanently:

  frame  4  reply   52 chars  children  52 chars  on screen   8 blocks  should be   8
  frame  5  reply   65 chars  children  52 chars  on screen   8 blocks  should be  10   <- stalled
  frame  8  reply  104 chars  children  52 chars  on screen   8 blocks  should be  16   <- stalled
  frame 12  reply  156 chars  children  52 chars  on screen   8 blocks  should be  24   <- stalled
  frame 24  reply  312 chars  children  52 chars  on screen   8 blocks  should be  48   <- stalled

It never recovers, because the frozen children value is reproduced every frame. The message appears to stop mid-generation and snaps to the full text at completion. Under random chunk sizes the milder version shows up on ordinary repeated content too: repeated identical paragraphs stalled 195 of 200 simulated streams, about 22% of frames, while numbered paragraphs and prose stalled zero times.

The fix that works here is making markdown change whenever the block list changes, for example by remembering the last returned string and deferring a commit that would collide with it. Changing the callback identity does not help, since the outer comparator ignores that prop.

Worth noting that tests/streaming-render-schedule.test.ts:83-96 cannot catch this: it calls render.parseMarkdownIntoBlocks fresh at every prefix, and the memo is the only thing that reads it in production.

2. Eight cases where the incremental blocks differ from the full repair

The invariant the PR rests on is that incremental output matches parseMarkdownIntoBlocks(remend(input)) at every prefix. These break it, all run through the real pipeline (stabilizeStreamingMarkdown(preprocessLaTeX(prefix), true)):

  four-backtick fence, then ~~   prefix  30  rendered "~~ y~~"           expected "~~ y"
  unclosed [ in prose            prefix  23  rendered "\n\n"             expected "](streamdown:incomplete-link)"
  escaped backtick, then $$      prefix  22  rendered "$$$$"             expected "$$"
  run of eight asterisks         prefix  28  rendered "*a*"              expected "*a"
  ** inside a fence              prefix  39  rendered "_u then **v**_"   expected "_u then **v_**"
  * inside inline code           prefix  41  rendered "****x"            expected "****x***"
  escaped fence \```             prefix  41  rendered "- \\>= 4"         expected "- >= 4"
  repeated link label            prefix  89  rendered "[x]: h"           expected "\n\n"

Cause by cause:

hasNeutralRepairParity omits emphasisInlineCode (:406). Together with boldFence that field mirrors remend's isWithinInlineCode, which gates seven of its handlers. A four-backtick fence leaves an inline span open that isTripleBacktick's three character window cannot see, and the tail then gets closers it should not. Adding the field to the array at :406 fixes it.

Unclosed [ is not tracked at all. remend's link handler scans the whole document backwards for an unmatched bracket and appends ](streamdown:incomplete-link) at the end. RepairParity has no bracket state, so a committed unmatched bracket disappears. This one has a realistic trigger: prose containing buffer[i diverges on 35 of 110 prefixes, and the user sees a placeholder link that vanishes the moment retention kicks in. A context prefix cannot express this since remend needs the actual unmatched bracket; it needs a cross-block bracket depth in the neutral check.

updateDisplayMathParity stops one character early (:359). remend uses that same bound but over the whole document, so it loses one character in total. Here it loses the last character of every committed block. index < text.length is enough; reading text[index + 1] past the end is undefined, which the $$ check already handles.

updateAsteriskParity returns before counting (:257-262). remend evaluates every * position independently, so a run of three or more always contributes exactly one to its single-asterisk count. The text[index + 1] === "*" branch returns before countsAsSingleAsterisk runs, so runs contribute zero. bold and tripleAsterisk mask most run lengths; eight is the smallest that slips through. Calling countsAsSingleAsterisk first fixes it.

Fenced ** is invisible to the ordering logic. remend picks between a mid-string _** and a trailing _ using a raw indexOf("**") that sees inside fences, while firstBoldOrSingleUnderscore (:259) is only set on the non-fence path. A fenced 2 ** 3 or **ptr is enough, and the stray _ lands on the wrong side of the bold marker.

INLINE_CODE_ASTERISK_CONTEXT is not parity neutral (:14). remend's countSingleAsterisks skips fences but not inline code, and one of its two call sites has no code guard, so the injected `a *b` flips the boldItalic decision for the tail. This is the one that contradicts the comment at :8-9. `a *b* c`\n\n keeps the same shape and restores neutrality. INLINE_CODE_UNDERSCORE_CONTEXT has the same asymmetry, currently latent behind a guard.

Escape and fence are checked in the wrong order (:294-305). remend's isWithinInlineCode applies the \` escape before the fence check; updateEmphasisParity does the fence first and the escape only after the boldFence early continue. An exhaustive scan of all 265,719 strings up to length 11 over {`, \, x} found 1,148 where remend says "inside code" and the parity model says neutral. The worst shape drops text rather than adding it: "The tag <s" renders as "The tag".

Link reference definitions are globally scoped too. The footnote bail-out at :534-539 treats footnotes as the only such construct, but marked registers link definitions in a per document tokens.links map and emits no token for a repeated label. Lexing only the tail never sees the earlier label, so the duplicate renders as a visible [x]: https://… line. 127 of 200 fuzzed documents with a repeated label diverge; 0 of 1000 with unique labels.

For scale: a differential fuzzer over the marker grammar found 108 divergences across 1,039,256 prefixes on this branch. With all seven parity fixes applied to a scratch copy, 0 across 4,174,597 prefixes. So the model is close, and these look like finishable gaps rather than a dead end.

3. The optimisation turns off on the replies it is meant to help

This is the part I would most want addressed before merge. repairTail().length / input.length on a 60 paragraph reply, where 1.00 means the whole document is still repaired and split on every token:

  plain prose (baseline)             0.07
  paragraph ends in `inline code`    1.00   <- optimisation off
  ```sh   echo $HOME                 1.00   <- optimisation off
  ```php  $x = 1;                    1.00   <- optimisation off
  ```make $(CC) x.c                  1.00   <- optimisation off
  `echo $HOME` inline                1.00   <- optimisation off
  ```js   const s = 'a`b';           1.00   <- optimisation off
  ```js   /[^a]/  (reads as footnote) 1.00   <- optimisation off
  prose: takes 5~10 minutes          1.00   <- optimisation off

Two roots.

updateEmphasisMathParity runs at :293, before the fence check at :294 and the inline code check at :302, so a $ inside a fence leaves emphasisInlineMath set for the rest of the message. That is pure conservatism, not safety, because remend does not act on fenced dollars at all:

remend("```sh\necho $HOME\n```\n\npara") === "```sh\necho $HOME\n```\n\npara"  // true

Unlike bold, asterisk and underscore there is no context prefix that can recover it, so every shell, PHP and Makefile snippet disables retention permanently.

Paragraphs ending in inline code are the other symptom of the text.length - 1 bound in updateDisplayMathParity. That shape is very common in coding replies.

Two more all-or-nothing bail-outs are worth a look. FOOTNOTE_REFERENCE_RE (:16) matches any regex character class, so /[^a]/ in a code block sends the message into sticky full document mode. The mid-string fallback fires on takes 5~10 minutes and - >= 16 GB of RAM, and one such string anywhere disables the optimisation for the whole reply. Separately, an unclosed HTML tag degrades silently: fullDocumentMode stays false, nothing is ever committable, and the cache measures slightly slower than not being there (365 ms against 350 ms on my run).

None of this shows up in the benchmark table because it uses prose and equations. Adding one code-heavy reply would make the picture much more representative.

Smaller things

markdown-text.tsx:446-452 swaps text.startsWith(displayed) for a length comparison, justified by the comment at :443 that the producer only appends. That is not the case: chat-adapter.ts:4446 yields "Generating audio..." and :4471 replaces the same part with <audio-player src="data:audio/wav;base64,…" />, which is longer and not a prefix. The old guard rejected it, the new one does not, so the placeholder survives an extra frame (longer if the tab is backgrounded and rAF is suspended). text.startsWith(displayed.text) restores it; keep the length check in front if the scan cost matters.

ROLLBACK_BLOCKS = 8 (:7) has no comment explaining the value, and since the block list interleaves "\n\n" separators it is roughly four content blocks rather than eight. Mutation testing only pins it above 1: 2, 3 and 20 all pass the suite.

parity.inlineMath and parity.inlineMathInlineCode look dead. They mirror a remend handler gated on options.inlineKatex === true, and remend is called with no options everywhere, so remend("$x") === "$x".

src/index.css:2494-2513 is now dead. With the animate plugin filtered out, no data-sd-animate span is ever emitted, and nothing else in the repo reads that attribute.

tests/markdown-block-remount-on-complete.test.ts no longer tests remount on complete. Its three tests are about animation-free props and memoisation, so the name is misleading now.

resetIncrementalState (:490) deliberately leaves this.source alone, which makes renderFullDocument (:502) correct only because all three call sites already assigned it. That is easy to break later without noticing.

On the tests

The prefix equivalence oracle in streaming-render-schedule.test.ts is exactly the right invariant, and because it calls remend live it would fail loudly if remend changed its rules. Both dependencies are pinned exactly, which helps. The corpus is where it falls short: 12 of 15 mutations survive the full 2,289 test suite, including deleting the getEmphasisContext ordering added in b66dbca (the whole content of that commit), stubbing isWithinHtmlTag and isWithinLinkDestination to return false, removing the escaped backtick and escaped dollar skips, and setting ROLLBACK_BLOCKS to 2, 3 or 20.

Instrumenting the corpus explains why: across all 30 cases at every prefix, hasSingleUnderscoreContext, firstSingleAsteriskContext === "inlineCode" and firstBoldOrSingleUnderscoreContext === "singleUnderscore" are never true. Three of the six context constants are never exercised. useCoalescedStreamingText has no behavioural test at all, only a source check that it mentions requestAnimationFrame.

Each of the eight documents in section 2 is short enough to drop straight into MARKDOWN_CASES.

What I checked that is fine

source === committedBlocks.join("") + tail holds on every path (2,811 update calls, no violations). update() is idempotent on repeated input, so the render-phase mutation at markdown-text.tsx:471-479 has no reproducible consequence beyond four new react-hooks/refs lint errors, and lint is not a CI gate. ROLLBACK_BLOCKS = 8 is sufficient against retro-merging constructs; 33 adversarial documents pass, and the real safety comes from the this.tail.startsWith(block, exactLength) check at :570. memo(StreamdownBlockContent) does not break the zustand or useSyncExternalStore subscriptions, and the useMemo on rehypePlugins is load bearing, since streamdown's Block comparator checks e.rehypePlugins !== t.rehypePlugins. parseIncompleteMarkdown={!incrementalRender} matches the library default for completed messages. Block keys, indices and isIncomplete match a full parse across 16,123 prefixes. No conflict with current main. #7892's direct commit path is preserved and #7949 is superseded properly, since no wrappers are created at all now. npm test (2,289 passing), npm run typecheck, npm run build and biome on the changed files are all green.

import remend from "remend";
import { parseMarkdownIntoBlocks } from "streamdown";
import { IncrementalMarkdownCache } from "../src/components/assistant-ui/streaming-render-schedule.ts";
import { stabilizeStreamingMarkdown } from "../src/components/assistant-ui/streaming-markdown.ts";
import { preprocessLaTeX } from "../src/lib/latex.ts";

// exactly what MarkdownTextImpl feeds the cache
const pipe = (text: string) => stabilizeStreamingMarkdown(preprocessLaTeX(text), true);
const filler = (count: number, label = "p") =>
  Array.from({ length: count }, (_, i) => `${label} ${i}\n\n`).join("");

console.log("=== 1. streamdown skips the render when the repaired tail repeats ===\n");
{
  const cache = new IncrementalMarkdownCache();
  let source = "";
  let renderedChildren: string | null = null;
  let renderedBlocks = 0;
  for (let frame = 1; frame <= 24; frame += 1) {
    source += "I am sorry.\n\n";
    const render = cache.update(pipe(source));
    // streamdown's memo compares `children`; it does not compare parseMarkdownIntoBlocksFn
    if (render.markdown !== renderedChildren) {
      renderedChildren = render.markdown;
      renderedBlocks = render.parseMarkdownIntoBlocks(render.markdown).length;
    }
    const actual = render.parseMarkdownIntoBlocks(render.markdown).length;
    if (frame % 4 === 0 || frame === 5) {
      console.log(
        `  frame ${String(frame).padStart(2)}  reply ${String(source.length).padStart(4)} chars` +
          `  children ${String(render.markdown.length).padStart(3)} chars` +
          `  on screen ${String(renderedBlocks).padStart(3)} blocks` +
          `  should be ${String(actual).padStart(3)}` +
          (renderedBlocks === actual ? "" : "   <- stalled"),
      );
    }
  }
}

console.log("\n=== 2. incremental blocks diverge from the full repair ===\n");
{
  const gap = "\n\np0\n\np1\n\np2\n\np3\n\n";
  const cases: [string, string][] = [
    ["four-backtick fence, then ~~", "```x````" + gap + "~~ y"],
    ["unclosed [ in prose", "see [note" + gap + "tail"],
    ["escaped backtick, then $$", "\\`" + gap + "$$"],
    ["run of eight asterisks", "********" + gap + "*a"],
    ["** inside a fence", "```\n**\n```" + gap + "_u then **v then **"],
    ["* inside inline code", "use `a *b* c` here" + gap + "****x"],
    ["escaped fence \\```", "a ``` b\n\nc \\``` d" + gap + "- >= 4 GB"],
    ["repeated link label", `[x]: https://e.test\n\n${filler(12)}[x]: https://e.test\n\nq\n\n`],
  ];
  for (const [name, document] of cases) {
    const cache = new IncrementalMarkdownCache();
    let report = "identical at every prefix";
    for (let length = 0; length <= document.length; length += 1) {
      const input = pipe(document.slice(0, length));
      const render = cache.update(input);
      const incremental = render.parseMarkdownIntoBlocks(render.markdown);
      const full = parseMarkdownIntoBlocks(remend(input));
      if (JSON.stringify(incremental) !== JSON.stringify(full)) {
        report =
          `prefix ${String(length).padStart(3)}  ` +
          `rendered ${JSON.stringify(incremental.at(-1))}  expected ${JSON.stringify(full.at(-1))}`;
        break;
      }
    }
    console.log(`  ${name.padEnd(30)} ${report}`);
  }
}

console.log("\n=== 3. share of the reply still re-parsed per update ===\n");
console.log("  1.00 means the whole document is repaired and split on every token.\n");
{
  const probe = (name: string, document: string) => {
    const input = pipe(document);
    const render = new IncrementalMarkdownCache().update(input);
    const ratio = render.markdown.length / input.length;
    console.log(
      `  ${name.padEnd(34)} ${ratio.toFixed(2)}${ratio > 0.5 ? "   <- optimisation off" : ""}`,
    );
  };
  const tail = filler(60);
  probe("plain prose (baseline)", tail);
  probe("paragraph ends in `inline code`", "run `foo`\n\n" + tail);
  probe("```sh   echo $HOME", "```sh\necho $HOME\n```\n\n" + tail);
  probe("```php  $x = 1;", "```php\n$x = 1;\n```\n\n" + tail);
  probe("```make $(CC) x.c", "```make\nall:\n\t$(CC) x.c\n```\n\n" + tail);
  probe("`echo $HOME` inline", "run `echo $HOME` now\n\n" + tail);
  probe("```js   const s = 'a`b';", "```js\nconst s = 'a`b';\n```\n\n" + tail);
  probe("```js   /[^a]/  (reads as footnote)", "```js\nconst re = /[^a]/;\n```\n\n" + tail);
  probe("prose: takes 5~10 minutes", "takes 5~10 minutes\n\n" + tail);
}

Two follow-ups on top of this round.

f2a7904 is the fix for the retained-block report above.

771fb27 covers three more places where the retained prefix did not model what remend does over the whole document. Each produced a block list that differs from a full repair, and each is now in the prefix-equality corpus:

• An unmatched [ in a retained block moved remend's dangling-link completion out of the tail. Pick x in the interval [0, 1) for the ratio. lost the completion block, and see ![alt text diverged on the whole body because remend truncates there. Brackets outside code now hold the neutrality gate.
• updateDisplayMathParity stopped one character short of every block, so a backtick ending a retained block never closed inline code and the tail gained a spurious $$. remend's own scan can stop early because it only ever reads a whole document; a retained block boundary is always interior to one.
• remend orders its bold and underscore closers from a raw indexOf("**"), so char **argv; inside a fence still has to seed the bold context even though it must not reach the fence-aware counter.

Verification for both commits: npm test 2291 passed, npm run typecheck, prefix equality against a full Streamdown split at every character prefix over the corpus plus periodic and bracket-heavy documents, 600 randomized streaming cases, and a Chromium run of the production render path.

Codex Review: Didn't find any major issues. More of your lovely PRs please.

Reviewed commit: e652271d45

Thanks @mahiatlinux, this is an unusually careful review and it found real problems. Your reproduction script ran as written. Everything below is on dad4740.

1. The stall when the repaired tail repeats

Your diagnosis matches what I landed in f2a7904, including the part that matters most: changing the callback identity does not help, because the comparator does not look at it. The cache now prices a candidate commit before applying it and holds those blocks in the live tail for one more update when the resulting string would repeat. In Chromium the repeating reply goes from 5 of 61 paragraphs to 61 of 61.

Your point about plugins is the piece I had not stated: the hoisting in this PR is what armed the bail-out, since the inline object literal made e.plugins === t.plugins false on every render before. That belongs in the description and I have added it.

2. The eight divergences

All eight are now identical at every prefix, and all eight are in MARKDOWN_CASES. Three had already gone in with 771fb27, the rest are in c1ccbb9.

• hasNeutralRepairParity omits emphasisInlineCode: added to the gate. It mirrors remend's fence-aware inline-code scan, which the three character isTripleBacktick window cannot express.
• Unclosed [: RepairParity now carries a bracket depth, counted outside code as remend counts it, and the gate holds on it. Measured against prose, closed links, reference links, code containing brackets and tables, the retention cost is nil; it only bites where the model was unsound.
• updateDisplayMathParity stopping a character early: bound corrected. remend can stop early because it only ever reads a whole document; a retained block boundary is always interior to one.
• updateAsteriskParity returning before counting: countsAsSingleAsterisk now runs before the pair branch consumes the next character.
• Fenced **: it seeds the bold context without reaching the fence-aware counter, since remend orders its closers from a raw indexOf("**") while A() skips fences.
• INLINE_CODE_ASTERISK_CONTEXT: now `a *b* c`, and the underscore twin now `a _b_ c`. You were right that the single marker contradicted the comment above it.
• Escape before fence: updateEmphasisParity consumes an escaped backtick first, as remend's inline-code scan does. The later text[index - 1] !== "\\" guard became redundant and is gone.
• Repeated link label: the cache records the definition labels it retains and gives up the prefix when the live tail redefines one, rather than adding another blanket bail-out.

3. Retention

paragraph ends in inline code was the text.length - 1 bound and is now 0.07 rather than 1.00, which is the shape you called very common in coding replies.

The rest of that table is unchanged, and here I think the reasoning is wrong rather than the measurement. remend's math parity is not inert on fenced dollars, it is fence-blind, and the effect is visible as soon as the tail has a marker to act on:

remend("see *italic")                                  // "see *italic*"
remend("```sh\necho $HOME\n```\n\nsee *italic")        // "see *italic"   closer withheld

Your para example has no marker, so nothing distinguishes the two runs. Retaining a prefix whose dollar parity is not neutral therefore does change how the tail is repaired, and ignoring fenced dollars would break the prefix oracle rather than satisfy it. Recovering that retention needs a context prefix that reproduces an open inline-math state, which the current mechanism cannot express and which I would rather do as its own change than fold in here.

The remaining bail-outs I have left alone on the same reasoning: the footnote regexes are copied from Streamdown's own splitter, which single-blocks the whole reply on the same raw match, so making ours context aware would only desync it.

Smaller things

• text.startsWith(displayed.text) is restored, with the length check still in front. The audio path is a real trigger: chat-adapter.ts:4447 yields Generating audio... and :4476 replaces the same part with the player. Measured cost of the scan is 59 ms across a 175,000 character stream, against the 132 ms the whole incremental parse now takes, so it is not worth trading correctness for.
• ROLLBACK_BLOCKS now says what it is and that the list interleaves separators.
• resetIncrementalState assigns this.source itself instead of relying on its callers.
• parity.inlineMath and parity.inlineMathInlineCode: the handler is indeed unreachable at remend 1.3.0. I left them, because emphasisInlineMath already dominates them on every input I could construct, so removing them changes nothing measurable while loosening a safety gate against a pinned dependency.
• The data-sd-animate rule in index.css: left in place. It costs nothing at runtime and it is the fix for a real visual bug if the animation ever comes back.

Tests

Your eight documents are in the corpus, plus three that reach contexts nothing previously touched. Instrumenting the corpus before, hasSingleUnderscoreContext, firstSingleUnderscoreContext === "inlineCode" and firstBoldOrSingleUnderscoreContext === "singleUnderscore" were never true at any prefix, which is how two of the context constants above stayed wrong. All seven are exercised now.

npm test 2293 passed, npm run typecheck, biome clean on the changed files, prefix equality over the corpus plus periodic and bracket-heavy documents, 600 randomized streaming cases, and a Chromium run of the production render path for the stall and the reset.

@codex review

@codex review

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: 15d19b89ca

Reviewed this at head dad474009 against merge base 10f34dbf6. The core claim holds up, and I have independent numbers for it plus a verdict on each of the three Codex findings.

The optimisation works

Two isolated Studio installs (install.sh --local from each tree, so each serves its own bundle), one deterministic mocked SSE producer, no model and no GPU. Both sides get the same 175,000 character reply, then 4,000 characters appended over 8 seconds, and are photographed at the same elapsed time from the producer's start.

In the same 8 seconds of producer time:

The DOM figure lands within a tenth of a percent of the -79.6% in the description. The saturation also showed up in my own harness clock: the 5s and 7s capture deadlines landed at 7.004s and 10.016s on the old renderer because the page could not service them, while the new one hit 5.002s and 7.000s.

At 2 seconds:

At 5 seconds, where the old renderer has already finished its (much shorter) stream:

One caveat on my own harness rather than on this PR: the producer is driven by requestAnimationFrame, so a starved renderer emits fewer markers and the two sides genuinely stream different text. That means my final text hash cannot be used as an equivalence control. Equivalence rests on the every-prefix block equality test in the suite instead.

Separately, replaying just the repair and split path over 420 late-stream updates on a 175,000 character reply reproduces the headline number: 8,689 ms to 76 ms, or -99.1% against the -98.9% in the description.

On the three review comments

Parser identity (streaming-render-schedule.ts:451). This was real, and it was a correctness bug rather than a throughput one. On the earlier head I could drive the display to freeze at 8 blocks while 120 existed, with 112 blocks simply never appearing, on any run of repeated blocks (identical list items, repeated rules). Worth noting for the future that the existing assertion style could not catch it: render.parseMarkdownIntoBlocks(render.markdown) calls the parser directly, which always recomputes, whereas Streamdown reaches it through useMemo(() => h(Se), [Se, h]). The renderGeneration work on the current head resolves it, and I can no longer reproduce any missing blocks.

Footnote detection (streaming-render-schedule.ts:535). I would leave this exactly as it is. The regex does over-match /[^a-z]/, but Streamdown 2.5.0's own parseMarkdownIntoBlocks short-circuits on the identical pair of raw regexes and returns the whole document as one block. Matching it is what keeps the two in agreement; making the detection code-aware would produce N blocks where the splitter produces 1. The suggested cost is also not what I measured: that case runs at +2.7% against the full-document path, because full-document mode is the correct and cheap answer there. The only gap is test coverage, since /[^\s]+/ in the existing case escapes the regex purely because a backslash is not in [\w-].

Math markers in fenced code (streaming-render-schedule.ts:293). This one is real, still present at dad474009, and worse than the comment suggests. The remedy in the comment would break things though: remend counts $ and $$ deliberately without fence awareness (yn and Nn skip backticks only when they are not part of a ``` run), so a fence-aware tracker would disagree with the repair it is mirroring.

The problem is the retry, not the parity. Because emphasisInlineMath never returns to neutral, nothing ever commits, and every update pays the incremental scan on top of the full repair it was meant to replace:

So a shell snippet anywhere in a reply makes this path about 2.3x slower than the renderer it replaces, which matters because code-heavy replies are the common case.

The description already has the right principle for this ("keeps that fallback cost equivalent to the existing renderer rather than repeatedly retrying the failed prefix"), it is just applied only to the mid-string repair path. Extending it to a tail that has committed nothing fixes it:

const STALLED_TAIL_CHARACTERS = 32_768;

if (!commit.parity) {
  if (commit.repairBroke || this.tail.length > STALLED_TAIL_CHARACTERS) {
    return this.renderFullDocument(markdown);
  }
  return this.render(repaired);
}

That takes echo $HOME from +132.9% to -2.6% and cost $$ each from +121.3% to +1.2%, with the clean case unchanged at -99.1% and the suite green at 2,293 passing. A character budget rather than a block count because characters are what the repair scan actually costs, and a genuinely transient imbalance closes far below it, so the recovery behaviour is kept.

Nice work on this one, the measurements back up what the description claims.

Thanks @danielhanchen. The stalled-tail finding is right and I had it wrong, so that one is fixed in bb228e5.

I reproduced your table independently on 15d19b89c, timing repair plus the split Streamdown then runs, 420 late-stream updates on a 175,000 character reply:

                                  incremental   full repair    change
clean                                  103 ms       2436 ms    -95.8%
one ```sh / echo $HOME fence          7319 ms       2723 ms   +168.8%
one ```text / cost $$ each fence      7544 ms       2739 ms   +175.5%
inline `echo $HOME`                   7190 ms       2723 ms   +164.0%

With the character budget applied those become -2.7%, +1.9% and +0.6%, clean unchanged at -96.0%. Your -2.6% and my -2.7% on the same case is closer agreement than I expected across two machines.

What I got wrong is worth stating plainly, because it is a measurement mistake rather than a judgement call. I had rejected this on the grounds that the cost "falls back to what main already pays", and I reached that by comparing characters repaired over the stream, 892k against 895k for the full-document path. That metric looks equivalent and is not, because it counts neither the boundary scan nor the second block split. Wall clock says 2.7x. I have corrected that reply and flipped the reaction on the item.

I also took the test-coverage gap you and @mahiatlinux both named. The existing character-class case used /[^\s]+/, which never matched the footnote regex in the first place, so it asserted nothing about the branch it was named for. It now covers both sides: /[^a-z]/ does match, Streamdown's splitter returns the whole reply as one block for it, and the cache agrees by taking the full-document path; /[^\s]+/ keeps retaining.

One tradeoff in the fix worth flagging. The budget reuses the existing sticky fallback, so a reply whose live tail passes 32,768 characters with nothing committed stays on the full-document path even if the marker later closes. A single fenced block longer than the budget is the realistic way to hit that. It is equal to the current renderer rather than better, which seemed like the right end of the trade against retrying a prefix that keeps failing, but it is a real limit rather than none.

Your other two verdicts match where this ended up. The footnote regexes are unchanged and I would leave them: they are copied from Streamdown 2.5.0's own short-circuit, so matching it is what keeps the two in agreement. And renderGeneration is what closed the parser-identity bug, after lastMarkdown alone turned out to cover only the retaining half; dropping retained blocks cannot wait for a different string, so that path moves the render identity instead.

Since dad474009 there are three more commits, all from review: a2a0264 and 15d19b8 for link reference definitions, where my first attempt at the duplicate-label check was itself wrong in both directions against Marked's table and got replaced by a single neutrality term, and 15d19b8 also stops the cache redoing its work on renders that carry unchanged text. npm test is at 2,296.

@codex review

Thanks for the correction, and for reproducing the table independently. Agreement that close across two machines is worth more than either number alone.

I put the branch through a broader simulation before signing off, aimed at the things that only show up off this machine: other browser engines, other line endings, and inputs that are not ASCII. Everything ran in isolated sandboxes on Linux against bb228e55, with npm ci from the committed lockfile.

What was checked

Differential fuzz, 14,234,746 prefixes, 0 failures. A grammar of about 40 Markdown fragment generators (headings, setext, fenced and tilde and indented code, ordered and nested and task lists, blockquotes, GFM tables, rules, closed and unclosed HTML, all four math syntaxes, footnotes, link reference definitions, autolinks, escapes) crossed with truncated tails and the mid-string repair shapes (5~10, >= 16 GB, 2 ** 3, *.py, _private). Every document replayed at every prefix, asserted against parseMarkdownIntoBlocks(remend(input)). Two assertion modes: the direct call, and one that goes through Streamdown's real useMemo(() => h(Se), [Se, h]) semantics, since a direct call always recomputes and structurally cannot see a stale committed prefix.

Browser engines. The cache was bundled and the same corpus run inside Chromium, Firefox and WebKit as well as Node. All four produce byte-identical digests over the whole prefix history, and each matches a full Streamdown split, across 1.7M prefixes per engine. Chromium covers Chrome and Edge; the desktop shell's WebView is Chromium on Windows and Linux and WebKit on macOS, so those three are the shipped matrix. No lookbehind, named groups or newer built-ins in the changed files; the only notable construct is \p{L}\p{N} with the u flag, which every target has had for years.

Whole app, all three engines. A real Studio, a mocked SSE stream and no model, streaming a fixed sequence of chunks so content is identical by construction:

Identical across engines, and identical to the merge base on all three. That also retires the caveat on my earlier comment: the final-hash control failed there only because that producer was driven by requestAnimationFrame, so a starved renderer received fewer markers and the two sides genuinely streamed different text. With the content pinned it is a real equivalence check, and it passes.

Line endings and Unicode. CRLF documents across every construct, lone CR, mixed endings; streams cut through a surrogate pair (emoji, ZWJ sequences, flag pairs); CJK, RTL, combining marks, zero-width joiners; astral-plane word characters around emphasis markers. All match a full split at every prefix.

Lifecycle and compatibility. Non-prefix edits, shrinking replies, repeated identical updates, empty and single-character inputs, aborts mid-token in six shapes, two concurrent caches. Plus the forwards-compatible degradation of withoutStreamdownAnimationPlugin when animatePlugin is absent, when it stops exposing rehypePlugin, and when the plugin is not in the array. Old installs are unaffected: the PR touches five frontend files and nothing outside assistant-ui, there is no persisted format, and a completed message takes the normal whole-document path.

One thing on the tradeoff you flagged

The limit is real but the example is not the one that triggers it. A single fenced block longer than the budget keeps retaining, at any size I tried up to 80,000 characters: while the fence is open the tail lexes to a handful of blocks, candidateCount stays 0, and the stalled check is never reached.

What does reach it is an inline marker with many paragraphs before its closer. And since the budget is what gets spent before giving up, and that spending grows with the square of the tail, the value matters more than it looks. An emphasis marker closing 40,000 characters later, 420 updates, five repetitions, median against the full-document path:

The distributions do not overlap. I pushed e679d24 setting the budget to 8,192 with that measurement in the comment, plus regression cover for both shapes, since the existing case only covers a marker that never closes at all. 8,192 is still about 1,300 words of slack, so a marker a later line genuinely closes keeps its recovery, and the transient case still passes.

npm test 2,298, typecheck, biome and eslint all clean.

Correcting the limitation I stated above, since @danielhanchen's e679d244 shows I had the shape wrong.

I said a single fenced block longer than the budget was the realistic way to reach it. It is not, and the reason is the one his commit message gives: while a fence is open the tail lexes to one block, so candidateCount stays 0, findCommitBoundary never runs, and the branch that spends the budget is never reached. Measured on this head:

open fence   10,026 chars -> blocks=1  candidateCount=0  sticky=false
open fence   40,026 chars -> blocks=1  candidateCount=0  sticky=false
open fence  120,006 chars -> blocks=1  candidateCount=0  sticky=false

and once the fence closes, retention resumes fully: a 12,000 character fence followed by 200 paragraphs ends with a 24 character live tail. What actually reaches the budget is an inline marker with many paragraphs before its closer, which is what he measured and sized against.

His 8,192 is the better number and I can reproduce why. On the same 420-update, 175,000 character benchmark the stalled cases now sit at -1.1%, +0.7% and -1.3% against the full-document path, against -2.7%, +1.9% and +0.6% at 32,768, with the clean case unchanged at -95.9%.

4100f918 on top handles the last round: a link reference label may contain an escaped bracket, [foo\]bar]: /url, which Marked registers and the character class did not, so that definition was retainable and a redefinition diverged at prefix 105. The label grammar now takes escapes.

The other two from that round I have argued rather than changed, both on the comments themselves. The completion render is not skipped, because the comparator does check isAnimating and that is what the status flips. And the cache call in render survives the only render React discards here, StrictMode's double invoke, which loses 0 blocks now against 392 on the commit before the unchanged-text guard went in.

Codex Review: Didn't find any major issues. More of your lovely PRs please.

Reviewed commit: 4100f918b1

@codex review

Codex Review: Didn't find any major issues. Bravo.

Reviewed commit: 6b95425a80