compaction sends mutated thinking block -> permanent 400 retry loop

[Samyak2406]

Bug: compaction sends mutated thinking block, causes permanent retry loop (400 invalid_request_error)

opencode version: 1.16.2
Provider: anthropic, model claude-sonnet-5, extended thinking enabled (budget_tokens 8000)
Agent: compaction

What happened

During context compaction, opencode rebuilds the request history and reuses a prior assistant
turn's thinking block, but the block's thinking text field comes back empty ("thinking":"")
while the signature is preserved from the original. Anthropic's API rejects this because thinking
blocks in the last assistant message must be sent back byte-identical to how they were returned.

Because compaction retries automatically and rebuilds the same mutated payload every time, the
session gets stuck in a permanent retry loop — same 400 error, dozens of times over roughly an
hour, never recovering. Only a fresh session avoids it.

Error (from Anthropic API, relayed by opencode)

AI_APICallError
messages.N.content.1: `thinking` or `redacted_thinking` blocks in the latest assistant message
cannot be modified. These blocks must remain as they were in the original response.

N varied across retries (7, 1, 5, 3, ...) — consistent with the mutated block shifting position
as compaction repeatedly re-summarizes a growing/changing history.

Repro conditions

• Long-running session that triggers auto-compaction with extended thinking enabled.
• Compaction request's latest assistant message contains a thinking block whose thinking text
  is "" but signature is non-empty (from the original response) — i.e. the block was stripped/
  edited before resending.

Expected

Compaction should either preserve thinking blocks completely unmodified when replaying them, or
strip them entirely (not send thinking type block with empty text + stale signature) when
building the summarization request.

Additional observation

Traffic in the failing session routed through http://127.0.0.1:4097/v1/messages — a local proxy
in front of the Anthropic API — worth checking whether the proxy or opencode itself is the one
truncating the thinking block content before the request leaves the client.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Compaction always fails on first attempt when session contains thinking blocks (Anthropic extended thinking) #31188: Same root cause — compaction with extended thinking enabled sends invalid thinking blocks, triggering the same thinking or redacted_thinking blocks in the latest assistant message cannot be modified Anthropic 400 error. That issue also includes a proposed fix (stripReasoning option in toModelMessagesEffect).

[iamjalberto]

Confirming this bug affects opencode 1.18.10 with MiniMax-M3 (Anthropic-compatible endpoint), and providing empirical data.

Environment

• opencode version: 1.18.10
• Provider: minimax-coding-plan (uses https://api.minimax.io/anthropic/v1)
• Model: MiniMax-M3 with variant: thinking
• Agent: build
• Session type: long-running investigation of legacy codebase

Empirical data from the affected session

Session: ses_064f372afffeAfS6ezjKK9RT5v
Title:   SIPD Convocatorias y Participaciones
Status:  STUCK in compaction loop (process still running, no progress)

Total messages:                 6,483
Total parts (DB rows):           22,837
Total parts size (serialized):   28 MB
Manual compactions performed:    6 (all "auto": false)
Auto compactions triggered:      0

Token breakdown (lifetime totals)

tokens_input:       38,391,311
tokens_output:       1,990,637
tokens_cache_read: 1,965,274,137  ← 1.96 BILLION
cost: $0.00

Behavior timeline (last 10 messages, seconds apart)

[20:47:40] assistant  in=     693  cr=    133,120  out=     115
[20:47:33] assistant  in=     431  cr=    132,864  out=      82
[20:47:24] assistant  in=     880  cr=    132,224  out=     131
[20:47:10] assistant  in=     579  cr=    131,840  out=     662
[20:46:59] assistant  in=     683  cr=    131,328  out=     386

cache_read is monotonically growing — each turn re-reads the same context.

Part distribution (proves the model is in a loop)

type=step-start     count=6058
type=step-finish    count=6045
type=tool bash      count=3438
type=text           count=3204
type=reasoning      count=1598
type=tool read      count=1126
type=tool edit      count= 922
...
type=compaction     count=   5  ← ALL manual (auto: false)

Observations consistent with #39291

1. auto: true in compaction config but zero auto-compactions ever fired
2. Last user prompt is empty — the model is in inference loop with no new user input
3. Each turn's cache_read keeps growing — same byte-identical context being re-sent with mutated thinking blocks
4. 6 manual compactions previously succeeded — but the next turn after each compaction triggered the loop again
5. Process keeps generating messages (every ~10 seconds) but makes no progress on actual work

Compaction config (for reference)

{
  "compaction": {
    "auto": true,
    "prune": true,
    "tail_turns": 2,
    "preserve_recent_tokens": 50000,
    "reserved": 500000
  }
}

Workaround applied

1. kill -9 <pid> to stop the looping process
2. Session is unrecoverable — opening it again reproduces the same loop
3. New session with same task starts cleanly

Suggested mitigation for users

Until fixed, disable auto-compaction for sessions using thinking-enabled models:

{
  "compaction": {
    "auto": false   // disable auto-compaction
  }
}

Or use a non-thinking variant (variant: none or default) for long sessions.

Confirmation

This is the same bug as #39291 — auto-compaction with extended thinking enabled produces a request that the API rejects, and opencode retries it forever with the same corrupted payload. The cache_read explosion is the downstream effect of dozens of failed retries per minute over roughly an hour.