Trigger.dev

Next week we're launching our all time most requested feature 👀

Here are 7 things we learned from building our first production chat agent: 1. Make the first reply fast by making the first model call in the request & simultaneously spinning up your actual agent 2. Count your context tokens correctly to avoid compacting prematurely (bad!). The tl;dr is to use the last step's input token count. 3. Cap retries to handle cases where a tool is broken 4. Make sure the conversation is resumable with durable streams (at Trigger, we use s2 dot dev under the hood. Or you can just use Trigger for the whole chat agent!) 5. Version your prompts (so much easier to iterate) 6. Consider giving your agents some of these tools: - a tool to render components e.g. charts - a tool to give feedback - a tool to know the users' page context 7. Do runtime evals! Full article in comments

Introducing Ask Trigger (in beta): Debug, investigate and generate reports on your runs by chatting with Ask Trigger right from your Trigger dashboard. https://tgr.dev/DaPBEKj

We (finally) upgraded to Zod 4.5 (from 3.x!) and our worker CPU demand plummeted, our batch throughput increased by 14% and our task trigger p99 dropped by 18%. Aaaand in unrelated news... We're now the platinum sponsor for Zod! Zod is one of those bits that we use and love and rely on every day and that's why we wanted to support the work Colin is doing. Link to the full write up in the comments

This summer we upgraded our 56TB Postgres database with (almost) no downtime. And we moved all new runs to PlanetScale Metal. This post covers everything we did and everything we learned along the way. https://tgr.dev/sdSp0oA

Your coding agent can now set up Trigger.dev end to end, and verify the result itself. New projects open with a "Copy AI agent prompt" button. Paste that prompt into Claude Code, Cursor, or any coding agent and it gets the project context and conventions it needs to go from an empty codebase to a registered, working task. With the Trigger.dev MCP server connected, the agent calls initialize_project, detects an existing trigger.config.ts, creates a project only when one's needed, and gets back the correct steps for your dev environment. From there the whole feedback loop stays in one conversation: it starts the dev server in the background and reads the logs, inspects your tasks and their payload schemas, fires a test run, then reads the trace span by span. AI spans include model, token, cost, and response data. The result is a task you can watch working in the dashboard, not just a handful of generated files. No MCP server? The prompt carries a complete CLI path: npx trigger.dev@latest init, install the SDK, scaffold a task, start the dev server, confirm it registers. It also ships the rules that keep generated code correct, like exporting every task and never wrapping wait.* or triggerAndWait in Promise.all. Browser login and your secret key still need a human, so the agent stops at those points and asks. The MCP server stays useful after setup: filter runs, explain a failure from its trace, deploy, or query runs and LLM usage with TRQL, all from your editor. When you want tighter guardrails, --dev-only blocks access outside development and --readonly hides the write tools. Open a project's dev environment, hit "Copy AI agent prompt", and let your agent do the setup: https://lnkd.in/e3izc5w7

Column control came to the Trigger.dev runs list. Show, hide, and reorder the columns on any runs list. The part worth the wait is smart columns: pick a value buried in a run and pull it out into its own column. Point a smart column at a run's payload, metadata, or output with a JSON path. $.order.total renders as a number, $.customerId as text, $.status as a badge. It fills in down the whole list, and the live poll keeps the values current as new runs come in. They're display-only by design. A smart column never adds a sort or filter, so nothing touches the ClickHouse sort key or the keyset cursor that keep the runs list fast at scale. You get the value on screen without paying for it in query time. And your whole column layout lives in the URL. A view is just a link: set the columns up for one investigation, bookmark it, and drop it in a thread for a teammate who opens the exact same table. It's live now: https://lnkd.in/ecWrge3P

One secret key per environment always felt too blunt. If a CI job and a background service and a third-party integration all authenticate with the same credential, rotating that key means breaking everything at once. Trigger.dev now supports multiple API keys per environment. Each service, CI job, and integration carries its own credential, and each key is scoped to exactly what it needs. You pick an access preset when you create a key: Trigger only, Task operator, Observer, Operator, Deploy only, Variables only, or no restrictions. Trigger-only and Task-operator keys can be narrowed further to a specific set of tasks (up to 10 identifiers per key), so a key can trigger the two tasks a service owns and nothing else. Keys are independent, which is the part that actually matters. Give a key an expiration date and it stops working automatically once that date passes. Revoke a key and it stops authenticating immediately, with every other key in the environment untouched. No environment-wide rotation. Security stays tight throughout: the full value is shown only once at creation, then hashed at rest, and the dashboard displays only an obfuscated suffix. `trigger deploy` can authenticate with a Deploy-only key, so a deploy credential never carries more access than it needs. Read the changelog: https://lnkd.in/eYyDSyQp

Bulk cancel and replay work from the Trigger.dev SDK, not just the dashboard. Ship a fix, then replay the runs that failed without paging through run IDs or scripting the retries by hand. runs.bulk.replay() and runs.bulk.cancel() take the same filter shape as runs.list() (status, task, tags, queue, version, region) and act on every matching run, from a handful to millions. Kick it off, then runs.bulk.poll() waits for it to finish and returns live counts. runs.bulk.abort() stops one mid-flight. It runs asynchronously, so you can wire it into a deploy script, a scheduled task, or an incident runbook. Changelog: https://lnkd.in/eyaVv22w