[Bug]: Typing after a selected skill lags, worse on long prompts#30657

opened11d agobyUUmais-Adeed

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 any project whose provider offers skills.
  2. In the composer, pick a skill from the $ or / menu so it becomes a chip.
  3. Keep typing after the chip, ideally until the prompt is a few hundred characters long.

Expected behavior

Typing after a skill chip costs the same as typing plain text.

Actual behavior

Each keystroke gets slower once a skill is selected, and the gap grows with prompt length.

Median time per keystroke (dev build, e68e19d605, measured in the browser):

PromptPer keystroke
plain, short18.3 ms
skill chip, short19.5 ms
plain, ~800 chars21.7 ms
skill chip, ~800 chars31.7 ms

A skill chip is serialized as $name. mayContainMath in packages/shared/src/markdownMath.ts treats any $ as possible math, so collectComposerInlineTokens and buildTiptapContent run the full remark + GFM + math parser over the whole prompt. That happens several times per keystroke: cursor conversions in ComposerPromptEditorTiptap and ChatComposer, plus buildDocJson passed as useEditor's content option, which is rebuilt on every render although it is only read on mount. splitPromptIntoComposerSegments goes from 3 µs on plain text to about 250 µs with one $skill.

Impact

Typing visibly lags after selecting a skill, worse on long prompts.

Version or commit

e68e19d605 (main)

Environment

Web, Linux, Chromium-based browser, dev build.

Synced from GitHub

Note

Comment written by Claude Opus 5.5 in T3 Code, on behalf of Jaiden

Open PR #30658 targets this exact case and looks likely to fix it. It links this issue through a git.cafe URL, so GitHub does not show it as linked here.

How I got there: the PR skips math parsing when the prompt has fewer than two $, because one chip adds one $ and that cannot close a formula. It also builds the editor's initial document once instead of on every render. Its own measurements with one skill chip go from 22.6 → 12.5 ms per keystroke at 840 chars, and 39.7 → 14.2 ms at 3,000 chars.

Known limit, stated in the PR: prompts with two or more $ (for example two skill chips) still go through the parser.