Add support for "stop_reason": "pause_turn" on Anthropic models

[Slava-256]

What's happening?

When a lot of server tools are used on with Anthropic models (web_search and web_fetch are server tools), Antropic API may return "stop_reason": "pause_turn" to indicate that the response is incomplete and that a new request needs to be submitted to continue. See https://platform.claude.com/docs/en/build-with-claude/handling-stop-reasons#pause-turn

To continue, the response needs to be added to the original user message (and previous responses if more than one pause_turn was encountered) and submitted back to the API. You are basically accumulating all the "content" blocks from the initial request and all of the turns.

You also need to transfer "container" id from the response to a new request, so that Anthropic would know which container on their servers contains work performed in previous turns. Note that the format of container id is different in the response compared to how it needs to be submitted in the request. See the script example below.

I generated a standalone example that reliably generates multiple turns in responses. It requires "web_search_20260209" and "web_fetch_20260209", with "max_uses": 50 set for both, and can be reproduced on claude-sonnet-4-6 running with adaptive thinking and "effort": "high".

System prompt:

Current date: Tue, Mar 3, 2026, 06 PM PST
Data presentation: prefer tables (auto-columns)

<role>
You are an expert research analyst conducting exhaustive, multi-source investigations. Your mission is to produce the most comprehensive, well-sourced findings achievable on any research query. Thoroughness and accuracy are your paramount values — cost and time are not constraints. Explore every reasonable avenue of investigation, going beyond the obvious and surface-level. Your existing knowledge helps you formulate better queries and evaluate what you find, but the deliverable is what your investigation surfaces — discovered, citable, verifiable sources and evidence. Even on familiar topics, systematic investigation surfaces sources, terminology, and connections that weren't apparent before searching — what you discover should extend meaningfully beyond what you could have produced from memory alone. The people relying on your research are making decisions where missing information has real consequences.
</role>

<search_strategy>
Treat every research task as a multi-round investigation — parallel queries within a round provide breadth, but comprehensive research requires sequential rounds where what you learned in earlier rounds genuinely shapes what you search for next.

Plan before searching. Decompose the research question into its constituent sub-questions and dimensions. Identify what types of evidence would constitute a complete answer, and determine which sub-questions can be explored in parallel versus which depend on earlier findings. A clear plan organizes the search space and prevents anchoring on the first results you find. Structure the investigation in phases — an initial reconnaissance to map the landscape, followed by targeted rounds pursuing leads, terminology, and angles that earlier results reveal. The most valuable follow-up queries are ones you couldn't have written before seeing initial results — treat the plan as a living framework, not a fixed script.

Start broad, then progressively narrow. Begin each area of inquiry with broad queries across multiple angles to survey the information landscape. Treat these first searches as reconnaissance — they map the terrain, reveal key terminology and major sources, and show what's available, but they are the beginning of the investigation, not the investigation itself. The real investigative depth comes in subsequent rounds, when you can search with the specific terminology, source names, and angles that initial results revealed. Explore across diverse source types, communities, and perspectives rather than fixating on early results.

Go deep on what matters. Read sources in full when they appear relevant — they reveal references, terminology, and arguments that search previews compress away. When reading, focus on extracting what fuels the investigation: key findings, cited works to trace, and terminology to search for. The investigation's depth compounds through source reading — each source generates references, terminology, and connections that open new search avenues, making subsequent rounds progressively richer as they build on accumulated leads from everything read before. When a source references something significant, trace it to the primary source — and when a primary source proves important, look for who has built on it since. Follow promising chains through multiple levels and mine bibliographies for leads — distinctive sources often sit several links deep, discoverable only through citation networks rather than keyword searches. When you find a particularly valuable source, explore its neighborhood: what else the author has written, what other works cite it, what adjacent works exist in the same tradition. When a finding seems important, seek corroboration from at least one independent source. When a finding seems surprising or contested, actively seek counterpoints and disconfirming evidence. Secondary sources compress and sometimes distort; primary sources settle disputes.

Evaluate and iterate between rounds. After each round of searching, pause to assess what you've gathered against your research plan. Focus on what the investigation has opened up but not yet explored — promising references not yet traced, perspectives not yet represented, claims resting on a single source — and what new questions, terminology, or leads emerged from your results. This keeps the investigation directed toward what's missing rather than anchored to what's found. Use this assessment to plan your next round — targeting gaps, following new leads, and approaching under-covered areas from different angles. Continue this cycle of searching, evaluating, and searching again until the completion criteria are genuinely met.

Push past surface convergence. The investigation naturally progresses through layers of depth, each accessing material the previous layer structurally cannot reach. When keyword-driven approaches begin to converge — varied phrasings returning material you've already encountered — this is surface convergence: the signal that the investigation's most distinctive phase is ready to begin, not that it's complete. Shift to the techniques that access deeper layers: trace citation chains from your strongest sources through multiple levels, where each level reveals sources the previous couldn't reach; mine bibliographies and reference lists for works that no keyword search would surface; investigate how the topic appears in unexpected fields and traditions; and search for critiques and challenges to the emerging picture. These techniques are iterative — each source traced reveals new references worth following, each cross-domain exploration opens new vocabulary to search with. The most surprising and distinctive discoveries consistently emerge from this phase. Surface convergence marks where it begins.

As you cycle through subsequent rounds, diversify your query approaches. Rotate through different phrasings: synonyms, related concepts, alternative terminology. Shift perspectives — approach the topic from different disciplines, stakeholder viewpoints, or levels of abstraction. Explore adjacent communities that might discuss the topic under different vocabulary. When the primary domain has been well-explored, deliberately investigate how the topic appears in unexpected fields — different academic disciplines, cultural traditions, or historical periods. Let terms discovered in earlier searches seed new queries; titles and terminology in found sources often reveal phrasings you hadn't considered. When a line of inquiry yields diminishing returns, step back and reframe the approach rather than repeating similar queries. After each reformulation cycle, verify that expanded queries still serve the original research question — breadth should illuminate the question, not drift from it.
</search_strategy>

<reasoning_discipline>
Throughout your thinking, periodically challenge your own conclusions using these reflective checkpoints, each targeting a distinct failure mode:

"Well, have I fully considered the nuances here?" — check for completeness and missing dimensions.

"Wait — what am I missing or oversimplifying?" — check for errors, unjustified leaps, and unstated assumptions.

"Hmm, let me reconsider this from a different angle." — check for alternative interpretations or overlooked perspectives.

"But does this actually hold up under scrutiny?" — stress-test conclusions against counterevidence.

"Let me verify — is this consistent with everything above?" — audit internal coherence across your reasoning.

Each time you pause, look for specific gaps, name specific assumptions, and propose specific alternatives — substantive reflection that identifies concrete issues, not a surface-level confirmation that things look fine. Reasoning that felt easy deserves extra scrutiny; it may have been shallow.

Scale the depth of self-reflection to the complexity of what you are examining — brief checks for straightforward items, deeper cycles for ambiguous or high-stakes findings. Refine your thinking before moving on.

Ground your conclusions in retrieved evidence. When making a claim, it should be traceable to a source found during the investigation, not assumed from background knowledge.
</reasoning_discipline>

<source_evaluation>
Prefer primary sources over secondary summaries — when a summary references an original study, document, or dataset, trace to the original. Favor authoritative, domain-specific sources such as official documentation, peer-reviewed research, recognized experts, and institutional publications over generic aggregators or SEO-optimized content. When sources conflict, treat the disagreement as a valuable signal worth investigating rather than a problem to sidestep. Assess recency contextually: for rapidly evolving topics, recent sources may supersede older ones; for stable knowledge, foundational works remain authoritative. Distinguish between established consensus, emerging findings, and speculation.
</source_evaluation>

<completion_criteria>
Before beginning your synthesis, test your findings: did the investigation surface sources, perspectives, and connections you genuinely wouldn't have found from memory alone? Were later searches shaped by what earlier results revealed — queries you couldn't have written before searching? Can you identify specific productive avenues you haven't pursued — citation chains worth following, bibliographies worth mining, cross-domain angles worth exploring, sources worth reading in full? If the first two tests aren't clearly satisfied, or if concrete next steps are readily apparent, the investigation has remaining depth. Return to the evaluate-and-iterate cycle before synthesizing.

Continue researching until you are genuinely confident that additional effort would not materially improve the findings. The research is ready for synthesis when these signals converge — assessed based on what your searches actually returned, not what you already know from training data:

- The major dimensions and sub-questions have been explored from multiple angles.
- Key claims are supported by two or more independent sources where achievable.
- Recent searches across genuinely different methods — keyword searching, deep source reading, citation tracing, and cross-domain exploration, each substantively exercised — are returning information already encountered rather than meaningfully new material. If any of these techniques has been used only in passing, apparent convergence may reflect the limits of the approach rather than the topic.
- Key sources identified during the investigation have been read in depth — their references, terminology, and core arguments extracted — not merely found in search results.
- Conflicting information has been investigated and either resolved or explicitly documented as contested.
- If information that a knowledgeable person would expect to find is absent, this has been noted and investigated — distinguishing "not yet found" from "likely does not exist."
- The investigation has surfaced a meaningful body of non-obvious findings — sources, perspectives, or connections you didn't anticipate. A single surprising find amid otherwise predictable results suggests the investigation has touched the edge of deeper territory, not reached its center.

If a sub-question has been explored from only one angle, that is not yet sufficient. If a new dimension emerges during research, follow it rather than treating the original plan as fixed. When uncertain whether coverage is sufficient, err toward one more search pass.
</completion_criteria>

<output_standards>
Ground every factual claim in retrieved evidence and cite sources so the user can verify. Distinguish clearly between well-established findings supported by multiple sources, emerging or tentative findings with limited evidence, and open questions where information is insufficient or contradictory. When sources conflict, present both perspectives with context on the strength of evidence for each. Explicitly acknowledge areas where the search was unable to find adequate information — gaps are valuable findings. Organize your response to serve the user's actual question.
</output_standards>

User prompt:

Research this extensively across multiple rounds. Use what you find to guide deeper follow-up searches. I need specific discovered sources I can go read myself, and your synthesis — grounded in what you discover, not what you already knew.

I am looking for references on algorithms to generate prime numbers.

Python script example:

#!/usr/bin/env python3
"""Call Anthropic API with system/user prompt files and save the JSON response."""

import argparse
import json
import os
import sys
import time
from concurrent.futures import ThreadPoolExecutor, as_completed
from pathlib import Path

import requests

API_URL = "https://api.anthropic.com/v1/messages"
API_VERSION = "2023-06-01"
REQUEST_TIMEOUT = 1800  # 30 minutes; max-effort + 128k output + web tools can be slow
NUM_ATTEMPTS = 5
MAX_CONTINUATIONS = 10

OMITTED = "<value omitted>"
_REDACT_IF_TYPE = {
    "id": {"message", "server_tool_use"},
    "signature": {"thinking"},
    "tool_use_id": {"web_search_tool_result", "web_fetch_tool_result"},
}

STAT_NAMES = (
    "thinking iterations",
    "server_tool_use iterations",
    "web_search count",
    "web_fetch count",
    "web_search_result count",
    "web_fetch_result count",
    "citations count",
)

_TOOL_USE_BLOCK_TYPES = {
    "server_tool_use",
    "web_search_tool_result",
    "web_fetch_tool_result",
    "code_execution_tool_result",
}


def sanitize_response(data):
    """Redact opaque/internal field values from the API response."""
    if isinstance(data, dict):
        obj_type = data.get("type")
        return {
            k: OMITTED
            if k.startswith("encrypted_") or obj_type in _REDACT_IF_TYPE.get(k, ())
            else sanitize_response(v)
            for k, v in data.items()
        }
    if isinstance(data, list):
        return [sanitize_response(item) for item in data]
    return data


def collect_stats(content):
    """Collect response statistics from the top-level content blocks."""
    thinking_count = 0
    tool_use_sequences = 0
    in_tool_use = False
    web_search_count = 0
    web_fetch_count = 0
    search_result_count = 0
    fetch_result_count = 0
    citation_count = 0

    for block in content:
        block_type = block.get("type")

        if block_type == "thinking":
            thinking_count += 1

        if block_type in _TOOL_USE_BLOCK_TYPES:
            if not in_tool_use:
                tool_use_sequences += 1
                in_tool_use = True
        else:
            in_tool_use = False

        if block_type == "server_tool_use":
            if block.get("name") == "web_search":
                web_search_count += 1
            elif block.get("name") == "web_fetch":
                web_fetch_count += 1

        if block_type == "web_search_tool_result":
            for item in block.get("content", []):
                if isinstance(item, dict) and item.get("type") == "web_search_result":
                    search_result_count += 1

        if block_type == "web_fetch_tool_result":
            fetch_result_count += 1

        citation_count += len(block.get("citations", []))

    return (
        thinking_count,
        tool_use_sequences,
        web_search_count,
        web_fetch_count,
        search_result_count,
        fetch_result_count,
        citation_count,
    )


def aggregate_stats(stats_list):
    """Sum per-turn stats tuples element-wise."""
    return tuple(sum(s[i] for s in stats_list) for i in range(len(STAT_NAMES)))


def format_stats_line(stats):
    """Format a stats tuple into a comma-separated report line."""
    return ", ".join(f"{name}: {value}" for name, value in zip(STAT_NAMES, stats))


def build_output_path(base_output, attempt_index, turn_index):
    """Build output path with attempt and optional turn index."""
    p = Path(base_output)
    if turn_index == 0:
        return str(p.with_name(f"{p.stem}_{attempt_index}{p.suffix}"))
    return str(p.with_name(f"{p.stem}_{attempt_index}_turn_{turn_index}{p.suffix}"))


def run_attempt(index, headers, body, base_output):
    """Execute API calls for one attempt, continuing on pause_turn."""
    t0 = time.monotonic()
    current_body = body
    per_turn_stats = []
    accumulated_content = []  # all turns' raw content, grown across continuations

    for turn in range(MAX_CONTINUATIONS + 1):
        try:
            response = requests.post(
                API_URL, headers=headers, json=current_body, timeout=REQUEST_TIMEOUT
            )
        except requests.exceptions.RequestException as exc:
            elapsed = time.monotonic() - t0
            return index, None, elapsed, None, str(exc)

        if not response.ok:
            elapsed = time.monotonic() - t0
            return index, None, elapsed, response.status_code, response.text

        data = response.json()
        raw_content = data.get("content", [])
        accumulated_content.extend(raw_content)

        # Save sanitized response for this turn
        output_path = build_output_path(base_output, index, turn)
        with open(output_path, "w") as f:
            json.dump(sanitize_response(data), f, indent=2)

        per_turn_stats.append(collect_stats(raw_content))

        if data.get("stop_reason") != "pause_turn":
            break

        # Continue: accumulated content keeps all server_tool_use/result pairs intact
        current_body = {**body}
        current_body["messages"] = [
            body["messages"][0],
            {"role": "assistant", "content": accumulated_content},
        ]

        # Preserve container for code execution continuations (API expects plain string)
        container = data.get("container")
        if container:
            container_id = (
                container.get("id") if isinstance(container, dict) else container
            )
            current_body["container"] = container_id

    elapsed = time.monotonic() - t0
    return index, aggregate_stats(per_turn_stats), elapsed, response.status_code, None


def main():
    parser = argparse.ArgumentParser(
        description="Call Anthropic API with system and user prompt files."
    )
    parser.add_argument("--system", required=True, help="Path to system prompt file")
    parser.add_argument("--user", required=True, help="Path to user prompt file")
    parser.add_argument("--output", required=True, help="Path to output JSON file")
    parser.add_argument(
        "--web_tool_2026",
        action="store_true",
        help="Use 2026 web tool versions (web_search_20260209, web_fetch_20260209)",
    )
    args = parser.parse_args()

    api_key = os.environ.get("ANTHROPIC_API_KEY")
    if not api_key:
        print(
            "Error: ANTHROPIC_API_KEY environment variable is not set",
            file=sys.stderr,
        )
        sys.exit(1)

    with open(args.system, "r") as f:
        system_prompt = f.read()

    with open(args.user, "r") as f:
        user_prompt = f.read()

    if args.web_tool_2026:
        web_search_type = "web_search_20260209"
        web_fetch_type = "web_fetch_20260209"
        beta_features = "context-1m-2025-08-07"
    else:
        web_search_type = "web_search_20250305"
        web_fetch_type = "web_fetch_20250910"
        beta_features = "web-fetch-2025-09-10,context-1m-2025-08-07"

    headers = {
        "x-api-key": api_key,
        "anthropic-version": API_VERSION,
        "anthropic-beta": beta_features,
        "content-type": "application/json",
    }

    body = {
        "max_tokens": 128000,
        "model": "claude-sonnet-4-6",
        "system": [
            {
                "cache_control": {"type": "ephemeral"},
                "type": "text",
                "text": system_prompt,
            }
        ],
        "messages": [
            {
                "role": "user",
                "content": [
                    {
                        "cache_control": {"type": "ephemeral"},
                        "type": "text",
                        "text": user_prompt,
                    }
                ],
            }
        ],
        "tools": [
            {
                "name": "web_search",
                "type": web_search_type,
                "max_uses": 50,
            },
            {
                "name": "web_fetch",
                "type": web_fetch_type,
                "citations": {"enabled": True},
                "max_uses": 50,
            },
        ],
        "thinking": {"type": "adaptive"},
        "output_config": {"effort": "high"},
    }

    results = []
    with ThreadPoolExecutor(max_workers=NUM_ATTEMPTS) as executor:
        futures = {}
        for i in range(NUM_ATTEMPTS):
            future = executor.submit(run_attempt, i, headers, body, args.output)
            futures[future] = i

        for future in as_completed(futures):
            results.append(future.result())

    results.sort(key=lambda r: r[0])

    all_stats = []
    elapsed_times = []
    for index, stats, elapsed, status_code, error_text in results:
        if stats is None:
            print(
                f"Error{f' {status_code}' if status_code else ''}: {error_text}",
                file=sys.stderr,
            )
        else:
            all_stats.append(stats)
            elapsed_times.append(elapsed)
            print(format_stats_line(stats))

    if all_stats:
        n = len(all_stats)
        print()
        for i, name in enumerate(STAT_NAMES):
            avg = sum(s[i] for s in all_stats) / n
            print(f"Average {name}: {avg:.2f}")
        print(f"Average response time: {sum(elapsed_times) / n:.2f}s")


if __name__ == "__main__":
    main()

Command line to run the script:

python call_anthropic.py --system system.txt --user user.txt --web_tool_2026 --output result.txt

The script launches 5 parallel requests.
In my testing, out of the 5 requests, 3 requests required 2 turns to complete, and 2 required 3 turns to complete.

Where does this happen?

Big-AGI Pro (big-agi.com)

Impact on your workflow

Medium - Workaround exists

Environment (if applicable)

No response

Additional context

No response

[github-actions]

Thanks for the detailed report with the standalone reproduction script — very helpful.

Assessment

This is a valid feature request. The pause_turn stop reason occurs when Anthropic's server-side sampling loop hits its iteration limit (default 10 iterations) while executing server tools like web_search and web_fetch. When this happens, the client must continue the conversation by sending back the accumulated content and making another API request.

Current State in Codebase

The codebase already has partial support for pause_turn:

1. Wire types (src/modules/aix/server/dispatch/wiretypes/anthropic.wiretypes.ts): pause_turn is included in the StopReason_schema ✅
2. Parser (src/modules/aix/server/dispatch/chatGenerate/parsers/anthropic.parser.ts L927-957): Maps pause_turn → ok-pause_continue ✅
3. AIX wire types (src/modules/aix/server/api/aix.wiretypes.ts): ok-pause_continue exists in GCTokenStopReason ✅
4. ContentReassembler (src/modules/aix/client/ContentReassembler.ts L695): Maps ok-pause_continue → undefined (normal completion) — no continuation logic ❌
5. Container support: Container is already parsed from responses and supported in request building ✅

What's Missing: The Continuation Loop

When stop_reason: "pause_turn" is received, there's no mechanism to:

1. Accumulate the raw Anthropic content blocks from the response
2. Build a continuation request with messages: [original_user_message, { role: "assistant", content: accumulated_content }]
3. Pass the container ID (extracted as a string from the response object { id: "..." })
4. Make another streaming API call and continue yielding particles to the client
5. Repeat until a non-pause_turn stop reason is received

Recommended Implementation: Server-Side Continuation

The cleanest architecture would be server-side continuation in the dispatch/executor layer, for several reasons:

• Raw content blocks are available before being transformed to particles — needed to send back to Anthropic
• Container ID is already parsed from the response (anthropic.parser.ts L131-135)
• Original request parameters (model, tools, system, etc.) are available in the dispatch creator
• Transparent to the client — particles continue streaming seamlessly across continuation turns
• Follows the existing retry pattern in chatGenerate.retrier.ts — similar loop-and-continue architecture

Sketch of the approach:

The server-side executor/retrier layer would need a new continuation mechanism:

1. In the Anthropic parser: When pause_turn is received, capture and store the raw accumulated content blocks and container ID (these are already available during parsing)
2. New continuation signal: Similar to RequestRetryError, introduce a PauseTurnContinuation that carries the accumulated content and container ID
3. In the executor/retrier: Catch the continuation signal, build a new dispatch with:
   • Same model, tools, and system prompt
   • Modified messages: [original_user, { role: "assistant", content: accumulated_blocks }]
   • container: container_id (string, extracted from the response object)
4. Stream stitching: Continue yielding particles from the continuation request without clearing the reassembler (no retry-reset) — just seamlessly append
5. Safety cap: Limit continuations (e.g., max 10) to prevent infinite loops

Key challenge: The raw Anthropic content blocks must be preserved through the parser → executor path. The parser currently transforms them into particles and discards the originals. A mechanism to accumulate and forward the raw blocks is needed.

Alternative: The parser itself could handle multi-turn stacking

A simpler but less clean approach: give the Anthropic parser access to the request builder and have it internally detect pause_turn, rebuild the request, make another fetch, and continue parsing — all within a single dispatch. This avoids needing to propagate raw blocks through the executor but violates separation of concerns.

Workaround for Users

Currently, when pause_turn triggers, the response will appear complete (since ok-pause_continue maps to normal completion). The user sees partial results without an error indicator, but the server-side tool processing is incomplete. There's no user-facing workaround within big-AGI — the continuation must be implemented in the application.

Priority Considerations

This will become increasingly important as:

• Anthropic server tools (web_search, web_fetch) see more adoption
• Higher max_uses values increase the likelihood of hitting the iteration limit
• Skills/container workflows involve more complex multi-step server-side execution

[enricoros]

@claude Please proceed with the proposed approach and prototype/productionize the server-side continuation.

[claude]

Claude finished @enricoros's task in 7m 14s —— View job • claude/issue-1010-20260304-2246 • Create PR ➔

---

Implementing server-side pause_turn continuation for Anthropic models

Resolves #1010

• Gather context - explore current AIX dispatch architecture
• Read key files in detail for implementation
• Implement PauseTurnContinuation error class in retrier
• Implement continuation loop in the retrier layer
• Modify Anthropic streaming parser to throw PauseTurnContinuation on pause_turn
• Modify Anthropic non-streaming parser for pause_turn
• Pass-through PauseTurnContinuation in executor (streaming + non-streaming)
• Validate with type checking and linting
• Commit and push changes

Summary

Implemented server-side continuation for Anthropic's pause_turn stop reason. When Anthropic server tools (web_search, web_fetch, Skills) exhaust the iteration limit and return stop_reason: "pause_turn", the server now automatically re-dispatches with accumulated content blocks and container ID - streaming particles seamlessly to the client across continuation turns.

3 files changed (+116, -8):

1. chatGenerate.retrier.ts - Added PauseTurnContinuation error class carrying accumulated raw content blocks + container ID. Extended the retrier loop to catch it, build a continuation dispatch (modified messages with original user message + accumulated assistant content, plus container ID string), and re-dispatch. Safety cap of 10 max continuations.

2. anthropic.parser.ts - Both streaming and non-streaming parsers now detect pause_turn and throw PauseTurnContinuation with responseMessage.content (raw Anthropic content blocks already accumulated during parsing) and container.id.

3. chatGenerate.executor.ts - Added PauseTurnContinuation pass-through in both streaming and non-streaming consumer catch blocks, alongside the existing RequestRetryError pass-through.

Architecture: The approach follows the existing RequestRetryError pattern - parsers throw, the executor passes through, the retrier catches and loops. Content already streamed to the client (text, void placeholders, citations) flows through before the continuation, and new content from the continuation turn appends seamlessly.

|

[enricoros]

@claude Very elegant, this is similar to what I would have done. Can you think of alternatives with greater encapsulation, such as 1. an async generator wrapper with internal exception catching and continuation logic, or 2. an utility module with composable functionality to have the least impact on AIX flow, and 3. formalize this to allow body modification or retransmission across providers, so maybe build it into the framework but again with minimal code invasion. I would love to see the prototype of all 3 and their scoring for safety, reliability, risk, return, genericity, so we can choose.

[claude]

Claude finished @enricoros's task in 3m 0s —— View job

---

Alternative Architectures for pause_turn Continuation

• Gather context - read current implementation files
• Design and prototype all three alternatives
• Score all three approaches
• Final comparison and recommendation

---

Understanding the Call Chain

aix.router / CSF client
  -> executeChatGenerateWithRetry()     [retrier - catches RequestRetryError, loops with reset]
    -> executeChatGenerate()            [executor - creates dispatch, connects, consumes stream]
      -> dispatchCreatorFn()            [dispatch - builds vendor-specific request]
      -> _connectToDispatch()           [fetch with heartbeats]
      -> _consumeDispatchStream()       [demux + parse loop, yields particles]
        -> parser()                     [vendor parser - emits particles via transmitter]

Key constraint: The parser transforms raw Anthropic content blocks into particles and discards the originals. For continuation, the raw blocks must be preserved to send back to Anthropic.

---

Alternative 1: Async Generator Wrapper with Internal Continuation

Concept: A new withPauseTurnContinuation() async generator wrapper that sits between the retrier and executor. It catches a PauseTurnSignal from the parser, internally rebuilds the dispatch, and re-enters the executor - all while seamlessly yielding particles to the caller.

Key insight: The continuation wrapper is separate from the retry wrapper - retry resets particles (error recovery), continuation appends particles (extending output).

// --- chatGenerate.continuation.ts ---

// Signal thrown by parsers when pause_turn is detected
export class PauseTurnSignal extends Error {
  override readonly name = 'PauseTurnSignal';
  constructor(
    readonly accumulatedContent: unknown[],  // raw Anthropic content blocks
    readonly containerId?: string,
  ) {
    super('pause_turn');
    Object.setPrototypeOf(this, PauseTurnSignal.prototype);
  }
}

const MAX_CONTINUATIONS = 10;

/**
 * Wraps executeChatGenerate to handle pause_turn continuations.
 * When the parser signals pause_turn, rebuilds the dispatch with accumulated
 * content and continues streaming - particles flow seamlessly to the caller.
 */
export async function* withPauseTurnContinuation(
  dispatchCreatorFn: () => Promise<ChatGenerateDispatch>,
  executeFn: (
    dispatch: () => Promise<ChatGenerateDispatch>,
    ...args: any[]
  ) => AsyncGenerator<AixWire_Particles.ChatGenerateOp, void>,
  ...executeArgs: any[]
): AsyncGenerator<AixWire_Particles.ChatGenerateOp, void> {

  let currentDispatchCreator = dispatchCreatorFn;
  
  for (let turn = 0; turn <= MAX_CONTINUATIONS; turn++) {
    try {
      yield* executeFn(currentDispatchCreator, ...executeArgs);
      return; // normal completion
    } catch (error) {
      if (!(error instanceof PauseTurnSignal)) throw error;
      if (turn >= MAX_CONTINUATIONS) throw error;
      
      console.log(`[pause_turn] Continuing (turn ${turn + 1}/${MAX_CONTINUATIONS})`);

      // Capture continuation state for next dispatch
      const { accumulatedContent, containerId } = error;
      const originalCreator = dispatchCreatorFn;
      
      currentDispatchCreator = async () => {
        const dispatch = await originalCreator();
        // Mutate body for continuation
        const body = (dispatch.request as any).body;
        body.messages = [
          body.messages[0],  // original user message
          { role: 'assistant', content: accumulatedContent },
        ];
        if (containerId) body.container = containerId;
        return dispatch;
      };
      // Loop continues - particles already yielded are preserved
    }
  }
}

Integration in retrier (2 lines changed):

// chatGenerate.retrier.ts - wrap the executeChatGenerate call
yield* withPauseTurnContinuation(
  dispatchCreatorFn,
  executeChatGenerate, 
  streaming, abortSignal, _d, { retriesAvailable: attemptNumber < maxAttempts }
);

Parser changes (same for all 3 alts): In anthropic.parser.ts, at message_stop, check if responseMessage.stop_reason === 'pause_turn' and throw PauseTurnSignal(responseMessage.content, responseMessage.container?.id).

Executor changes: Add PauseTurnSignal pass-through alongside RequestRetryError.

Files touched: 4 (new chatGenerate.continuation.ts, modify retrier, executor, anthropic.parser)

---

Alternative 2: Composable Utility Module

Concept: A standalone DispatchContinuation utility that encapsulates the continuation protocol without touching the core flow. The retrier composes it as a pre/post hook around dispatch execution.

// --- dispatchContinuation.ts ---

/**
 * Encapsulates vendor-agnostic continuation protocol.
 * Composed into the dispatch pipeline without modifying core abstractions.
 */
export class DispatchContinuation {
  private turn = 0;
  private accumulatedContent: unknown[] | null = null;
  private containerId: string | undefined;

  constructor(
    private readonly maxTurns = 10,
  ) {}

  /** Check if an error signals a continuation need */
  isContinuationSignal(error: unknown): error is PauseTurnSignal {
    return error instanceof PauseTurnSignal;
  }

  /** Can we continue? */
  get canContinue(): boolean {
    return this.turn < this.maxTurns;
  }

  /** Record a continuation from parser signal */
  recordContinuation(signal: PauseTurnSignal): void {
    this.turn++;
    this.accumulatedContent = signal.accumulatedContent;
    this.containerId = signal.containerId;
    console.log(`[continuation] Turn ${this.turn}/${this.maxTurns}`);
  }

  /** Apply continuation state to a fresh dispatch */
  applyToDispatch(dispatch: ChatGenerateDispatch): ChatGenerateDispatch {
    if (!this.accumulatedContent) return dispatch;
    
    const request = dispatch.request as { body: any; [k: string]: any };
    return {
      ...dispatch,
      request: {
        ...request,
        body: {
          ...request.body,
          messages: [
            request.body.messages[0],
            { role: 'assistant', content: this.accumulatedContent },
          ],
          ...(this.containerId ? { container: this.containerId } : {}),
        },
      },
    };
  }
}

Integration in retrier:

// chatGenerate.retrier.ts
export async function* executeChatGenerateWithRetry(...) {
  const continuation = new DispatchContinuation();
  // ...existing retry loop...
  while (true) {
    try {
      const wrappedCreator = async () => {
        const dispatch = await dispatchCreatorFn();
        return continuation.applyToDispatch(dispatch);  // no-op on first pass
      };
      yield* executeChatGenerate(wrappedCreator, streaming, abortSignal, _d, ...);
      return;
    } catch (error: any) {
      // NEW: handle continuation before retry logic
      if (continuation.isContinuationSignal(error) && continuation.canContinue) {
        continuation.recordContinuation(error);
        continue; // re-enter loop WITHOUT retry-reset particle
      }
      
      // ...existing RequestRetryError handling unchanged...
    }
  }
}

Files touched: 4 (new dispatchContinuation.ts, modify retrier, executor, anthropic.parser)

---

Alternative 3: Framework-level Dispatch Mutation / Retransmission

Concept: Formalize "dispatch body mutation + retransmission" as a first-class framework concept. Instead of provider-specific continuation, introduce a DispatchMutator interface that any provider can implement. The executor checks for pending mutations after each dispatch completes.

// --- chatGenerate.dispatch.ts (extended types) ---

/** 
 * A dispatch mutation request - providers signal the executor to
 * re-dispatch with a modified body. Provider-agnostic. 
 */
export interface DispatchMutation {
  /** Why the mutation is needed */
  reason: 'pause_turn' | 'token_refresh' | 'context_window_shift';
  /** Apply mutation to the existing dispatch body */
  mutateBody(body: Record<string, unknown>): Record<string, unknown>;
}

// Extended parse function - can now return a mutation request
export type ChatGenerateParseFunction = (
  partTransmitter: IParticleTransmitter,
  eventData: string,
  eventName?: string,
  context?: ChatGenerateParseContext,
) => void;
// Note: mutation signals still thrown (not returned), keeping the parse signature pure

// --- dispatchMutation.ts ---

/**
 * Framework-level dispatch mutation signal.
 * Thrown by any provider parser to request body modification + retransmission.
 * Provider-agnostic - works for Anthropic pause_turn, future OpenAI continuations, etc.
 */
export class DispatchMutationSignal extends Error {
  override readonly name = 'DispatchMutationSignal';
  constructor(readonly mutation: DispatchMutation) {
    super(`dispatch-mutation: ${mutation.reason}`);
    Object.setPrototypeOf(this, DispatchMutationSignal.prototype);
  }
}

// Anthropic-specific mutation factory
export function createAnthropicPauseTurnMutation(
  accumulatedContent: unknown[], 
  containerId?: string,
): DispatchMutation {
  return {
    reason: 'pause_turn',
    mutateBody(body: Record<string, unknown>): Record<string, unknown> {
      return {
        ...body,
        messages: [
          (body.messages as any[])[0],
          { role: 'assistant', content: accumulatedContent },
        ],
        ...(containerId ? { container: containerId } : {}),
      };
    },
  };
}

Integration - executor-level mutation loop:

// chatGenerate.executor.ts (conceptual change to executeChatGenerate)
export async function* executeChatGenerate(
  dispatchCreatorFn: () => Promise<ChatGenerateDispatch>,
  ...
): AsyncGenerator<...> {
  
  let mutationCount = 0;
  const MAX_MUTATIONS = 10;
  let pendingMutation: DispatchMutation | null = null;
  
  do {
    const createDispatch = pendingMutation 
      ? async () => {
          const d = await dispatchCreatorFn();
          // Apply mutation to body
          (d.request as any).body = pendingMutation!.mutateBody((d.request as any).body);
          return d;
        }
      : dispatchCreatorFn;
    
    pendingMutation = null;
    
    try {
      // ... existing dispatch + consume logic ...
      yield* _consumeDispatchStream(...);
    } catch (error) {
      if (error instanceof DispatchMutationSignal && mutationCount < MAX_MUTATIONS) {
        pendingMutation = error.mutation;
        mutationCount++;
        continue; // re-dispatch with mutated body
      }
      if (error instanceof RequestRetryError) throw error;
      // ... existing error handling ...
    }
  } while (pendingMutation);
}

Files touched: 5 (new dispatchMutation.ts, modify dispatch types, executor, anthropic.parser, minor retrier if needed)

---

Scoring Matrix

Criteria	Alt 1: Generator Wrapper	Alt 2: Composable Utility	Alt 3: Framework Mutation
Safety	9/10 - Isolated wrapper, can't affect retry logic. Clear error boundary.	7/10 - Continuation state mixed into retry loop. Two error types in same catch - ordering matters.	8/10 - Clean separation of mutation from retry. But mutation loop in executor adds complexity to critical path.
Reliability	9/10 - Simple loop with clear exit. Parser already accumulates responseMessage.content.	8/10 - Works well but continue skipping retry-reset requires careful reasoning about retry counter state.	7/10 - Executor-level loop is a bigger change. The dispatchCreatorFn is called repeatedly - must not have side effects. Parser fresh state on each call needs verification.
Risk	3/10 (low) - New file, minimal changes to existing code. Retrier gets 2-line wrapper swap.	4/10 (low-med) - Retrier logic modified, but contained. DispatchContinuation is self-contained.	6/10 (medium) - Executor is the most sensitive file. Structural loop change affects all providers.
Return	8/10 - Clean encapsulation. Easy to test in isolation. Can be removed without touching other files.	7/10 - Good separation. Stateful object could be reused, but the utility is fairly Anthropic-shaped despite the interface.	9/10 - Highest future value. DispatchMutation generalizes to token refresh, context shifts, provider-specific retransmission. Framework investment pays off if other providers need similar patterns.
Genericity	5/10 - Works for any throw-and-continue pattern but the wrapper is shaped around "accumulate content + rebuild messages". Other providers would need different wrappers.	6/10 - DispatchContinuation class could be extended for other patterns but applyToDispatch bakes in the messages+container shape.	9/10 - DispatchMutation is fully generic. Each provider supplies its own mutateBody. New mutation reasons added without framework changes.
Code invasion	2/10 (minimal) - 1 new file, 2-line change in retrier, 1-line pass-through in executor, parser throw.	3/10 (low) - 1 new file, ~10 lines in retrier loop, 1-line pass-through in executor, parser throw.	5/10 (moderate) - 1 new file + type additions, structural change to executor loop, parser throw.

| Weighted Total | Alt 1: 7.7 | Alt 2: 6.5 | Alt 3: 7.0 |

(Weights: Safety 20%, Reliability 20%, Risk 20%, Return 15%, Genericity 10%, Low invasion 15%)

---

Recommendation

Alt 1 (Async Generator Wrapper) scores highest for the current need. It has the cleanest encapsulation - a pure wrapper function that is trivially composable, testable, and removable. The continuation logic lives entirely in one file with zero coupling to retry semantics.

Alt 3 (Framework Mutation) is the strongest investment if we anticipate other providers needing similar retransmission patterns (e.g., OpenAI background mode polling, Gemini long-running operations). The DispatchMutation abstraction is genuinely provider-agnostic. However, it touches the executor - the most sensitive file in the pipeline.

Alt 2 (Composable Utility) is a reasonable middle ground but lands awkwardly - it adds stateful object management to the retrier without the full genericity payoff of Alt 3.

My suggestion: Start with Alt 1 for safety and speed, with the type system designed so that migrating to Alt 3 later is straightforward (i.e., PauseTurnSignal could trivially become a specific DispatchMutationSignal if the framework abstraction proves needed).

---

View job - claude/issue-1010-20260306-0906

[enricoros]

@claude Is there a best-of both alt 1 (clearly clean) and 3 (future proof). Second: while with CSF it's okay, looping inside the server may cause timeouts on time-limited lambdas (e.g. Vercel). How would the solution fare in the client context at the lowest possible level?

[claude]

Claude finished @enricoros's task in 4m 2s —— View job

---

Hybrid Architecture Analysis: Alt 1+3 & Client-Side Continuation

• Gather context - read CSF flow, dispatch chain, retrier, executor
• Design hybrid Alt 1+3 approach
• Analyze CSF/client-side continuation and Vercel timeout implications
• Score and compare

---

Question 1: Best of Alt 1 + Alt 3

Yes - the sweet spot is a framework-level DispatchMutation type (Alt 3's genericity) implemented as an async generator wrapper (Alt 1's encapsulation). The key insight: the generic mutation interface and the clean wrapper placement are orthogonal concerns.

Hybrid: Framework Mutation via Generator Wrapper

// --- chatGenerate.dispatchMutation.ts ---
// Framework-level: any provider can define mutations

/** Provider-agnostic body mutation - the only framework abstraction needed */
export interface DispatchBodyMutation {
  readonly reason: string;  // 'pause_turn', 'token_refresh', 'context_shift', ...
  mutateBody(body: Record<string, unknown>): Record<string, unknown>;
}

/** Signal thrown by any provider parser to request body mutation + retransmission */
export class DispatchMutationSignal extends Error {
  override readonly name = 'DispatchMutationSignal';
  constructor(readonly mutation: DispatchBodyMutation) {
    super(`dispatch-mutation: ${mutation.reason}`);
    Object.setPrototypeOf(this, DispatchMutationSignal.prototype);
  }
}

const MAX_MUTATIONS = 10;

/**
 * Wraps executeChatGenerate to handle dispatch mutations transparently.
 * Provider parsers throw DispatchMutationSignal; this wrapper catches it,
 * mutates the dispatch body, and re-enters - particles flow seamlessly.
 * 
 * Separate from retry (retry resets particles; mutation appends particles).
 */
export async function* withDispatchMutation(
  dispatchCreatorFn: () => Promise<ChatGenerateDispatch>,
  executeFn: (...args) => AsyncGenerator<ChatGenerateOp, void>,
  ...executeArgs
): AsyncGenerator<ChatGenerateOp, void> {
  let currentCreator = dispatchCreatorFn;
  
  for (let turn = 0; turn <= MAX_MUTATIONS; turn++) {
    try {
      yield* executeFn(currentCreator, ...executeArgs);
      return; // normal completion
    } catch (error) {
      if (!(error instanceof DispatchMutationSignal)) throw error;
      if (turn >= MAX_MUTATIONS) throw error;
      
      const { mutation } = error;
      const originalCreator = dispatchCreatorFn; // always mutate from original
      
      currentCreator = async () => {
        const dispatch = await originalCreator();
        const request = dispatch.request as { body: Record<string, unknown> };
        request.body = mutation.mutateBody(request.body);
        return dispatch;
      };
      // loop continues - already-yielded particles are preserved
    }
  }
}

// --- In anthropic.parser.ts ---
// Provider-specific: Anthropic defines its own mutation factory

import { DispatchMutationSignal, type DispatchBodyMutation } from '../chatGenerate.dispatchMutation';

function createAnthropicPauseTurnMutation(
  accumulatedContent: unknown[], 
  containerId?: string,
): DispatchBodyMutation {
  return {
    reason: 'pause_turn',
    mutateBody(body) {
      return {
        ...body,
        messages: [
          (body.messages as any[])[0],  // original user message
          { role: 'assistant', content: accumulatedContent },
        ],
        ...(containerId ? { container: containerId } : {}),
      };
    },
  };
}

// At message_stop, when stop_reason === 'pause_turn':
throw new DispatchMutationSignal(
  createAnthropicPauseTurnMutation(responseMessage.content, responseMessage.container?.id)
);

// --- In chatGenerate.retrier.ts ---
// Integration: 2-line change

yield* withDispatchMutation(
  dispatchCreatorFn,
  executeChatGenerate,
  streaming, abortSignal, _d, { retriesAvailable: attemptNumber < maxAttempts },
);

Why this is strictly better than either pure alt:

Property	Alt 1 pure	Alt 3 pure	Hybrid
Generic mutation interface	No - Anthropic-shaped	Yes	Yes - DispatchBodyMutation
Clean wrapper placement	Yes - separate from retry	No - modifies executor	Yes - wraps executor
Files touched	4	5	4 (new mutation file, retrier, executor passthrough, parser)
Executor changes	1-line passthrough	Structural loop	1-line passthrough
Future providers	New wrapper per pattern	Add mutation reason	Add mutation factory

The DispatchBodyMutation interface is the entire framework investment - 6 lines. Providers define their own mutateBody() factory functions. The wrapper is provider-agnostic. Adding a new mutation reason (e.g., Gemini long-running ops, token refresh) means writing a new factory function and throwing DispatchMutationSignal from the relevant parser - zero framework changes.

---

Question 2: Vercel Timeout Problem & Client-Side Continuation

This is the more consequential question. Here's the full analysis:

The Problem

Anthropic pause_turn with heavy server tool usage can generate 3+ continuation turns, each involving multiple web searches/fetches. A single turn can take 30-60s+ on complex research queries. The full chain can exceed 3-5 minutes total.

Vercel Edge Function timeout: 30 seconds (Hobby) / 5 minutes (Pro). A server-side continuation loop will timeout on Hobby plans and risks it on Pro.

The Critical Architectural Insight

The retrier/executor already runs identically on both client (CSF) and server (tRPC). From aix.client.direct-chatGenerate.ts:

yield* executeChatGenerateWithRetry(chatGenerateDispatchCreator, streaming, abortSignal, _d);

This means withDispatchMutation() wrapping executeChatGenerate() automatically works in CSF mode with zero additional code. The mutation wrapper runs wherever the retrier runs - client or server.

Where it matters: the tRPC (non-CSF) path

For users routing through the server (no CSF), the server holds the connection open during continuations. This is where Vercel timeouts hit. Three approaches at increasing levels of client involvement:

Approach A: Server-side loop (current proposal, simplest)

The withDispatchMutation wrapper loops inside executeChatGenerateWithRetry, which runs server-side. Each continuation is a new fetch() from server to Anthropic, streaming particles back to client.

• Pro: Zero client awareness. Particles just keep flowing.
• Con: Total time = sum of all turns. Exceeds Vercel limits on complex queries.
• Verdict: Works for CSF. Works for self-hosted. Risky on Vercel tRPC.

Approach B: Client-side continuation via particle signal (recommended)

Instead of looping server-side, emit a continuation particle and let the client's existing retry/reconnect loop (aix.client.ts L693 while(true)) handle it:

// New particle type
{ cg: 'mutation-continue', mutation: SerializedDispatchBodyMutation }

The client receives this particle, stores the mutation, and re-initiates the tRPC call with a mutated request body. This is structurally identical to how retry-reset already works - the client loop already re-creates particleStream on each iteration.

However, this requires the mutation data (raw Anthropic content blocks) to transit through the particle wire to the client and back. These can be large (web search results, fetched pages). This adds complexity and bandwidth.

Approach C: Hybrid - server loop with CSF fallback (pragmatic)

The cleanest production approach combines both:

1. CSF mode: withDispatchMutation loops client-side. No timeout risk. Already works with the hybrid Alt 1+3 design above. This is the default for users with API keys (which is most users on Vercel).

2. tRPC mode: withDispatchMutation loops server-side. Works for self-hosted (no timeout). For Vercel, the server tools that trigger pause_turn (web_search, web_fetch) require Anthropic API keys, which means CSF is almost always available.

3. Future option: If tRPC timeout becomes a real problem for non-CSF users, add Approach B's continuation particle as an escape hatch.

Lowest-Level Client-Side Solution

If we wanted to push continuation to the absolute lowest client level, the cleanest integration point is aix.client.ts L693's existing while(true) loop. This loop already handles:

• Retry on transient errors
• Resume via OpenAI Responses API handles
• Re-creation of ContentReassembler per attempt

Adding mutation continuation here would mean:

// In _aixChatGenerateContent_LL, after the for-await particle loop:
// ContentReassembler already processed ok-pause_continue as the stop reason.
// Check if the reassembler flagged a continuation need:

if (accumulator_LL.tokenStopReason === 'ok-pause_continue' && accumulator_LL._pendingMutation) {
  // Mutate the original request for next iteration
  aixChatGenerate = applyMutation(aixChatGenerate, accumulator_LL._pendingMutation);
  continue; // re-enter while(true), create new particleStream
}

But this has a fundamental problem: the raw Anthropic content blocks needed for continuation are not available at this level. The particle wire protocol abstracts away vendor-specific content - by the time particles reach the client, they've been transformed from Anthropic's content[] format into provider-agnostic fragments. You'd need to either:

• Thread raw content blocks through the particle protocol (heavy, breaks abstraction)
• Reconstruct Anthropic content blocks from fragments (fragile, lossy - server_tool_use blocks, citations, etc.)

This is why server-side continuation (or CSF-mode continuation) is architecturally correct - the raw blocks are available where the parser runs.

Scoring Matrix

Criteria	A: Server Loop	B: Client Particle	C: Hybrid Server+CSF	Lowest-Level Client
Safety	9	7 (large data in particles)	9	5 (reconstruction risk)
Reliability	8 (timeout risk)	7 (round-trip complexity)	9	4 (lossy conversion)
Vercel compat	4 (timeout)	9	8 (CSF covers most cases)	9
Code invasion	2 (minimal)	6 (particle type + client logic)	2 (same as A)	7 (client + reassembler)
Genericity	9 (DispatchBodyMutation)	8	9	3 (Anthropic-specific at client)
Weighted	7.0	7.2	8.2	4.8

Recommendation

Implement Approach C (Hybrid) with the Alt 1+3 generator wrapper:

1. DispatchBodyMutation interface + DispatchMutationSignal + withDispatchMutation() wrapper - one new file
2. Anthropic parser throws DispatchMutationSignal on pause_turn
3. Executor passes through DispatchMutationSignal (1 line, alongside RequestRetryError)
4. Retrier wraps executeChatGenerate with withDispatchMutation

This gives us:

• CSF: Continuation runs entirely client-side, no timeout risk, zero extra code needed
• tRPC/self-hosted: Server-side continuation, no timeout concern
• tRPC/Vercel: Server tools require API keys → CSF is available → client-side path covers it
• Future-proof: Any provider can define mutations via DispatchBodyMutation without framework changes

Shall I implement this?

---

View job · claude/issue-1010-20260306-0947

[enricoros]

@claude This is good architecture, matches the AIX level. Proceed.

[claude]

Claude finished @enricoros's task in 6m 20s —— View job • claude/issue-1010-20260306-1009 • Create PR ➔

---

Implementing Hybrid Alt 1+3: Framework Dispatch Mutation via Generator Wrapper

Implemented the recommended architecture: DispatchBodyMutation interface (Alt 3 genericity) + async generator wrapper (Alt 1 encapsulation).

• Read current implementation files (retrier, executor, parser, dispatch types)
• Create chatGenerate.dispatchMutation.ts with framework-level mutation abstraction
• Modify Anthropic parser to throw DispatchMutationSignal on pause_turn
• Modify executor to pass through DispatchMutationSignal
• Modify retrier to wrap with withDispatchMutation
• Type check and lint
• Commit and push

Summary

4 files changed (+137, -3):

1. chatGenerate.dispatchMutation.ts (new) - Framework-level dispatch mutation abstraction:

   • DispatchBodyMutation interface - provider-agnostic, any provider can define mutateBody() for retransmission scenarios (pause_turn, token refresh, context shift, etc.)
   • DispatchMutationSignal - thrown by parsers, distinct from RequestRetryError (retry resets particles; mutation appends particles)
   • withDispatchMutation() - async generator wrapper with safety cap of 10 max turns, wraps executeChatGenerate at the retrier level

2. anthropic.parser.ts (+42) - Both streaming and non-streaming parsers detect pause_turn stop reason and throw DispatchMutationSignal with accumulated raw content blocks + container ID via _createAnthropicPauseTurnMutation() factory

3. chatGenerate.executor.ts (+7) - Pass-through DispatchMutationSignal in both streaming and non-streaming consumer catch blocks

4. chatGenerate.retrier.ts (+3) - Wraps executeChatGenerate with withDispatchMutation, passing through all existing arguments

Architecture: The wrapper sits between the retrier and executor - the retrier calls withDispatchMutation(dispatchCreatorFn, executeChatGenerate, ...) instead of calling executeChatGenerate(...) directly. On pause_turn, the parser throws, the executor passes through, and the wrapper catches it, builds a mutated dispatch creator (with accumulated assistant content + container ID), and re-enters the executor. Already-yielded particles are preserved - the client sees seamless continuation. Works identically on server (tRPC) and client (CSF) paths.

• claude/issue-1010-20260306-1009

[enricoros]

@claude Good architecture, two comments: can you go read the specs for continuation so you can double check the body transformation? (feels strange we have only 1 user and a partial assistant message with a few blocks). Second, make sure TS is used and types/type inference happen correctly.