Summary

When the model hits its max_output_tokens limit mid-generation (especially during tool_use with large parameters), the agent runtime silently proceeds with truncated output. There is no detection, no recovery, and no signal to the LLM that its output was incomplete.

This is a complementary request to #63188, which covers mode:"run" subagent sessions. This issue covers the main interactive agent session, where truncated tool_use parameters lead to silent data corruption.

Root Cause Analysis (from source code)

1. Provider maps max_tokens → "length", but the agent loop never checks for it.

In pi-ai/dist/providers/amazon-bedrock.js (line 555):

case BedrockStopReason.MAX_TOKENS:
case BedrockStopReason.MODEL_CONTEXT_WINDOW_EXCEEDED:
    return "length";

In the Anthropic provider, Dr() maps "max_tokens" → "length".

But in pi-embedded (pi-embedded-bukGSgEe.js), grep -c length returns 0. The agent loop only handles "error", "aborted", "toolUse", and "stop". When stopReason is "length", it falls through to default behavior and is treated as a normal completion.

2. One code path overwrites the provider stop_reason entirely.

buildAssistantMessageFromResponse() (line 30117):

stopReason: content.some((part) => part.type === "toolCall") ? "toolUse" : "stop"

This derives stopReason from content type, ignoring the provider's actual stop reason. If the model was truncated mid-tool-call but the partial JSON still parsed as a toolCall content block, the stopReason is set to "toolUse" — and the tool executes with truncated parameters.

3. Empirical evidence: zero max_tokens events in session history.

Across all agent sessions on our instance (main + subagents), stopReason:"max_tokens" has never appeared. This could mean:

• The current maxTokens setting (model.maxTokens/3 ≈ 10K for Opus 4.6) is high enough that truncation is rare
• OR truncation IS happening but is masked by the content-type-based stopReason override (finding #2)

Problem Scenarios

Scenario A: Tool parameter truncation (most dangerous) LLM generates write(file, <8000 chars of content>). Output hits token limit mid-content. The write tool receives truncated content and writes an incomplete file. No error is raised. The LLM proceeds as if the write succeeded.

This was the root cause of a 20-hour subagent death spiral on 2026-03-31: truncated write → incomplete file → compaction reads corrupt context → empty exec loop.

Scenario B: Text + tool_use truncation LLM generates explanation text + tool_use in one response. Token limit cuts off the tool_use JSON. If the partial JSON doesn't parse, the toolCall content block is dropped, stopReason becomes "stop" (no toolCalls detected), and the turn ends prematurely without executing the intended tool.

Proposed Solution

Phase 1: Detection (low risk, high value)

When the runtime receives stopReason: "length" from the provider (before content-type override):

1. Preserve the original provider stop_reason as metadata (e.g., _providerStopReason) alongside the derived stopReason
2. If the assistant message contains tool_use blocks AND the provider stop_reason was max_tokens/length:
   • Validate JSON completeness of each tool_use parameter
   • If any tool_use has malformed JSON → do not execute tools
   • Inject a system message: "⚠️ Your previous response was truncated (stop_reason=max_tokens, output_tokens=N). Your tool call parameters may be incomplete. Please break your output into smaller parts and retry."
3. If no tool_use blocks (pure text was truncated):
   • Inject: "⚠️ Your previous response was truncated at the output token limit. Please continue from where you left off."

Phase 2: Tool execution failure feedback loop

When a tool execution fails (regardless of truncation):

1. Return the error to the LLM as a tool_result with is_error: true (this already exists)
2. Add a retry budget (configurable, default: 3) — track consecutive failures for the same tool
3. After exhausting retries, inject a system message asking the LLM to reflect on the failure pattern and try a different approach
4. Circuit breaker: if a tool fails > N times across the session, temporarily block it and inform the LLM

Configuration

{
  "agents": {
    "defaults": {
      "runtime": {
        "onOutputTruncation": "recover",
        "maxTruncationRecoveries": 3,
        "toolRetryBudget": 3
      }
    }
  }
}

Values for onOutputTruncation:

• "ignore" — current behavior (default for backward compat)
• "warn" — inject warning message to LLM, still execute tools
• "recover" — validate tool params, block execution if malformed, inject recovery prompt

Relationship to #63188

#63188 covers mode:"run" subagent sessions with onLengthTruncation: "continue"/"fail"/"terminate".

This issue covers the main interactive session and focuses on:

• Preserving provider stop_reason through the content-type override
• Tool parameter JSON validation before execution
• LLM-facing recovery prompts (the LLM can self-correct, unlike a terminated subagent)
• Tool execution failure feedback loops (applicable beyond truncation)

These are complementary — #63188's "fail" mode gives the orchestrator a signal; this issue gives the LLM itself a signal to self-correct.

Environment

• OpenClaw: 2026.4.1
• OS: Ubuntu 24.04 / Linux 6.17.0
• Model: Claude Opus 4.6 via Amazon Bedrock
• Source files examined:
  • dist/pi-embedded-bukGSgEe.js (lines 24808, 24972, 30066-30117, 37397-37400)
  • node_modules/@mariozechner/pi-ai/dist/providers/amazon-bedrock.js (lines 548-563)
  • Anthropic SDK stream handler Dr() function