@trigger.dev/sdk 4.5.0-rc.7 → 4.5.0

package/docs/ai-chat/patterns/oom-resilience.mdx

@@ -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.

package/docs/ai-chat/patterns/persistence-and-replay.mdx

@@ -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.

package/docs/ai-chat/patterns/recovery-boot.mdx

@@ -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.

package/docs/ai-chat/patterns/skills.mdx

@@ -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.

package/docs/ai-chat/patterns/sub-agents.mdx

@@ -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.

package/docs/ai-chat/patterns/tool-result-auditing.mdx

@@ -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.

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

@@ -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.

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

@@ -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.

package/docs/ai-chat/pending-messages.mdx

@@ -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.

package/docs/ai-chat/prompt-caching.mdx

@@ -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.
@@ -135,6 +131,10 @@ The system breakpoint and the conversation breakpoint compose: the system block
   Anthropic allows **at most 4** cache breakpoints per request, and a prefix must be at least ~1024 tokens (model-dependent) to cache at all — shorter prefixes silently don't cache. One system breakpoint plus one rolling message breakpoint is the typical setup and leaves headroom.
 </Note>
 
+<Note>
+  This rolling-breakpoint pattern composes with [Head Start](/ai-chat/fast-starts#head-start). On a head-start handover, the first turn's pending tool call is handed to the agent as a tool-approval round whose trailing `tool` message must reach `streamText` untouched for that call to execute. `chat.agent` preserves that tail across `prepareMessages` automatically, so rewriting the last message here is safe: on a resume turn the breakpoint just lands on the next user or assistant message instead of the transient approval row.
+</Note>
+
 ## Caching and compaction
 
 Compaction rewrites the conversation prefix — it replaces earlier turns with a summary — so it necessarily invalidates the cached message prefix at that point. That's a one-time reset, not a regression: because `prepareMessages` also runs on the compaction rebuild and result paths, the new (shorter) prefix gets a fresh breakpoint and re-warms on the next turn. Your system-prompt cache is unaffected — compaction never touches the system block. See [Compaction](/ai-chat/compaction) for how the summary is produced.

package/docs/ai-chat/quick-start.mdx

@@ -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.

package/docs/ai-chat/reference.mdx

@@ -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. |

package/docs/ai-chat/server-chat.mdx

@@ -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

package/docs/ai-chat/sessions.mdx

@@ -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.

package/docs/ai-chat/testing.mdx

@@ -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.

package/docs/ai-chat/tools.mdx

@@ -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

package/docs/ai-chat/types.mdx

@@ -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`

package/docs/ai-chat/upgrade-guide.mdx

@@ -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

package/docs/building-with-ai.mdx

@@ -1,5 +1,5 @@
 ---
-title: "Overview"
+title: "Building with AI: overview"
 sidebarTitle: "Overview"
 description: "Tools and resources for building Trigger.dev projects with AI coding assistants."
 ---

package/docs/deploy-environment-variables.mdx

@@ -230,7 +230,7 @@ To sync environment variables from your Vercel projects to Trigger.dev, you can
 
 #### Deploy
 
-When you run the [CLI deploy command](/cli-deploy) directly or using [GitHub Actions](/github-actions) it will sync the environment variables from [Infisical](https://infisical.com) to Trigger.dev. This means they'll appear on the Environment Variables page so you can confirm that it's worked.
+When you run the [CLI deploy command](/cli-deploy-commands) directly or using [GitHub Actions](/github-actions) it will sync the environment variables from [Infisical](https://infisical.com) to Trigger.dev. This means they'll appear on the Environment Variables page so you can confirm that it's worked.
 
 This means that you need to redeploy your Trigger.dev tasks if you change the environment variables in [Infisical](https://infisical.com).
 

package/docs/deployment/dev-branches.mdx

@@ -0,0 +1,92 @@
+---
+title: "Development branches"
+sidebarTitle: "Dev branches"
+description: "Run multiple local dev sessions in isolation by giving each one its own development branch. Use branches to keep parallel work (in separate worktrees, directories, or agents) from clashing."
+---
+
+Every project starts with a single development environment called `default`. A **dev branch** is an isolated environment that lives under development, with its own runs, schedules, and concurrency.
+
+Branches are useful when you run more than one local dev session at a time. Give each session its own branch so their runs don't collide:
+
+- Run several [git worktrees](https://git-scm.com/docs/git-worktree) or copies of your project in parallel, one branch each.
+- Let multiple coding agents each work in their own branch without stepping on one another.
+
+When you're done with a branch, you can archive it to free up a slot or just re-use it.
+
+## Run a dev session on a branch
+
+Log in with the CLI first:
+
+<CodeGroup>
+
+```bash npm
+npx trigger.dev@latest login
+```
+
+```bash pnpm
+pnpm dlx trigger.dev@latest login
+```
+
+```bash bun
+bunx trigger.dev@latest login
+```
+
+</CodeGroup>
+
+Then start a dev session on a branch with the `--branch` flag. If the branch doesn't exist yet, it's created:
+
+<CodeGroup>
+
+```bash npm
+npx trigger.dev@latest dev --branch my-feature
+```
+
+```bash pnpm
+pnpm dlx trigger.dev@latest dev --branch my-feature
+```
+
+```bash bun
+bunx trigger.dev@latest dev --branch my-feature
+```
+
+</CodeGroup>
+
+Without `--branch`, the session runs on the `default` branch.
+
+<Tip>
+You can also set the branch with the `TRIGGER_DEV_BRANCH` environment variable instead of the flag.
+</Tip>
+
+## Archive a branch
+
+Archive a branch from the CLI when you no longer need it. The CLI detects your local git branch, or you can name one with `--branch`:
+
+<CodeGroup>
+
+```bash npm
+npx trigger.dev@latest dev archive --branch my-feature
+```
+
+```bash pnpm
+pnpm dlx trigger.dev@latest dev archive --branch my-feature
+```
+
+```bash bun
+bunx trigger.dev@latest dev archive --branch my-feature
+```
+
+</CodeGroup>
+
+You can also create and archive branches from the **Dev branches** page in the dashboard.
+
+## Limits on active branches
+
+Each branch has its own concurrency, so we limit how many can be active per project. Archive a branch at any time to unlock another slot.
+
+| Plan  | Active dev branches |
+| ----- | ------------------- |
+| Free  | 25                  |
+| Hobby | 25                  |
+| Pro   | 25                  |
+
+Need more? [Get in touch](https://trigger.dev/contact) and we'll raise the limit.

package/docs/deployment/overview.mdx

@@ -6,7 +6,7 @@ description: "Learn how to deploy your tasks to Trigger.dev."
 
 import CorepackError from "/snippets/corepack-error.mdx";
 
-Before you can run production workloads on Trigger.dev, you need to deploy your tasks. The only way to do this at the moment is through the [deploy CLI command](/cli-deploy):
+Before you can run production workloads on Trigger.dev, you need to deploy your tasks. The only way to do this at the moment is through the [deploy CLI command](/cli-deploy-commands):
 
 <CodeGroup>
 

package/docs/help-slack.mdx

@@ -1,5 +1,6 @@
 ---
 title: "Slack support"
+description: "Trigger.dev Pro plan customers can request a private Slack Connect channel for support."
 ---
 
 If you're on the Trigger.dev Pro plan, you can request a private Slack Connect channel.

package/docs/how-to-reduce-your-spend.mdx

@@ -16,21 +16,28 @@ Monitor your usage dashboard to understand your spending patterns. You can see:
 
 You can view your usage page by clicking the "Organization" menu in the top left of the dashboard and then clicking "Usage".
 
-## Create billing alerts
+## Set billing limits and alerts
 
-Configure billing alerts in your dashboard to get notified when you approach spending thresholds. This helps you:
+Configure billing limits and alerts in your dashboard to protect against unexpected usage and get notified when you approach spending thresholds. This helps you:
 
+- Set a monthly compute spend limit for your organization
 - Catch unexpected cost increases early
 - Identify runaway tasks before they become expensive
 
-The billing alerts page includes two types of alerts:
+The **Billing limits** settings page has two sections:
 
-- **Standard alerts**: Get notified at 75%, 90%, 100%, 200%, and 500% of your monthly budget
-- **Spike alerts**: Catch runaway usage from bugs or errors with alerts at 10x (1000%), 20x (2000%), 50x (5000%), and 100x (10000%) of your monthly budget. We recommend keeping these enabled as a safety net.
+- **Billing limit**: Choose your plan limit, a custom amount, or no limit. When a limit is reached, billable environments (`production`, `staging`, and `preview`) enter a **grace period** — queues pause and new runs queue without starting. After grace expires, new triggers are rejected until you increase or remove the limit.
+- **Billing alerts**: Add email alerts at specific spend thresholds (% of your limit when a limit is set, or dollar amounts when no limit is configured). Alerts notify you only; they do **not** pause environments or reject triggers.
 
-![Billing alerts](./images/billing-alerts-ui.png)
+**Limits vs alerts:** A billing limit enforces spend (grace → reject). Billing alerts are optional notifications at thresholds you choose.
 
-You can view your billing alerts page by clicking the "Organization" menu in the top left of the dashboard and then clicking "Settings".
+**Soft limits:** Billing limits are not instantaneous hard caps. Usage is evaluated on a short delay, so spend can briefly exceed your limit before enforcement applies. Queued runs during grace incur no compute cost until they start. See our [terms](https://trigger.dev/terms) for refund policy details.
+
+On the **Usage** page, when you have a custom billing limit (or a plan limit that differs from included usage), a **Billing limit** marker appears on the usage bar alongside your current spend and plan included usage.
+
+![Billing limits and alerts settings](./images/billing-alerts-ui.png)
+
+You can open the page from the **Organization** menu in the top left of the dashboard, then **Settings** → **Billing limits**.
 
 ## Reduce your machine sizes
 

package/docs/introduction.mdx

@@ -91,19 +91,19 @@ We provide everything you need to build and manage background tasks: a CLI and S
 
 | Extension             | What it does                                                 | Docs                                                   |
 | :-------------------- | :----------------------------------------------------------- | :----------------------------------------------------- |
-| prismaExtension       | Use Prisma with Trigger.dev                                  | [Learn more](/config/extensions/prismaExtension)       |
-| pythonExtension       | Execute Python scripts in Trigger.dev                        | [Learn more](/config/extensions/pythonExtension)       |
-| playwright            | Use Playwright with Trigger.dev                              | [Learn more](/config/extensions/playwright)            |
-| puppeteer             | Use Puppeteer with Trigger.dev                               | [Learn more](/config/extensions/puppeteer)             |
-| lightpanda            | Use Lightpanda with Trigger.dev                              | [Learn more](/config/extensions/lightpanda)            |
-| ffmpeg                | Use FFmpeg with Trigger.dev                                  | [Learn more](/config/extensions/ffmpeg)                |
-| aptGet                | Install system packages with aptGet                          | [Learn more](/config/extensions/aptGet)                |
-| additionalFiles       | Copy additional files to the build directory                 | [Learn more](/config/extensions/additionalFiles)       |
-| additionalPackages    | Include additional packages in the build                     | [Learn more](/config/extensions/additionalPackages)    |
-| syncEnvVars           | Automatically sync environment variables to Trigger.dev      | [Learn more](/config/extensions/syncEnvVars)           |
-| esbuildPlugin         | Add existing or custom esbuild plugins to your build process | [Learn more](/config/extensions/esbuildPlugin)         |
-| emitDecoratorMetadata | Support for the emitDecoratorMetadata TypeScript compiler    | [Learn more](/config/extensions/emitDecoratorMetadata) |
-| audioWaveform         | Support for Audio Waveform in your project                   | [Learn more](/config/extensions/audioWaveform)         |
+| prismaExtension       | Use Prisma with Trigger.dev                                  | [prismaExtension docs](/config/extensions/prismaExtension)             |
+| pythonExtension       | Execute Python scripts in Trigger.dev                        | [pythonExtension docs](/config/extensions/pythonExtension)             |
+| playwright            | Use Playwright with Trigger.dev                              | [playwright extension docs](/config/extensions/playwright)             |
+| puppeteer             | Use Puppeteer with Trigger.dev                               | [puppeteer extension docs](/config/extensions/puppeteer)               |
+| lightpanda            | Use Lightpanda with Trigger.dev                              | [lightpanda extension docs](/config/extensions/lightpanda)             |
+| ffmpeg                | Use FFmpeg with Trigger.dev                                  | [ffmpeg extension docs](/config/extensions/ffmpeg)                     |
+| aptGet                | Install system packages with aptGet                          | [aptGet extension docs](/config/extensions/aptGet)                     |
+| additionalFiles       | Copy additional files to the build directory                 | [additionalFiles docs](/config/extensions/additionalFiles)             |
+| additionalPackages    | Include additional packages in the build                     | [additionalPackages docs](/config/extensions/additionalPackages)       |
+| syncEnvVars           | Automatically sync environment variables to Trigger.dev      | [syncEnvVars docs](/config/extensions/syncEnvVars)                     |
+| esbuildPlugin         | Add existing or custom esbuild plugins to your build process | [esbuildPlugin docs](/config/extensions/esbuildPlugin)                 |
+| emitDecoratorMetadata | Support for the emitDecoratorMetadata TypeScript compiler    | [emitDecoratorMetadata docs](/config/extensions/emitDecoratorMetadata) |
+| audioWaveform         | Support for Audio Waveform in your project                   | [audioWaveform docs](/config/extensions/audioWaveform)                 |
 
 ## Explore by example
 

package/docs/mcp-agent-rules.mdx

@@ -19,7 +19,7 @@ The install command is the same, and now installs skills:
 npx trigger.dev@latest skills
 ```
 
-`npx trigger.dev@latest install-rules` still works as an alias, 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.
 

package/docs/open-source-self-hosting.mdx

@@ -156,7 +156,7 @@ TRIGGER_DOMAIN=1234-42-42-42-42.ngrok-free.app
 
 ### Registry setup
 
-If you want to deploy v3 projects, you will need access to a Docker registry. The [CLI deploy](/cli-deploy) command will push the images, and then the worker machine can pull them when needed. We will use Docker Hub as an example.
+If you want to deploy v3 projects, you will need access to a Docker registry. The [CLI deploy](/cli-deploy-commands) command will push the images, and then the worker machine can pull them when needed. We will use Docker Hub as an example.
 
 1. Sign up for a free account at [Docker Hub](https://hub.docker.com/)
 

package/docs/self-hosting/overview.mdx

@@ -1,5 +1,6 @@
 ---
-title: "Overview"
+title: "Self-hosting overview"
+sidebarTitle: "Overview"
 description: "You can self-host Trigger.dev on your own infrastructure."
 ---
 

package/docs/tasks/scheduled.mdx

@@ -95,7 +95,7 @@ There are two ways of doing this:
 
 ### Declarative schedules
 
-These sync when you run the [dev](/cli-dev) or [deploy](/cli-deploy) commands.
+These sync when you run the [dev](/cli-dev-commands) or [deploy](/cli-deploy-commands) commands.
 
 To create them you add the `cron` property to your `schedules.task()`. This property is optional and is only used if you want to add a declarative schedule to your task:
 
@@ -127,7 +127,7 @@ export const secondScheduledTask = schedules.task({
 });
 ```
 
-When you run the [dev](/cli-dev) or [deploy](/cli-deploy) commands, declarative schedules will be synced. If you add, delete or edit the `cron` property it will be updated when you run these commands. You can view your schedules on the Schedules page in the dashboard.
+When you run the [dev](/cli-dev-commands) or [deploy](/cli-deploy-commands) commands, declarative schedules will be synced. If you add, delete or edit the `cron` property it will be updated when you run these commands. You can view your schedules on the Schedules page in the dashboard.
 
 ### Imperative schedules
 

package/docs/troubleshooting-debugging-in-vscode.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Debugging in VS Code"
 sidebarTitle: "Debugging in VS Code"
+description: "Attach the VS Code debugger to your Trigger.dev tasks to set breakpoints and step through your code."
 ---
 
 import DebuggingInVSCode from '/snippets/debugging_in_vscode.mdx';

package/docs/troubleshooting-github-issues.mdx

@@ -3,4 +3,4 @@ title: "GitHub Issues"
 url: "https://github.com/triggerdotdev/trigger.dev/issues"
 ---
 
-Please [join our community on Discord](https://github.com/triggerdotdev/trigger.dev/issues) to ask questions, share your projects, and get help from other developers.
+Please [join our community on Discord](https://trigger.dev/discord) to report bugs, request features, or get help from the team and other developers.

package/docs/troubleshooting-uptime-status.mdx

@@ -1,5 +1,6 @@
 ---
 title: "Uptime Status"
+description: "Subscribe to email notifications for Trigger.dev platform incidents and status updates."
 ---
 
 Get email notifications when Trigger.dev creates, updates or resolves a platform incident.

package/docs/video-walkthrough.mdx

@@ -20,4 +20,4 @@ description: "Go from zero to a working task in your Next.js app in 10 minutes."
 - [1:44](https://youtu.be/YH_4c0K7fGM?si=J8svVzotZtyTXDap&t=104) – [Run and test](/run-tests) the "Hello, world!" example project
 - [2:09](https://youtu.be/YH_4c0K7fGM?si=FMTP8ep_cDBCU0_x&t=128) – Create and run an AI image generation task that uses [Fal.ai](https://fal.ai) – ([View the code](/guides/examples/fal-ai-image-to-cartoon))
 - [6:25](https://youtu.be/YH_4c0K7fGM?si=pPc8iLI2Y9FGD3yo&t=385) – Create and run a [Realtime](/realtime/overview) example using [React hooks](/realtime/react-hooks) – ([View the code](/guides/examples/fal-ai-realtime))
-- [11:10](https://youtu.be/YH_4c0K7fGM?si=Mjd0EvvNsNlVouvY&t=670) – [Deploy your task](/cli-deploy) to the Trigger.dev Cloud
+- [11:10](https://youtu.be/YH_4c0K7fGM?si=Mjd0EvvNsNlVouvY&t=670) – [Deploy your task](/cli-deploy-commands) to the Trigger.dev Cloud

package/docs/wait-for.mdx

@@ -38,5 +38,5 @@ You can pass an idempotency key to any wait function, allowing you to skip waits
 
 ```ts
 // Specify the idempotency key and TTL when waiting for a duration:
-await wait.for({ seconds: 10 }, { idempotencyKey: "my-idempotency-key", idempotencyKeyTTL: "1h" });
+await wait.for({ seconds: 10, idempotencyKey: "my-idempotency-key", idempotencyKeyTTL: "1h" });
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trigger.dev/sdk",
-  "version": "4.5.0-rc.7",
+  "version": "4.5.0",
   "description": "trigger.dev Node.JS SDK",
   "license": "MIT",
   "publishConfig": {
@@ -66,7 +66,7 @@
   "dependencies": {
     "@opentelemetry/api": "1.9.1",
     "@opentelemetry/semantic-conventions": "1.41.1",
-    "@trigger.dev/core": "4.5.0-rc.7",
+    "@trigger.dev/core": "4.5.0",
     "chalk": "^5.2.0",
     "cronstrue": "^2.21.0",
     "debug": "^4.3.4",

package/docs/cli-dev.mdx

@@ -1,8 +0,0 @@
----
-title: "CLI dev command"
-description: "The `trigger.dev dev` command is used to run your tasks locally."
----
-
-import CliDevCommands from "/snippets/cli-commands-develop.mdx";
-
-<CliDevCommands />