[Bug]: Composer becomes extremely laggy/unresponsive with large input content

Before submitting

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

Area

• apps/web

Steps to reproduce

1. Open the T3 Code web app (local web app at the default port) in a browser.
2. Start a new conversation and type (or paste) a very large prompt into the input/composer box — for example a large code snippet, a long pasted log, or a big block of text (tens of KB or more).
3. Continue typing, selecting text, or scrolling inside the composer.
4. Observe the UI behavior while the composer holds this large content.

Expected behavior

Editing, typing, and scrolling inside the composer should stay reasonably responsive even with large content, and typing should not visibly lag behind keystrokes.

Actual behavior

As soon as the input box contains a large amount of content, the whole UI becomes extremely laggy and nearly unresponsive:

• Typing lags badly; characters appear noticeably late or the input freezes for a while.
• Selecting text and moving the caret feel very sluggish.
• Scrolling inside the composer (if enabled) stutters.
• Even interacting with the rest of the page can feel slow while the large content is in the composer.

Impact

• Major degradation or frequent failure

Version or commit

T3 Code latest release (checked from the Releases page), web app

Environment

• OS: macOS
• App: web app in a browser (reproduced with Chrome / Safari)
• Server: npx t3@latest

Logs or stack traces

No console errors observed; the issue appears to be a pure performance/rendering problem with no error output.

Screenshots, recordings, or supporting files

No attachments yet — can add a screen recording showing the lag if needed.

Workaround

N/A — clearing the composer restores responsiveness, but the lag returns as soon as large content is entered again.

---

Possible cause (for maintainers): the composer may be re-rendering or re-analyzing the full content on every keystroke (e.g., syntax highlighting, token counting, or a large state object in a framework dependency). A debounce, memoization, or limiting expensive work to what's visible would likely help a lot. Happy to provide a screen recording or more details if useful.

Start in apps/web by locating the composer implementation, then reproduce the problem in a browser with a tens-of-kilobytes prompt while profiling typing, selection, scrolling, and page interaction. Trace the work triggered by each edit and verify that large content remains responsive without changing normal composer behavior.