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

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/kubernetes.mdx

@@ -61,7 +61,7 @@ webapp:
 ```bash
 helm upgrade -n trigger --install trigger \
   oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "~4.0.0" \
+  --version "^4.5.0" \
   --create-namespace
 ```
 
@@ -107,11 +107,11 @@ The following commands will display the default values:
 ```bash
 # Specific version
 helm show values oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "4.0.5"
+  --version "4.5.0"
 
 # Latest v4
 helm show values oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "~4.0.0"
+  --version "^4.5.0"
 ```
 
 ### Custom values
@@ -171,7 +171,7 @@ Deploy with your custom values:
 ```bash
 helm upgrade -n trigger --install trigger \
   oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "~4.0.0" \
+  --version "^4.5.0" \
   --create-namespace \
   -f values-custom.yaml
 ```
@@ -510,14 +510,14 @@ You can lock versions in two ways:
 # Pin to a specific version for production
 helm upgrade -n trigger --install trigger \
   oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "4.0.5"
+  --version "4.5.0"
 
 # The app version will be different from the chart version
 # This is the version of the Trigger.dev webapp and supervisor
 # ..and should always match your Trigger.dev CLI version
 helm show chart \
   oci://ghcr.io/triggerdotdev/charts/trigger \
-  --version "4.0.5" | grep appVersion
+  --version "4.5.0" | grep appVersion
 ```
 
 **Specific image tags:**
@@ -525,11 +525,11 @@ helm show chart \
 ```yaml
 webapp:
   image:
-    tag: "v4.0.0"
+    tag: "v4.5.0"
 
 supervisor:
   image:
-    tag: "v4.0.0"
+    tag: "v4.5.0"
 ```
 
 The chart version's `appVersion` field determines the default image tags. Newer image tags may be incompatible with older chart versions and vice versa.

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.1",
   "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.1",
     "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 />