@trigger.dev/sdk 0.0.0-python-preview-20250226140121 → 0.0.0-rc-4-8-0-20261021151928

package/docs/ai-chat/patterns/trusted-edge-signals.mdx

@@ -0,0 +1,333 @@
+---
+title: "Trusted edge signals"
+sidebarTitle: "Trusted edge signals"
+description: "How to safely deliver server-trusted signals (bot scores, JA4, ASN, ReCAPTCHA verdicts) to a chat.agent run via an edge proxy."
+---
+
+A common need for chat-style endpoints is to drive agent behavior from **server-trusted signals** that the browser cannot be allowed to declare itself — bot management scores, JA4 fingerprints, ASN, ReCAPTCHA verdicts, or any other anti-abuse data only the edge can see. The agent's [`clientData`](/ai-chat/reference#withclientdata) channel is the right delivery mechanism, but `clientData` set in the browser is by definition spoofable. The fix is to move the value population out of the browser and into a trusted edge proxy.
+
+This page documents the pattern using Cloudflare Workers as the proxy. The same shape applies to any edge layer (custom reverse proxy, Vercel Edge Middleware, AWS Lambda@Edge) — the trust comes from the deployment topology, not from Trigger.dev validating the source.
+
+## Why headers don't work
+
+It's tempting to ask whether `POST /realtime/v1/sessions/{id}/in/append` could carry the signal as an HTTP header. It cannot. The realtime route reads only `Authorization` and `X-Part-Id`; the remaining headers are dropped at the route boundary and the body is persisted to the durable stream as opaque bytes. There is no `headers → run payload` channel.
+
+The trigger.dev wire payload, on the other hand, has a typed per-turn metadata channel ([`ChatTaskWirePayload.metadata`](/ai-chat/client-protocol#chattaskwirepayload)). It already flows from the wire into [`clientData`](/ai-chat/reference#withclientdata) on every hook (`onBoot`, `onChatStart`, `onTurnStart`, `run`, `onTurnComplete`). That field is where signals must land.
+
+## The trust boundary
+
+The pattern has one architectural requirement and one wire-shape convention.
+
+**Topology**: the browser must not be able to reach `trigger.dev` directly. All four chat-related requests (`POST /api/v1/sessions`, `GET /realtime/v1/sessions/{id}/out`, `POST /realtime/v1/sessions/{id}/in/append`, `POST /api/v1/auth/jwt/claims`) flow through your edge proxy. The proxy holds the trust; trigger.dev simply persists whatever the proxy writes.
+
+**Namespace**: pick a key your edge proxy owns exclusively — e.g. `__cf`, `__edge`, `__trust`. The proxy **strips** anything in that key on the way in and **injects** its own value on every request. Nothing else in your system should write that key. This is the convention that converts deployment topology into a guarantee the agent can rely on.
+
+```mermaid
+sequenceDiagram
+  participant Browser
+  participant Edge as Edge Proxy (CF Worker)
+  participant Trigger as trigger.dev API
+  participant Agent as chat.agent run
+
+  Browser->>Edge: POST /api/v1/sessions { triggerConfig.basePayload.metadata: {...} }
+  Edge->>Edge: strip body.triggerConfig.basePayload.metadata.__cf<br/>inject body.triggerConfig.basePayload.metadata.__cf = { botScore, ja4, asn }
+  Edge->>Trigger: POST /api/v1/sessions (rewritten body)
+  Trigger-->>Agent: run boots with payload.metadata.__cf
+  Browser->>Edge: POST /realtime/v1/sessions/{id}/in/append { kind: "message", payload: {...} }
+  Edge->>Edge: strip payload.metadata.__cf<br/>inject payload.metadata.__cf
+  Edge->>Trigger: POST /in/append (rewritten body)
+  Trigger-->>Agent: chat.messages.wait() resolves with payload.metadata.__cf
+```
+
+## Wire payload — the two endpoints to rewrite
+
+The signal needs to land in **two** places. Both bodies are JSON; the edge proxy parses, mutates the namespaced key, and re-serializes.
+
+### `POST /api/v1/sessions` — session create
+
+The browser's session-create call carries the first-turn metadata under `triggerConfig.basePayload.metadata`. The proxy mutates that:
+
+```ts
+// Before
+{
+  "type": "chat.agent",
+  "externalId": "conv-123",
+  "taskIdentifier": "my-agent",
+  "triggerConfig": {
+    "basePayload": {
+      "chatId": "conv-123",
+      "trigger": "preload",
+      "metadata": { "userId": "user-456" }
+    }
+  }
+}
+
+// After
+{
+  "type": "chat.agent",
+  "externalId": "conv-123",
+  "taskIdentifier": "my-agent",
+  "triggerConfig": {
+    "basePayload": {
+      "chatId": "conv-123",
+      "trigger": "preload",
+      "metadata": {
+        "userId": "user-456",
+        "__cf": { "botScore": 95, "ja4": "...", "asn": 13335, "country": "US" }
+      }
+    }
+  }
+}
+```
+
+### `POST /realtime/v1/sessions/{id}/in/append` — every follow-up turn
+
+The body is a JSON-serialized `ChatInputChunk`. The proxy parses it, checks `kind === "message"`, and mutates `payload.metadata`:
+
+```ts
+// Before
+{
+  "kind": "message",
+  "payload": {
+    "message": { "id": "u-2", "role": "user", "parts": [{ "type": "text", "text": "..." }] },
+    "chatId": "conv-123",
+    "trigger": "submit-message",
+    "metadata": { "userId": "user-456" }
+  }
+}
+
+// After
+{
+  "kind": "message",
+  "payload": {
+    "message": { ... },
+    "chatId": "conv-123",
+    "trigger": "submit-message",
+    "metadata": {
+      "userId": "user-456",
+      "__cf": { "botScore": 95, "ja4": "...", "asn": 13335, "country": "US" }
+    }
+  }
+}
+```
+
+Both bodies stay well under the [per-record cap on `/in/append`](/ai-chat/client-protocol#step-3-send-messages-stops-and-actions) — a typical trust object is ~200 bytes.
+
+Other paths — `.out` SSE, `/api/v1/auth/jwt/claims`, anything else — pass through the proxy untouched. The SSE stream in particular must not be buffered; preserve the response body as-is.
+
+## Cloudflare Worker reference implementation
+
+A complete worker that proxies all paths to `TRIGGER_API_UPSTREAM` and injects `__cf` on the two body-write endpoints:
+
+```ts
+export interface Env {
+  TRIGGER_API_UPSTREAM: string; // e.g. "https://api.trigger.dev"
+}
+
+type CfTrustData = {
+  botScore: number;
+  ja4: string;
+  asn: number;
+  country: string;
+};
+
+function readCfTrustData(request: Request): CfTrustData {
+  const cf = (request as Request & { cf?: Record<string, unknown> }).cf;
+  const bm = cf?.botManagement as Record<string, unknown> | undefined;
+  return {
+    botScore: (bm?.score as number) ?? 0,
+    ja4: (bm?.ja4 as string) ?? "",
+    asn: (cf?.asn as number) ?? 0,
+    country: (cf?.country as string) ?? "",
+  };
+}
+
+function injectCf(metadata: Record<string, unknown> | undefined, cf: CfTrustData) {
+  // Strip anything the client tried to send under our namespace,
+  // then inject the edge-trusted value. Topology + convention =
+  // trust.
+  const stripped = { ...(metadata ?? {}) };
+  delete stripped.__cf;
+  return { ...stripped, __cf: cf };
+}
+
+function rewriteSessionsCreate(body: string, cf: CfTrustData) {
+  const parsed = JSON.parse(body) as Record<string, unknown>;
+  const tc = (parsed.triggerConfig as Record<string, unknown>) ?? {};
+  const bp = (tc.basePayload as Record<string, unknown>) ?? {};
+  parsed.triggerConfig = {
+    ...tc,
+    basePayload: { ...bp, metadata: injectCf(bp.metadata as Record<string, unknown>, cf) },
+  };
+  return JSON.stringify(parsed);
+}
+
+function rewriteAppend(body: string, cf: CfTrustData) {
+  let parsed: Record<string, unknown>;
+  try {
+    parsed = JSON.parse(body);
+  } catch {
+    return body;
+  }
+  if (parsed.kind !== "message") return body;
+  const payload = (parsed.payload as Record<string, unknown>) ?? {};
+  parsed.payload = { ...payload, metadata: injectCf(payload.metadata as Record<string, unknown>, cf) };
+  return JSON.stringify(parsed);
+}
+
+export default {
+  async fetch(request: Request, env: Env): Promise<Response> {
+    const incoming = new URL(request.url);
+    const target = new URL(incoming.pathname + incoming.search, env.TRIGGER_API_UPSTREAM);
+    const cf = readCfTrustData(request);
+
+    const isSessionsCreate =
+      request.method === "POST" && incoming.pathname === "/api/v1/sessions";
+    const isAppend =
+      request.method === "POST" &&
+      /^\/realtime\/v1\/sessions\/[^/]+\/in\/append$/.test(incoming.pathname);
+
+    let body: BodyInit | null = null;
+    if (request.method !== "GET" && request.method !== "HEAD") {
+      const raw = await request.text();
+      if (isSessionsCreate && raw) body = rewriteSessionsCreate(raw, cf);
+      else if (isAppend && raw) body = rewriteAppend(raw, cf);
+      else body = raw;
+    }
+
+    const headers = new Headers(request.headers);
+    headers.delete("host");
+    headers.delete("content-length");
+
+    return fetch(target.toString(), {
+      method: request.method,
+      headers,
+      body,
+      redirect: "manual",
+    });
+  },
+};
+```
+
+Browser-only deployments also need CORS on the worker — echo `Access-Control-Request-Headers` on preflight and set `Access-Control-Allow-Origin` to your frontend origin. The trigger.dev route itself allows all origins, but the worker becomes the visible cross-origin endpoint to the browser.
+
+### Streaming and latency
+
+The SDK's `baseURL` accepts a function (see [Browser transport configuration](#browser-transport-configuration)), so the recommended setup routes `.in/append` and session-create through the worker but lets `.out` SSE go direct to `api.trigger.dev`. Body-mutation only happens on the POST paths; the SSE stream is read-only, doesn't need rewriting, and routing it direct saves an edge hop on every reconnect.
+
+If you do route `.out` through the proxy (e.g. you want a single origin in front of `api.trigger.dev` and don't care about the extra hop), the template above handles it correctly because the worker returns `response.body` as a `ReadableStream`. **Do not replace that with `await response.text()`** anywhere in your fork; doing so converts the streaming SSE response into a buffered read and breaks per-chunk delivery.
+
+[Cloudflare Workers HTTP requests](https://developers.cloudflare.com/workers/platform/limits/) have no wall-clock duration limit while the client stays connected — the 60-second long-poll runs to completion on every plan, including Free. CPU-time limits (10 ms on Free, 30 s default on Paid) only apply to active computation; relaying bytes through `fetch` doesn't burn CPU. The two body-rewrite paths use sub-millisecond CPU for typical message sizes, well under either ceiling.
+
+Network-wise the proxy adds one edge hop: roughly 10–50 ms per request round trip versus talking to `api.trigger.dev` directly. Routing SSE direct via the function-form `baseURL` eliminates that hop on the long-lived path.
+
+## Agent side — declare the namespace in `clientDataSchema`
+
+Mirror the namespace in the agent so every turn lands typed:
+
+```ts
+import { chat } from "@trigger.dev/sdk/ai";
+import { z } from "zod";
+
+export const myAgent = chat
+  .withClientData({
+    schema: z.object({
+      userId: z.string(),
+      __cf: z.object({
+        botScore: z.number(),
+        ja4: z.string(),
+        asn: z.number(),
+        country: z.string(),
+      }),
+    }),
+  })
+  .agent({
+    id: "my-agent",
+    run: async ({ messages, clientData, signal }) => {
+      // Score-based routing. The values arrive from the edge proxy.
+      if (clientData.__cf.botScore < 30) {
+        return streamText({
+          model: anthropic("claude-haiku-4-5"),
+          messages: [{ role: "system", content: "Reject politely; do not engage." }],
+          abortSignal: signal,
+          stopWhen: stepCountIs(15),
+        });
+      }
+
+      return streamText({
+        model: anthropic("claude-sonnet-4-5"),
+        messages,
+        abortSignal: signal,
+        // ...
+        stopWhen: stepCountIs(15),
+      });
+    },
+  });
+```
+
+Because the schema requires `__cf` on every turn, any request that *doesn't* go through the proxy fails at the agent boundary — the turn produces a `[ERROR]` span on the trace and an empty `turn-complete` on the wire (see [the client protocol error-detection note](/ai-chat/client-protocol#step-3-send-messages-stops-and-actions)). That gives you a server-side enforcement check for "did this request actually come through the trusted path?"
+
+## Browser transport configuration
+
+Point the `TriggerChatTransport` at the worker, not at `api.trigger.dev`:
+
+`baseURL` accepts a function so you can route `.in/append` through the worker while keeping `.out` SSE direct to `api.trigger.dev`. The append path is where the body-mutation matters; the SSE stream is a read-only one-way channel that doesn't need to be proxied. Routing it direct saves an edge hop on every long-poll.
+
+```tsx
+import { useTriggerChatTransport } from "@trigger.dev/sdk/chat/react";
+
+const WORKER = "https://worker.your-domain.com";
+const DIRECT = "https://api.trigger.dev";
+
+const transport = useTriggerChatTransport({
+  task: "my-agent",
+  baseURL: ({ endpoint }) => (endpoint === "out" ? DIRECT : WORKER),
+  // ... accessToken, startSession, etc.
+  // NOTE: do not set __cf in clientData here. The browser cannot be
+  // trusted to populate it — the worker is the source of truth.
+  clientData: { userId: currentUserId },
+});
+```
+
+If you'd rather route everything through the worker, pass a single string:
+
+```tsx
+baseURL: "https://worker.your-domain.com",
+```
+
+`baseURL` accepts the same string-or-function shape on `chat.createStartSessionAction`, so the Next.js server action that creates the session also flows through the worker — that's how the very first run's `basePayload.metadata.__cf` gets injected before reaching `api.trigger.dev`:
+
+```ts
+// actions.ts — server-only
+import { chat } from "@trigger.dev/sdk/ai";
+
+export const startSession = chat.createStartSessionAction("my-agent", {
+  tokenTTL: "1h",
+  baseURL: ({ endpoint }) =>
+    endpoint === "sessions" ? WORKER : DIRECT,
+});
+```
+
+The session-create endpoint discriminator is `"sessions"` (POST `/api/v1/sessions`) or `"auth"` (POST `/api/v1/auth/jwt/claims`) — distinct from the chat transport's `"in"` / `"out"`. If you want everything proxied, pass a string.
+
+## Threat model
+
+Two important invariants follow from this design:
+
+1. **Direct browser-to-trigger.dev requests cannot succeed**. As long as your agent's `clientDataSchema` requires the namespaced field, any request that doesn't go through the proxy fails schema validation and produces an empty turn. This is your gate.
+2. **Anything inside the namespaced key is trusted only as far as the proxy is the sole writer**. If a client could obtain the public access token and bypass the proxy, they could send arbitrary values under `__cf`. The schema would still validate (it only checks shape, not provenance). The mitigation is operational: the public access token must only be served to clients that reach trigger.dev through the proxy. In practice this means your Next.js server actions and your browser are both behind the same edge layer, and the worker is the only fetch destination for `trigger.dev` baked into either of them.
+
+You can harden further with a shared-secret header the worker injects (e.g. `X-Edge-Signature`) and an agent-side check, but in most CDN deployments the deployment topology is already sufficient.
+
+## Recipe summary
+
+1. Pick a namespaced key the edge proxy owns (`__cf`, `__edge`, `__trust`).
+2. Deploy a proxy in front of `trigger.dev` that rewrites POST `/api/v1/sessions` and POST `/realtime/v1/sessions/{id}/in/append` to inject your trusted values under that key.
+3. Declare the namespace in the agent's `clientDataSchema` so missing or malformed signals fail at the agent boundary.
+4. Point your transport's `baseURL` at the proxy. Never expose `api.trigger.dev` directly to the browser.
+
+## See also
+
+- [Client Protocol](/ai-chat/client-protocol) — the full wire shape the proxy is rewriting.
+- [`withClientData`](/ai-chat/reference#withclientdata) — agent-side typed metadata channel.
+- [Large payloads](/ai-chat/patterns/large-payloads) — for when injected signals or hooks need to ship more than the 1 MiB stream cap allows.

package/docs/ai-chat/patterns/version-upgrades.mdx

@@ -0,0 +1,261 @@
+---
+title: "Version upgrades"
+sidebarTitle: "Version upgrades"
+description: "Gracefully migrate chat agents to a new deployment using chat.requestUpgrade(), chat.endAndContinue(), and the continuation mechanism."
+---
+
+Chat agent runs are pinned to the worker version they started on. When you deploy a new version, suspended runs resume on the **old** code. If your deploy includes breaking changes (new tools, changed schemas, updated API contracts), this can cause issues.
+
+`chat.requestUpgrade()` is the managed upgrade signal for `chat.agent()` and the `chat.createSession()` iterator. Fully hand-rolled custom agents use `chat.endAndContinue()` between turns to immediately hand the Session to a new run.
+
+<Note>
+  If your sessions are pinned by [version skew
+  protection](/deployment/atomic-deployment#chat-sessions), you do not need this page to move a
+  conversation onto a new deployment. A pinned session follows its pin on its own: when the stored
+  `externalDeploymentId` stops naming the deployment a run is on, the agent hands over at the next
+  turn boundary. Set [`versionSkew: "hold"`](#staying-put) to turn that off for one agent.
+
+  Read on for the cases that are still yours to decide — leaving a pin for a version nobody named,
+  a session that was never pinned, and hand-rolled custom agents.
+</Note>
+
+## How it works
+
+When `chat.requestUpgrade()` is called in `onTurnStart` or `onValidateMessages`:
+
+1. `run()` is **skipped** — no response is generated on old code
+2. The agent calls the server-side `endAndContinueSession` endpoint, which atomically swaps the Session's `currentRunId` to a freshly-triggered run on the latest deployment (optimistic-claim against `currentRunVersion`)
+3. The new run picks up the conversation and produces the response
+4. The transport's existing SSE subscription to `session.out` keeps receiving chunks across the swap — no client-side reconnect
+
+The new run lives on the **same Session** as the old one. `chatId` is the durable identity; only the underlying `currentRunId` rotates. The audit log records the new run with `reason: "upgrade"`.
+
+### What "the latest deployment" means
+
+The handoff clears the session's [external deployment id](/deployment/atomic-deployment#chat-sessions) so the new run can land on the current version — re-applying the pin the agent just rejected would make the upgrade impossible. The cleared pin is persisted on the session, so the next continuation doesn't fall back to it either.
+
+To move to a specific deployment rather than to whatever is current, name it:
+
+```ts
+chat.requestUpgrade({ externalDeploymentId: clientData.commitSha });
+```
+
+That is usually what you want when the client told you which build it is on: it upgrades to the version the client expects instead of merely to the newest one.
+
+<Warning>
+  `lockToVersion` is a different thing and is **never** cleared. A session started with an explicit
+  `lockToVersion` re-applies it on every run including upgrade handoffs, so `chat.requestUpgrade()`
+  cannot escape it — the new run lands on the same version the old one did. Use the external
+  deployment id if you want a pin an agent can opt out of.
+</Warning>
+
+When called from inside `run()` or `chat.defer()`, the current turn completes normally first and the run exits afterward. The next message triggers the continuation on the same session.
+
+```mermaid
+sequenceDiagram
+  participant User
+  participant Transport
+  participant Session as session.in
+  participant RunV1 as Run (v1)
+  participant RunV2 as Run (v2)
+
+  User->>Transport: send message
+  Transport->>Session: append message
+  Session->>RunV1: input stream
+  RunV1->>RunV1: onTurnStart → requestUpgrade()
+  RunV1->>RunV2: end-and-continue triggers the successor
+  RunV1-->>Transport: trigger:upgrade-required (filtered, no re-send)
+  RunV1->>RunV1: exit (run() never called, message left unacknowledged)
+  Session->>RunV2: same message, replayed on boot
+  RunV2-->>Transport: response stream (same session.out)
+  Transport-->>User: response (seamless)
+```
+
+## Contract versioning
+
+Define an explicit version for the contract between your frontend and agent. The frontend sends a `protocolVersion` via `clientData`, and the agent declares which versions it supports. When a breaking change ships (new tools, changed data parts, updated response format), bump the version.
+
+This gives you full control — the frontend can be backwards-compatible across multiple agent versions, and the agent only upgrades when it sees a version it doesn't support.
+
+```tsx title="app/components/Chat.tsx"
+import { useTriggerChatTransport } from "@trigger.dev/sdk/chat/react";
+import { useChat } from "@ai-sdk/react";
+
+export function Chat() {
+  const transport = useTriggerChatTransport({
+    task: "my-chat",
+    accessToken: ({ chatId }) => mintChatAccessToken(chatId),
+    startSession: ({ chatId, clientData }) =>
+      startChatSession({ chatId, clientData }),
+    // Bump this when you ship a breaking change to the chat UI or tools
+    clientData: { userId: user.id, protocolVersion: "v2" },
+  });
+
+  const { messages, sendMessage } = useChat({ transport });
+  // ...
+}
+```
+
+On the agent side, declare which versions the current code supports:
+
+```ts
+import { chat } from "@trigger.dev/sdk/ai";
+import { streamText } from "ai";
+import { anthropic } from "@ai-sdk/anthropic";
+
+// The set of frontend protocol versions this agent code supports.
+// When you deploy a breaking change, remove old versions from this set.
+const SUPPORTED_VERSIONS = new Set(["v2", "v3"]);
+
+export const myChat = chat
+  .withClientData({
+    schema: z.object({
+      userId: z.string(),
+      protocolVersion: z.string(),
+    }),
+  })
+  .agent({
+    id: "my-chat",
+    onTurnStart: async ({ clientData }) => {
+      if (clientData?.protocolVersion && !SUPPORTED_VERSIONS.has(clientData.protocolVersion)) {
+        chat.requestUpgrade();
+      }
+    },
+    run: async ({ messages, signal }) => {
+      return streamText({ model: anthropic("claude-sonnet-4-5"), messages, abortSignal: signal });
+    },
+  });
+```
+
+The transport includes `clientData` in every payload — both the initial trigger and subsequent records on the session's `.in` channel — so the agent always has the current value.
+
+This pattern is useful when:
+- Your frontend is backwards-compatible across several agent versions, but occasionally ships breaking changes
+- You want explicit control over when upgrades happen rather than upgrading on every deploy
+- Multiple frontend versions may be active at the same time (e.g., users with cached tabs)
+
+## Auto-detect from build ID (Next.js / Vercel)
+
+<Warning>
+  You probably don't need this any more. If your sessions are pinned, following the pin is the
+  built-in behaviour and it needs no `clientData` and no `chat.local`. Reach for the recipe below
+  only when you want to upgrade on a signal the pin doesn't carry — a frontend build id that moves
+  independently of the deployment your app names.
+</Warning>
+
+For automatic upgrade on every deploy, pass your platform's build ID via `clientData` instead of a manual version. The agent stores the ID from the first message and upgrades when it changes:
+
+```tsx title="app/components/Chat.tsx"
+// Vercel sets this at build time, or use your own build ID
+const APP_VERSION = process.env.NEXT_PUBLIC_VERCEL_DEPLOYMENT_ID
+  ?? process.env.NEXT_PUBLIC_BUILD_ID
+  ?? "dev";
+
+export function Chat() {
+  const transport = useTriggerChatTransport({
+    task: "my-chat",
+    accessToken: ({ chatId }) => mintChatAccessToken(chatId),
+    startSession: ({ chatId, clientData }) =>
+      startChatSession({ chatId, clientData }),
+    clientData: { userId: user.id, appVersion: APP_VERSION },
+  });
+  // ...
+}
+```
+
+```ts title="trigger/chat.ts"
+const initialAppVersion = chat.local<{ version: string }>({ id: "appVersion" });
+
+export const myChat = chat
+  .withClientData({
+    schema: z.object({
+      userId: z.string(),
+      appVersion: z.string(),
+    }),
+  })
+  .agent({
+    id: "my-chat",
+    onBoot: async ({ clientData }) => {
+      initialAppVersion.init({ version: clientData.appVersion });
+    },
+    onTurnStart: async ({ clientData }) => {
+      if (clientData?.appVersion && clientData.appVersion !== initialAppVersion.version) {
+        chat.requestUpgrade();
+      }
+    },
+    run: async ({ messages, signal }) => {
+      return streamText({ model: anthropic("claude-sonnet-4-5"), messages, abortSignal: signal });
+    },
+  });
+```
+
+This upgrades on **every** deploy, not just breaking changes. Good for fast-moving projects where you always want the latest code.
+
+## Staying put
+
+A pinned session follows its pin by default. To keep one agent where it is — a long tool chain you
+don't want interrupted, or a conversation you'd rather move on your own terms — set `versionSkew`:
+
+```ts
+export const myChat = chat.agent({
+  id: "my-chat",
+  versionSkew: "hold",
+  run: async ({ messages, signal }) => { ... },
+});
+```
+
+`"hold"` only stops the automatic handoff. `chat.requestUpgrade()` still works, so you can keep the
+decision and still get the seamless swap.
+
+Two cases never hand over automatically, whatever `versionSkew` says:
+
+- **A session with no pin.** There is nothing to compare against, and an unpinned session already
+  lands on the current version every time it starts a run.
+- **A session using `lockToVersion`.** That pin outranks the external deployment id and
+  `chat.requestUpgrade()` cannot escape it, so handing over would land on the same version and
+  repeat.
+
+<Note>
+  Following the pin costs one session read per turn on pinned chats, and the handoff happens at a
+  turn boundary — never mid-turn. If the pin names a deployment that hasn't landed yet, the successor
+  parks: your messages stay durable, and the transport emits `run-pending-version` with
+  `source: "upgrade"` so you can say so in the UI. See [parked
+  chats](/deployment/atomic-deployment#chat-sessions).
+</Note>
+
+## Custom agents
+
+Use `chat.requestUpgrade()` with `chat.agent()`. With `chat.createSession()`, call `chat.requestUpgrade()`, then advance the iterator once more so it can exit normally. For an immediate handoff, close the iterator before calling `chat.endAndContinue()`. In a fully hand-rolled `chat.customAgent()` task, detach input listeners, persist the completed turn, write its boundary, then call `chat.endAndContinue()` and return immediately:
+
+Close a `chat.createSession()` iterator between reads. If `return()` races a `next()` that is already waiting for input, it waits for that read to settle before the handoff can continue. Input dispatched while the iterator is closing is not yielded as a turn and remains available to the continuation unless you write another turn-complete boundary.
+
+```ts
+// Detach any chat.messages.on() subscriptions you created.
+stop.cleanup();
+await persistMessages(conversation.uiMessages);
+await chat.writeTurnComplete();
+await chat.endAndContinue();
+return;
+```
+
+The continuation uses the same durable Session and receives `.in` records that the old run has not consumed. It starts on the latest deployed task version only if the Session is unpinned — a Session carrying `lockToVersion` or an `externalDeploymentId` re-applies that pin, so the continuation lands where the Session says rather than on the newest build.
+
+If input has been dispatched to the old run but should be processed by the continuation, detach the old listeners and skip the final `chat.writeTurnComplete()`. A turn-complete boundary acknowledges the latest input dispatched to the old run, so writing one after that dispatch would cause the continuation to resume past the input.
+
+<Warning>
+  `chat.endAndContinue()` starts the successor but does not stop the calling run. Perform no more Session reads or writes after calling it, and return from the task. If the handoff fails, the promise rejects.
+</Warning>
+
+## Interaction with recovery boot
+
+When `chat.requestUpgrade()` is handled before a turn starts, the SDK immediately hands the Session to a new run, which processes the same input on the latest version. When it is requested during a turn, including through `chat.createSession()`, the current turn finishes and the old run exits; the next input starts the continuation run.
+
+Both are graceful exits. [`onRecoveryBoot`](/ai-chat/patterns/recovery-boot) does not fire — the hook is reserved for mid-stream interruptions (cancel, crash, or OOM) where a partial assistant exists on the tail.
+
+## See also
+
+- [Version skew protection](/deployment/atomic-deployment#chat-sessions) — pin a session to the deployment matching the app build that started it
+- [Lifecycle hooks](/ai-chat/lifecycle-hooks) — where `onTurnStart` and `onChatResume` fit in the turn cycle
+- [Recovery boot](/ai-chat/patterns/recovery-boot) — the sibling hook for mid-stream interruptions (does NOT fire on `requestUpgrade`)
+- [Database persistence](/ai-chat/patterns/database-persistence) — how continuations interact with session state
+- [Client Protocol](/ai-chat/client-protocol#step-4-handle-continuations) — how clients handle continuations at the wire level