AI Agent Frameworks Release Notes

Latest AI Agent Frameworks Updates

• August 2026

  • No date parsed from source.
  • First seen by Releasebot:
    Aug 29, 2026
  

  Agentforce by Salesforce

  Agentforce and Generative AI Release Notes

  Agentforce adds broader voice and agent management updates, including Gemini model rerouting prep, simpler agent metadata moves between orgs, default platform enablement, full post-call transcripts, stricter phone number limits, flexible call recording control, and custom SIP header support.

  Bring the power of assistive and autonomous AI to your business with Agentforce.

  Gemini 2.5 Pro, Flash, and Flash-Lite Reroute Date Approaching

  Gemini 2.5 Pro, Flash, and Flash-Lite model requests will be rerouted to Gemini 3.5 Pro, Flash, and Flash-Lite on October 20, 2026. We recommend that you test your prompts and applications with the new model in Prompt Builder and Einstein Studio as soon as possible, because expected responses can change.

  Move Agents Between Orgs More Easily with Simplified Agent Metadata Types

  Starting in API version 68.0, we’ve streamlined Agentforce agent metadata types to make it easier to retrieve and deploy agents. Previously, moving an agent from sandbox to production required at least three metadata types. Plus, you had to manually add every Apex class, flow, and prompt template associated with an agent action, making sure to indicate the correct agent version. With the new AiAgentDefinition and AiAgentDefinitionVersion types, Salesforce CLI now retrieves the agent and all its dependencies automatically.

  Agentforce Platform Enabled by Default

  In Winter ’27, the Agentforce platform is enabled by default for all orgs with Agentforce access, as granted by SKUs, licensing, and editions. New orgs are enabled at creation, and existing orgs will be auto-enabled. The Agentforce setting will be removed from the Agentforce Agents page in Setup, so you can build, test, and deploy agents with one less step. The platform is enabled at no additional cost and there are no changes to billing.

  Show Full Conversation History in Post-Call Transcripts for Agentforce Voice Calls

  The Enhance Conversation component in the Service Console now displays consistent transcripts during and after a voice call handled by a voice-enabled agent. When the agent transfers the call to a service rep, the voice call record for the rep-customer conversation (VC1) now shows both the agent-customer and rep-customer transcripts after the call, matching what was visible during the call. Previously, VC1 showed both transcripts during the call but dropped the agent-customer transcript after the call ended.

  Agentforce Voice Now Enforces the Limit on Procured Phone Numbers

  Agentforce Voice now enforces the Salesforce Voice (Native Telephony) limit on the number of phone numbers that you can procure. In production orgs, your Agentforce Voice license determines the limit. In sandbox and trial orgs, the limit is 10 phone numbers regardless of your license. Previously, these limits weren't enforced.

  Enable Flexible Call Recording Control Within Conversations via Toolkit API

  Salesforce developers and admins can now use the Salesforce Voice Toolkit API to pause and resume call recordings without the Control Call Recording user permission. Previously, these users needed this permission. This permission is still required to use the pause and resume controls in the Salesforce UI.

  Pass Context with Custom SIP Headers and Disconnect with REFER in Agentforce Voice

  Capture custom SIP X-headers from inbound calls to deliver contextual information, such as customer intent, language preference, or case history. Configure your escalation and fallback flows to return or modify headers using the SIP REFER method when disconnecting or transferring calls.

  Original source

  Show more
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  Trigger.dev v4.5.14

  Trigger.dev adds realtime stream upgrades, including from: latest starts, cursor resumption, a new useSessionStream hook, and token refresh for long-running subscriptions. It also improves native build server logs and fixes queue retries in the server.

  Highlights

  Realtime stream improvements: from: "latest", cursor resumption, and useSessionStream

  Realtime stream improvements: from: "latest", cursor resumption, and useSessionStream get three new capabilities in this release.

  Start at the current tail. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to skip history and only receive live updates from the point you connect. Pair it with maxParts to keep the accumulated parts array bounded, which is useful for "last value" views like a live progress indicator.

  Resume from a saved cursor. useRealtimeStream now accepts a lastEventId option and returns lastEventId in its result, so you can persist the position across page reloads and resume exactly where you left off. An onParts callback delivers each throttled batch alongside their event IDs. A reconnect or remount resumes from the last record seen, so no records are missed or replayed.

  New useSessionStream hook. Read a chat agent Session's realtime channel from React without hand-rolling the API client, record accumulation, unmount cleanup, throttling, or cursor tracking. Because a Session is durable and can span multiple runs, the channel it reads outlives any single run and supports multiple concurrent subscribers, which makes it the natural way to render a chat.agent session's output as it streams.

  Pass io: "out" (the default) to read the agent's output channel, or io: "in" to read its input. It takes the same subscription controls as the run-stream hooks, from: "latest", maxRecords, and lastEventId, plus an onRecords callback that delivers each throttled batch of records with their event ids and an onControl callback for control records like turn-complete (control records never enter the records array). It returns { records, lastEventId, lastControl, error, stop }.

  Where useRealtimeStream reads a single run's stream, useSessionStream reads a Session's channel, so it keeps streaming across the runs that make up a conversation. It reads only, and requires a Public Access Token scoped read:sessions:{id}. (#4811)

  Token refresh. A Public Access Token is short-lived (15 minutes by default), so a realtime subscription that watches a long-running run or a session stream can outlive its token. Until now that surfaced as an auth error with no recovery short of tearing the subscription down and creating a new one. The new refreshAccessToken option lets a subscription mint a fresh token and reconnect on its own.

  It's an async callback that resolves to a fresh token, typically fetched from your backend where your secret key lives:

  Set it on any realtime subscription (run streams, realtime runs, and session streams), or once on TriggerAuthContext.Provider so every hook underneath shares one refresher:

  The refresh is reactive: when a connection is rejected with an auth error, the subscription calls refreshAccessToken once, retries with the new token, and resumes from its last-seen record, so there is no gap and no replay. It is bounded to one refresh per connection so a rejected token can't drive a retry loop, and hooks that share a refresher dedupe a single in-flight mint. It is fully opt-in: with no refreshAccessToken supplied, auth errors stay terminal exactly as before. (#4811)

  Improvements

  • Native build server deploys now show a single updating log line by default. Pass --build-logs full to stream every line, which is always the behavior in CI and when output is not a terminal. (#4817)

  Server changes

  These changes are included in the v4.5.14 Docker image and are already live on Trigger.dev Cloud:

  • Task retries that wait in the queue no longer count against the queue's internal redelivery limit, fixing runs with many long-delay retries being wrongly failed with TASK_RUN_DEQUEUED_MAX_RETRIES. (#4810)

  How to upgrade

  Update the trigger.dev/* packages to v4.5.14 using your package manager:

  npx trigger.dev@latest update # npm
  pnpm dlx trigger.dev@latest update # pnpm
  yarn dlx trigger.dev@latest update # yarn
  bunx trigger.dev@latest update # bun
  

  Self-hosted users: update your Docker image to ghcr.io/triggerdotdev/trigger.dev:v4.5.14.

  Original source

  Show more
• All of your release notes in one feed

  Join Releasebot and get updates from Salesforce and hundreds of other software products.

  Create account

  Get updates with: RSS Email CLI MCP API Slack n8n
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  Trigger.dev v4.5.13

  Trigger.dev releases stronger chat agent reliability and new custom agent building blocks, including pending message handling, handoff to fresh runs, and client data validation. It also adds deployment and dashboard improvements, plus performance boosts and bug fixes across chat, logs, and runs lists.

  6 improvements, 4 bug fixes, and 10 server changes

  Highlights

  More reliable chat agents

  This release hardens chat agent message delivery from end to end. A message that arrives while an agent is mid-turn is no longer dropped, a recovered answer after a crash is no longer cut off, and a message left outstanding when a run is killed is now re-answered on the next run. Together these close the cases where a chat could silently lose a message or leave a turn stuck.

  Custom agents also get new building blocks. chat.messages.hasPending() and chat.messages.next() let a hand-rolled loop inspect pending input without consuming it and take one record at a time:

  if (await chat.messages.hasPending()) {
    const record = await chat.messages.next({ timeoutInSeconds: 0 });
    if (record) handle(record.payload);
  }
  

  chat.endAndContinue() hands a conversation off to a fresh run on the latest deployed task version while preserving unconsumed session input, and chat.withClientData({ schema }) now validates and parses client data before it reaches agent code.

  Improvements

  • A message that arrives mid-turn and isn't injected into the current turn is now answered as the next turn instead of being dropped. Previously, configuring pendingMessages without a shouldInject declined every batch, so every mid-turn message was silently lost. A declined message keeps its place in the queue and survives a crash; an injected one is consumed at injection and never also answered as a later turn. (#4795)
  • Browser chats now keep the active turn open across page reloads when older completion records are replayed. (#4643)
  • Added chat.endAndContinue() so fully hand-rolled custom chat agents can hand a conversation off to a fresh run on the latest deployed task version while preserving unconsumed session input. (#4647)
  • Custom chat agents now validate and parse client data declared with chat.withClientData({ schema }) before passing it to agent code. (#4646)
  • Added an experimental --local-bundle deploy flag that runs the install and bundling steps on your machine and uploads only the build output; the image is still built remotely. Useful when your project's install step needs tooling or credentials that only exist locally. (#4331)
  • trigger.dev deploy now asks the server whether to build with Depot or the native build server, unless --native-build, --depot-build, or --local-build is explicitly passed. --local-bundle and --detach now require --native-build. (#4803)

  Bug fixes

  • Fixed several chat message reliability issues: a message arriving mid-turn could be silently lost if the run crashed; a recovered answer after a crash could be cut off because the stop that arrived during the turn was replayed into the recovery run; a retried send could be answered twice when its idempotency claim was lost. Custom agent loops can now inspect pending input without consuming it using chat.messages.hasPending() and consume one record at a time with chat.messages.next(). (#4644)
  • Fixed a chat agent hanging after an interrupted turn: when a run was killed mid-answer and only the one message it was answering was still outstanding, the new run never replied to it. (#4768)
  • Fixed chat transport discarding the next turn after stopping generation. skipToTurnComplete is now reset when a new message or action is sent, so a message sent after stopGeneration streams normally instead of leaving the chat stuck in a streaming state. (#4744)
  • Fixed a message sent while the agent was mid-answer being lost if the run then crashed. The cursor written at the end of each turn now holds back behind any message still waiting to be handled. The in-memory buffer for pending mid-turn messages has been removed from both chat.agent and chat.createSession() so waiting messages are durable. (#4795)

  Server changes

  These changes are included in the v4.5.13 Docker image and are already live on Trigger.dev Cloud:

  • Self-hosted instances can now disable the admin dashboard and user impersonation entirely via a new setting. (#4774)
  • The dashboard has two new themes, Black and White, plus appearance options for stronger colors and underlined links. (#4547)
  • Deployment logs no longer jump to the bottom while you are reading earlier output. Scroll up to pause auto-scroll; scroll back down or use the new scroll-to-bottom button in the log header to resume. (#4776)
  • Customize the runs list: show, hide, and reorder columns, and add smart columns that pull a value out of a run's payload, metadata, or output. Column choices are saved in the page URL so you can share or bookmark a view. (#4652)
  • The browser no longer offers to autofill or save environment variable values as saved credentials. (#4777)
  • Cut webapp CPU usage by about a quarter on the routes workers call most. Detailed event-loop blocking traces are no longer recorded by default, as producing them was a significant part of that cost. (#4746)
  • Runs list and runs.list API requests that span too much data now return a clear error asking you to narrow the time range, instead of failing with a generic error. (#4773)
  • Improved performance and reliability of the runs list and runs.list API, especially for large projects and filtered views. (#4763)
  • New Vercel connections now get version skew protection turned on automatically, so each run uses the task version its deployment shipped with. Automatic atomic deployments are deprecated and no longer offered when connecting a project, but remain available in your Vercel integration settings. (#4741)
  • The Staging branch setting now shows a correct status when it's not available in the current configuration, instead of appearing editable and silently doing nothing on save. (#4784)

  How to upgrade

  Update the trigger.dev/* packages to v4.5.13 using your package manager:

  npx trigger.dev@latest update # npm
  pnpm dlx trigger.dev@latest update # pnpm
  yarn dlx trigger.dev@latest update # yarn
  bunx trigger.dev@latest update # bun
  

  Self-hosted users: update your Docker image to ghcr.io/triggerdotdev/trigger.dev:v4.5.13.

  Original source

  Show more
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  trigger.dev v4.5.14

  Trigger.dev releases v4.5.14 with clearer native build server logs, more resilient realtime streams that can refresh tokens and resume from the latest record, plus a new useSessionStream React hook and a fix for queued retries hitting redelivery limits.

  trigger.dev v4.5.14

  Upgrade

  npx trigger.dev@latest update # npm

  pnpm dlx trigger.dev@latest update # pnpm

  yarn dlx trigger.dev@latest update # yarn

  bunx trigger.dev@latest update # bun

  Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.14

  Release notes

  Read the full release notes: https://trigger.dev/changelog/v4-5-14

  What's changed

  Improvements

  Native build server deploys now show a single updating build log line by default; pass --build-logs full to stream every line (always used in CI and when output is not a terminal). (#4817)

  Realtime stream subscriptions can now refresh an expired access token and reconnect, via a new optional refreshAccessToken option on the client configuration and the React hooks. (#4811)

  Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay. (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  Added a useSessionStream React hook for reading a session's output or input channel in realtime. It accumulates records with automatic resume from the last record you received, and supports from: "latest" (start at the current tail, only new records after you connect), maxRecords (keep a bounded number of records in memory), a lastEventId resume cursor, and an onRecords callback that delivers each throttled batch of records with their event ids. (#4811)

  Server changes

  These changes affect the self-hosted Docker image and Trigger.dev Cloud:

  Task retries that wait in the queue no longer count against the queue's internal redelivery limit, so runs with many long-delay retries are not wrongly failed with TASK_RUN_DEQUEUED_MAX_RETRIES. (#4810)

  All packages: v4.5.14

  @trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev

  Contributors

  Saadi Myftija, James Ritchie, @d-cs, github-actions[bot], Matt Aitken, @nicktrn, Chris Arderne, Eric Allam

  Full changelog: v4.5.13...v4.5.14

  Original source

  Show more
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  trigger.dev v4.5.13

  Trigger.dev ships v4.5.13 with smarter deploys, a new experimental local-bundle flag, and major chat reliability fixes that preserve mid-turn messages across crashes. It also adds dashboard themes, customizable run lists, and performance and self-hosting improvements.

  Upgrade

  npx trigger.dev@latest update # npm
  pnpm dlx trigger.dev@latest update # pnpm
  yarn dlx trigger.dev@latest update # yarn
  bunx trigger.dev@latest update # bun
  

  Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.13

  Release notes

  Read the full release notes: https://trigger.dev/changelog/v4-5-13

  What's changed

  Improvements

  trigger.dev deploy now asks the server whether to build with Depot or the native build server unless --native-build, --depot-build, or --local-build is passed, so the native build server can be rolled out per organization without a CLI change. --local-bundle and --detach now require --native-build. (#4803)

  Add an experimental --local-bundle deploy flag that runs the install and bundling steps on your machine and uploads only the build output; the image is still built remotely. Useful when your project's install step needs tooling or credentials that only exist locally. (#4331)

  Send the CLI version header on all API requests so deployments are attributable to a CLI version (#4778)

  A message that arrives mid-turn and is not injected into that turn is now answered as the next turn, instead of being dropped. This is what the pendingMessages docs have always described, and it applies to the default too: configuring pendingMessages without a shouldInject declines every batch, which previously meant every mid-turn message was lost with no error at either end. (#4795)

  chat.agent({
    id: "my-chat",
    pendingMessages: {
      onReceived: ({ message }) =>
        logger.info("arrived mid-turn", { id: message.id }),
      // Only interrupt once the agent has started calling tools.
      shouldInject: ({ steps }) => steps.length > 0,
    },
    run: async ({ messages, signal }) =>
      streamText({
        model,
        messages,
        abortSignal: signal,
        // Required for injection. Without it nothing injects, and every
        // mid-turn message is answered as the next turn instead.
        ...chat.toStreamTextOptions(),
      }),
  });
  

  A declined message keeps its place in the queue, so it survives a crash and is answered by whichever run picks the conversation up. An injected one is consumed at the moment it is injected, so it is never also answered as a later turn.

  Browser chats now keep the active turn open across page reloads when older completion records are replayed. (#4643)

  Add chat.endAndContinue() so fully hand-rolled custom chat agents can hand a conversation off to a fresh run on the latest deployed task version while preserving unconsumed Session input. (#4647)

  Custom chat agents now validate and parse client data declared with chat.withClientData({ schema }) before passing it to agent code. (#4646)

  Bug fixes

  Fixes a case where a chat could silently lose a message. If a message arrived while the agent was between turns and a stop arrived after it, the cursor the next boot resumed from could point past that message, so it was never answered and no error was raised. This affected chat.agent, not just custom agents. (#4644)

  Fixes a recovered answer being cut off. After a crash the agent replays the message it had not answered yet, but it was replaying the stop that arrived after that message too, so the turn answering it was aborted the moment it began. A stop is now only applied to the turn that was live when it arrived. That holds however the stop got there: sent after the last completed turn, or sent to a chat whose most recent turn was completed by an older version of the SDK.

  One limitation to know about: the recovered answer is persisted correctly, but a chat page that stayed open across the crash keeps showing the partial answer it had already received. Reload the page to see the full recovered answer.

  Also fixes a retried send being answered twice. When a send was retried and its idempotency claim was lost, the agent could consume the same message a second time.

  Custom agent loops can now inspect pending chat input without consuming it, and consume one record at a time, with chat.messages.hasPending() and chat.messages.next(). Records carry stable identifiers so a redelivery is recognisable.

  if (await chat.messages.hasPending()) {
    const record = await chat.messages.next({ timeoutInSeconds: 0 });
    if (record) handle(record.payload);
  }
  

  hasPending() answers for messages alone, so a message sitting behind a stop, or behind a record this version of the SDK does not recognise, still reports as pending and is still delivered. Anything the agent has no consumer for is discarded rather than left where it would make every message queued behind it undeliverable. chat.messages.next() returning undefined means no message became consumable before the timeout.

  chat.writeTurnComplete()'s sessionInEventId is the cursor that is safe to resume from, not the sequence of the record the turn answered. It is held back behind any message still waiting to be handled, so a value below the record you just handled is expected.

  Fixed a chat agent hanging after an interrupted turn: when a run was killed mid-answer (out of memory, crash, or eviction) and only the one message it was answering was still outstanding, the new run never replied to it. That message is now re-answered on the new run. (#4768)

  Fix chat transport discarding the next turn after stopping generation. skipToTurnComplete is now reset when a new message or action is sent, so a message sent after stopGeneration streams normally instead of leaving the chat stuck in a streaming state. (#4744)

  Fixes a message sent while the agent was mid-answer being lost if the run then crashed. The cursor written at the end of each turn could point past a message that had arrived during that turn but had not been answered yet, so the next boot skipped it and no error was raised anywhere. Such a message is now held until a turn actually takes it. (#4795)

  This also removes the in-memory buffer those messages used to sit in, on both chat.agent and chat.createSession(), so a message waiting for its turn is durable rather than only present in the worker that received it.

  Server changes

  These changes affect the self-hosted Docker image and Trigger.dev Cloud:

  Self-hosted instances can now disable the admin dashboard and user impersonation entirely. See the self-hosting docs for the new setting. (#4774)

  The dashboard has two new themes, Black and White, plus appearance options for stronger colors and underlined links. (#4547)

  Deployment logs no longer jump to the bottom while you are reading earlier output. Scroll up to pause auto-scroll, and scroll back down or use the new scroll-to-bottom button in the log header to resume following. (#4776)

  Customize the runs list: show, hide, and reorder columns, and add smart columns that pull a value straight out of a run's payload, metadata, or output. Your column choices are saved in the page URL, so you can share a view, bookmark it, or save it straight to your favorites. (#4652)

  Stop the browser offering to autofill or save environment variable values as saved credentials. (#4777)

  Cut webapp CPU usage by about a quarter on the routes that workers call most, freeing headroom at the same request rate. Detailed event-loop blocking traces are no longer recorded by default, because producing them was itself a large part of that cost. (#4746)

  When a runs list or runs.list API request spans too much data to complete, it now returns a clear, actionable error asking you to narrow the time range, instead of failing with a generic error. (#4773)

  Improved the performance and reliability of the runs list and the runs.list API, especially for large projects and filtered views. (#4763)

  New Vercel connections now get version skew protection turned on automatically, so each run uses the task version its deployment shipped with. Automatic atomic deployments are deprecated and no longer offered when you connect a project, but stay available in your Vercel integration settings. (#4741)

  The Staging branch setting now shows an upgrade prompt on plans that don't include a Staging environment, instead of looking editable and then silently doing nothing when saved. (#4784)

  All packages: v4.5.13

  @trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev

  Contributors

  @d-cs, Eric Allam, Saadi Myftija, Graham Tremper, Oskar Otwinowski, @nicktrn, claude[bot], @D-K-P, github-actions[bot], @wei-wei, James Ritchie, Chris Arderne

  Full changelog: v4.5.12...v4.5.13

  Original source

  Show more
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  v.docker.4.5.14: chore: release v4.5.14 (#4813)

  Trigger.dev adds smarter realtime streaming and more reliable deployments, with resumable stream subscriptions, latest-record access, session stream hooks, refreshed access tokens, bounded record history, and cleaner native build logs. It also fixes queue retries so delayed tasks are not wrongly failed.

  Summary

  4 improvements, 1 bug fix.

  Improvements

  Native build server deploys now show a single updating build log line by default; pass --build-logs full to stream every line (always used in CI and when output is not a terminal).

  (#4817)

  Realtime stream subscriptions can now refresh an expired access token and reconnect, via a new optional refreshAccessToken option on the client configuration and the React hooks.

  (#4811)

  Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay.

  (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  Added a useSessionStream React hook for reading a session's output or input channel in realtime. It accumulates records with automatic resume from the last record you received, and supports from: "latest" (start at the current tail, only new records after you connect), maxRecords (keep a bounded number of records in memory), a lastEventId resume cursor, and an onRecords callback that delivers each throttled batch of records with their event ids.

  (#4811)

  Server changes

  These changes affect the self-hosted Docker image and Trigger.dev Cloud:

  Task retries that wait in the queue no longer count against the queue's internal redelivery limit, so runs with many long-delay retries are not wrongly failed with TASK_RUN_DEQUEUED_MAX_RETRIES.

  (#4810)

  Raw changeset output

  Releases

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  [email protected]

  Patch Changes

  Native build server deploys now show a single updating build log line by default; pass --build-logs full to stream every line (always used in CI and when output is not a terminal).

  (#4817)

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Realtime stream subscriptions can now refresh an expired access token and reconnect, via a new optional refreshAccessToken option on the client configuration and the React hooks.

  (#4811)

  Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay.

  (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Realtime stream subscriptions can now refresh an expired access token and reconnect, via a new optional refreshAccessToken option on the client configuration and the React hooks.

  (#4811)

  Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay.

  (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  Added a useSessionStream React hook for reading a session's output or input channel in realtime. It accumulates records with automatic resume from the last record you received, and supports from: "latest" (start at the current tail, only new records after you connect), maxRecords (keep a bounded number of records in memory), a lastEventId resume cursor, and an onRecords callback that delivers each throttled batch of records with their event ids.

  (#4811)

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay.

  (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  Updated dependencies:

  @trigger.dev/[email protected]

  Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

  Original source

  Show more
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  v.docker.4.5.13: chore: release v4.5.13 (#4769)

  Trigger.dev adds a major release with smarter deploy builds, new local bundle options, and stronger chat agent handling. It also improves runs list performance, dashboard themes and controls, and fixes several message delivery and recovery bugs for more reliable chats.

  Summary

  4 new features, 12 improvements, 5 bug fixes.

  Improvements

  trigger.dev deploy now asks the server whether to build with Depot
  or the native build server unless --native-build, --depot-build, or
  --local-build is passed, so the native build server can be rolled out
  per organization without a CLI change. --local-bundle and --detach
  now require --native-build.

  (#4803)

  Add an experimental --local-bundle deploy flag that runs the install
  and bundling steps on your machine and uploads only the build output;
  the image is still built remotely. Useful when your project's install
  step needs tooling or credentials that only exist locally.

  (#4331)

  Send the CLI version header on all API requests so deployments are
  attributable to a CLI version

  (#4778)

  A message that arrives mid-turn and is not injected into that turn is
  now answered as the next turn, instead of being dropped. This is what
  the pendingMessages docs have always described, and it applies to the
  default too: configuring pendingMessages without a shouldInject
  declines every batch, which previously meant every mid-turn message was
  lost with no error at either end.

  (#4795)

  chat.agent({
  id: "my-chat",
  pendingMessages: {
  onReceived: ({ message }) =>
  logger.info("arrived mid-turn", { id: message.id }),
  // Only interrupt once the agent has started calling tools.
  shouldInject: ({ steps }) => steps.length > 0,
  },
  run: async ({ messages, signal }) =>
  streamText({
  model,
  messages,
  abortSignal: signal,
  // Required for injection. Without it nothing injects, and every
  // mid-turn message is answered as the next turn instead.
  ...chat.toStreamTextOptions(),
  }),
  });
  

  A declined message keeps its place in the queue, so it survives a crash
  and is answered by whichever run picks the conversation up. An injected
  one is consumed at the moment it is injected, so it is never also
  answered as a later turn.

  Browser chats now keep the active turn open across page reloads when
  older completion records are replayed.

  (#4643)

  Add chat.endAndContinue() so fully hand-rolled custom chat agents
  can hand a conversation off to a fresh run on the latest deployed task
  version while preserving unconsumed Session input.

  (#4647)

  Custom chat agents now validate and parse client data declared with
  chat.withClientData({ schema }) before passing it to agent code.

  (#4646)

  Bug fixes

  Fixes a case where a chat could silently lose a message. If a message
  arrived while the agent was between turns and a stop arrived after it,
  the cursor the next boot resumed from could point past that message, so
  it was never answered and no error was raised. This affected
  chat.agent, not just custom agents.

  (#4644)

  Fixes a recovered answer being cut off. After a crash the agent replays
  the message it had not answered yet, but it was replaying the stop that
  arrived after that message too, so the turn answering it was aborted the
  moment it began. A stop is now only applied to the turn that was live
  when it arrived. That holds however the stop got there: sent after the
  last completed turn, or sent to a chat whose most recent turn was
  completed by an older version of the SDK.
  One limitation to know about: the recovered answer is persisted
  correctly, but a chat page that stayed open across the crash keeps
  showing the partial answer it had already received. Reload the page to
  see the full recovered answer.

  Also fixes a retried send being answered twice. When a send was retried
  and its idempotency claim was lost, the agent could consume the same
  message a second time.

  Custom agent loops can now inspect pending chat input without consuming
  it, and consume one record at a time, with chat.messages.hasPending()
  and chat.messages.next(). Records carry stable identifiers so a
  redelivery is recognisable.

  if (await chat.messages.hasPending()) {
  const record = await chat.messages.next({ timeoutInSeconds: 0 });
  if (record) handle(record.payload);
  }
  

  hasPending() answers for messages alone, so a message sitting behind a
  stop, or behind a record this version of the SDK does not recognise,
  still reports as pending and is still delivered. Anything the agent has
  no consumer for is discarded rather than left where it would make every
  message queued behind it undeliverable. chat.messages.next() returning
  undefined means no message became consumable before the timeout.

  chat.writeTurnComplete()'s sessionInEventId is the cursor that is
  safe to resume from, not the sequence of the record the turn answered.
  It is held back behind any message still waiting to be handled, so a
  value below the record you just handled is expected.

  Fixed a chat agent hanging after an interrupted turn: when a run was
  killed mid-answer (out of memory, crash, or eviction) and only the one
  message it was answering was still outstanding, the new run never
  replied to it. That message is now re-answered on the new run.

  (#4768)

  Fix chat transport discarding the next turn after stopping generation.
  skipToTurnComplete is now reset when a new message or action is sent,
  so a message sent after stopGeneration streams normally instead of
  leaving the chat stuck in a streaming state.

  (#4744)

  Fixes a message sent while the agent was mid-answer being lost if the
  run then crashed. The cursor written at the end of each turn could point
  past a message that had arrived during that turn but had not been
  answered yet, so the next boot skipped it and no error was raised
  anywhere. Such a message is now held until a turn actually takes it.

  (#4795)

  This also removes the in-memory buffer those messages used to sit in, on
  both chat.agent and chat.createSession(), so a message waiting for
  its turn is durable rather than only present in the worker that received
  it.

  Server changes

  These changes affect the self-hosted Docker image and Trigger.dev Cloud:

  Self-hosted instances can now disable the admin dashboard and user
  impersonation entirely. See the self-hosting docs for the new setting.

  (#4774)

  The dashboard has two new themes, Black and White, plus appearance
  options for stronger colors and underlined links.

  (#4547)

  Deployment logs no longer jump to the bottom while you are reading
  earlier output. Scroll up to pause auto-scroll, and scroll back down or
  use the new scroll-to-bottom button in the log header to resume
  following.

  (#4776)

  Customize the runs list: show, hide, and reorder columns, and add
  smart columns that pull a value straight out of a run's payload,
  metadata, or output. Your column choices are saved in the page URL, so
  you can share a view, bookmark it, or save it straight to your
  favorites.

  (#4652)

  Stop the browser offering to autofill or save environment variable
  values as saved credentials.

  (#4777)

  Cut webapp CPU usage by about a quarter on the routes that workers
  call most, freeing headroom at the same request rate. Detailed
  event-loop blocking traces are no longer recorded by default, because
  producing them was itself a large part of that cost.

  (#4746)

  When a runs list or runs.list API request spans too much data to
  complete, it now returns a clear, actionable error asking you to narrow
  the time range, instead of failing with a generic error.

  (#4773)

  Improved the performance and reliability of the runs list and the
  runs.list API, especially for large projects and filtered views.

  (#4763)

  New Vercel connections now get version skew protection turned on
  automatically, so each run uses the task version its deployment shipped
  with. Automatic atomic deployments are deprecated and no longer offered
  when you connect a project, but stay available in your Vercel
  integration settings.

  (#4741)

  The Staging branch setting now shows an upgrade prompt on plans that
  don't include a Staging environment, instead of looking editable and
  then silently doing nothing when saved.

  (#4784)

  Raw changeset output

  Releases

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  [email protected]

  [email protected]

  Patch Changes

  trigger.dev deploy now asks the server whether to build with Depot
  or the native build server unless --native-build, --depot-build, or
  --local-build is passed, so the native build server can be rolled out
  per organization without a CLI change. --local-bundle and --detach
  now require --native-build.

  (#4803)

  Add an experimental --local-bundle deploy flag that runs the install
  and bundling steps on your machine and uploads only the build output;
  the image is still built remotely. Useful when your project's install
  step needs tooling or credentials that only exist locally.

  (#4331)

  Send the CLI version header on all API requests so deployments are
  attributable to a CLI version

  (#4778)

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  trigger.dev deploy now asks the server whether to build with Depot
  or the native build server unless --native-build, --depot-build, or
  --local-build is passed, so the native build server can be rolled out
  per organization without a CLI change. --local-bundle and --detach
  now require --native-build.

  (#4803)

  Add an experimental --local-bundle deploy flag that runs the install
  and bundling steps on your machine and uploads only the build output;
  the image is still built remotely. Useful when your project's install
  step needs tooling or credentials that only exist locally.

  (#4331)

  A message that arrives mid-turn and is not injected into that turn is
  now answered as the next turn, instead of being dropped. This is what
  the pendingMessages docs have always described, and it applies to the
  default too: configuring pendingMessages without a shouldInject
  declines every batch, which previously meant every mid-turn message was
  lost with no error at either end.

  (#4795)

  chat.agent({
  id: "my-chat",
  pendingMessages: {
  onReceived: ({ message }) =>
  logger.info("arrived mid-turn", { id: message.id }),
  // Only interrupt once the agent has started calling tools.
  shouldInject: ({ steps }) => steps.length > 0,
  },
  run: async ({ messages, signal }) =>
  streamText({
  model,
  messages,
  abortSignal: signal,
  // Required for injection. Without it nothing injects, and every
  // mid-turn message is answered as the next turn instead.
  ...chat.toStreamTextOptions(),
  }),
  });
  

  A declined message keeps its place in the queue, so it survives a crash
  and is answered by whichever run picks the conversation up. An injected
  one is consumed at the moment it is injected, so it is never also
  answered as a later turn.

  Fixes a case where a chat could silently lose a message. If a message
  arrived while the agent was between turns and a stop arrived after it,
  the cursor the next boot resumed from could point past that message, so
  it was never answered and no error was raised. This affected
  chat.agent, not just custom agents.

  (#4644)

  Fixes a recovered answer being cut off. After a crash the agent replays
  the message it had not answered yet, but it was replaying the stop that
  arrived after that message too, so the turn answering it was aborted the
  moment it began. A stop is now only applied to the turn that was live
  when it arrived. That holds however the stop got there: sent after the
  last completed turn, or sent to a chat whose most recent turn was
  completed by an older version of the SDK.
  One limitation to know about: the recovered answer is persisted
  correctly, but a chat page that stayed open across the crash keeps
  showing the partial answer it had already received. Reload the page to
  see the full recovered answer.

  Also fixes a retried send being answered twice. When a send was retried
  and its idempotency claim was lost, the agent could consume the same
  message a second time.

  Custom agent loops can now inspect pending chat input without consuming
  it, and consume one record at a time, with chat.messages.hasPending()
  and chat.messages.next(). Records carry stable identifiers so a
  redelivery is recognisable.

  if (await chat.messages.hasPending()) {
  const record = await chat.messages.next({ timeoutInSeconds: 0 });
  if (record) handle(record.payload);
  }
  

  hasPending() answers for messages alone, so a message sitting behind a
  stop, or behind a record this version of the SDK does not recognise,
  still reports as pending and is still delivered. Anything the agent has
  no consumer for is discarded rather than left where it would make every
  message queued behind it undeliverable. chat.messages.next() returning
  undefined means no message became consumable before the timeout.

  chat.writeTurnComplete()'s sessionInEventId is the cursor that is
  safe to resume from, not the sequence of the record the turn answered.
  It is held back behind any message still waiting to be handled, so a
  value below the record you just handled is expected.

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Fixed a chat agent hanging after an interrupted turn: when a run was
  killed mid-answer (out of memory, crash, or eviction) and only the one
  message it was answering was still outstanding, the new run never
  replied to it. That message is now re-answered on the new run.

  (#4768)

  Browser chats now keep the active turn open across page reloads when
  older completion records are replayed.

  (#4643)

  Add chat.endAndContinue() so fully hand-rolled custom chat agents
  can hand a conversation off to a fresh run on the latest deployed task
  version while preserving unconsumed Session input.

  (#4647)

  Fix chat transport discarding the next turn after stopping generation.
  skipToTurnComplete is now reset when a new message or action is sent,
  so a message sent after stopGeneration streams normally instead of
  leaving the chat stuck in a streaming state.

  (#4744)

  Custom chat agents now validate and parse client data declared with
  chat.withClientData({ schema }) before passing it to agent code.

  (#4646)

  Fixes a message sent while the agent was mid-answer being lost if the
  run then crashed. The cursor written at the end of each turn could point
  past a message that had arrived during that turn but had not been
  answered yet, so the next boot skipped it and no error was raised
  anywhere. Such a message is now held until a turn actually takes it.

  (#4795)

  This also removes the in-memory buffer those messages used to sit in, on
  both chat.agent and chat.createSession(), so a message waiting for
  its turn is durable rather than only present in the worker that received
  it.

  A message that arrives mid-turn and is not injected into that turn is
  now answered as the next turn, instead of being dropped. This is what
  the pendingMessages docs have always described, and it applies to the
  default too: configuring pendingMessages without a shouldInject
  declines every batch, which previously meant every mid-turn message was
  lost with no error at either end.

  (#4795)

  chat.agent({
  id: "my-chat",
  pendingMessages: {
  onReceived: ({ message }) =>
  logger.info("arrived mid-turn", { id: message.id }),
  // Only interrupt once the agent has started calling tools.
  shouldInject: ({ steps }) => steps.length > 0,
  },
  run: async ({ messages, signal }) =>
  streamText({
  model,
  messages,
  abortSignal: signal,
  // Required for injection. Without it nothing injects, and every
  // mid-turn message is answered as the next turn instead.
  ...chat.toStreamTextOptions(),
  }),
  });
  

  A declined message keeps its place in the queue, so it survives a crash
  and is answered by whichever run picks the conversation up. An injected
  one is consumed at the moment it is injected, so it is never also
  answered as a later turn.

  Fixes a case where a chat could silently lose a message. If a message
  arrived while the agent was between turns and a stop arrived after it,
  the cursor the next boot resumed from could point past that message, so
  it was never answered and no error was raised. This affected
  chat.agent, not just custom agents.

  (#4644)

  Fixes a recovered answer being cut off. After a crash the agent replays
  the message it had not answered yet, but it was replaying the stop that
  arrived after that message too, so the turn answering it was aborted the
  moment it began. A stop is now only applied to the turn that was live
  when it arrived. That holds however the stop got there: sent after the
  last completed turn, or sent to a chat whose most recent turn was
  completed by an older version of the SDK.
  One limitation to know about: the recovered answer is persisted
  correctly, but a chat page that stayed open across the crash keeps
  showing the partial answer it had already received. Reload the page to
  see the full recovered answer.

  Also fixes a retried send being answered twice. When a send was retried
  and its idempotency claim was lost, the agent could consume the same
  message a second time.

  Custom agent loops can now inspect pending chat input without consuming
  it, and consume one record at a time, with chat.messages.hasPending()
  and chat.messages.next(). Records carry stable identifiers so a
  redelivery is recognisable.

  if (await chat.messages.hasPending()) {
  const record = await chat.messages.next({ timeoutInSeconds: 0 });
  if (record) handle(record.payload);
  }
  

  hasPending() answers for messages alone, so a message sitting behind a
  stop, or behind a record this version of the SDK does not recognise,
  still reports as pending and is still delivered. Anything the agent has
  no consumer for is discarded rather than left where it would make every
  message queued behind it undeliverable. chat.messages.next() returning
  undefined means no message became consumable before the timeout.

  chat.writeTurnComplete()'s sessionInEventId is the cursor that is
  safe to resume from, not the sequence of the record the turn answered.
  It is held back behind any message still waiting to be handled, so a
  value below the record you just handled is expected.

  Updated dependencies:
  @trigger.dev/[email protected]

  Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

  Original source

  Show more
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  helm-v4.5.14: chore: release v4.5.14 (#4813)

  Trigger.dev adds realtime stream resume and latest-tail subscriptions, plus refreshed access-token reconnects, bounded history, and a new useSessionStream hook. It also improves native build server deploy logs and fixes queue retries that could fail too early.

  Summary

  4 improvements, 1 bug fix.

  Improvements

  Native build server deploys now show a single updating build log line
  by default; pass --build-logs full to stream every line (always used
  in CI and when output is not a terminal).

  (#4817)

  Realtime stream subscriptions can now refresh an expired access token
  and reconnect, via a new optional refreshAccessToken option on the
  client configuration and the React hooks.

  (#4811)

  Subscribe to a realtime stream from its latest record instead of
  replaying the whole history. Pass from: "latest" to
  useRealtimeStream, streams.read(), or fetchStream to start at the
  current tail (the latest record, then live updates) instead of replaying
  (a live "last value" view), and maxParts to keep the accumulated
  parts array bounded. A reconnect or remount resumes from the last
  record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall
  back to a full replay.

  (#4811)

  useRealtimeStream also gains a lastEventId option and returns the
  lastEventId of the last part seen, so you can persist the cursor (for
  example across a page reload) and resume exactly where you left off. An
  onParts callback delivers each throttled batch of parts with their
  event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames",
  {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  Added a useSessionStream React hook for reading a session's output
  or input channel in realtime. It accumulates records with automatic
  resume from the last record you received, and supports from: "latest"
  (start at the current tail, only new records after you connect),
  maxRecords (keep a bounded number of records in memory), a
  lastEventId resume cursor, and an onRecords callback that delivers
  each throttled batch of records with their event ids.

  (#4811)

  Server changes

  These changes affect the self-hosted Docker image and Trigger.dev Cloud:

  Task retries that wait in the queue no longer count against the
  queue's internal redelivery limit, so runs with many long-delay retries
  are not wrongly failed with TASK_RUN_DEQUEUED_MAX_RETRIES.

  (#4810)

  Raw changeset output

  Releases

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  [email protected]

  Patch Changes

  Native build server deploys now show a single updating build log line
  by default; pass --build-logs full to stream every line (always used
  in CI and when output is not a terminal).

  (#4817)

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Realtime stream subscriptions can now refresh an expired access token
  and reconnect, via a new optional refreshAccessToken option on the
  client configuration and the React hooks.

  (#4811)

  Subscribe to a realtime stream from its latest record instead of
  replaying the whole history. Pass from: "latest" to
  useRealtimeStream, streams.read(), or fetchStream to start at the
  current tail (the latest record, then live updates) instead of replaying
  (a live "last value" view), and maxParts to keep the accumulated
  parts array bounded. A reconnect or remount resumes from the last
  record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall
  back to a full replay.

  (#4811)

  useRealtimeStream also gains a lastEventId option and returns the
  lastEventId of the last part seen, so you can persist the cursor (for
  example across a page reload) and resume exactly where you left off. An
  onParts callback delivers each throttled batch of parts with their
  event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames",
  {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Realtime stream subscriptions can now refresh an expired access token
  and reconnect, via a new optional refreshAccessToken option on the
  client configuration and the React hooks.

  (#4811)

  Subscribe to a realtime stream from its latest record instead of
  replaying the whole history. Pass from: "latest" to
  useRealtimeStream, streams.read(), or fetchStream to start at the
  current tail (the latest record, then live updates) instead of replaying
  (a live "last value" view), and maxParts to keep the accumulated
  parts array bounded. A reconnect or remount resumes from the last
  record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall
  back to a full replay.

  (#4811)

  useRealtimeStream also gains a lastEventId option and returns the
  lastEventId of the last part seen, so you can persist the cursor (for
  example across a page reload) and resume exactly where you left off. An
  onParts callback delivers each throttled batch of parts with their
  event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames",
  {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  Added a useSessionStream React hook for reading a session's output
  or input channel in realtime. It accumulates records with automatic
  resume from the last record you received, and supports from: "latest"
  (start at the current tail, only new records after you connect),
  maxRecords (keep a bounded number of records in memory), a
  lastEventId resume cursor, and an onRecords callback that delivers
  each throttled batch of records with their event ids.

  (#4811)

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:
  @trigger.dev/[email protected]
  @trigger.dev/[email protected]

  Patch Changes

  Subscribe to a realtime stream from its latest record instead of
  replaying the whole history. Pass from: "latest" to
  useRealtimeStream, streams.read(), or fetchStream to start at the
  current tail (the latest record, then live updates) instead of replaying
  (a live "last value" view), and maxParts to keep the accumulated
  parts array bounded. A reconnect or remount resumes from the last
  record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall
  back to a full replay.

  (#4811)

  useRealtimeStream also gains a lastEventId option and returns the
  lastEventId of the last part seen, so you can persist the cursor (for
  example across a page reload) and resume exactly where you left off. An
  onParts callback delivers each throttled batch of parts with their
  event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames",
  {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });
  

  Updated dependencies:
  @trigger.dev/[email protected]

  Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

  Original source

  Show more
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  helm-v4.5.13: chore: release v4.5.13 (#4769)

  Trigger.dev adds smarter deploy builds with server-selected native or Depot options, an experimental local-bundle flag, and CLI version reporting. It also improves chat message durability and recovery, plus dashboard themes, run list customization, and faster, more reliable runs lists.

  Summary

  4 new features, 12 improvements, 5 bug fixes.

  Improvements

  trigger.dev deploy now asks the server whether to build with Depot
  or the native build server unless --native-build, --depot-build, or
  --local-build is passed, so the native build server can be rolled out
  per organization without a CLI change. --local-bundle and --detach
  now require --native-build.
  (#4803)

  Add an experimental --local-bundle deploy flag that runs the install
  and bundling steps on your machine and uploads only the build output;
  the image is still built remotely. Useful when your project's install
  step needs tooling or credentials that only exist locally.
  (#4331)

  Send the CLI version header on all API requests so deployments are
  attributable to a CLI version
  (#4778)

  A message that arrives mid-turn and is not injected into that turn is
  now answered as the next turn, instead of being dropped. This is what
  the pendingMessages docs have always described, and it applies to the
  default too: configuring pendingMessages without a shouldInject
  declines every batch, which previously meant every mid-turn message was
  lost with no error at either end.
  (#4795)

  chat.agent({
  id: "my-chat",
  pendingMessages: {
  onReceived: ({ message }) =>
  logger.info("arrived mid-turn", { id: message.id }),
  // Only interrupt once the agent has started calling tools.
  shouldInject: ({ steps }) => steps.length > 0,
  },
  run: async ({ messages, signal }) =>
  streamText({
  model,
  messages,
  abortSignal: signal,
  // Required for injection. Without it nothing injects, and every
  // mid-turn message is answered as the next turn instead.
  ...chat.toStreamTextOptions(),
  }),
  });
  

  A declined message keeps its place in the queue, so it survives a crash
  and is answered by whichever run picks the conversation up. An injected
  one is consumed at the moment it is injected, so it is never also
  answered as a later turn.

  Browser chats now keep the active turn open across page reloads when
  older completion records are replayed.
  (#4643)

  Add chat.endAndContinue() so fully hand-rolled custom chat agents
  can hand a conversation off to a fresh run on the latest deployed task
  version while preserving unconsumed Session input.
  (#4647)

  Custom chat agents now validate and parse client data declared with
  chat.withClientData({ schema }) before passing it to agent code.
  (#4646)

  Bug fixes

  Fixes a case where a chat could silently lose a message. If a message
  arrived while the agent was between turns and a stop arrived after it,
  the cursor the next boot resumed from could point past that message, so
  it was never answered and no error was raised. This affected
  chat.agent, not just custom agents.
  (#4644)

  Fixes a recovered answer being cut off. After a crash the agent replays
  the message it had not answered yet, but it was replaying the stop that
  arrived after that message too, so the turn answering it was aborted the
  moment it began. A stop is now only applied to the turn that was live
  when it arrived. That holds however the stop got there: sent after the
  last completed turn, or sent to a chat whose most recent turn was
  completed by an older version of the SDK.

  One limitation to know about: the recovered answer is persisted
  correctly, but a chat page that stayed open across the crash keeps
  showing the partial answer it had already received. Reload the page to
  see the full recovered answer.

  Also fixes a retried send being answered twice. When a send was retried
  and its idempotency claim was lost, the agent could consume the same
  message a second time.

  Custom agent loops can now inspect pending chat input without consuming
  it, and consume one record at a time, with chat.messages.hasPending()
  and chat.messages.next(). Records carry stable identifiers so a
  redelivery is recognisable.

  if (await chat.messages.hasPending()) {
  const record = await chat.messages.next({ timeoutInSeconds: 0 });
  if (record) handle(record.payload);
  }
  

  hasPending() answers for messages alone, so a message sitting behind a
  stop, or behind a record this version of the SDK does not recognise,
  still reports as pending and is still delivered. Anything the agent has
  no consumer for is discarded rather than left where it would make every
  message queued behind it undeliverable. chat.messages.next() returning
  undefined means no message became consumable before the timeout.

  chat.writeTurnComplete()'s sessionInEventId is the cursor that is
  safe to resume from, not the sequence of the record the turn answered.
  It is held back behind any message still waiting to be handled, so a
  value below the record you just handled is expected.

  Fixed a chat agent hanging after an interrupted turn: when a run was
  killed mid-answer (out of memory, crash, or eviction) and only the one
  message it was answering was still outstanding, the new run never
  replied to it. That message is now re-answered on the new run.
  (#4768)

  Fix chat transport discarding the next turn after stopping generation.
  skipToTurnComplete is now reset when a new message or action is sent,
  so a message sent after stopGeneration streams normally instead of
  leaving the chat stuck in a streaming state.
  (#4744)

  Fixes a message sent while the agent was mid-answer being lost if the
  run then crashed. The cursor written at the end of each turn could point
  past a message that had arrived during that turn but had not been
  answered yet, so the next boot skipped it and no error was raised
  anywhere. Such a message is now held until a turn actually takes it.
  (#4795)

  This also removes the in-memory buffer those messages used to sit in, on
  both chat.agent and chat.createSession(), so a message waiting for
  its turn is durable rather than only present in the worker that received
  it.

  Server changes

  These changes affect the self-hosted Docker image and Trigger.dev Cloud:

  Self-hosted instances can now disable the admin dashboard and user
  impersonation entirely. See the self-hosting docs for the new setting.
  (#4774)

  The dashboard has two new themes, Black and White, plus appearance
  options for stronger colors and underlined links.
  (#4547)

  Deployment logs no longer jump to the bottom while you are reading
  earlier output. Scroll up to pause auto-scroll, and scroll back down or
  use the new scroll-to-bottom button in the log header to resume
  following.
  (#4776)

  Customize the runs list: show, hide, and reorder columns, and add
  smart columns that pull a value straight out of a run's payload,
  metadata, or output. Your column choices are saved in the page URL, so
  you can share a view, bookmark it, or save it straight to your
  favorites.
  (#4652)

  Stop the browser offering to autofill or save environment variable
  values as saved credentials.
  (#4777)

  Cut webapp CPU usage by about a quarter on the routes that workers
  call most, freeing headroom at the same request rate. Detailed
  event-loop blocking traces are no longer recorded by default, because
  producing them was itself a large part of that cost.
  (#4746)

  When a runs list or runs.list API request spans too much data to
  complete, it now returns a clear, actionable error asking you to narrow
  the time range, instead of failing with a generic error.
  (#4773)

  Improved the performance and reliability of the runs list and the
  runs.list API, especially for large projects and filtered views.
  (#4763)

  New Vercel connections now get version skew protection turned on
  automatically, so each run uses the task version its deployment shipped
  with. Automatic atomic deployments are deprecated and no longer offered
  when you connect a project, but stay available in your Vercel
  integration settings.
  (#4741)

  The Staging branch setting now shows an upgrade prompt on plans that
  don't include a Staging environment, instead of looking editable and
  then silently doing nothing when saved.
  (#4784)

  Raw changeset output

  Releases

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  [email protected]

  Patch Changes

  trigger.dev deploy now asks the server whether to build with Depot
  or the native build server unless --native-build, --depot-build, or
  --local-build is passed, so the native build server can be rolled out
  per organization without a CLI change. --local-bundle and --detach
  now require --native-build.
  (#4803)

  Add an experimental --local-bundle deploy flag that runs the install
  and bundling steps on your machine and uploads only the build output;
  the image is still built remotely. Useful when your project's install
  step needs tooling or credentials that only exist locally.
  (#4331)

  Send the CLI version header on all API requests so deployments are
  attributable to a CLI version
  (#4778)

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  trigger.dev deploy now asks the server whether to build with Depot
  or the native build server unless --native-build, --depot-build, or
  --local-build is passed, so the native build server can be rolled out
  per organization without a CLI change. --local-bundle and --detach
  now require --native-build.
  (#4803)

  Add an experimental --local-bundle deploy flag that runs the install
  and bundling steps on your machine and uploads only the build output;
  the image is still built remotely. Useful when your project's install
  step needs tooling or credentials that only exist locally.
  (#4331)

  A message that arrives mid-turn and is not injected into that turn is
  now answered as the next turn, instead of being dropped. This is what
  the pendingMessages docs have always described, and it applies to the
  default too: configuring pendingMessages without a shouldInject
  declines every batch, which previously meant every mid-turn message was
  lost with no error at either end.
  (#4795)

  chat.agent({
  id: "my-chat",
  pendingMessages: {
  onReceived: ({ message }) =>
  logger.info("arrived mid-turn", { id: message.id }),
  // Only interrupt once the agent has started calling tools.
  shouldInject: ({ steps }) => steps.length > 0,
  },
  run: async ({ messages, signal }) =>
  streamText({
  model,
  messages,
  abortSignal: signal,
  // Required for injection. Without it nothing injects, and every
  // mid-turn message is answered as the next turn instead.
  ...chat.toStreamTextOptions(),
  }),
  });
  

  A declined message keeps its place in the queue, so it survives a crash
  and is answered by whichever run picks the conversation up. An injected
  one is consumed at the moment it is injected, so it is never also
  answered as a later turn.

  Fixes a case where a chat could silently lose a message. If a message
  arrived while the agent was between turns and a stop arrived after it,
  the cursor the next boot resumed from could point past that message, so
  it was never answered and no error was raised. This affected
  chat.agent, not just custom agents.
  (#4644)

  Fixes a recovered answer being cut off. After a crash the agent replays
  the message it had not answered yet, but it was replaying the stop that
  arrived after that message too, so the turn answering it was aborted the
  moment it began. A stop is now only applied to the turn that was live
  when it arrived. That holds however the stop got there: sent after the
  last completed turn, or sent to a chat whose most recent turn was
  completed by an older version of the SDK.

  One limitation to know about: the recovered answer is persisted
  correctly, but a chat page that stayed open across the crash keeps
  showing the partial answer it had already received. Reload the page to
  see the full recovered answer.

  Also fixes a retried send being answered twice. When a send was retried
  and its idempotency claim was lost, the agent could consume the same
  message a second time.

  Custom agent loops can now inspect pending chat input without consuming
  it, and consume one record at a time, with chat.messages.hasPending()
  and chat.messages.next(). Records carry stable identifiers so a
  redelivery is recognisable.

  if (await chat.messages.hasPending()) {
  const record = await chat.messages.next({ timeoutInSeconds: 0 });
  if (record) handle(record.payload);
  }
  

  hasPending() answers for messages alone, so a message sitting behind a
  stop, or behind a record this version of the SDK does not recognise,
  still reports as pending and is still delivered. Anything the agent has
  no consumer for is discarded rather than left where it would make every
  message queued behind it undeliverable. chat.messages.next() returning
  undefined means no message became consumable before the timeout.

  chat.writeTurnComplete()'s sessionInEventId is the cursor that is
  safe to resume from, not the sequence of the record the turn answered.
  It is held back behind any message still waiting to be handled, so a
  value below the record you just handled is expected.

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Updated dependencies:

  @trigger.dev/[email protected]

  @trigger.dev/[email protected]

  Patch Changes

  Fixed a chat agent hanging after an interrupted turn: when a run was
  killed mid-answer (out of memory, crash, or eviction) and only the one
  message it was answering was still outstanding, the new run never
  replied to it. That message is now re-answered on the new run.
  (#4768)

  Browser chats now keep the active turn open across page reloads when
  older completion records are replayed.
  (#4643)

  Add chat.endAndContinue() so fully hand-rolled custom chat agents
  can hand a conversation off to a fresh run on the latest deployed task
  version while preserving unconsumed Session input.
  (#4647)

  Fix chat transport discarding the next turn after stopping generation.
  skipToTurnComplete is now reset when a new message or action is sent,
  so a message sent after stopGeneration streams normally instead of
  leaving the chat stuck in a streaming state.
  (#4744)

  Custom chat agents now validate and parse client data declared with
  chat.withClientData({ schema }) before passing it to agent code.
  (#4646)

  Fixes a message sent while the agent was mid-answer being lost if the
  run then crashed. The cursor written at the end of each turn could point
  past a message that had arrived during that turn but had not been
  answered yet, so the next boot skipped it and no error was raised
  anywhere. Such a message is now held until a turn actually takes it.
  (#4795)

  This also removes the in-memory buffer those messages used to sit in, on
  both chat.agent and chat.createSession(), so a message waiting for
  its turn is durable rather than only present in the worker that received
  it.

  A message that arrives mid-turn and is not injected into that turn is
  now answered as the next turn, instead of being dropped. This is what
  the pendingMessages docs have always described, and it applies to the
  default too: configuring pendingMessages without a shouldInject
  declines every batch, which previously meant every mid-turn message was
  lost with no error at either end.
  (#4795)

  chat.agent({
  id: "my-chat",
  pendingMessages: {
  onReceived: ({ message }) =>
  logger.info("arrived mid-turn", { id: message.id }),
  // Only interrupt once the agent has started calling tools.
  shouldInject: ({ steps }) => steps.length > 0,
  },
  run: async ({ messages, signal }) =>
  streamText({
  model,
  messages,
  abortSignal: signal,
  // Required for injection. Without it nothing injects, and every
  // mid-turn message is answered as the next turn instead.
  ...chat.toStreamTextOptions(),
  }),
  });
  

  A declined message keeps its place in the queue, so it survives a crash
  and is answered by whichever run picks the conversation up. An injected
  one is consumed at the moment it is injected, so it is never also
  answered as a later turn.

  Fixes a case where a chat could silently lose a message. If a message
  arrived while the agent was between turns and a stop arrived after it,
  the cursor the next boot resumed from could point past that message, so
  it was never answered and no error was raised. This affected
  chat.agent, not just custom agents.
  (#4644)

  Fixes a recovered answer being cut off. After a crash the agent replays
  the message it had not answered yet, but it was replaying the stop that
  arrived after that message too, so the turn answering it was aborted the
  moment it began. A stop is now only applied to the turn that was live
  when it arrived. That holds however the stop got there: sent after the
  last completed turn, or sent to a chat whose most recent turn was
  completed by an older version of the SDK.

  One limitation to know about: the recovered answer is persisted
  correctly, but a chat page that stayed open across the crash keeps
  showing the partial answer it had already received. Reload the page to
  see the full recovered answer.

  Also fixes a retried send being answered twice. When a send was retried
  and its idempotency claim was lost, the agent could consume the same
  message a second time.

  Custom agent loops can now inspect pending chat input without consuming
  it, and consume one record at a time, with chat.messages.hasPending()
  and chat.messages.next(). Records carry stable identifiers so a
  redelivery is recognisable.

  if (await chat.messages.hasPending()) {
  const record = await chat.messages.next({ timeoutInSeconds: 0 });
  if (record) handle(record.payload);
  }
  

  hasPending() answers for messages alone, so a message sitting behind a
  stop, or behind a record this version of the SDK does not recognise,
  still reports as pending and is still delivered. Anything the agent has
  no consumer for is discarded rather than left where it would make every
  message queued behind it undeliverable. chat.messages.next() returning
  undefined means no message became consumable before the timeout.

  chat.writeTurnComplete()'s sessionInEventId is the cursor that is
  safe to resume from, not the sequence of the record the turn answered.
  It is held back behind any message still waiting to be handled, so a
  value below the record you just handled is expected.

  Updated dependencies:

  @trigger.dev/[email protected]

  Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

  Original source

  Show more
• Aug 28, 2026

  • Date parsed from source:
    Aug 28, 2026
  • First seen by Releasebot:
    Aug 29, 2026
  

  Trigger.dev

  docs-release-2026-08-28

  Trigger.dev publishes docs for chat agent custom-agent APIs and version skew protection.

  Publish docs: chat agent custom-agent APIs, version skew protection, …

  Original source