# \[Bug\]: Streamed replies are rescanned from the top on every update · Issue \#19992 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/19992)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/19992)

---

### Before submitting

- [x] I searched existing issues and did not find a duplicate.
- [x] I included enough detail to reproduce or investigate the problem.

### Area

apps/server

### Steps to reproduce

1. Ask any agent for a long reply (tens of KB) that streams inside a code fence or a long paragraph.
2. Watch server CPU while it streams.

### Expected behavior

Per-update server work stays roughly constant as the reply grows.

### Actual behavior

`makeAssistantStreamingFilter` (`apps/server/src/orchestration-v2/assistantStreaming.ts`) rescans the whole accumulated reply with `splitBufferedAssistantText` on every update past its 400 ms window, because no new markdown boundary appears. Work grows quadratically with reply length, on the event loop. A 50 KB fenced reply in 10-character updates costs ~282 ms of CPU; a ~50 KB newline-free paragraph ~129 ms.

### Impact

Minor bug or occasional failure

### Version or commit

`main` at 26fffe5ae

### Environment

Any provider, any client. Server-side.

### Logs or stack traces

None.

### Workaround

None.

Fix: #19990

Implemented with Claude Opus 5.5 in T3 Code. Reviewed with GPT-6.1-Sol.