ReleaseCloudflare (Workers AI)Cloudflare (Workers AI)published Jun 2, 2026seen Jun 26

cloudflare/agents @cloudflare/ai-chat@0.8.0

cloudflare/agents

Open original ↗

Captured source

source ↗
published Jun 2, 2026seen Jun 26captured 4whttp 200method plain

@cloudflare/ai-chat@0.8.0

Repository: cloudflare/agents

Tag: @cloudflare/ai-chat@0.8.0

Published: 2026-06-02T10:03:24Z

Prerelease: no

Release notes:

Minor Changes

products can build a terminal-state policy without re-deriving anything (#1631).

  • ChatRecoveryContext (the onChatRecovery argument) now includes

recoveryRootRequestId — the stable request ID for the whole continuation chain. Unlike requestId, it doesn't change across chained continuations, so it's the right key for per-incident budget tracking / fresh-incident detection without re-deriving identity from message IDs.

  • ChatRecoveryExhaustedContext (the onExhausted argument) now carries

recoveryRootRequestId, terminalMessage (the exact text shown to the user), partialText / partialParts (what the turn produced before it was given up on), and streamId / createdAt — enough to render or persist a user-facing terminal banner AND emit correlated terminal telemetry (e.g. time-since-turn-start, stream correlation) directly, without re-deriving anything.

All fields are additive. Applied across agents (shared types), @cloudflare/think, and @cloudflare/ai-chat.

When a durable chat turn is interrupted (a deploy/eviction, or a stream-stall watchdog abort) and resumes, clients had no "in progress" signal — the turn looked frozen until it completed or a terminal error was replayed. A new cf_agent_chat_recovering protocol frame is now broadcast on recovery schedule and cleared on every terminal outcome (completed/skipped/failed/exhausted), so the indicator can't spin forever. In @cloudflare/think it's also persisted and replayed on connect, so a client that joins mid-recovery learns the turn is working. useAgentChat exposes a new isRecovering flag (distinct from isStreaming — a recovering turn isn't producing tokens yet); most UIs render isStreaming || isRecovering as "busy". Backward-compatible: clients that don't understand the frame ignore it.

> Note: @cloudflare/ai-chat broadcasts the live signal but does not yet replay > it on connect (it has no idle-connect hydration path; tracked in #1645). > @cloudflare/think has both.

For recovery telemetry, subscribe to the chat:recovery:* observability events and route them to your analytics sink.

  • #1611 `02f9380` Thanks @threepointone! - Add bounded, observable recovery foundations for durable chat turns and fibers.
  • Add dedicated recovery observability channels/events for fibers, chat recovery, transcript repair, and agent-tool recovery.
  • Bound internal framework fiber recovery hooks and parent agent-tool recovery scans so startup and recovery work cannot wedge indefinitely.
  • Add shared chat recovery incident tracking with attempt counts, configurable chatRecovery defaults, and terminal exhaustion behavior for AIChatAgent and Think. Think recovery now exhausts after six failed attempts by default and sends a terminal error frame instead of spinning indefinitely.
  • Keep the recovery attempt budget bounded even when an interrupted turn flips between retry and continue recovery kinds (the incident identity no longer includes the kind), guard a throwing onExhausted hook so the terminal UX is still delivered, mark incidents failed when the recovery dispatch throws, and reclaim incident records on success plus a TTL sweep for abandoned ones so durable storage does not grow without bound.
  • Bound generic unmanaged fiber recovery with a configurable fiberRecoveryMaxAgeMs so a repeatedly-throwing onFiberRecovered() hook cannot re-trigger forever across restarts.
  • Surface Think post-persist chat request failures through onChatError(error, ctx) and chat:request:failed.
  • Repair incomplete Think tool-call transcripts before provider calls and allow createCompactFunction() to use a supplied token counter for tail budgeting.

count, so a healthy turn under deploy churn isn't sealed prematurely (#1637).

Under continuous deploys the attempt count is the wrong primary bound: one rollout drops/reconnects the socket several times (~11–22s), each firing a recovery alarm, so the count inflated far faster than the real interruption rate and exhausted turns that were still advancing (0/23 model calls errored in the reported incident — it was pure eviction churn).

Now:

  • Primary bound: a 5-minute no-progress wall clock keyed to lastProgressAt,

which resets on every progress-bearing attempt. A turn that keeps producing content survives churn indefinitely; one that genuinely goes quiet is sealed within 5 minutes.

  • Alarm debounce (~30s): recovery alarms bunched within the window (a single

rollout's reconnect storm) collapse into one attempt.

  • Attempt cap is now a high secondary backstop (default raised 6 → 10),

resets on progress; it only catches a pathological tight alarm-loop.

  • The existing 15-minute absolute incident-age ceiling is kept as the final

non-resetting hard stop.

  • Progress signal moved to production time (when new content is durably

flushed/streamed) instead of persist time — so it advances only on genuinely new content and is immune to client reconnects and recovery re-persists, which the no-progress window depends on. (Builds on the...

Excerpt shown — open the source for the full document.

Notability

notability 4.0/10

Routine package release by Cloudflare, minor version update.