docs: drop release-candidate framing ahead of the 4.5 GA (#4100)
Removes the release-candidate framing from the docs for the 4.5 GA: the `@rc` install caveats on the `skills` CLI command, and the AI Agents and Prompts release-candidate banner (a shared snippet used across the ai-chat and prompts pages) plus the `>=4.5.0-rc.0` compatibility pin in the AI reference.
This commit is contained in:
Eric Allam
@@ -4,10 +4,6 @@ sidebarTitle: "Actions"
|
||||
description: "Custom commands sent from the frontend that mutate chat state without consuming a turn — undo, rollback, edit, regenerate."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
## Overview
|
||||
|
||||
Custom actions let the frontend send structured commands (undo, rollback, edit, regenerate) that modify the conversation state. **Actions are not turns**: they fire `hydrateMessages` (if set) and `onAction` only. No turn lifecycle hooks (`onTurnStart` / `prepareMessages` / `onBeforeTurnComplete` / `onTurnComplete`), no `run()`, no turn-counter increment. The trace span is named `chat action`.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Anatomy"
|
||||
description: "The moving parts of a chat agent — the agent task, the session, the frontend transport — and which page covers each."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
**A chat agent is three parts: a long-lived agent task that runs the turn loop, a durable Session carrying messages in and the response stream out, and a frontend transport that plugs the session into `useChat`.** The pages in this section each own one part of that picture. This page is the map — if you'd rather read mechanics end to end, skip to [How it works](/ai-chat/how-it-works).
|
||||
|
||||
```mermaid
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Backend"
|
||||
description: "Three approaches to building your chat backend — chat.agent(), session iterator, or raw task primitives."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
There are three abstraction levels for a chat backend. All three speak the same wire protocol, so the [frontend transport](/ai-chat/frontend) works unchanged whichever you pick.
|
||||
|
||||
| Capability | `chat.agent()` | `chat.createSession()` | Raw primitives |
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Background injection"
|
||||
description: "Inject context from background work into the agent's conversation — self-review, RAG augmentation, or any async analysis."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
## Overview
|
||||
|
||||
`chat.inject()` queues model messages for injection into the conversation. Messages are picked up at the start of the next turn or at the next `prepareStep` boundary (between tool-call steps).
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "chat.local"
|
||||
description: "Typed, run-scoped data accessible from hooks, run(), tools, and subtasks. Survives across turns, auto-cleared between runs, auto-hydrated into subtasks."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
Use `chat.local` to create typed, run-scoped data that persists across turns and is accessible from anywhere — the run function, tools, nested helpers. Each run gets its own isolated copy, and locals are automatically cleared between runs.
|
||||
|
||||
Lifecycle hooks and **`run`** also receive **`ctx`** ([`TaskRunContext`](/ai-chat/reference#task-context-ctx)) — the same object as on a standard `task()` — for tags, metadata, and cleanup that needs the full run record.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Client Protocol"
|
||||
description: "The wire protocol for building custom chat transports — how clients communicate with chat agents over Sessions and SSE."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
This page documents the protocol that chat clients use to communicate with `chat.agent()` tasks. Use this if you're building a custom transport (e.g., for a Slack bot, CLI tool, or native app) instead of using the built-in `TriggerChatTransport` or `AgentChat`.
|
||||
|
||||
<Note>
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Compaction"
|
||||
description: "Automatic context compaction to keep long conversations within token limits."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
## Overview
|
||||
|
||||
Long conversations accumulate tokens across turns. Eventually the context window fills up, causing errors or degraded responses. Compaction solves this by automatically summarizing the conversation when token usage exceeds a threshold, then using that summary as the context for future turns.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Custom agents"
|
||||
description: "Build chat agents without chat.agent()'s managed lifecycle: register with chat.customAgent(), then drive turns with the createSession iterator or a hand-rolled loop."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
**A custom agent is a task you register with `chat.customAgent()` and drive yourself — either with the managed turn iterator from `chat.createSession()`, or with a fully hand-rolled loop over the raw chat primitives.** You give up `chat.agent()`'s lifecycle hooks and automatic continuation recovery; you gain inline control over every turn, and (at the lowest level) full control over the stream conversion.
|
||||
|
||||
See the [comparison table](/ai-chat/backend) before dropping down. The frontend is unchanged either way: all levels speak the same wire protocol, so [`useTriggerChatTransport`](/ai-chat/frontend) points at a custom agent exactly like a `chat.agent()`.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Error handling"
|
||||
description: "How errors flow through chat.agent — stream errors, hook errors, run failures — and how to recover."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
`chat.agent` errors fall into four layers, each with different recovery semantics. The default behavior is **conversation-preserving**: a thrown error in a hook or `run()` does not kill the chat. The current turn ends with an error chunk, and the agent waits for the user's next message.
|
||||
|
||||
## Error layers at a glance
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Fast starts"
|
||||
description: "Two ways to cut first-turn TTFC: Preload eagerly triggers the run before the first message; Head Start runs step 1 in your warm server while the agent boots in parallel."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
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.
|
||||
|
||||
## Picking an approach
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Frontend"
|
||||
description: "Transport setup, session management, client data, and frontend patterns for AI Chat."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
## How the transport works
|
||||
|
||||
Vanilla `useChat` expects an `api` URL — it POSTs the conversation to your own Next.js route handler, which terminates the stream. `useTriggerChatTransport` replaces that round-trip: instead of an `api` URL, you pass a custom [`ChatTransport`](https://ai-sdk.dev/docs/ai-sdk-ui/transport) that talks directly to the Trigger.dev cloud (or your self-hosted webapp) on behalf of `useChat`.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "How it works"
|
||||
description: "End-to-end mechanics of a chat.agent turn: the two durable channels per session, the long-lived task that reads and writes them, and how a chat survives refreshes, deploys, and idle gaps."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
This page explains how `chat.agent` is put together, what each piece does on a single turn, and how a chat survives across turns. It is not an API tour — for that, see [Backend](/ai-chat/backend), [Frontend](/ai-chat/frontend), and the [Reference](/ai-chat/reference). For the byte-level wire format, see [Client Protocol](/ai-chat/client-protocol).
|
||||
|
||||
<Note>
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Lifecycle hooks"
|
||||
description: "Hook into every stage of a chat agent's run: preload, turn start, turn complete, suspend, resume, and more."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
`chat.agent({ ... })` accepts a set of lifecycle hooks for persisting state, validating input, transforming messages, and reacting to suspension and resumption. They fire at well-defined points in the chat agent's lifetime.
|
||||
|
||||
**Once per worker process (every fresh run boot):** `onBoot` → `onPreload` (preloaded runs only).
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "MCP Server"
|
||||
description: "Chat with your agents from any AI coding tool using the Trigger.dev MCP server."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
The Trigger.dev MCP server includes tools for having conversations with your chat agents directly from AI coding tools like Claude Code, Cursor, Windsurf, and others. This lets your AI assistant interact with your agents without writing any code.
|
||||
|
||||
## Available tools
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Overview"
|
||||
description: "Durable multi-turn AI chats — one Trigger.dev task per conversation, surviving refreshes, deploys, and crashes."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
An AI chat isn't a request — it's a session. `chat.agent` runs every conversation as a single long-lived Trigger.dev task: you write the loop, it wakes up when a message arrives, freezes when none do, and the same in-memory state and on-disk workspace survive across page refreshes, deploys, idle gaps, and crashes. The substrate handles the parts most teams stitch together by hand — turn lifecycle, mid-stream resume, recovery from cancel/crash/OOM, HITL approvals, deploy upgrades — so your code is the loop you'd write anyway: messages in, `streamText` out.
|
||||
|
||||
## A minimal example
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Branching conversations"
|
||||
description: "Build ChatGPT-style conversation trees with edit, regenerate, undo, and branch switching using hydrateMessages, chat.history, and actions."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
Most chat UIs treat conversations as linear sequences. But real conversations branch — users edit previous messages, regenerate responses, undo exchanges, and explore alternative paths. This pattern shows how to build a branching conversation system using `hydrateMessages`, `chat.history`, and custom actions.
|
||||
|
||||
## Data model
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Code sandbox"
|
||||
description: "Warm an isolated sandbox on each chat turn, run an AI SDK executeCode tool, and tear down right before the run suspends — using chat.agent hooks and chat.local."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
Use a **hosted code sandbox** (for example [E2B](https://e2b.dev)) when the model should run short scripts to analyze tool output (PostHog queries, CSV-like data, math) without executing arbitrary code on the Trigger worker host.
|
||||
|
||||
This page describes a **durable chat** pattern that fits `chat.agent()`:
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Database persistence"
|
||||
description: "Split conversation state and live session metadata across hooks — preload, turn start, turn complete — without tying the pattern to a specific ORM or schema."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
Durable chat runs can span **hours** and **many turns**. You usually want:
|
||||
|
||||
1. **Conversation state** — full **`UIMessage[]`** (or equivalent) keyed by **`chatId`**, so reloads and history views work.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Human-in-the-loop"
|
||||
description: "Pause the agent mid-response to ask the user a clarifying question, then resume with their answer."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
Some turns need to stop and ask the user something before they can finish — picking between options, confirming a destructive action, or clarifying an ambiguous request. The AI SDK calls this **human-in-the-loop** (HITL), and the building block is a tool with no `execute` function.
|
||||
|
||||
When the LLM calls a tool that has no `execute`, `streamText` ends with the tool call still pending. The turn completes cleanly, the frontend renders UI to collect the answer, and when the user responds, a new turn resumes with the answer merged into the same assistant message.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Large payloads"
|
||||
description: "Why a single chunk on the chat stream is capped at ~1 MiB, what error you'll see, and how to work around it with ID references."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
The realtime stream that backs `chat.agent` enforces a **per-record cap of ~1 MiB** (`1048576` bytes minus a small envelope reserve). Anything written through the chat output — auto-piped LLM chunks, `chat.response.write`, custom `writer.write` parts — counts as one record per chunk and is rejected if it crosses the cap.
|
||||
|
||||
This is a platform-level limit and cannot be raised per project or per stream.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "OOM resilience"
|
||||
description: "Recover from out-of-memory errors mid-turn by automatically retrying the failed turn on a larger machine — without losing the in-flight user message or re-processing completed turns."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
When a `chat.agent` turn runs out of memory, the worker process dies and everything in it is gone: the in-flight LLM call, the accumulator, any tool execution mid-flight. By default, Trigger.dev surfaces the OOM as a run failure.
|
||||
|
||||
Setting `oomMachine` opts the agent into automatic recovery: the failed turn re-runs on a larger machine, picks up the user message that triggered the OOM (without re-processing earlier completed turns), and produces a normal response.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Persistence and replay"
|
||||
description: "How chat.agent rebuilds conversation history at run boot — durable JSON snapshot in object storage plus session.out replay, with a hydrateMessages short-circuit for backend-owned history."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
`chat.agent` runs are processes — they boot, stream a turn, and either suspend (waiting for the next message) or exit. When the next message arrives at a session whose previous run already exited, a **fresh** run boots with no in-memory state. Something has to rebuild the conversation history before that turn can produce a coherent response.
|
||||
|
||||
This page walks through the **snapshot + replay** model the runtime uses by default, and the [`hydrateMessages`](/ai-chat/lifecycle-hooks#hydratemessages) short-circuit that turns the whole thing off when the customer owns history.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Recovery boot"
|
||||
description: "Recover from cancel-mid-stream, crashes, and OOM kills with full conversational context. The smart default Just Works; the onRecoveryBoot hook is the override path for advanced policies."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
When a `chat.agent` run dies in the middle of streaming a response — the user cancels, the worker OOMs, or an unhandled exception kills the process — the durable streams hold what was in flight. The next run boots as a continuation, reads both stream tails, and reconstructs a chain that preserves the partial response so any follow-up (`keep going`, `actually do X instead`, a new question) has full context.
|
||||
|
||||
The behavior is automatic. The `onRecoveryBoot` hook is opt-in for policies that need something different.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Agent Skills"
|
||||
description: "Ship reusable capabilities (folders with SKILL.md + scripts) that a chat agent discovers and invokes on demand."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
Agent skills are reusable capabilities you ship as folders — a `SKILL.md` describing when and how to use them, plus optional scripts, references, and assets. The chat agent sees a short description of each skill in its system prompt, loads the full instructions on demand via a `loadSkill` tool, and invokes the bundled scripts via `bash` — all without you wiring anything up manually.
|
||||
|
||||
Built on the [AI SDK cookbook pattern](https://ai-sdk.dev/cookbook/guides/agent-skills). Works with any provider (OpenAI, Anthropic, Gemini, etc.) — not tied to Anthropic's server-side skills.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Sub-Agents"
|
||||
description: "Delegate work to durable sub-agents from within a parent agent's tool calls, with streaming preliminary results."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
Sub-agents let a parent agent delegate work to other agents running as durable Trigger.dev tasks. The sub-agent's response streams back through the parent as preliminary tool results, so the frontend sees the sub-agent working inside the parent's tool call card.
|
||||
|
||||
This builds on the AI SDK's [async generator tool pattern](https://ai-sdk.dev/docs/agents/subagents) and Trigger.dev's [AgentChat](/ai-chat/server-chat) for server-side agent interaction.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Tool result auditing"
|
||||
description: "Fire side effects exactly once per resolved tool call — audit logs, billing, notifications — using extractNewToolResults inside hydrateMessages or onTurnComplete."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
When a chat agent uses [tools](/ai-chat/tools) (especially [human-in-the-loop](/ai-chat/patterns/human-in-the-loop) tools that wait on `addToolOutput` from the frontend), you often need to fire side effects exactly once per resolved tool call:
|
||||
|
||||
- **Audit logs** — record every tool result for compliance.
|
||||
|
||||
@@ -4,10 +4,6 @@ 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."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
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.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Version upgrades"
|
||||
description: "Gracefully migrate suspended chat agents to a new deployment using chat.requestUpgrade() and the continuation mechanism."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
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()` lets the agent opt out of the current run so the transport triggers a new one on the latest version.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Pending Messages"
|
||||
description: "Inject user messages mid-execution to steer agents between tool-call steps."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
## Overview
|
||||
|
||||
When an AI agent is executing tool calls, users may want to send a message that **steers the agent mid-execution** — adding context, correcting course, or refining the request without waiting for the response to finish.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Prompt caching"
|
||||
description: "Cache the stable prefix of your agent's prompt with Anthropic prompt caching to cut token cost and latency on every turn."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
**Prompt caching lets a provider reuse the unchanged prefix of your prompt across requests, billing it at a fraction of the input price and skipping re-processing.** With Anthropic, cache reads cost ~10% of base input tokens, so a long, stable system prompt or a growing conversation history pays full price once and reads cheaply on every turn after.
|
||||
|
||||
Caching is a **byte-exact prefix match**: any change in the prefix invalidates everything after it. A multi-turn agent is the ideal case — the system prompt, tools, and earlier turns are identical turn over turn, so the cacheable prefix only grows. `chat.agent` is built to keep that prefix stable across turns, suspends, and resumes; this page shows how to place the cache breakpoints and verify they're hitting.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Quick Start"
|
||||
description: "Get a working AI agent in 3 steps — define an agent, generate a token, and wire up the frontend."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
These steps assume you already have a Trigger.dev project with the SDK installed and the CLI authenticated — if you don't, follow [Manual setup](/manual-setup) (or `npx trigger.dev@latest init` in an existing project) first. You should be able to run `pnpm exec trigger dev` from your project root before continuing.
|
||||
|
||||
The chat surface works with Vercel AI SDK **v5, v6, or v7**; install whichever major you want. On **v7**, also install `@ai-sdk/otel` so your model calls are traced (the SDK registers it for you). See [compatibility](/ai-chat/reference#compatibility) for the full matrix.
|
||||
|
||||
@@ -4,15 +4,11 @@ sidebarTitle: "API Reference"
|
||||
description: "Complete API reference for the AI Agents SDK — backend options, events, frontend transport, and hooks."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
## Compatibility
|
||||
|
||||
| Dependency | Supported | Notes |
|
||||
|---|---|---|
|
||||
| `@trigger.dev/sdk` | `>=4.5.0-rc.0` | The chat agent surface lives in this SDK release. Install with `@trigger.dev/sdk@rc`. |
|
||||
| `@trigger.dev/sdk` | `>=4.5.0` | The chat agent surface lives in this SDK release. Install with `@trigger.dev/sdk@latest`. |
|
||||
| `ai` (Vercel AI SDK) | `^5.0.0 \|\| ^6.0.0 \|\| >=7.0.0-canary <8` | Declared as a peer. v6 is what we develop against day to day; v5 and v7 work too (v7 is in canary/beta upstream). Your installed `ai` major drives the chat surface's types. |
|
||||
| `@ai-sdk/otel` | `1.x` (v7 only) | Optional. AI SDK 7 moved model-call span emission out of `ai` core into this adapter. Install it alongside `ai@7` and the SDK auto-registers it, so your model calls show up as spans in the run trace. Not needed on v5/v6, where `ai` core emits spans. See [AI SDK 7 telemetry](#ai-sdk-7-telemetry) below. |
|
||||
| `@ai-sdk/react` | matches your `ai` major | Pulled in by `useChat`. The transport works with whichever React hook ships in the same major as your `ai` version. |
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Server-Side Chat"
|
||||
description: "Use AgentChat to interact with chat agents from server-side code — tasks, webhooks, scripts, or other agents."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
`AgentChat` lets you chat with agents from server-side code. It works inside tasks (agent-to-agent), request handlers, webhook processors, and scripts.
|
||||
|
||||
```ts
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Sessions"
|
||||
description: "A Session is a stateful execution of an agent, with two-way streaming and durable compute. A single Session can have multiple runs associated with it."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
**A Session is a stateful execution of an agent.** It includes two-way streaming and durable compute, and a single Session can have multiple runs associated with it.
|
||||
|
||||
The **two-way streaming** is a pair of durable streams. The input stream (`.in`) carries incoming user messages to your task. The output stream (`.out`) carries everything the agent produces back to your clients: AI generation parts (text, reasoning, tool calls) and any custom data parts you write.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Testing"
|
||||
description: "Drive a chat.agent through real turns in unit tests — no network, no task runtime, no mocking the SDK."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
## Overview
|
||||
|
||||
`@trigger.dev/sdk/ai/test` exports `mockChatAgent`, an offline harness that runs your `chat.agent` definition's `run()` function inside an in-memory task runtime. You send messages, actions, and stop signals through driver methods and assert against the chunks the agent emits.
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Tools"
|
||||
description: "Declare tools on chat.agent so toModelOutput survives across turns, get them back typed in run(), and type your messages from them."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
`chat.agent` doesn't call the model for you. Your tools still go to [`streamText`](https://sdk.vercel.ai/docs/ai-sdk-core/tools-and-tool-calling) inside `run()`. But you should **also declare them on the agent config**:
|
||||
|
||||
```ts
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Types"
|
||||
description: "TypeScript types for AI Agents, UI messages, and the frontend transport."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
TypeScript patterns for [AI Chat](/ai-chat/overview). This page covers how to pin a custom AI SDK [`UIMessage`](https://sdk.vercel.ai/docs/reference/ai-sdk-core/ui-message) subtype with `chat.withUIMessage`, fix a typed `clientData` schema with `chat.withClientData`, chain builder-level hooks, and align types on the client.
|
||||
|
||||
## Custom `UIMessage` with `chat.withUIMessage`
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Sessions Upgrade Guide"
|
||||
description: "Migrating chat.agent code from the prerelease API to the Sessions-as-run-manager release."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
This guide is for customers who tried `chat.agent` during the prerelease period.
|
||||
The public surface of `chat.agent({...})`, `useTriggerChatTransport`,
|
||||
`AgentChat`, `chat.defer`, and `chat.history` is largely
|
||||
|
||||
@@ -4,10 +4,6 @@ sidebarTitle: "Prompts"
|
||||
description: "Define prompt templates as code, version them on deploy, and override from the dashboard without redeploying."
|
||||
---
|
||||
|
||||
import RcBanner from "/snippets/ai-chat-rc-banner.mdx";
|
||||
|
||||
<RcBanner />
|
||||
|
||||
## Overview
|
||||
|
||||
AI Prompts let you define prompt templates in your codebase alongside your tasks. When you deploy, Trigger.dev automatically versions your prompts. You can then:
|
||||
|
||||
@@ -28,11 +28,6 @@ We provide multiple tools to help AI coding assistants write correct Trigger.dev
|
||||
npx trigger.dev@latest skills
|
||||
```
|
||||
|
||||
<Warning>
|
||||
The `skills` command is currently only available in the release candidate. Until it ships to
|
||||
the stable release, run it with the `@rc` tag: `npx trigger.dev@rc skills`.
|
||||
</Warning>
|
||||
|
||||
[Learn more →](/skills)
|
||||
</Step>
|
||||
|
||||
@@ -46,7 +41,7 @@ Skills and the MCP server do different jobs and work best together. Here's how t
|
||||
|:--|:-----------|:---------------|
|
||||
| **What it does** | Drops skill files into your project that teach Trigger.dev patterns | Runs a live server your AI connects to |
|
||||
| **Installs to** | `.claude/skills/`, `.cursor/skills/`, `.github/skills/`, `.agents/skills/` | `mcp.json`, `~/.claude.json`, etc. |
|
||||
| **Updates** | Re-run `npx trigger.dev@latest skills` (`@rc` until it ships to stable), or auto-prompted on `trigger dev` | Always latest (uses `@latest`) |
|
||||
| **Updates** | Re-run `npx trigger.dev@latest skills`, or auto-prompted on `trigger dev` | Always latest (uses `@latest`) |
|
||||
| **Best for** | Teaching patterns and best practices | Live project interaction (deploy, trigger, monitor) |
|
||||
| **Works offline** | Yes | No (calls Trigger.dev API) |
|
||||
|
||||
|
||||
@@ -19,12 +19,7 @@ The install command is the same, and now installs skills:
|
||||
npx trigger.dev@latest skills
|
||||
```
|
||||
|
||||
<Warning>
|
||||
The `skills` command is currently only available in the release candidate. Until it ships to the
|
||||
stable release, run it with the `@rc` tag: `npx trigger.dev@rc skills`.
|
||||
</Warning>
|
||||
|
||||
`npx trigger.dev@latest install-rules` still works as an alias for `skills` (so the same `@rc` caveat applies for now), and `trigger dev` offers to install the skills on first run.
|
||||
`npx trigger.dev@latest install-rules` still works as an alias for `skills`, and `trigger dev` offers to install the skills on first run.
|
||||
|
||||
The old task and realtime guidance now lives in the `trigger-authoring-tasks` and `trigger-realtime-and-frontend` skills, alongside two new skills for building `chat.agent` AI agents. See [Skills](/skills) for the full list and supported assistants.
|
||||
|
||||
|
||||
+1
-8
@@ -24,11 +24,6 @@ Run the installer with the CLI:
|
||||
npx trigger.dev@latest skills
|
||||
```
|
||||
|
||||
<Warning>
|
||||
The `skills` command is currently only available in the release candidate. Until it ships to the
|
||||
stable release, run it with the `@rc` tag: `npx trigger.dev@rc skills`.
|
||||
</Warning>
|
||||
|
||||
The CLI detects your installed AI tools, lets you pick which skills to install, and writes each one into that tool's native skills directory (`.claude/skills/`, `.cursor/skills/`, `.github/skills/`, `.agents/skills/`). It also adds a one-line pointer to your primary instructions file (`CLAUDE.md`, `.cursor/rules`, etc.) so your assistant always knows the skills are there and loads the right one on demand.
|
||||
|
||||
When you run `trigger dev` for the first time, the CLI offers to install the skills for you.
|
||||
@@ -43,8 +38,6 @@ Pass `--target` to choose tools and `-y` to install every skill without promptin
|
||||
npx trigger.dev@latest skills --target claude-code --target cursor -y
|
||||
```
|
||||
|
||||
While the command is still release-candidate only, swap `@latest` for `@rc`.
|
||||
|
||||
## Available skills
|
||||
|
||||
| Skill | Use for | Covers |
|
||||
@@ -72,7 +65,7 @@ Using a tool that does not support skills yet? Select "Unsupported target" in th
|
||||
|
||||
## Keeping skills updated
|
||||
|
||||
The API guidance updates on its own: it lives in `@trigger.dev/sdk` and is read from `node_modules`, so upgrading the SDK in your project upgrades the guidance with it. Re-run `npx trigger.dev@latest skills` (use `@rc` until the command ships to the stable release, or accept the prompt that `trigger dev` shows when a newer version is available) only to add skills or refresh the installed pointer files. Re-running overwrites them in place without creating duplicates.
|
||||
The API guidance updates on its own: it lives in `@trigger.dev/sdk` and is read from `node_modules`, so upgrading the SDK in your project upgrades the guidance with it. Re-run `npx trigger.dev@latest skills` (or accept the prompt that `trigger dev` shows when a newer version is available) only to add skills or refresh the installed pointer files. Re-running overwrites them in place without creating duplicates.
|
||||
|
||||
## Next steps
|
||||
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
<Warning>
|
||||
The AI Agents and Prompts surface ships as part of the **v4.5 release candidate**. Install with `@trigger.dev/sdk@rc` (or pin `4.5.0-rc.0` or later) to use these features — they aren't yet on the latest stable, and APIs may still change before the 4.5.0 GA. See [supported AI SDK versions](/ai-chat/reference#compatibility) and the [AI chat changelog](/ai-chat/changelog) for details.
|
||||
</Warning>
|
||||
Reference in New Issue
Block a user