useObjectChat rebuilds its DefaultChatTransport on every render — the memo's `body` dep is an inline literal every caller recreates (finding, dormant)

[yinlianghui]

Observation-class. Nothing a user hits today; filing so it is on the record rather than rediscovered.

packages/plugin-chatbot/src/useObjectChat.ts memoizes the transport:

const transport = useMemo(() => {
 if (!isApiMode) return undefined;
 return new DefaultChatTransport({ api: api!, ... });
}, [isApiMode, api, headers, body, model, systemPrompt, streamingEnabled, conversationId]);

body and headers are object props, and every caller passes a fresh literal on each render. AiChatPage's ChatPane is the clearest case:

body: {
 context: {
 activeApp: 'AI',
 agentName: activeAgent,
 autoPublishAiBuilds: getRuntimeConfig().features.autoPublishAiBuilds,
 ...(editPackageId ? { packageId: editPackageId } : {}),
 },
},

That object has a new identity on every render, so the memo never hits and a DefaultChatTransport is constructed on every render of every chat surface — during a streaming turn, that is once per token batch.

Why it is dormant rather than broken

@ai-sdk/react@4.0.59's useChat does not rebuild its Chat when the transport identity changes. It stores the latest transport in a ref and its own chatOptions.transport delegates through getTransport():

latestRef.current = { ..., transport: options.transport };
const chatOptions = { ..., transport: { sendMessages: (o) => getTransport().sendMessages(o), ... } };
const shouldRecreateChat = "chat" in options && options.chat !== chatRef.current
 || "id" in options && options.id != null && chatRef.current.id !== options.id;

useObjectChat passes neither chat nor id, so the Chat object — and with it the whole message list — survives. The wasted construction is the entire cost.

Why it is worth recording anyway

The safety here is entirely a property of the SDK's internals, not of this call site. The memo looks like it is protecting something, and the dep list reads as if a changing transport would be disruptive. An SDK upgrade that starts keying the Chat on the transport (or a future id being threaded through) would turn a silent inefficiency into a thread that resets on every render — and the memo would give a reviewer no warning, because it is already written as though it works.

Two candidate directions, neither obviously right without measuring:

• memoize at the call sites (body / headers behind useMemo), which fixes it wherever it is done but is unenforceable and will re-rot;
• drop body/headers from the dep list and read them through a ref inside prepareSendMessagesRequest, which is what the file already does for model (modelRef) and for the handoff id (parentConvRef) — the established idiom in this very hook, and the only one that cannot be undone by a new caller.

Found while working #2627 (the AI build thread's blank-out was a different mechanism entirely — a pane remount driven by useChatConversation clearing the conversation id; PR #4183). This was ruled out as its cause and is unrelated to it.

[claude]

Findings triage (first grade; premise check @ origin/main e1ade8f): HOLD — finding stands.

Anchors verified live: the transport memo at packages/plugin-chatbot/src/useObjectChat.ts:383 (new DefaultChatTransport at :385), and — the detail that makes the card's second direction concrete — the ref idiom it proposes is already the file's own house style two dozen lines above: modelRef at :357-358 and parentConvRef at :371-376. So the suggested fix is not a new pattern, it is the pattern this hook already uses for exactly this problem.

Held rather than promoted because the card is honest about what it measured: the waste is real, the breakage is not — @ai-sdk/react's Chat survives transport identity changes, so nothing a user hits today. And the two candidate directions differ in more than mechanics (call-site memoization is unenforceable; the ref rewrite changes when body/headers are sampled), which is a judgement no one has taken. Both are cheap to revisit.

⚠️ Recorded restart condition, so this does not just age: an @ai-sdk/react major bump, or any change that starts passing chat/id through useObjectChat, converts this from waste into a per-render thread reset. A dependency bump touching @ai-sdk/react is the trigger to re-grade this immediately rather than at cadence.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Findings cadence re-check @ origin/main 6314e87: HOLD — finding stands.

Premise live: packages/plugin-chatbot/src/useObjectChat.ts:383-398 — the transport useMemo closes over body and lists it in its deps ([isApiMode, api, headers, body, …]), so any caller passing an inline body literal recreates DefaultChatTransport every render, exactly as filed. Held: perf-class, no correctness fault observed; the fix (stable serialization or ref-equality guard) is small but touches every caller's contract expectations, natural to bundle with the next chatbot-transport change.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Findings cadence re-check @ origin/main 6d01319: HOLD — finding stands, premise frozen.

The memo dep list is verbatim at useObjectChat.ts:417 ([isApiMode, api, headers, body, …]), @ai-sdk/react is still ^4.0.59 in plugin-chatbot/package.json:34, and the file is untouched since filing — so the dormancy contract (SDK stores transport in a ref, no chat/id keying) still holds and the cost remains construction-only. Held: the card's second direction (ref-read body/headers inside prepareSendMessagesRequest, matching the hook's own modelRef/parentConvRef idiom) is the durable fix, but nothing user-visible pushes on it today. Restart condition: promote before any @ai-sdk/react major/minor bump that touches useChat's chat-recreation keying, or the moment an id is threaded through useObjectChat — either flips this from waste to a thread-resetting bug.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Findings state conversion (batch 3): finding → pm:on-hold, type Task.

Held three times without leaving the label — converting per the 2026-08-13 state-semantics ruling.

Hold rationale (unchanged): construction waste only — @ai-sdk/react@4.0.59 keeps the Chat alive across transport identity changes, so nothing user-visible breaks today. The durable fix (ref-read body/headers inside prepareSendMessagesRequest, matching the hook's own modelRef/parentConvRef idiom) is recorded on the card.

Restart-when: the @ai-sdk/react version in packages/plugin-chatbot/package.json moves off ^4.0.59, or chat/id starts being passed through useObjectChat — either flips this from waste to a thread-resetting bug. Re-grade IMMEDIATELY on that trigger, not at cadence.

Trigger files: packages/plugin-chatbot/package.json, packages/plugin-chatbot/src/useObjectChat.ts.

Hold date: 2026-08-17. 本评论来自分诊座位 Routine,不构成认领。

---

Generated by Claude Code

[os-zhuang]

On-hold daily batch (triage seat, round of ~14:47Z fire): Restart-when fired — plugin-chatbot/package.json now carries "@ai-sdk/react": "^4.0.68" (off the pinned ^4.0.59), and this hold's own instruction is "re-grade IMMEDIATELY on that trigger, not at cadence". pm:on-hold → pm:queue. Claimer: re-verify the transport question against 4.0.68's actual API before assuming the hold-era analysis still describes it.

---

Generated by Claude Code