docs/ai-chat/fast-starts.mdx
The first turn of a brand-new conversation pays for the chat.agent run's cold start: dequeue, process boot, onPreload / onChatStart hooks, and only then the LLM call. Two features address this from different angles.
| Preload | Head Start | |
|---|---|---|
| What it does | Eagerly triggers the run before the first message | Runs step 1's LLM call in your warm process while the agent boots in parallel |
| First-turn TTFC win | Hides agent boot if the user does send a message | ~50% reduction (LLM TTFB floor); boot fully overlaps with TTFB |
| When to fire | Page load / input focus — your call | First message arrival — automatic |
| Cost when user never sends | Idle compute until the preload window times out | Zero (no run was triggered) |
| Requires a warm server process | No — works for browser-only surfaces | Yes — your route handler runs step 1 |
| Requires LLM keys client-side? | No | No — keys stay in your warm server |
| Bundle constraints | None | Route handler must import schema-only tools (no heavy executes) |
Pick one, not both. Running both for the same chat is wasted work — Head Start gates on a real first message, so adding Preload on top eats the idle-compute cost Head Start was avoiding.
Use Preload when the chat surface is browser-only, when you don't have a warm Node/Bun/Edge process serving the page, or when you can confidently predict the user will send a message (the run never goes idle).
Use Head Start when the chat lives behind a warm server (Next.js App Router, Hono, SvelteKit, Workers, etc.) and you want first-turn TTFC down at the LLM TTFB floor without any speculative run.
Preload eagerly triggers a run for a chat before the first message is sent. Initialization (DB setup, context loading) happens while the user is still typing, reducing first-response latency.
Call transport.preload(chatId) to start a run early:
import { useEffect } from "react";
import { useTriggerChatTransport } from "@trigger.dev/sdk/chat/react";
import { useChat } from "@ai-sdk/react";
export function Chat({ chatId }) {
const transport = useTriggerChatTransport({
task: "my-chat",
accessToken: ({ chatId }) => mintChatAccessToken(chatId),
startSession: ({ chatId, clientData }) =>
startChatSession({ chatId, clientData }),
clientData: { userId: currentUser.id },
});
// Preload on mount: run starts before the user types anything.
// Trigger config (idleTimeoutInSeconds, machine, tags) lives in the
// server action that wraps `chat.createStartSessionAction`.
useEffect(() => {
transport.preload(chatId);
}, [chatId]);
const { messages, sendMessage } = useChat({ id: chatId, transport });
// ...
}
Preload is a no-op if a session already exists for this chatId.
Your accessToken callback receives { chatId } and is invoked the same way on preload as on any other refresh — no special branching by purpose. See TriggerChatTransport options.
The onPreload hook fires immediately. The run then waits for the first message. When the user sends a message, onChatStart fires with preloaded: true so you can skip work that already ran:
export const myChat = chat.agent({
id: "my-chat",
onPreload: async ({ chatId, clientData }) => {
// Eagerly initialize: runs before the first message
userContext.init(await loadUser(clientData.userId));
await db.chat.create({ data: { id: chatId } });
},
onChatStart: async ({ preloaded }) => {
if (preloaded) return; // Already initialized in onPreload
// ... fallback initialization for non-preloaded runs
},
run: async ({ messages, signal }) => {
return streamText({ model: anthropic("claude-sonnet-4-5"), messages, abortSignal: signal });
},
});
With chat.createSession() or raw tasks, check payload.trigger === "preload" and wait for the first message:
if (payload.trigger === "preload") {
// Initialize early...
const result = await chat.messages.waitWithIdleTimeout({
idleTimeoutInSeconds: 60,
timeout: "1h",
});
if (!result.ok) return;
currentPayload = result.output;
}
Head Start runs step 1's LLM call in your warm server process while the agent run boots in parallel. The user sees one continuous turn: text first from your server, then a clean handover to the agent for tool execution and any further steps. The agent you hand off to can be a chat.agent, a chat.customAgent, or a chat.createSession loop (see Handover with custom agents).
chat.headStart returns a standard Web Fetch API handler — (req: Request) => Promise<Response> — so it slots into any runtime that speaks Web Fetch.
Drive it one of two ways: wire the handler into the transport's headStart option so the browser's first message POSTs to it (the setup below), or call chat.startHeadStart from a backend that creates the chat and triggers the run in one request, then resumes on a separate page.
Verified runtimes: Node 18+, Bun, Deno, Cloudflare Workers, Vercel (Node and Edge), Netlify (Functions and Edge). The handler uses only fetch and Web ReadableStream / TransformStream (no node:* imports), and the S2 streaming dependency picks the right transport for each runtime automatically (HTTP/2 on Node/Deno, HTTP/1.1 on Bun/Workers/browsers).
Compatible frameworks (native Web Fetch): Next.js App Router, Hono, SvelteKit, Remix, React Router v7, TanStack Start, Astro, Nitro/Nuxt, Elysia. Mount the handler directly.
Node-only frameworks (Express, Fastify, Koa): the handler still works, but the framework gives you a Node IncomingMessage instead of a Web Request. Use a small adapter — examples in Mounting in your framework below.
When the first turn is pure text (no tool calls), the agent run boots and exits without ever calling an LLM. You only pay for what the conversation actually needed.
3 runs each, prompt "say hi in five words", same model both sides (Anthropic Claude Sonnet 4):
| Without Head Start | With Head Start | Δ | |
|---|---|---|---|
| TTFT (avg) | 2801 ms | 1218 ms | −57% |
| TTFT (range) | 2351–3101 ms | 1201–1252 ms | |
| Total turn | 4180 ms | 2345 ms | −44% |
With Head Start, time-to-first-text is essentially the LLM TTFB floor (50ms spread). Without it, agent boot + hooks stack before the LLM call, adding 750ms of variance.
sequenceDiagram
autonumber
participant B as Browser
participant H as Route handler
(your warm server)
participant T as chat.agent run
(Trigger.dev)
B->>H: POST first message
(headStart URL)
par Step 1 + agent boot in parallel
H->>H: streamText step 1
(your model, schema-only tools)
H-->>B: SSE: step 1 chunks
and
H->>T: createSession + trigger run
T->>T: boot → wait on session.in
end
alt finishReason: tool-calls
H->>T: handover signal
(partial assistant message)
T->>T: execute tools, run step 2 LLM
T-->>H: chunks via session.out
H-->>B: SSE: step 2 chunks
T-->>H: trigger:turn-complete
else finishReason: stop (pure text)
H->>T: handover-skip signal
T->>T: exit (no LLM call)
end
H-->>B: SSE close
Note over B,T: Subsequent turns bypass the handler:
browser writes directly to session.in
This is an import-chain problem, not a runtime one. A "we'll strip the executes at runtime" helper would not fix it — bundlers resolve imports at build time. The only correct shape is to keep schemas in their own module that imports ai and zod only.
</Warning>
```ts lib/chat-tools/schemas.ts
// ⚠️ This file MUST NOT import anything heavier than `ai` and `zod`.
// Any import here lands in the route-handler bundle.
import { tool } from "ai";
import { z } from "zod";
export const fetchPage = tool({
description: "Fetch a URL and return text",
inputSchema: z.object({ url: z.string().url() }),
// No execute — agent task adds it elsewhere.
});
export const headStartTools = { fetchPage };
```
```ts trigger/chat-tools.ts
// Heavy deps live here. Only the trigger task imports this module.
import { tool } from "ai";
import TurndownService from "turndown";
import { fetchPage as fetchPageSchema } from "@/lib/chat-tools/schemas";
const turndown = new TurndownService();
export const fetchPage = tool({
...fetchPageSchema,
execute: async ({ url }) => {
const res = await fetch(url);
return { body: turndown.turndown(await res.text()) };
},
});
export const chatTools = { fetchPage };
```
```ts trigger/chat.ts
import { chat } from "@trigger.dev/sdk/ai";
import { streamText, stepCountIs } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { chatTools } from "./chat-tools";
export const myChat = chat.agent({
id: "my-chat",
run: async ({ messages, signal }) =>
streamText({
...chat.toStreamTextOptions({ tools: chatTools }),
model: anthropic("claude-sonnet-4-6"),
messages,
stopWhen: stepCountIs(10),
abortSignal: signal,
}),
});
```
```ts lib/chat-handler.ts
import { chat } from "@trigger.dev/sdk/chat-server";
import { streamText } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { headStartTools } from "@/lib/chat-tools/schemas";
export const chatHandler = chat.headStart({
agentId: "my-chat",
run: async ({ chat: helper }) =>
streamText({
...helper.toStreamTextOptions({ tools: headStartTools }),
model: anthropic("claude-sonnet-4-6"),
system: "You are a helpful assistant.",
stopWhen: stepCountIs(15),
}),
});
```
<Tip>
Use the **same model** on both sides (route handler and `chat.agent`) to avoid a tone or style shift between step 1 and step 2+. Your LLM provider keys stay server-side in your warm process — Trigger.dev never holds them in this design.
</Tip>
Mount the handler in whatever framework you use — see [Mounting in your framework](#mounting-in-your-framework) below.
```tsx components/chat.tsx
const transport = useTriggerChatTransport<typeof myChat>({
task: "my-chat",
accessToken: ({ chatId }) => mintChatAccessToken(chatId),
startSession: ({ chatId, clientData }) =>
startChatSession({ chatId, clientData }),
headStart: "/api/chat",
});
```
chat.headStart returns a Web Fetch handler — (req: Request) => Promise<Response>. Frameworks that natively pass Web Request objects mount it as-is. Node-only frameworks (Express, Fastify, Koa) need a small adapter.
// app/api/chat/route.ts
import { chatHandler } from "@/lib/chat-handler";
export const POST = chatHandler;
// Default function timeout on Vercel is 10s. Bump if your turns
// run long (multi-step tool use, slow models):
// export const maxDuration = 60;
// src/index.ts
import { Hono } from "hono";
import { chatHandler } from "./chat-handler";
const app = new Hono();
app.post("/api/chat", (c) => chatHandler(c.req.raw));
export default app;
// src/routes/api/chat/+server.ts
import type { RequestHandler } from "./$types";
import { chatHandler } from "$lib/chat-handler";
export const POST: RequestHandler = ({ request }) => chatHandler(request);
// app/routes/api.chat.ts
import type { ActionFunctionArgs } from "@remix-run/node";
import { chatHandler } from "~/lib/chat-handler";
export async function action({ request }: ActionFunctionArgs) {
return chatHandler(request);
}
// app/routes/api/chat.ts
import { createAPIFileRoute } from "@tanstack/start/api";
import { chatHandler } from "~/lib/chat-handler";
export const Route = createAPIFileRoute("/api/chat")({
POST: ({ request }) => chatHandler(request),
});
// src/pages/api/chat.ts
import type { APIRoute } from "astro";
import { chatHandler } from "../../lib/chat-handler";
export const POST: APIRoute = ({ request }) => chatHandler(request);
// server/api/chat.post.ts
import { chatHandler } from "~/lib/chat-handler";
export default defineEventHandler((event) => chatHandler(toWebRequest(event)));
// src/index.ts
import { Elysia } from "elysia";
import { chatHandler } from "./chat-handler";
new Elysia()
.post("/api/chat", ({ request }) => chatHandler(request))
.listen(3000);
// src/index.ts
import { chatHandler } from "./chat-handler";
export default {
async fetch(req: Request): Promise<Response> {
const url = new URL(req.url);
if (req.method === "POST" && url.pathname === "/api/chat") {
return chatHandler(req);
}
return new Response("Not found", { status: 404 });
},
};
// server.ts
import { chatHandler } from "./chat-handler";
Bun.serve({
port: 3000,
async fetch(req) {
const url = new URL(req.url);
if (req.method === "POST" && url.pathname === "/api/chat") {
return chatHandler(req);
}
return new Response("Not found", { status: 404 });
},
});
// server.ts
import { chatHandler } from "./chat-handler.ts";
Deno.serve({ port: 3000 }, async (req) => {
const url = new URL(req.url);
if (req.method === "POST" && url.pathname === "/api/chat") {
return chatHandler(req);
}
return new Response("Not found", { status: 404 });
});
Express, Fastify, and Koa pass Node IncomingMessage / ServerResponse objects rather than Web Request / Response. The SDK ships chat.toNodeListener that wraps any Web Fetch handler as a Node (req, res) listener — body bytes are read upfront, headers translated, the response body streamed chunk-by-chunk, and client disconnect is propagated to the handler via AbortSignal.
import express from "express";
import { chat } from "@trigger.dev/sdk/chat-server";
import { chatHandler } from "./chat-handler";
const app = express();
app.post("/api/chat", chat.toNodeListener(chatHandler));
app.listen(3000);
import Fastify from "fastify";
import { chat } from "@trigger.dev/sdk/chat-server";
import { chatHandler } from "./chat-handler";
const fastify = Fastify();
const listener = chat.toNodeListener(chatHandler);
fastify.post("/api/chat", (req, reply) => {
// Hand the raw Node request/response to the adapter and tell
// Fastify we'll handle the response ourselves (no auto-reply).
reply.hijack();
return listener(req.raw, reply.raw);
});
fastify.listen({ port: 3000 });
import Koa from "koa";
import Router from "@koa/router";
import { chat } from "@trigger.dev/sdk/chat-server";
import { chatHandler } from "./chat-handler";
const app = new Koa();
const router = new Router();
const listener = chat.toNodeListener(chatHandler);
router.post("/api/chat", async (ctx) => {
ctx.respond = false; // Tell Koa not to send the response itself.
await listener(ctx.req, ctx.res);
});
app.use(router.routes()).listen(3000);
import http from "node:http";
import { chat } from "@trigger.dev/sdk/chat-server";
import { chatHandler } from "./chat-handler";
const listener = chat.toNodeListener(chatHandler);
http
.createServer((req, res) => {
if (req.method === "POST" && req.url === "/api/chat") {
return listener(req, res);
}
res.statusCode = 404;
res.end();
})
.listen(3000);
The handler keeps the SSE response open until the agent run signals turn-complete (or skip, on a pure-text turn). Make sure your framework / serverless function timeout accommodates that:
export const maxDuration = N; on the route segment.| First turn (handover) | Subsequent turns | |
|---|---|---|
| Browser sends message via | POST to headStart URL | Direct write to session.in |
| Step 1 LLM call runs in | Your warm process | Trigger.dev agent run |
| Tool execution runs in | Trigger.dev agent run | Trigger.dev agent run |
| Step 2+ LLM call runs in | Trigger.dev agent run | Trigger.dev agent run |
onChatStart / onTurnStart fire | After handover signal arrives | Normally |
hydrateMessages fires (if registered) | After handover, with the first-turn history as incomingMessages | Normally |
onTurnComplete fires | After turn finishes (handover) or skipped (handover-skip) | Normally |
A head-start turn persists exactly like a normal turn — the handover machinery is invisible to your hooks. The guarantees:
messageId across the whole turn. The route handler generates the id, the handover signal carries it to the agent, and the agent's step 2+ stream reuses it — so the browser merges step 1 and step 2+ into a single assistant message, and you can merge-by-id when persisting.onTurnComplete is the canonical persistence point, same as any turn. It carries the full assistant message under that one id: step-1 text, reasoning, and tool calls plus step-2+ tool results and text. The database persistence patterns apply unchanged.onTurnComplete) under the same messageId, with provider metadata intact — Anthropic thinking signatures survive a replay back to the model. Step-2 reasoning appends to the same message rather than replacing it.hydrateMessagesHead Start composes with hydrateMessages. On the first turn, the hook receives the route handler's first-turn history as incomingMessages — the canonical upsert-and-return pattern persists the user message exactly as it would on a direct-trigger turn. The runtime splices the warm handler's partial assistant onto your hydrated chain after the hook returns, deduplicated by the assistant messageId, so your hook never needs to include the in-flight partial.
Your hydrate hook shapes model context, not the transcript — dropping reasoning-only entries or unresolved tool rows from the returned chain is fine and does not affect what onTurnComplete persists or what the UI renders.
prepareMessagesWhen the first turn's handover carries a pending tool call, the runtime reshapes it into a tool-approval round: the partial assistant gets a tool-approval-request and the chain ends with a tool message holding the matching tool-approval-response. The agent's streamText reads that trailing row to execute the handed-over call before step 2. chat.agent keeps that tail intact across your prepareMessages hook, so the common prompt-caching pattern of rolling a cache breakpoint onto the last message is safe on a resume turn (the breakpoint lands on the next user or assistant message instead). If you hand-roll a backend with chat.customAgent or chat.createSession, preserve that trailing approval row yourself.
The route handler is backend-agnostic: agentId can point at a chat.agent, a chat.customAgent, or a chat.createSession loop. With chat.agent the handover is consumed for you (the steps above). The two hand-rolled backends consume it explicitly on turn 0.
The turn iterator surfaces the handover as turn.handover. On a final (pure-text) handover, call turn.complete() with no source to finalize the warm partial without streaming; otherwise stream as usual. The iterator threads the spliced partial as originalMessages for you, so a resumed tool round merges into the handed-over assistant.
for await (const turn of session) {
// Pure-text handover (isFinal): step 1 already IS the response.
const result = turn.handover?.isFinal
? undefined
: streamText({
model: anthropic("claude-sonnet-4-6"),
messages: turn.messages,
abortSignal: turn.signal,
stopWhen: stepCountIs(10),
});
await turn.complete(result); // no source on a final handover
}
In a hand-rolled loop, call conversation.consumeHandover({ payload }) at the top of turn 0. It waits for the handover signal, seeds prior history from payload.headStartMessages, splices the warm step-1 partial into the accumulator, and returns { isFinal, skipped }.
// Turn 0, gated on a head-start run:
if (turn === 0 && payload.trigger === "handover-prepare") {
const { isFinal, skipped } = await conversation.consumeHandover({ payload });
if (skipped) return; // not a head-start run, or the warm handler aborted — exit
if (!isFinal) {
// The partial carries a pending tool call. Run step 2 to execute it,
// passing originalMessages so the tool output merges into the
// handed-over assistant instead of starting a new message.
const result = streamText({
model: anthropic("claude-sonnet-4-6"),
messages: conversation.modelMessages,
stopWhen: stepCountIs(10),
});
const response = await chat.pipeAndCapture(result, {
originalMessages: conversation.uiMessages,
});
if (response) await conversation.addResponse(response);
}
await chat.writeTurnComplete(); // on isFinal the warm partial is already the response
return;
}
Gate the call on trigger === "handover-prepare" — consumeHandover consumes the warm handover, not a normal first message. See Custom agents for the full loop (continuation seeding, stop handling, persistence). The lower-level chat.waitForHandover({ payload }) and accumulator.applyHandover(signal) are exported if you need to wait and splice in separate steps.
chat.headStart APIchat.headStart<TTools>({
agentId: string, // The chat.agent / chat.customAgent id you're handing off to
run: (args: HeadStartRunArgs<TTools>) => Promise<StreamTextResult<any, any>>,
idleTimeoutInSeconds?: number, // How long the agent waits for the handover signal. Default: 60
triggerConfig?: Partial<SessionTriggerConfig>, // Run options for the handover-prepare run
}): (req: Request) => Promise<Response>
triggerConfig sets run options on the auto-triggered handover-prepare run: tags, queue, machine, maxAttempts, maxDuration, region, and lockToVersion. The chat:{chatId} tag is prepended automatically. Because the session is created once on the first head-start turn (idempotent on the chat id), this is the only place to set those options for a head-start chat's lifetime, mirroring what chat.createStartSessionAction sets for the direct-trigger path.
export const chatHandler = chat.headStart({
agentId: "my-chat",
triggerConfig: { tags: ["org:acme"], queue: "chat", machine: "small-2x" },
run: async ({ chat: helper }) =>
streamText({ ...helper.toStreamTextOptions({ tools: headStartTools }), model, system }),
});
The run callback receives:
messages: UIMessage[] — user messages parsed from the request body.signal: AbortSignal — fires when the request closes or the SDK times out the handover.chat: HeadStartChatHelper<TTools> — exposes chat.toStreamTextOptions({ tools }) and a chat.session escape hatch for power users.chat.toStreamTextOptions({ tools }) returns options to spread into streamText. The SDK owns these keys — overriding them will break the protocol:
| Key | What the SDK sets | Why |
|---|---|---|
messages | convertToModelMessages(uiMessages) | First-turn user history |
tools | What you pass | Schema-only tools for step 1 |
stopWhen | stepCountIs(1) | Step 1 only — agent picks up step 2+ |
abortSignal | Combined request + idle timeout | Safe cleanup on disconnect |
You bring model, system, providerOptions, prepareStep, anything else streamText accepts.
useTriggerChatTransport({
// ... task, accessToken, startSession, ...
headStart?: string, // URL of your chat.headStart route handler
});
Optional. When set, the FIRST message of a brand-new chat (no existing session state) routes through this URL. Subsequent turns bypass it and use the direct-trigger path.
This is not a stock useChat endpoint — it's not the canonical request URL for every turn, just the first-turn shortcut.
chat.startHeadStart runs the same head start as the chat.headStart handler above; the difference is how step 1 reaches the browser. chat.headStart streams step 1 back over the live connection the browser opens when it sends the first message. chat.startHeadStart has no open browser connection to stream to, so it drains step 1 into the durable session stream and the browser resumes it when the chat page loads.
Use it when there's no open connection at first-turn time, because the first message is captured outside the chat UI and the conversation renders on a separate page. A typical flow: a "new chat" form posts the prompt to your backend, which creates the chat row, starts the run with chat.startHeadStart, and returns a chatId; the browser then navigates to /chats/{chatId} and resumes. You still get the first-turn TTFC win; the browser picks step 1 up on resume instead of live.
1. Start the head start in your create endpoint. Call chat.startHeadStart, keep completion alive past the response (waitUntil / Next.js after), and return the chatId.
import { chat } from "@trigger.dev/sdk/chat-server";
import { streamText } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { after } from "next/server";
// Schema-only tools; same bundle-isolation rule as chat.headStart.
import { headStartTools } from "@/lib/chat-tools/schemas";
export async function POST(req: Request) {
const { chatId, messages } = await req.json();
// Persist your own chat row + the first user message here.
const { completion } = await chat.startHeadStart({
agentId: "my-chat",
chatId, // session externalId; reuse it on the destination page
messages, // first-turn user history
run: async ({ chat: helper }) =>
streamText({
...helper.toStreamTextOptions({ tools: headStartTools }),
model: anthropic("claude-sonnet-4-6"),
system: "You are a helpful assistant.",
}),
});
// Keep the function warm until step 1 drains and the handover dispatches.
after(completion);
return Response.json({ chatId });
}
2. Resume the chat on the destination page. Set no headStart and no startSession: the run is already in flight, so the transport resumes session.out and replays step 1 (warm) then step 2+ (agent) under one assistant message.
import { useTriggerChatTransport } from "@trigger.dev/sdk/chat/react";
import { useChat } from "@ai-sdk/react";
const transport = useTriggerChatTransport({
task: "my-chat",
accessToken: ({ chatId }) => mintChatAccessToken(chatId),
});
const { messages } = useChat({ id: chatId, transport, resume: true });
The run callback and bundle-isolation rule are the same as chat.headStart. Pass metadata to attach auth tokens or context to the run; it never reaches the browser. The cost over the transport-routed handler is one extra round trip: the create request, then the resume.
chat.startHeadStart APIchat.startHeadStart<TTools>({
agentId: string, // chat.agent / chat.customAgent / chat.createSession id
chatId: string, // session externalId; reuse on the destination page
messages: UIMessage[], // first-turn user history
run: (args: HeadStartRunArgs<TTools>) => Promise<StreamTextResult<any, any>>,
idleTimeoutInSeconds?: number, // how long the agent waits for the handover signal. Default: 60
triggerConfig?: Partial<SessionTriggerConfig>, // tags, queue, machine, …
apiClient?: ApiClientConfiguration, // when the agent lives in another project/env
metadata?: Record<string, unknown>, // merged into the run payload; never sent to the browser
}): Promise<{ chatId: string; completion: Promise<void> }>
completion resolves once the head start finishes; await it or hand it to waitUntil. It rejects if the warm step or the dispatch fails.
stopWhen: stepCountIs(1). Multi-step handover (handler does step 1 + step 2 + ...) is out of scope.Response body or equivalent). Most modern hosts do — Next.js, Hono, SvelteKit, Workers, Bun, Deno, Vercel, etc. Some legacy platforms that buffer full responses won't deliver chunks until the turn is over, which negates the TTFC benefit (correctness still holds).useChat chat surfaces (Slack bots, Discord bots, custom protocols) don't fit the chat.headStart shape — the API expects the AI SDK transport's wire payload on input. For those, trigger the chat.agent directly from your bot handler.chat.headStart factory and types — full signatures for HeadStartRunArgs, HeadStartChatHelper, HeadStartSession, HeadStartHandlerOptions.headStart transport option — alongside accessToken, startSession, etc.onPreload hook — the backend hook that fires when a run is preloaded.chat.customAgent and chat.createSession loops that consumeHandover / turn.handover plug into.