lag when streaming long tool-input deltas (useUIMessages / useThreadMessages)

[KevinGrajeda]

I think I found the core issue that eventually led me to #187

It looks like streaming long tool-input deltas causes lag in useUIMessages / useThreadMessages, while normal text deltas do not trigger the same slowdown.

Here’s a video showing the issue (left = long tool input, right = normal text):

issue4.mp4

Left side:

I give the agent a ~12,000‑character HTML string and ask it to save it to a file via a (mock) writeFile tool.

Since tool calls stream their args, the whole 12k characters are streamed to the tool input.

After a few seconds, the UI begins lagging heavily to low fps

Right side:
I give the exact same 12k characters but simply ask the agent to "repeat this"

Even though the assistant message gets extremely long, there’s no lag at all.

---

It seems that tool-input deltas are handled differently from normal text deltas, and something about how useUIMessages or useThreadMessages processes the tool‑input stream causes massive slowdown.

But normal assistant deltas of the same size do not cause any slowdown, even when they are equally huge.

---

If helpful, I can provide the exact reproduction setup used in the video.

It’s just a small mock tool on top of the agent example

[ianmacartney]

Yes a production would help - as are any PRs. Sorry for the delayed responses here

…

On Wed, Nov 26, 2025 at 4:01 PM Kevin Grajeda ***@***.***> wrote: *KevinGrajeda* created an issue (get-convex/agent#190) <#190> I think I found the core issue that eventually led me to #187 <#187> It looks like streaming long tool-input deltas causes lag in useUIMessages / useThreadMessages, while normal text deltas do not trigger the same slowdown. Here’s a video showing the issue (left = long tool input, right = normal text): https://github.com/user-attachments/assets/e3025316-faf8-4318-96d9-ca1a6169b609 Left side: I give the agent a ~12,000‑character HTML string and ask it to save it to a file via a (mock) writeFile tool. Since tool calls stream their args, the whole 12k characters are streamed to the tool input. After a few seconds, the UI begins lagging heavily to low fps Right side: I give the exact same 12k characters but simply ask the agent to "repeat this" Even though the assistant message gets extremely long, there’s no lag at all. ------------------------------ It seems that tool-input deltas are handled differently from normal text deltas, and something about how useUIMessages or useThreadMessages processes the tool‑input stream causes massive slowdown. But normal assistant deltas of the same size do not cause any slowdown, even when they are equally huge. ------------------------------ If helpful, I can provide the exact reproduction setup used in the video. It’s just a small mock tool on top of the agent example + a long HTML file streamed as tool input. — Reply to this email directly, view it on GitHub <#190>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQW5ICR6TI5BOJZYT5FT36Y5N3AVCNFSM6AAAAACNKA2HE2VHI2DSMVQWIX3LMV43ASLTON2WKOZTGY3DSMZZGY2TENY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[brandon-julio-t]

Yes a production would help - as are any PRs. Sorry for the delayed
responses here
…

I am also having this issue and it seems to be caused by tool call with big parameters. My use case is business intelligence agent, which is basically just a Text-to-SQL agent for but heavy analytical queries, so the SQL query can be quite long, and when it does the UI lags and I even got the legendary 1 FPS. Additional info is that there's at least 90+ table involved in the BI app that I'm building, so that might contribute to be the edge case of this problem, because there are going to be many tool calls and SQL query string length grows too.

My tool is just as simple as this:

export function queryTool({ timezone }: { timezone: Timezone }) {
  return createTool({
    description: "Execute a read-only SQL query against Redshift.",
    inputSchema: z.object({
      explanation: z.string().trim().min(1),
      query: z.string().trim().min(1),
    }),
    execute: async (ctx, input) => {
      return await executeQuery(ctx, {
        ...input,
        timezone,
      });
    },
  });
}

You can imagine executeQuery is just a drizzle raw query.

Maybe when I have time on some weekend I'll create a repo for this.

Another observation of problematic use case is generating chart, time series data can get long and many quickly, causing the same performance issue.

This is what I used:

export function chartTool() {
  return createTool({
    description:
      "Render a chart in the UI from already-computed data. Use this after you have the final aggregated data you want to visualize. Provide chartType (area, bar, line, or pie), categoryKey for the x-axis or pie labels, series for the numeric fields to render, and data for the final rows to visualize. You can also provide title, description, showGrid, and showLegend. Prefer line charts for time series, bar charts for ranked comparisons, area charts for cumulative-looking trends, and pie charts only for simple share-of-total views with a single numeric series. Keep the data tight and important only: high-volume chart payloads can hurt UI performance and may crash the user's device.",
    inputSchema: chartToolInputSchema,
    execute: async (_ctx, input) => {
      return {
        points: input.data.length,
        rendered: true,
        series: input.series.length,
      };
    },
  });
}

Another observation is that I modified the default saveStreamDeltas to be per line and throttle by 2500ms, which seems to alleviate the performance issue, reducing the computation load.

saveStreamDeltas: {
    chunking: "line",
    throttleMs: 250 * 10,
}

From these observations I think there's a big chance that this problem has something to do with tool streaming.

[brandon-julio-t]

I may have a fix, this bun patch seems to fix the performance issue during tool streaming. I have been using this for a while and in production too.

https://gist.github.com/brandon-julio-t/b203784e2421b35dd7bf7e427483919e

here are some video demonstrations, feel free to to skip 3/4 of the video or play it at 2x because I am using gpt-5-nano, so it runs around for a while.

• Original (lags)

original.mp4

• Patched (no lag, or at least minimal lag)

fixed.mp4

[brandon-julio-t]

I have made a small benchmark repository for this, although it's not a full reproduction app first as it'll require lots of setup like infra, guiding the AI, etc.

hopefully this serves as a good inspiration for now

https://github.com/brandon-julio-t/agent-190-repro

btw disclosure these are made by gpt-5.4-xhigh, but behaviors are verified by me