@trigger.dev/sdk 4.7.3 → 4.7.4

package/docs/deployment/dev-branches.mdx

@@ -59,7 +59,7 @@ You can also set the branch with the `TRIGGER_DEV_BRANCH` environment variable i
 
 ## 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`:
+Archive a branch from the CLI when you no longer need it. Pass the branch with `--branch` (or set `TRIGGER_DEV_BRANCH`); it's required, and the `default` branch can't be archived:
 
 <CodeGroup>
 
@@ -81,12 +81,12 @@ You can also create and archive branches from the **Dev branches** page in the d
 
 ## 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.
+Each branch has its own concurrency, so we limit how many dev branches each developer can have active per project. The `default` development environment counts toward this limit. If you are at the limit when you run `dev --branch`, the CLI automatically archives up to 3 of your branches that have no connected dev session and have been idle for over an hour, to make room. You can also archive a branch any time to free a slot.
 
 | Plan  | Active dev branches |
 | ----- | ------------------- |
-| Free  | 25                  |
-| Hobby | 25                  |
-| Pro   | 25                  |
+| Free  | 50                  |
+| Hobby | 50                  |
+| Pro   | 50                  |
 
 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-commands):
+Before you can run production workloads on Trigger.dev, you need to deploy your tasks. The manual way to do this is the [deploy CLI command](/cli-deploy-commands). You can also deploy automatically with the [GitHub integration](/github-integration) or the [Vercel integration](/vercel-integration):
 
 <CodeGroup>
 
@@ -100,8 +100,9 @@ When you deploy, the version number is automatically incremented, and the new ve
 The current version defines which version of the code new task runs will execute against. When a task run starts, it is locked to the current version. This ensures that the task run is not affected by changes to the code. Retries of the task run will also be locked to the original version.
 
 <Note>
-  When you Replay a run in the dashboard we will create a new run, locked to the current version and
-  not necessarily the version of the original run.
+  When you Replay a run in the dashboard we create a new run that uses the current version by default
+  (in deployed environments you can pick a specific version in the replay dialog), not necessarily
+  the version of the original run.
 </Note>
 
 ### Version locking
@@ -186,10 +187,10 @@ For additional environments beyond `prod` and `staging`, you can use [preview br
 
 ## Local builds
 
-By default we use a remote build provider to speed up builds. However, you can also force the build to happen locally on your machine using the `--force-local-build` flag:
+By default we use a remote build provider to speed up builds. However, you can also force the build to happen locally on your machine using the `--local-build` flag:
 
 ```bash
-npx trigger.dev deploy --force-local-build
+npx trigger.dev deploy --local-build
 ```
 
 <Tip>
@@ -205,7 +206,7 @@ To use local builds, you need the following tools installed on your machine:
 
 ## Environment variables
 
-To add custom environment variables to your deployed tasks, you need to add them to your project in the Trigger.dev dashboard, or automatically sync them using our [syncEnvVars](/config/config-file#syncenvvars) or [syncVercelEnvVars](/config/config-file#syncvercelenvvars) build extensions.
+To add custom environment variables to your deployed tasks, you need to add them to your project in the Trigger.dev dashboard, or automatically sync them using our [syncEnvVars](/config/extensions/syncEnvVars) or [syncVercelEnvVars](/config/extensions/syncEnvVars#syncvercelenvvars) build extensions.
 
 For more information on environment variables, see our [environment variables](/deploy-environment-variables) guide.
 
@@ -235,7 +236,7 @@ You can run the deploy command with `--log-level debug` at the end. This will pr
 
 There should be a link below the error message to the full build logs on your machine. Take a look at these to see what went wrong. Join [our Discord](https://trigger.dev/discord) and you share it privately with us if you can't figure out what's going wrong. Do NOT share these publicly as the verbose logs might reveal private information about your project.
 
-Sometimes these errors are caused by upstream availability issues with our remote build provider. In this case, you can try deploying with a local build using the `--force-local-build` flag. Refer to the [Local builds](#local-builds) section for more information.
+Sometimes these errors are caused by upstream availability issues with our remote build provider. In this case, you can try deploying with a local build using the `--local-build` flag. Refer to the [Local builds](#local-builds) section for more information.
 
 #### `Deployment encountered an error`
 

package/docs/deployment/preview-branches.mdx

@@ -18,10 +18,13 @@ The process to use preview branches looks like this:
 3. Create a named **Trigger only** API key in the Preview environment, then trigger runs using the key (`TRIGGER_SECRET_KEY`) and branch name (`TRIGGER_PREVIEW_BRANCH`).
 4. Archive the preview branch when the branch is done.
 
-There are two main ways to do this:
+There are three main ways to do this:
 
-1. Automatically: using GitHub Actions (recommended).
-2. Manually: in the dashboard and/or using the CLI.
+1. Automatically: using the [GitHub integration](/github-integration), which deploys pull requests to preview branches and archives them when the PR is merged or closed, without a GitHub Action.
+2. Automatically: using GitHub Actions, if you deploy from your own CI workflows.
+3. Manually: in the dashboard and/or using the CLI.
+
+Pick one of the automatic options, not both.
 
 ### Limits on active preview branches
 

package/docs/errors-retrying.mdx

@@ -15,8 +15,8 @@ You can configure retrying in two ways:
 <Note>Task-level retry settings override the defaults in your `trigger.config` file.</Note>
 
 <Note>
-  By default when you create your project using the CLI init command we disabled retrying in the DEV
-  environment. You can enable it in your [trigger.config file](/config/config-file).
+  By default when you create your project using the CLI init command, retrying is enabled in the DEV
+  environment. You can disable it by setting `enabledInDev: false` in your [trigger.config file](/config/config-file).
 </Note>
 
 ## A simple example with OpenAI
@@ -112,7 +112,7 @@ import { task, logger, retry } from "@trigger.dev/sdk";
 
 export const taskWithFetchRetries = task({
   id: "task-with-fetch-retries",
-  run: async ({ payload, ctx }) => {
+  run: async (payload: any, { ctx }) => {
     //if the Response is a 429 (too many requests), it will retry using the data from the response. A lot of good APIs send these headers.
     const headersResponse = await retry.fetch("http://my.host/test-headers", {
       retry: {
@@ -182,7 +182,7 @@ export const taskWithFetchRetries = task({
 
 ## Advanced error handling and retrying
 
-We provide a `catchError` callback on the task and in your `trigger.config` file. This gets called when an uncaught error is thrown in your task.
+We provide a `catchError` callback on the task, and you can register one globally with `tasks.catchError()`. This gets called when an uncaught error is thrown in your task.
 
 You can
 

package/docs/how-it-works.mdx

@@ -6,7 +6,7 @@ description: "Understand how Trigger.dev works and how it can help you."
 
 ## Introduction
 
-Trigger.dev v3 allows you to integrate long-running async tasks into your application and run them in the background. This allows you to offload tasks that take a long time to complete, such as sending multi-day email campaigns, processing videos, or running long chains of AI tasks.
+Trigger.dev allows you to integrate long-running async tasks into your application and run them in the background. This allows you to offload tasks that take a long time to complete, such as sending multi-day email campaigns, processing videos, or running long chains of AI tasks.
 
 For example, the below task processes a video with `ffmpeg` and sends the results to an s3 bucket, then updates a database with the results and sends an email to the user.
 
@@ -278,8 +278,8 @@ export const convertVideo = task({
     // Update database
     await updateVideoUrl(videoId, s3Url);
 
-    // Send email, we don't need to wait for this to finish
-    await sendUserEmail.trigger({ videoId, s3Url }, { idempotencyKey });
+    // Send email
+    await sendUserEmail.triggerAndWait({ videoId, s3Url }, { idempotencyKey }).unwrap();
 
     return { success: true, s3Url };
   },
@@ -420,7 +420,7 @@ When you run `npx trigger.dev@latest dev`, we run your task code locally on your
 - Changes are automatically detected and a new version is spun up when you save your code.
 - Add debuggers and breakpoints to your code and debug it locally.
 - Each task is run in a separate process, so you can run multiple tasks in parallel.
-- Auto-cancels tasks when you stop the dev server.
+- Stopping the dev server stops your local task processes. If the CLI is killed abruptly (for example by a package manager sending SIGKILL), in-flight runs are cancelled automatically. After a normal Ctrl-C stop, in-flight runs are not cancelled and can end with a `TASK_RUN_STALLED_EXECUTING` error once the 5 minute heartbeat timeout passes.
 
 <Note>
   Trigger.dev currently does not support "offline" dev mode, where you can run tasks without an
@@ -430,7 +430,7 @@ When you run `npx trigger.dev@latest dev`, we run your task code locally on your
 
 ## Staging and production environments
 
-Trigger.dev supports deploying to `prod` and `staging` environments. This allows you to test your tasks in a staging environment before deploying them to production. You can deploy to a different environment by running `npx trigger.dev@latest deploy --env <env>`, where `<env>` is either `prod` or `staging`. Each environment has its own API Key, which you can use to trigger tasks in that environment.
+Trigger.dev supports deploying to `prod` and `staging` environments. This allows you to test your tasks in a staging environment before deploying them to production. You can deploy to a different environment by running `npx trigger.dev@latest deploy --env <env>`, where `<env>` is `prod`, `staging` or `preview` (the branch is detected from git, or you can pass `--branch`). Each environment has its own API Key, which you can use to trigger tasks in that environment.
 
 For additional isolated environments, you can use [preview branches](/deployment/preview-branches), which allow you to create separate environments for each branch of your code.
 

package/docs/introduction.mdx

@@ -5,6 +5,8 @@ description: "Build and run durable AI agents and workflows in TypeScript. Long-
 mode: "center"
 ---
 
+import AgentSetupPrompt from "/snippets/agent-setup-prompt.mdx";
+
 <CardGroup cols={2}>
   <Card title="Quick start" icon="rocket" href="/quick-start" color="#A8FF53">
     Go from zero to your first task in 3 minutes.
@@ -20,6 +22,10 @@ mode: "center"
   </Card>
 </CardGroup>
 
+## Set up with AI
+
+<AgentSetupPrompt />
+
 ## What is Trigger.dev?
 
 Trigger.dev is the open source platform for building and running durable AI agents and workflows in TypeScript. Run them for hours, configure automatic retries, control concurrency, and manage queues. There's no execution timeout, and no queue or worker infrastructure for you to build.

package/docs/limits.mdx

@@ -43,7 +43,7 @@ You can request a higher rate limit from us if you're on a paid plan.
 The maximum number of runs that can be queued **per queue** (not across all queues in the environment). Each queue can hold up to its limit independently. When a queue hits its limit, new triggers to that queue are rejected.
 
 <Note>
-  The limits below apply to [Trigger.dev Cloud](https://trigger.dev). If you self-host Trigger.dev, queue size limits are configurable via the `MAXIMUM_DEV_QUEUE_SIZE` and `MAXIMUM_DEPLOYED_QUEUE_SIZE` environment variables — see [Self-hosting environment variables](/self-hosting/env/webapp#run-engine).
+  The limits below apply to [Trigger.dev Cloud](https://trigger.dev). If you self-host Trigger.dev, queue size limits are configurable via the `MAXIMUM_DEV_QUEUE_SIZE` and `MAXIMUM_DEPLOYED_QUEUE_SIZE` environment variables — see [Self-hosting environment variables](/self-hosting/env/webapp).
 </Note>
 
 | Pricing tier | Development (per queue) | Staging / Production (per queue) |
@@ -60,7 +60,7 @@ On Trigger.dev Cloud, all runs have an enforced maximum TTL of 14 days. Runs wit
 
 There is no maximum on `delay`.
 
-If you self-host, you can configure a maximum TTL via the `RUN_ENGINE_DEFAULT_MAX_TTL` environment variable — see [Self-hosting environment variables](/self-hosting/env/webapp#run-engine).
+If you self-host, you can configure a maximum TTL via the `RUN_ENGINE_DEFAULT_MAX_TTL` environment variable — see [Self-hosting environment variables](/self-hosting/env/webapp).
 
 ## Schedules
 
@@ -124,8 +124,6 @@ Payloads and outputs over 512KB are kept in object storage rather than inline. C
 
 A single batch can have a maximum of 1,000 items with SDK 4.3.1+. Prior versions are limited to 500 items.
 
-<SoftLimit />
-
 ## Batch trigger rate limits
 
 Batch triggering uses a token bucket algorithm to rate limit the number of runs you can trigger per environment. Each run in a batch consumes one token.
@@ -154,6 +152,26 @@ When you send a batch trigger, we convert it into individual runs. This limit co
 | Hobby        | 10 concurrent batches |
 | Pro          | 50 concurrent batches |
 
+## Webhook ingest rate limits
+
+Each hosted webhook endpoint accepts a limited number of requests per 10 seconds. Requests over the limit get a `429` response with a `Retry-After` header, and providers that retry deliver them again after the window.
+
+| Pricing tier | Requests per endpoint |
+| :----------- | :-------------------- |
+| Free         | 100 every 10 sec      |
+| Hobby        | 300 every 10 sec      |
+| Pro          | 1,000 every 10 sec    |
+| Enterprise   | Set per organization  |
+
+All of an environment's endpoints also share a per-environment limit, counted in tokens: a request costs one token for every 64 KiB of body, started, so a 10 KiB event costs one and a 1 MiB event costs 16. Requests over it get the same `429` with `Retry-After`.
+
+| Pricing tier | Tokens per environment |
+| :----------- | :--------------------- |
+| Free         | 300 every 10 sec       |
+| Hobby        | 1,000 every 10 sec     |
+| Pro          | 3,000 every 10 sec     |
+| Enterprise   | Set per organization   |
+
 ## Log retention
 
 | Pricing tier | Limit   |
@@ -170,8 +188,8 @@ We limit the size of logs to prevent oversized data potentially causing issues.
 
 #### Attribute Limits
 
-- Span Attribute Count Limit: 256
-- Log Attribute Count Limit: 256
+- Span Attribute Count Limit: 1024
+- Log Attribute Count Limit: 1024
 - Span Attribute Value Length Limit: 131072 characters
 - Log Attribute Value Length Limit: 131072 characters
 
@@ -188,8 +206,8 @@ We limit the size of logs to prevent oversized data potentially causing issues.
 
 #### Attribute Clipping Behavior
 
-- Attributes exceeding the value length limit (1028 characters) are discarded.
-- If the total number of attributes exceeds 256, additional attributes are not included.
+- Attributes exceeding the value length limit (131072 characters) are discarded.
+- If the total number of attributes exceeds 1024, additional attributes are not included.
 
 #### Attribute Value Size Calculation
 

package/docs/logging.mdx

@@ -159,7 +159,7 @@ Trigger.dev automatically collects the following metrics for deployed tasks. No
 | `nodejs.heap.total` | gauge | bytes | V8 heap total |
 
 <Note>
-In dev mode (`trigger dev`), only `process.*` and custom metrics are available.
+In dev mode (`trigger dev`), the `process.*` and `nodejs.*` metrics above are collected, along with custom metrics.
 </Note>
 
 ### Context attributes

package/docs/machines.mdx

@@ -11,7 +11,7 @@ import { task } from "@trigger.dev/sdk";
 export const heavyTask = task({
   id: "heavy-task",
   machine: "large-1x",
-  run: async ({ payload, ctx }) => {
+  run: async (payload, { ctx }) => {
     //...
   },
 });

package/docs/mcp-introduction.mdx

@@ -299,7 +299,7 @@ After adding the config, restart your client. You should see a server named **tr
 
 ## Authentication
 
-The `search_docs` tool works without authentication. All other tools require you to be logged in via the [Trigger.dev CLI](/cli-login-commands). The first time you use an authenticated tool, your MCP client will prompt you to log in.
+The `search_docs` tool works without authentication, and so do the local-only tools `list_profiles`, `dev_server_status` and `stop_dev_server`. All other tools require you to be logged in via the [Trigger.dev CLI](/cli-login-commands). The first time you use an authenticated tool, your MCP client will prompt you to log in.
 
 <Accordion title="CLI Options">
 
@@ -310,7 +310,6 @@ The `install-mcp` command supports these options:
 - `-p, --project-ref <project ref>` — Scope the MCP server to a specific project
 - `-t, --tag <package tag>` — CLI package version to use (default: latest)
 - `--dev-only` — Restrict to the dev environment only
-- `--readonly` — Read-only mode. Hides write tools (`deploy`, `trigger_task`, `cancel_run`) so the AI cannot make changes to your account
 - `--yolo` — Install into all supported clients automatically
 - `--scope <scope>` — `user`, `project`, or `local`
 - `--client <clients...>` — Install into specific client(s)
@@ -341,17 +340,19 @@ Restrict to dev environment for a specific project:
 npx trigger.dev@latest install-mcp --dev-only --project-ref proj_abc123
 ```
 
-Read-only mode (prevents AI from deploying or triggering tasks):
+To add these options to a manual config, append them to the `args` array:
 
-```bash
-npx trigger.dev@latest install-mcp --readonly
+```json
+{
+  "args": ["trigger.dev@latest", "mcp", "--dev-only", "--project-ref", "proj_abc123"]
+}
 ```
 
-To add these options to a manual config, append them to the `args` array:
+The `mcp` command also accepts `--readonly`, which hides the tools that write to your account (for example `deploy`, `trigger_task` and `cancel_run`) so the AI cannot make changes to it. It is only available as a manual config arg:
 
 ```json
 {
-  "args": ["trigger.dev@latest", "mcp", "--dev-only", "--project-ref", "proj_abc123"]
+  "args": ["trigger.dev@latest", "mcp", "--readonly"]
 }
 ```
 

package/docs/mcp-tools.mdx

@@ -102,6 +102,20 @@ Cancel a running or queued run.
 - `"Cancel run run_abc123"`
 - `"Stop that task"`
 
+### replay_run
+
+Replay a run as a new run of the same task, in the same environment. The new run reuses the original run's payload, metadata, tags, queue, concurrency key, and machine unless you override them. See [Replaying](/replaying) for how each option falls back.
+
+**Parameters:**
+- `runId` (required): The run to replay, starting with `run_`
+- `payload`, `metadata`, `tags` (optional): Replace the original run's values
+- `queue`, `concurrencyKey`, `machine`, `version`, `region`, `delay`, `ttl`, `idempotencyKey`, `maxAttempts`, `maxDuration`, `priority` (optional): Override the trigger options for the new run
+
+**Example usage:**
+- `"Replay run run_abc123"`
+- `"Replay that failed run with userId set to user_456"`
+- `"Replay run run_abc123 on a large-1x machine in 10 minutes"`
+
 ## Deployment Tools
 
 ### deploy
@@ -225,7 +239,7 @@ Check the status of the dev server and view recent output. Shows whether it is s
 - `"Are there any build errors?"`
 
 <Callout type="warning">
-  The deploy and list_preview_branches tools are not available when the MCP server is running with the `--dev-only` flag. The `--readonly` flag hides deploy, trigger_task, and cancel_run.
+  The deploy and list_preview_branches tools are not available when the MCP server is running with the `--dev-only` flag. The `--readonly` flag hides deploy, trigger_task, cancel_run, and replay_run.
 </Callout>
 
 ## Agent Chat Tools

package/docs/migrating-from-v3.mdx

@@ -248,7 +248,7 @@ import { task } from "@trigger.dev/sdk";
 
 export const myTask = task({
   id: "my-task",
-  onStart: ({ payload, ctx }) => {},
+  onStart: (payload, { ctx }) => {},
   run: async (payload, { ctx }) => {},
 });
 ```

package/docs/observability/dashboards.mdx

@@ -98,5 +98,7 @@ There is a separate concurrency limits for metric widgets.
 | Limit                     | Details        |
 | :------------------------ | :------------- |
 | Concurrent widget queries | 30 per project |
+| Custom dashboards         | Free 0, Hobby 1, Pro 5 per organization |
+| Widgets per dashboard     | Free 0, Hobby 10, Pro 20 |
 
 See [Limits](/limits) for details.

package/docs/observability/query.mdx

@@ -8,6 +8,7 @@ description: "Query allows you to write custom queries against your data using T
 - `runs`: contains all task run data including status, timing, costs, and task output. Run metadata (key-value set in your task) is not available on the Query page.
 - `metrics`: contains metrics data for your runs including CPU, memory, and your custom metrics
 - `llm_metrics`: contains LLM/AI metrics including token usage, costs, latency, and model performance data from GenAI spans
+- `llm_models`: anonymized cross-tenant model performance aggregates (calls, cost, latency, throughput per model per minute); it has no tenant-specific data
 
 ### `metrics` table columns
 
@@ -24,6 +25,9 @@ description: "Query allows you to write custom queries against your data using T
 | `machine_name` | string | Machine preset (e.g., `small-1x`) |
 | `worker_version` | string | Worker version |
 | `environment_type` | string | `PRODUCTION`, `STAGING`, `DEVELOPMENT`, `PREVIEW` |
+| `worker_id` | string | Worker ID that produced the metric |
+| `environment` | string | Environment slug |
+| `project` | string | Project ref, starting with `proj_` |
 | `attributes` | json | Raw JSON attributes for custom data |
 
 See [Logging, tracing & metrics](/logging#automatic-system-and-runtime-metrics) for the full list of automatically collected metrics and how to create custom metrics. You can visualize this data on [Dashboards](/observability/dashboards).
@@ -68,7 +72,7 @@ ORDER BY timeBucket
 LIMIT 1000
 ```
 
-Available format types: `bytes`, `percent`, `duration`, `durationSeconds`, `quantity`, `costInDollars`.
+Available format types: `bytes`, `percent`, `duration`, `durationSeconds`, `quantity`, `costInDollars`, `decimalBytes`, `cost`.
 
 ## Using the Query dashboard
 
@@ -602,7 +606,7 @@ LIMIT 100
 
 We have several limits to prevent abuse and ensure performance:
 
-- **Concurrency limit**: We limit the number of concurrent queries per organization.
+- **Concurrency limit**: We limit the number of concurrent queries per project.
 - **Row limit**: We limit the number of rows returned to 10k.
 - **Time restrictions**: We limit the time period you can query.
 - **Time/Memory limit**: We limit the memory a query can use and the time it can run for. As well as other limits like AST complexity.

package/docs/private-networking/aws-console-setup.mdx

@@ -250,7 +250,7 @@ By default, no one can connect to your endpoint service. You need to explicitly
 
     - **Friendly name**: a short, human-readable label for this connection.
     - **VPC Endpoint Service name**: paste the `com.amazonaws.vpce.<region>.vpce-svc-...` value from Step 4.
-    - **Target region**: the AWS region your endpoint service lives in.
+    - **Target region**: the Trigger.dev region where the VPC Endpoint is created (pick one from the list, such as `us-east-1` or `eu-central-1`), normally the region your tasks run in. If it differs from the region your endpoint service lives in, enable cross-region access in Step 3.
 
   </Step>
   <Step title="Submit">

package/docs/private-networking/overview.mdx

@@ -119,7 +119,7 @@ All three conditions must be true. No organization can route traffic to another
 
 ## Limits
 
-- **Two connections per organization.** This is a soft limit — get in touch if you need more.
+- **Four connections per organization.** This is a soft limit — get in touch if you need more.
 - **All ports accepted.** Our security group allows all TCP ports from peered CIDRs. You control which ports are reachable through your NLB and target groups.
 - **Same-region or cross-region.** Connections work within the same region as your tasks or across regions (cross-region adds AWS-level cost and ~10-30ms latency).
 

package/docs/quick-start.mdx

@@ -8,48 +8,11 @@ import CliInitStep from "/snippets/step-cli-init.mdx";
 import CliDevStep from "/snippets/step-cli-dev.mdx";
 import CliRunTestStep from "/snippets/step-run-test.mdx";
 import CliViewRunStep from "/snippets/step-view-run.mdx";
+import AgentSetupPrompt from "/snippets/agent-setup-prompt.mdx";
 
-## Set up with AI
+## Copy the setup prompt
 
-Using an AI coding assistant? Copy this prompt and paste it into Claude Code, Cursor, Copilot, Windsurf, or any AI tool. It'll handle the setup for you.
-
-<Accordion title="Copy the setup prompt">
-
-```text
-Help me add Trigger.dev to this project.
-
-## What to do
-
-1. I need a Trigger.dev account. If I don't have one, point me to https://cloud.trigger.dev to sign up. Wait for me to confirm.
-2. Run `npx trigger.dev@latest init` in the project root.
-   - When it asks about the MCP server, recommend I install it (best DX: gives you direct access to Trigger.dev docs, deploys, and run monitoring).
-   - Install the "Hello World" example task when prompted.
-3. Run `npx trigger.dev@latest dev` to start the dev server.
-4. Once the dev server is running, test the example task from the Trigger.dev dashboard.
-5. Create a named API key in my Development environment with **Trigger only** access. Set it as TRIGGER_SECRET_KEY in my .env file (or .env.local for Next.js).
-6. Ask me what framework I'm using and show me how to trigger the task from my backend code.
-
-If I've already run init and want the MCP server, run: npx trigger.dev@latest install-mcp
-
-## Critical rules
-
-- ALWAYS import from `@trigger.dev/sdk`. NEVER import from `@trigger.dev/sdk/v3`.
-- NEVER use `client.defineJob()` — that's the deprecated v2 API.
-- Use type-only imports when triggering from backend code to avoid bundling task code:
-
-  import type { myTask } from "./trigger/example";
-  import { tasks } from "@trigger.dev/sdk";
-
-  const handle = await tasks.trigger<typeof myTask>("hello-world", { message: "Hello from my app!" });
-
-## When done, point me to
-
-- Writing tasks: https://trigger.dev/docs/tasks/overview
-- Real-time updates: https://trigger.dev/docs/realtime/overview
-- AI tooling: https://trigger.dev/docs/building-with-ai
-```
-
-</Accordion>
+<AgentSetupPrompt />
 
 ## Manual setup
 

package/docs/realtime/auth.mdx

@@ -157,7 +157,7 @@ const { parts } = useRealtimeStream<{ url: string }>(runId, "frames", {
 
 When you [trigger tasks](/triggering) from your backend, the `handle` received includes a `publicAccessToken` field. This token can be used to authenticate real-time requests in your frontend application.
 
-By default, auto-generated tokens expire after 15 minutes and have a read scope for the specific run(s) that were triggered. You can customize the expiration by passing a `publicTokenOptions` object to the trigger function.
+Auto-generated tokens expire after 1 hour and have a read scope for the specific run(s) that were triggered. For a different expiration or scopes, create a token yourself with [`auth.createPublicToken`](#creating-public-access-tokens).
 
 See our [triggering documentation](/triggering) for detailed examples of how to trigger tasks and get auto-generated tokens.