agents 0.17.0 → 0.17.1

package/dist/{agent-tool-types-Cd1TZPfB.d.ts → agent-tool-types-CNyE1iz_.d.ts}

@@ -1,10 +1,10 @@
 import { n as AgentEmail } from "./internal_context-Dg4Cgjcu.js";
-import { t as RetryOptions } from "./retries-CwlpAGet.js";
+import { t as RetryOptions } from "./retries-CvHJwSuh.js";
 import {
   n as Observability,
   r as ObservabilityEvent,
   s as MCPObservabilityEvent
-} from "./index-CcbnKkNh.js";
+} from "./index-BRnybD6X.js";
 import { t as AgentMcpOAuthProvider } from "./do-oauth-client-provider-D4ZwyBDu.js";
 import {
   _ as WorkflowEventPayload,
@@ -2349,6 +2349,15 @@ declare const DEFAULT_AGENT_STATIC_OPTIONS: {
   agentToolReattachMaxWindowMs: number;
   detachedMaxBudgetMs: number;
   detachedNoProgressBudgetMs: number;
+  /**
+   * Consecutive alarm invocations that may end in a Durable Object memory-limit
+   * reset (the isolate exceeded its 128 MB limit) before the alarm-boundary
+   * circuit breaker stops the platform's auto-retry loop and seals the looping
+   * work (#1825). A small budget tolerates a genuinely transient memory spike;
+   * a deterministic OOM (the work's footprint, not the platform, is the cause)
+   * is bounded here regardless of whether the in-DO recovery budgets could run.
+   */
+  maxAlarmMemoryLimitStrikes: number;
 };
 /**
  * Configuration options for the Agent.
@@ -2436,6 +2445,20 @@ interface AgentStaticOptions {
    * `detached: { noProgressBudgetMs }`.
    */
   detachedNoProgressBudgetMs?: number;
+  /**
+   * Consecutive alarm invocations that may end in a Durable Object memory-limit
+   * reset (the isolate exceeded its 128 MB limit) before the alarm-boundary
+   * circuit breaker stops the platform's auto-retry loop and seals the looping
+   * recovery work (#1825). Default: 3. Set to `0` to seal on the first such
+   * reset. This is the universal backstop for the case where the in-DO recovery
+   * budgets (`chatRecovery.maxOomRetries` / `maxRecoveryWork`) can't engage
+   * because the OOM bypasses them — e.g. it is thrown before the budget code
+   * runs, or its own writes also OOM. The boundary handler runs at the outermost
+   * alarm frame, after the heavy turn has unwound and GC has reclaimed its
+   * footprint, so its small seal/purge writes can land where mid-turn writes
+   * could not.
+   */
+  maxAlarmMemoryLimitStrikes?: number;
 }
 declare function getCurrentAgent<
   T extends Agent<Cloudflare.Env> = Agent<Cloudflare.Env>
@@ -3420,6 +3443,66 @@ declare class Agent<
    * See {@link https://developers.cloudflare.com/agents/api-reference/schedule-tasks/}
    */
   alarm(): Promise<void>;
+  /**
+   * The alarm body: PartyServer init + due-schedule processing + housekeeping +
+   * next-alarm arm. Extracted from {@link alarm} so the memory-limit circuit
+   * breaker can wrap it at the outermost frame (see {@link alarm}).
+   */
+  private _cf_runAlarmBody;
+  /**
+   * Durable storage key for the alarm memory-limit strike counter (#1825).
+   */
+  private static readonly _CF_OOM_ALARM_STRIKES_KEY;
+  /**
+   * The schedule row id currently executing in the alarm loop, so the
+   * memory-limit circuit breaker can purge the exact looping row (#1825).
+   * `undefined` outside a callback (e.g. an OOM from `super.alarm()`/onStart).
+   */
+  private _cf_executingScheduleRowId?;
+  /**
+   * The schedule-callback names whose alarm rows drive a recovery loop that can
+   * deterministically OOM. The base agent has none; chat hosts (`Think`,
+   * `AIChatAgent`) override this to return their recovery continuation callbacks
+   * so the circuit breaker can surgically back them off / purge them WITHOUT
+   * disturbing unrelated scheduled tasks. See {@link _cf_handleAlarmMemoryLimitReset}.
+   */
+  protected _cf_recoveryAlarmCallbacks(): string[];
+  /**
+   * Hook for a host to terminalize ("seal") any in-flight recovery work as an
+   * out-of-memory exhaustion when the alarm circuit breaker trips at its strike
+   * budget (#1825). Runs at the outermost alarm frame (post-unwind, so writes
+   * can land). Default: no-op. Chat hosts override to fire `onExhausted` + the
+   * terminal banner and persist the sealed incident.
+   */
+  protected _cf_sealMemoryLimitedRecovery(): Promise<void>;
+  /**
+   * Clear the durable memory-limit strike counter after a clean alarm so the
+   * circuit breaker counts CONSECUTIVE resets rather than lifetime ones
+   * (#1825). Reads first (cheap, usually cached) and only writes when a strike
+   * is actually recorded, so the common no-strike path costs no write.
+   * Best-effort: a stale strike only costs one extra tolerated spike later.
+   */
+  private _cf_clearAlarmMemoryLimitStrikes;
+  /**
+   * Alarm-boundary circuit breaker for Durable Object memory-limit resets
+   * (#1825). The in-DO recovery budgets (`chatRecovery.maxOomRetries` /
+   * `maxRecoveryWork`) only engage if their code runs AND its writes land; a
+   * severe OOM can defeat both — thrown before the budget runs (boot hydration),
+   * or its own small writes also OOM under memory pressure. In that case the
+   * error reaches {@link alarm} and, unhandled, the platform auto-retries the
+   * alarm indefinitely (re-running the doomed, billable turn each cycle).
+   *
+   * This runs at the OUTERMOST frame: the heavy turn has unwound and GC has
+   * reclaimed its footprint, so the small writes here can land where mid-turn
+   * ones (e.g. give-up's incident read) OOMed. A durable strike counter tolerates
+   * a few resets (a transient spike may clear), backing off the recovery rows so
+   * the retry is not a hot loop. At the `maxAlarmMemoryLimitStrikes` budget it
+   * seals the recovery work and purges the looping rows so the loop — and the
+   * bill — stops. Each step is best-effort: even these tiny writes can OOM, but
+   * swallowing (not re-throwing) still halts the platform's auto-retry, and a
+   * later wake re-arms legitimate schedules.
+   */
+  private _cf_handleAlarmMemoryLimitReset;
   /**
    * Intercept incoming HTTP/WS requests whose URL contains a
    * `/sub/{child-class}/{child-name}` marker and forward them to
@@ -5305,4 +5388,4 @@ export {
   EmailRoutingOptions as z,
   ElicitResult$1 as zt
 };
-//# sourceMappingURL=agent-tool-types-Cd1TZPfB.d.ts.map
+//# sourceMappingURL=agent-tool-types-CNyE1iz_.d.ts.map

package/dist/agent-tool-types.d.ts

@@ -24,7 +24,7 @@ import {
   w as RunAgentToolOptions,
   x as ChatCapableAgentClass,
   y as AgentToolStoredChunk
-} from "./agent-tool-types-Cd1TZPfB.js";
+} from "./agent-tool-types-CNyE1iz_.js";
 export {
   AGENT_TOOL_MILESTONE_PART,
   AGENT_TOOL_PROGRESS_PART,

package/dist/{agent-tools-_E8wxUIK.d.ts → agent-tools-CSnyGvJ2.d.ts}

@@ -4,7 +4,7 @@ import {
   o as AgentToolEventMessage,
   s as AgentToolEventState,
   y as AgentToolStoredChunk
-} from "./agent-tool-types-Cd1TZPfB.js";
+} from "./agent-tool-types-CNyE1iz_.js";
 
 //#region src/chat/agent-tools.d.ts
 type AgentToolProgressEmitResult = "emitted" | "coalesced" | "inactive";
@@ -116,4 +116,4 @@ export {
   interceptAgentToolBroadcast as s,
   AgentToolBroadcastHooks as t
 };
-//# sourceMappingURL=agent-tools-_E8wxUIK.d.ts.map
+//# sourceMappingURL=agent-tools-CSnyGvJ2.d.ts.map

package/dist/agent-tools.d.ts

@@ -19,7 +19,7 @@ import {
   w as RunAgentToolOptions,
   x as ChatCapableAgentClass,
   y as AgentToolStoredChunk
-} from "./agent-tool-types-Cd1TZPfB.js";
+} from "./agent-tool-types-CNyE1iz_.js";
 import { Tool } from "ai";
 
 //#region src/agent-tools.d.ts

package/dist/chat/index.d.ts

@@ -4,7 +4,7 @@ import {
   a as AgentToolEvent,
   o as AgentToolEventMessage,
   s as AgentToolEventState
-} from "../agent-tool-types-Cd1TZPfB.js";
+} from "../agent-tool-types-CNyE1iz_.js";
 import {
   n as ClientToolSchema,
   r as createToolsFromClientSchemas,
@@ -18,7 +18,7 @@ import {
   r as AgentToolProgressEmitResult,
   s as interceptAgentToolBroadcast,
   t as AgentToolBroadcastHooks
-} from "../agent-tools-_E8wxUIK.js";
+} from "../agent-tools-CSnyGvJ2.js";
 import { JSONSchema7, UIMessage } from "ai";
 import { Connection } from "agents";
 
@@ -457,6 +457,9 @@ type ChatRecoveryExhaustedContext = Pick<
    * - `work_budget_exceeded` — the turn kept producing content but exceeded the
    *   configured `maxRecoveryWork` runaway-loop budget.
    * - `recovery_aborted` — the caller's `shouldKeepRecovering` hook returned `false`.
+   * - `out_of_memory` — recovery attempts kept hitting a Durable Object
+   *   memory-limit reset (the isolate exceeded its 128 MB limit) until the
+   *   tight `maxOomRetries` budget drained (#1825).
    * - `stable_timeout` — a recovery attempt kept timing out waiting for the
    *   isolate to reach stable state until the budget drained (extreme churn).
    * - `max_recovery_window_exceeded` — DEPRECATED. The old absolute incident-age
@@ -494,7 +497,7 @@ type ChatRecoveryProgressContext = {
 /**
  * Configuration for durable chat recovery. `true` uses these defaults:
  * `maxAttempts: 10`, `stableTimeoutMs: 10_000`, `noProgressTimeoutMs: 300_000`
- * (5 min), `maxRecoveryWork: Infinity`, and a generic terminal message.
+ * (5 min), `maxRecoveryWork: 1000`, and a generic terminal message.
  *
  * **Apply this as a class field or in the constructor — never assign it in
  * `onStart()`.** On every wake the SDK evaluates recovery budgets (and may seal
@@ -522,12 +525,31 @@ type ChatRecoveryConfig =
       /**
        * Runaway-loop guard. Maximum recovery WORK — produced content/tool units
        * since the incident began — before a still-progressing turn is sealed
-       * with `reason="work_budget_exceeded"`. Defaults to `Infinity` (no cap):
-       * the SDK never terminates a progressing turn on its own. Set a finite
-       * value (or use `shouldKeepRecovering`) to bound a loop that keeps
-       * emitting content but never converges.
+       * with `reason="work_budget_exceeded"`. Defaults to `1000`: a generous
+       * backstop that bounds wasted re-run cost when a turn keeps emitting a
+       * little content but never converges (e.g. an isolate that OOMs mid-stream
+       * on every recovery — #1825 — which otherwise resets the attempt cap and
+       * no-progress window forever). Work only accrues from the first
+       * interruption until the turn completes, so a normal interrupted turn
+       * never approaches it. A very long agentic turn under heavy interruption
+       * that legitimately needs more can raise this (or set `Infinity` to
+       * disable the framework cap and bound the runaway via `shouldKeepRecovering`
+       * instead).
        */
       maxRecoveryWork?: number;
+      /**
+       * Tight retry budget for the specific case of a Durable Object isolate
+       * exceeding its memory limit and being reset mid-turn. An OOM is usually
+       * deterministic (the turn's working set no longer fits in 128 MB), so
+       * re-running re-OOMs; but a single OOM can be a transient spike, so
+       * recovery retries this many times before sealing with
+       * `reason="out_of_memory"`. Counts only attempts that ended in an OOM (not
+       * total attempts), so a turn interrupted by deploys is unaffected.
+       * Defaults to `3`. Set `0` to seal on the first OOM. Much tighter than
+       * `maxRecoveryWork` because an OOM is attributable and each re-run is
+       * expensive (it re-runs the model).
+       */
+      maxOomRetries?: number;
       /**
        * Caller policy consulted on each recovery attempt from the second
        * onward — it is NOT called on the first detection (the attempt that
@@ -555,6 +577,7 @@ type ResolvedChatRecoveryConfig = {
   terminalMessage: string;
   noProgressTimeoutMs: number;
   maxRecoveryWork: number;
+  maxOomRetries: number;
   shouldKeepRecovering?: (
     ctx: ChatRecoveryProgressContext
   ) => boolean | Promise<boolean>;
@@ -2094,6 +2117,18 @@ type ChatRecoveryIncident = {
    * from an older build is never falsely sealed.
    */
   workBaseline?: number;
+  /**
+   * Count of recovery attempts for this incident that ended in a Durable Object
+   * memory-limit reset (the isolate exceeded its 128 MB limit — see
+   * `isDurableObjectMemoryLimitReset`). An OOM is a poison signal: re-running the
+   * same memory-heavy turn deterministically re-OOMs, so unlike a deploy/eviction
+   * it must NOT credit forward progress and must be bounded by a tight,
+   * OOM-specific budget (`maxOomRetries`) rather than the generic attempt cap
+   * (which resets on progress). Bumped by `ChatRecoveryEngine.recordOomAndDecide`
+   * when a recovery callback observes an OOM; exceeding `maxOomRetries` seals the
+   * incident with `reason="out_of_memory"` (#1825). Optional for backward-compat.
+   */
+  oomAttempts?: number;
 };
 declare const CHAT_RECOVERY_INCIDENT_KEY_PREFIX = "cf:chat-recovery:incident:";
 /**
@@ -2123,12 +2158,42 @@ declare const CHAT_LAST_TERMINAL_KEY = "cf:chat:last-terminal";
  */
 declare const DEFAULT_CHAT_RECOVERY_MAX_ATTEMPTS = 10;
 /**
- * Runaway-loop guard default. `Infinity` = no SDK-imposed work cap: a turn that
- * keeps making forward progress is never terminated by the framework on its own
- * (rfc-chat-recovery-work-budget). Integrators bound a content-emitting runaway
- * by setting `maxRecoveryWork` or a `shouldKeepRecovering` predicate.
- */
-declare const DEFAULT_CHAT_RECOVERY_MAX_WORK: number;
+ * Runaway-loop guard default — the framework-imposed backstop on cumulative
+ * recovery WORK (produced content/tool units) since an incident opened.
+ *
+ * Originally `Infinity` (rfc-chat-recovery-work-budget): the SDK shipped the
+ * *mechanism* but no default cap, so a progressing turn was never terminated on
+ * its own. Production issue #1825 showed that this is a footgun: an isolate that
+ * OOMs mid-stream still credits a little progress before it dies, which resets
+ * BOTH progress-keyed bounds (the attempt cap and the no-progress window) on
+ * every wake — and a fast crash loop (each attempt inside the alarm-debounce
+ * window) pins the attempt counter too. With `maxRecoveryWork = Infinity` the
+ * ONLY instrument whose meter still climbs across such a loop is disabled, so
+ * recovery re-runs the turn (and its LLM calls) forever.
+ *
+ * A finite default closes that loop out of the box: work climbs regardless of
+ * debounce/progress resets, so a content-emitting runaway is always sealed with
+ * `reason="work_budget_exceeded"`. The value is deliberately generous — it
+ * bounds wasted re-run cost without clipping a normal interrupted turn (work
+ * only accrues from the first interruption until the turn completes, after which
+ * the incident is deleted). A very long agentic turn under heavy interruption
+ * that legitimately needs more should raise `maxRecoveryWork` (or set it to
+ * `Infinity` to restore the pre-#1825 unbounded behavior).
+ */
+declare const DEFAULT_CHAT_RECOVERY_MAX_WORK = 1000;
+/**
+ * Tight, OOM-specific retry budget (#1825). A Durable Object memory-limit reset
+ * (`isDurableObjectMemoryLimitReset`) is usually deterministic — the turn's
+ * working set no longer fits in the isolate's 128 MB — so re-running it re-OOMs.
+ * But a single OOM CAN be a transient spike (the isolate's 128 MB is shared
+ * across the global scope / noisy neighbors), so recovery retries a small number
+ * of times before sealing with `reason="out_of_memory"` rather than abandoning a
+ * turn that one more attempt might have completed. Far tighter than the generic
+ * `maxRecoveryWork` backstop because an OOM is attributable and re-running it is
+ * expensive (it re-runs the model). Counts attempts that ended in an OOM, not
+ * total attempts, so a turn interrupted by deploys (no OOM) is unaffected.
+ */
+declare const DEFAULT_CHAT_RECOVERY_MAX_OOM_RETRIES = 3;
 declare const DEFAULT_CHAT_RECOVERY_STABLE_TIMEOUT_MS = 10000;
 /**
  * Delay before retrying a recovery that timed out waiting for stable state.
@@ -2182,6 +2247,21 @@ declare function sweepStaleChatRecoveryIncidents(
   storage: Pick<DurableObjectStorage, "list" | "delete">,
   now: number
 ): Promise<void>;
+/**
+ * List the persisted recovery incidents that are still live (status
+ * `detected` / `scheduled` / `attempting`) — i.e. NOT yet terminalized
+ * (`exhausted` / `failed`). Used by the alarm-boundary OOM circuit breaker
+ * (#1825) to find the incident(s) it must seal when the in-DO budgets could not.
+ * Lists by the incident key prefix so the storage layout stays encapsulated.
+ */
+declare function listActiveChatRecoveryIncidents(
+  storage: Pick<DurableObjectStorage, "list">
+): Promise<
+  {
+    key: string;
+    incident: ChatRecoveryIncident;
+  }[]
+>;
 /**
  * Summarize a child agent's persisted recovery incidents for the parent's
  * agent-tool reattach decision: `"in-progress"` if any incident is still live
@@ -2794,6 +2874,34 @@ declare class ChatRecoveryEngine {
     data: Record<string, unknown> | undefined;
     fallbackMaxAttempts: number;
   }): Promise<boolean>;
+  /**
+   * Record that a recovery callback observed a Durable Object memory-limit reset
+   * (the isolate exceeded its 128 MB limit — `isDurableObjectMemoryLimitReset`)
+   * and decide what to do next (#1825).
+   *
+   * Bumps the incident's durable `oomAttempts` counter, then:
+   *  - if it is still within `maxOomRetries`, issues a delayed, NON-idempotent
+   *    reschedule of the SAME callback (same machinery as
+   *    {@link rescheduleAfterStableTimeout}: the executing one-shot row is
+   *    deleted only after the callback returns, so an idempotent reschedule
+   *    would dedup onto that doomed row) and returns `"rescheduled"`. The small
+   *    delay lets a transient memory spike clear before the re-run;
+   *  - otherwise leaves the incremented count persisted (so a begin-path
+   *    re-evaluation agrees) and returns `"exhausted"` — the caller then
+   *    terminalizes via the give-up path with `reason="out_of_memory"`.
+   *
+   * Returns `"exhausted"` when there is no incident to track against (no id /
+   * record gone): an OOM we cannot bound must seal rather than loop. Unlike a
+   * stable-state retry this is gated by the OOM-specific budget, NOT the generic
+   * attempt cap — re-running an OOM streams a little "progress" that would
+   * otherwise reset the attempt cap forever (the #1825 loop).
+   */
+  recordOomAndDecide(input: {
+    incidentId: string | undefined;
+    callback: ChatRecoveryScheduleCallback;
+    data: Record<string, unknown> | undefined;
+    maxOomRetries: number;
+  }): Promise<"rescheduled" | "exhausted">;
   /**
    * Give up on a recovery turn whose retry budget drained, terminalizing it so
    * it can never become an eternal spinner (#1645). The shared spine both
@@ -3179,6 +3287,7 @@ export {
   type ContinuationSpec,
   ContinuationState,
   DEFAULT_CHAT_RECOVERY_MAX_ATTEMPTS,
+  DEFAULT_CHAT_RECOVERY_MAX_OOM_RETRIES,
   DEFAULT_CHAT_RECOVERY_MAX_WORK,
   DEFAULT_CHAT_RECOVERY_NO_PROGRESS_TIMEOUT_MS,
   DEFAULT_CHAT_RECOVERY_STABLE_TIMEOUT_MS,
@@ -3254,6 +3363,7 @@ export {
   interceptAgentToolBroadcast,
   isReplayChunk,
   iterateWithStallWatchdog,
+  listActiveChatRecoveryIncidents,
   normalizeToolInput,
   parseProtocolMessage,
   partAwaitsClientInteraction,

package/dist/chat/index.js

@@ -2445,12 +2445,42 @@ const CHAT_LAST_TERMINAL_KEY = "cf:chat:last-terminal";
 */
 const DEFAULT_CHAT_RECOVERY_MAX_ATTEMPTS = 10;
 /**
-* Runaway-loop guard default. `Infinity` = no SDK-imposed work cap: a turn that
-* keeps making forward progress is never terminated by the framework on its own
-* (rfc-chat-recovery-work-budget). Integrators bound a content-emitting runaway
-* by setting `maxRecoveryWork` or a `shouldKeepRecovering` predicate.
-*/
-const DEFAULT_CHAT_RECOVERY_MAX_WORK = Number.POSITIVE_INFINITY;
+* Runaway-loop guard default — the framework-imposed backstop on cumulative
+* recovery WORK (produced content/tool units) since an incident opened.
+*
+* Originally `Infinity` (rfc-chat-recovery-work-budget): the SDK shipped the
+* *mechanism* but no default cap, so a progressing turn was never terminated on
+* its own. Production issue #1825 showed that this is a footgun: an isolate that
+* OOMs mid-stream still credits a little progress before it dies, which resets
+* BOTH progress-keyed bounds (the attempt cap and the no-progress window) on
+* every wake — and a fast crash loop (each attempt inside the alarm-debounce
+* window) pins the attempt counter too. With `maxRecoveryWork = Infinity` the
+* ONLY instrument whose meter still climbs across such a loop is disabled, so
+* recovery re-runs the turn (and its LLM calls) forever.
+*
+* A finite default closes that loop out of the box: work climbs regardless of
+* debounce/progress resets, so a content-emitting runaway is always sealed with
+* `reason="work_budget_exceeded"`. The value is deliberately generous — it
+* bounds wasted re-run cost without clipping a normal interrupted turn (work
+* only accrues from the first interruption until the turn completes, after which
+* the incident is deleted). A very long agentic turn under heavy interruption
+* that legitimately needs more should raise `maxRecoveryWork` (or set it to
+* `Infinity` to restore the pre-#1825 unbounded behavior).
+*/
+const DEFAULT_CHAT_RECOVERY_MAX_WORK = 1e3;
+/**
+* Tight, OOM-specific retry budget (#1825). A Durable Object memory-limit reset
+* (`isDurableObjectMemoryLimitReset`) is usually deterministic — the turn's
+* working set no longer fits in the isolate's 128 MB — so re-running it re-OOMs.
+* But a single OOM CAN be a transient spike (the isolate's 128 MB is shared
+* across the global scope / noisy neighbors), so recovery retries a small number
+* of times before sealing with `reason="out_of_memory"` rather than abandoning a
+* turn that one more attempt might have completed. Far tighter than the generic
+* `maxRecoveryWork` backstop because an OOM is attributable and re-running it is
+* expensive (it re-runs the model). Counts attempts that ended in an OOM, not
+* total attempts, so a turn interrupted by deploys (no OOM) is unaffected.
+*/
+const DEFAULT_CHAT_RECOVERY_MAX_OOM_RETRIES = 3;
 const DEFAULT_CHAT_RECOVERY_STABLE_TIMEOUT_MS = 1e4;
 /**
 * Delay before retrying a recovery that timed out waiting for stable state.
@@ -2497,6 +2527,7 @@ function resolveChatRecoveryConfig(raw) {
 		terminalMessage: custom?.terminalMessage ?? "The assistant was interrupted and could not recover. Please try again.",
 		noProgressTimeoutMs: Math.max(0, Math.floor(custom?.noProgressTimeoutMs ?? 3e5)),
 		maxRecoveryWork: typeof custom?.maxRecoveryWork === "number" && custom.maxRecoveryWork >= 0 ? custom.maxRecoveryWork : DEFAULT_CHAT_RECOVERY_MAX_WORK,
+		maxOomRetries: typeof custom?.maxOomRetries === "number" && custom.maxOomRetries >= 0 ? Math.floor(custom.maxOomRetries) : 3,
 		...custom?.shouldKeepRecovering ? { shouldKeepRecovering: custom.shouldKeepRecovering } : {},
 		...custom?.onExhausted ? { onExhausted: custom.onExhausted } : {}
 	};
@@ -2539,6 +2570,22 @@ async function sweepStaleChatRecoveryIncidents(storage, now) {
 	for (let i = 0; i < staleKeys.length; i += 128) await storage.delete(staleKeys.slice(i, i + 128));
 }
 /**
+* List the persisted recovery incidents that are still live (status
+* `detected` / `scheduled` / `attempting`) — i.e. NOT yet terminalized
+* (`exhausted` / `failed`). Used by the alarm-boundary OOM circuit breaker
+* (#1825) to find the incident(s) it must seal when the in-DO budgets could not.
+* Lists by the incident key prefix so the storage layout stays encapsulated.
+*/
+async function listActiveChatRecoveryIncidents(storage) {
+	const entries = await storage.list({ prefix: CHAT_RECOVERY_INCIDENT_KEY_PREFIX });
+	const active = [];
+	for (const [key, incident] of entries) if (incident && (incident.status === "detected" || incident.status === "scheduled" || incident.status === "attempting")) active.push({
+		key,
+		incident
+	});
+	return active;
+}
+/**
 * Summarize a child agent's persisted recovery incidents for the parent's
 * agent-tool reattach decision: `"in-progress"` if any incident is still live
 * (detected/scheduled/attempting), else `"failed"` if any terminalized
@@ -2725,10 +2772,12 @@ async function evaluateChatRecoveryIncident(input) {
 	const progress = Math.max(prevProgress, currentProgress);
 	const work = progress - workBaseline;
 	const workBudgetExceeded = existing != null && Number.isFinite(config.maxRecoveryWork) && work > config.maxRecoveryWork;
+	const oomAttempts = existing?.oomAttempts ?? 0;
+	const oomBudgetExceeded = existing != null && !awaitingClientInteraction && oomAttempts > config.maxOomRetries;
 	const debounced = existing != null && !madeProgress && now - existing.lastAttemptAt < 3e4;
 	const attempt = madeProgress ? 1 : debounced ? existing?.attempt ?? 1 : (existing?.attempt ?? 0) + 1;
 	let abortedByCaller = false;
-	if (existing != null && !awaitingClientInteraction && config.shouldKeepRecovering && !noProgressExceeded && !workBudgetExceeded && attempt <= config.maxAttempts) try {
+	if (existing != null && !awaitingClientInteraction && config.shouldKeepRecovering && !noProgressExceeded && !workBudgetExceeded && !oomBudgetExceeded && attempt <= config.maxAttempts) try {
 		const ctx = {
 			incidentId,
 			requestId: identity.requestId,
@@ -2743,7 +2792,7 @@ async function evaluateChatRecoveryIncident(input) {
 	} catch (error) {
 		input.onShouldKeepRecoveringError?.(error);
 	}
-	const exhausted = !awaitingClientInteraction && (noProgressExceeded || workBudgetExceeded || abortedByCaller || attempt > config.maxAttempts);
+	const exhausted = !awaitingClientInteraction && (oomBudgetExceeded || noProgressExceeded || workBudgetExceeded || abortedByCaller || attempt > config.maxAttempts);
 	const incident = {
 		incidentId,
 		requestId: identity.requestId,
@@ -2757,7 +2806,8 @@ async function evaluateChatRecoveryIncident(input) {
 		lastProgressAt,
 		progress,
 		workBaseline,
-		...exhausted ? { reason: workBudgetExceeded ? "work_budget_exceeded" : noProgressExceeded ? "no_progress_timeout" : abortedByCaller ? "recovery_aborted" : "max_attempts_exceeded" } : {}
+		...oomAttempts > 0 ? { oomAttempts } : {},
+		...exhausted ? { reason: oomBudgetExceeded ? "out_of_memory" : workBudgetExceeded ? "work_budget_exceeded" : noProgressExceeded ? "no_progress_timeout" : abortedByCaller ? "recovery_aborted" : "max_attempts_exceeded" } : {}
 	};
 	const events = [];
 	if (!existing) events.push({
@@ -3031,6 +3081,54 @@ var ChatRecoveryEngine = class {
 		return true;
 	}
 	/**
+	* Record that a recovery callback observed a Durable Object memory-limit reset
+	* (the isolate exceeded its 128 MB limit — `isDurableObjectMemoryLimitReset`)
+	* and decide what to do next (#1825).
+	*
+	* Bumps the incident's durable `oomAttempts` counter, then:
+	*  - if it is still within `maxOomRetries`, issues a delayed, NON-idempotent
+	*    reschedule of the SAME callback (same machinery as
+	*    {@link rescheduleAfterStableTimeout}: the executing one-shot row is
+	*    deleted only after the callback returns, so an idempotent reschedule
+	*    would dedup onto that doomed row) and returns `"rescheduled"`. The small
+	*    delay lets a transient memory spike clear before the re-run;
+	*  - otherwise leaves the incremented count persisted (so a begin-path
+	*    re-evaluation agrees) and returns `"exhausted"` — the caller then
+	*    terminalizes via the give-up path with `reason="out_of_memory"`.
+	*
+	* Returns `"exhausted"` when there is no incident to track against (no id /
+	* record gone): an OOM we cannot bound must seal rather than loop. Unlike a
+	* stable-state retry this is gated by the OOM-specific budget, NOT the generic
+	* attempt cap — re-running an OOM streams a little "progress" that would
+	* otherwise reset the attempt cap forever (the #1825 loop).
+	*/
+	async recordOomAndDecide(input) {
+		const { adapter } = this;
+		if (!input.incidentId) return "exhausted";
+		const key = chatRecoveryIncidentKey(input.incidentId);
+		const incident = await adapter.getIncident(key);
+		if (!incident) return "exhausted";
+		const oomAttempts = (incident.oomAttempts ?? 0) + 1;
+		if (oomAttempts > input.maxOomRetries) {
+			await adapter.putIncident(key, {
+				...incident,
+				oomAttempts,
+				lastAttemptAt: adapter.now(),
+				reason: "out_of_memory"
+			});
+			return "exhausted";
+		}
+		await adapter.putIncident(key, {
+			...incident,
+			oomAttempts,
+			status: "scheduled",
+			lastAttemptAt: adapter.now(),
+			reason: "oom_retry"
+		});
+		await adapter.scheduleRecovery(input.callback, input.data ?? {}, "stable_timeout_retry", 3);
+		return "rescheduled";
+	}
+	/**
 	* Give up on a recovery turn whose retry budget drained, terminalizing it so
 	* it can never become an eternal spinner (#1645). The shared spine both
 	* packages repeated verbatim:
@@ -3305,6 +3403,6 @@ async function* iterateWithStallWatchdog(source, timeoutMs, onStall) {
 	}
 }
 //#endregion
-export { AGENT_TOOL_STREAM_PROGRESS_BUMP_THROTTLE_MS, AbortRegistry, AgentToolProgressEmitter, AgentToolStreamProgressThrottle, AutoContinuationController, CHAT_LAST_TERMINAL_KEY, CHAT_MESSAGE_TYPES, CHAT_RECOVERING_FLAG_TTL_MS, CHAT_RECOVERING_KEY, CHAT_RECOVERY_ALARM_DEBOUNCE_MS, CHAT_RECOVERY_INCIDENT_KEY_PREFIX, CHAT_RECOVERY_INCIDENT_TTL_MS, CHAT_RECOVERY_PROGRESS_KEY, CHAT_RECOVERY_STABLE_RETRY_DELAY_SECONDS, CHAT_STREAM_PROGRESS_CREDIT_THROTTLE_MS, ChatRecoveryEngine, ChatStreamStalledError, ContinuationState, DEFAULT_CHAT_RECOVERY_MAX_ATTEMPTS, DEFAULT_CHAT_RECOVERY_MAX_WORK, DEFAULT_CHAT_RECOVERY_NO_PROGRESS_TIMEOUT_MS, DEFAULT_CHAT_RECOVERY_STABLE_TIMEOUT_MS, DEFAULT_CHAT_RECOVERY_TERMINAL_MESSAGE, KV_DELETE_MAX_KEYS, MAX_BOUND_PARAMS, MessageType, PreStreamTurns, ROW_MAX_BYTES, ResumableStream, ResumeHandshake, STREAM_CLEANUP_DELAY_SECONDS, StreamAccumulator, StreamProgressCreditThrottle, SubmitConcurrencyController, TIMED_OUT, TurnQueue, aiSdkRecoveryCodec, applyAgentToolEvent, applyChunkToParts, applyToolUpdate, awaitWithDeadline, transition as broadcastTransition, buildChatRecoveringFrame, buildInClauseStrings, bumpChatRecoveryProgress, byteLength, chatRecoverySchedulePolicy, classifyAgentToolChildRecovery, cleanupStreamBuffers, clearChatTerminal, clientResolvableToolNames, createAgentToolEventState, createChatFiberSnapshot, createToolsFromClientSchemas, crossMessageToolResultUpdate, drainInteractionApplies, enforceRowSizeLimit, hasIncompleteToolBatch, interceptAgentToolBroadcast, isReplayChunk, iterateWithStallWatchdog, normalizeToolInput, parseProtocolMessage, partAwaitsClientInteraction, pausedExecutionUpdate, pendingChatTerminal, persistReconstructedOrphan, readChatRecoveryProgress, reconcileMessages, reconcileOrphanPartial, recordChatTerminal, repairInterruptedToolParts, resolveChatRecoveryConfig, resolveToolMergeId, runChatRecoveryExhaustion, sanitizeMessage, sendIfOpen, setChatRecovering, shouldCreditStreamProgress, sweepStaleChatRecoveryIncidents, toolApprovalUpdate, toolPartHasSettledResult, toolResultUpdate, unwrapChatFiberSnapshot, wrapChatFiberSnapshot };
+export { AGENT_TOOL_STREAM_PROGRESS_BUMP_THROTTLE_MS, AbortRegistry, AgentToolProgressEmitter, AgentToolStreamProgressThrottle, AutoContinuationController, CHAT_LAST_TERMINAL_KEY, CHAT_MESSAGE_TYPES, CHAT_RECOVERING_FLAG_TTL_MS, CHAT_RECOVERING_KEY, CHAT_RECOVERY_ALARM_DEBOUNCE_MS, CHAT_RECOVERY_INCIDENT_KEY_PREFIX, CHAT_RECOVERY_INCIDENT_TTL_MS, CHAT_RECOVERY_PROGRESS_KEY, CHAT_RECOVERY_STABLE_RETRY_DELAY_SECONDS, CHAT_STREAM_PROGRESS_CREDIT_THROTTLE_MS, ChatRecoveryEngine, ChatStreamStalledError, ContinuationState, DEFAULT_CHAT_RECOVERY_MAX_ATTEMPTS, DEFAULT_CHAT_RECOVERY_MAX_OOM_RETRIES, DEFAULT_CHAT_RECOVERY_MAX_WORK, DEFAULT_CHAT_RECOVERY_NO_PROGRESS_TIMEOUT_MS, DEFAULT_CHAT_RECOVERY_STABLE_TIMEOUT_MS, DEFAULT_CHAT_RECOVERY_TERMINAL_MESSAGE, KV_DELETE_MAX_KEYS, MAX_BOUND_PARAMS, MessageType, PreStreamTurns, ROW_MAX_BYTES, ResumableStream, ResumeHandshake, STREAM_CLEANUP_DELAY_SECONDS, StreamAccumulator, StreamProgressCreditThrottle, SubmitConcurrencyController, TIMED_OUT, TurnQueue, aiSdkRecoveryCodec, applyAgentToolEvent, applyChunkToParts, applyToolUpdate, awaitWithDeadline, transition as broadcastTransition, buildChatRecoveringFrame, buildInClauseStrings, bumpChatRecoveryProgress, byteLength, chatRecoverySchedulePolicy, classifyAgentToolChildRecovery, cleanupStreamBuffers, clearChatTerminal, clientResolvableToolNames, createAgentToolEventState, createChatFiberSnapshot, createToolsFromClientSchemas, crossMessageToolResultUpdate, drainInteractionApplies, enforceRowSizeLimit, hasIncompleteToolBatch, interceptAgentToolBroadcast, isReplayChunk, iterateWithStallWatchdog, listActiveChatRecoveryIncidents, normalizeToolInput, parseProtocolMessage, partAwaitsClientInteraction, pausedExecutionUpdate, pendingChatTerminal, persistReconstructedOrphan, readChatRecoveryProgress, reconcileMessages, reconcileOrphanPartial, recordChatTerminal, repairInterruptedToolParts, resolveChatRecoveryConfig, resolveToolMergeId, runChatRecoveryExhaustion, sanitizeMessage, sendIfOpen, setChatRecovering, shouldCreditStreamProgress, sweepStaleChatRecoveryIncidents, toolApprovalUpdate, toolPartHasSettledResult, toolResultUpdate, unwrapChatFiberSnapshot, wrapChatFiberSnapshot };
 
 //# sourceMappingURL=index.js.map