[Bug] advisor() silently returns no result (red circle, ~4s, no advisor_tool_result) when transcript exceeds the 100-image API limit

What's wrong?

In an image-heavy session (Playwright screenshots / SVG / HTML renders), every advisor() call fails silently:

• The assistant emits a server_tool_use{name:"advisor"} block, but no advisor_tool_result block ever comes back.
• The turn ends with stop_reason: end_turn.
• The UI shows a red error circle that finishes in ~4s, then the agent stalls (looks like the session "paused").
• No 400 is surfaced, and the rest of the session keeps working normally (Bash/Read/Edit/Write all succeed afterward).

So this is neither the advisor message-structure 400 brick cluster (#63507, #62885, #63626, #63553, #63375, #63790 — those surface a 400 and brick the whole session) nor a main-loop image-limit error (#23392 and the closed >100-image cluster — those 400 loudly in the main loop and block every prompt). It's a third, silent failure mode.

Root cause

advisor() is a server-side tool that auto-forwards the entire session transcript — including every image block — to the reviewer model, with no way to trim the payload.

When the transcript has accumulated more than 100 image blocks, the advisor's own forwarded sub-request exceeds the Messages API per-request image cap (too many images and documents: N > 100, exactly as in #23392). That sub-request is rejected synchronously (~4s). The rejection is swallowed: the advisor server-tool returns no advisor_tool_result, no error is propagated to the main loop, and the turn simply ends.

The novel combination, distinct from every existing report, is: image COUNT in the forwarded advisor payload → silent advisor no-result, while the main session is unharmed.

Evidence (two sessions compared, transcript-level)

| | Image-free session | Image-heavy session |
|---|---|---|
| Advisor calls | 1 | 6 |
| advisor_tool_result returned | 1 ✅ | 0 — all 6 failed |
| Image blocks in transcript | 0 | 226 (~15.3 MB base64) |
| Bash/Read/Edit during session | working | working (490+ Bash calls fine) |

• A successful advisor call is followed by a message containing an advisor_tool_result block. Every failed call has no such block anywhere in the transcript; the assistant message is just [server_tool_use] with stop_reason: end_turn.
• The smallest failing call had only ~77k context tokens, so this is driven by image count, not token size. Opus handles 200k-token contexts fine; the differentiator is the 226 images.

Expected behavior

Before forwarding the transcript, advisor should strip, cap, or summarize image blocks (e.g. keep ≤ the API image limit, or replace older images with text placeholders). On rejection it should surface the error (or return a text-only degraded result) instead of silently producing no advisor_tool_result.

Related issues (different root cause — not duplicates)

• #63966 — closest by symptom (advisor server_tool_use with no tool_result), but its root cause is a generic parallel-load payload-delivery failure across all tools, with no image-count involvement.
• #23392 (and closed #19822 / #26188 / #25272 / #24541) — the loud main-loop counterpart of the same 100-image API cap. Confirms the exact cap/wording, but those 400 visibly and block the main session rather than failing the advisor sub-call silently.
• #63507 / #62885 / #63626 / #63553 / #63375 / #63790 — advisor message-structure 400 / session-brick cluster. Those surface a 400 and brick the session; this bug surfaces nothing and leaves the session usable.

Environment

• Version: 2.1.158
• Model: claude-opus-4-8[1m]
• Platform: darwin