fix(agent): recover from unsupported image input instead of poisoning the turn

[tlongwell-block]

Problem

buzz-dev-mcp advertises view_image to every agent regardless of whether the session's model accepts images. When a text-only model (e.g. DeepSeek V4 Flash) takes the bait, the image lands in session history and every subsequent LLM request 404s with No endpoints found that support image input. The error was classified as LlmModelNotFound and propagated fatally out of the turn loop — history stays poisoned, buzz-acp retries the batch with exponential backoff, and the session burns its entire clock doing no work. In a recent trial run, all 57 trials that called view_image on a text-only model died this way; none recovered.

Fix

Capability-gating the advertised tool isn't reliable — there is no image-capability metadata at the agent layer across providers. Instead, recover at the turn loop:

• Typed error: new AgentError::UnsupportedImageInput, classified narrowly on the exact provider phrase No endpoints found that support image input on both the generic 404 path and OpenRouter's 404 path. Unknown-model 404s and OpenRouter parameter-routing 404s keep their existing classifications. No deterministic retry.
• In-turn recovery: on this error, RunCtx::run strips every image block from history — keeping the tool result (and therefore tool-call/result pairing) intact — marks the result is_error, appends actionable model-facing guidance ("The current model does not support image input. The image was removed from conversation history so this turn can continue. Use a text-based inspection tool…"), and continues the same turn. Base64 never replays again.
• Loop guard: recovery only fires when at least one image was removed; if the provider says "image" and history has none, the error propagates as before.

Tests

• Unit: phrase classification (typed, not retried; unknown-model 404 unaffected), idempotent image-to-error history mutation preserving call IDs and text.
• End-to-end (fake_llm.rs + fake_mcp.rs): tool call → MCP image result → 404 unsupported-image → same-turn recovery. Captured requests prove round 2 carried the image, round 3 replays no image, carries the guidance text, preserves pairing, and ends end_turn.
• Loop guard: typed unsupported-image error with no image in history fails after exactly one provider request instead of spinning — mutation-testing showed deleting the removed == 0 guard survived the suite, and max_rounds defaults to unlimited in production, so this branch needed direct coverage.

Verified at a210305019b33d5f56677b4c82bab79e4ac52d24: cargo test -p buzz-agent (full package, 381 unit + all integration suites) green; clippy --all-targets -D warnings green; fmt --check green; pre-push hooks (rust-tests, desktop-tauri-checks, branch-skew) green.

Scope of the classification guarantee: the classifier runs in the shared post() (which Anthropic and OpenAI paths route through) and in openrouter_post() — i.e., every 404 path in llm.rs. It only runs on 404 responses; providers that reject images with a different status (e.g. a 400) are out of scope for this PR — see the review-comment discussion for why broadening the phrase list alone would not cover them.

Authored by Wren, loop-guard test by Sami, reviewed by Eva.

[atishpatel]

This seems too fragile?
Maybe break it into a few different errors
contains("not support image") // for open ai models
|| contains("no endpoints found that support image input") // for deepseek models
|| contains("image inputs are not supported") // for claude models

[atishpatel]

I think ollama outputs: "not support multi-modal inputs"

[tlongwell-block]

Good instinct — the matcher is deliberately narrow, but we probed the suggestion before taking it, and the phrase list turns out not to be the binding constraint: the status gate is. is_unsupported_image_input_error only runs inside the status == 404 arms (both here and in openrouter_post). We measured all four cases against the real post path:

phrase	status	result
OpenAI-style "not support image"	400	AgentError::Llm — never reaches the matcher
Claude-style "image inputs are not supported"	400	AgentError::Llm — never reaches the matcher
Claude-style phrase	404	LlmModelNotFound — matcher ran, phrase absent
DeepSeek/OpenRouter phrase	404	UnsupportedImageInput — works today

So adding the OpenAI/Claude phrases as written would close the comment without changing behavior for either provider — their rejections arrive as 400s and are swallowed upstream of the matcher. Real coverage means hoisting the check above the status dispatch, which is a structurally different patch.

Two more reasons we're holding to the narrow matcher in this PR:

1. We can't verify the other phrases. The DeepSeek phrase is in this PR because a live trial produced it verbatim; nobody in this effort has a captured 400 body from OpenAI or Anthropic rejecting an image. Matching a guessed phrase fails silently the moment the real wording differs.
2. A false positive here is not benign. contains("not support image") is broad, and misclassification strips images out of history on a turn where images were fine. The neighboring test openrouter_post_404_unknown_model_stays_model_not_found exists precisely because 404-classification mistakes send users to the wrong fix.

Filed as a follow-up: broaden coverage (hoist above the status dispatch + per-provider phrases) once we have real captured rejection bodies to match against. The PR body now states the scope guarantee explicitly.

[tlongwell-block]

Following up on the measurement above — you were right about Ollama, and I have the captured body now.

Ollama is reachable through our openai-compat path with no credential, so I pulled a text-only model and drove the real buzz-agent binary against it at this PR's head. The rejection is real, close to your guess but not identical:

HTTP 400
{"error":{"message":"{\"error\":{\"code\":400,\"message\":\"Multimodal data provided, but model does not support multimodal requests.\",\"type\":\"invalid_request_error\"}}","type":"invalid_request_error","param":null,"code":null}}

You guessed "not support multi-modal inputs"; the actual wording is does not support multimodal requests — no hyphen, "requests" not "inputs". That gap is exactly why I wanted a captured body rather than a guessed phrase: a matcher built on the guess would have silently missed this. Also worth flagging for whoever implements it — the body is doubly encoded, so the real sentence sits in a JSON string nested inside error.message.

At this PR's head the failure is unchanged for Ollama — three consecutive turns die on the same 400, history stays poisoned. I also ran a proxy that rewrote only that 400 into the OpenRouter 404 + phrase: recovery fires and all three turns end end_turn. Same binary, same rig, sole variable is the status and phrase. So the recovery machinery here is right; it just isn't reached.

Two more measurements that constrain the fix, and they argue against the simple version:

• Ollama returns 404 for model not found (text-only request, no image).
• Ollama returns 404 for model not found even when the request does carry an image.

So we can't just add the phrase to the existing 404 arm or loosen that arm — on this provider 404 already means something else. Real coverage needs the check hoisted above the status dispatch, plus a test pinning that Ollama's model-not-found 404 keeps LlmModelNotFound.

Full evidence, controls, and a reproduction recipe are on #4899. OpenAI and Anthropic bodies are still uncaptured, so I'd keep those phrases out until someone has them verbatim.

[tlongwell-block]

Update: your instinct on the phrase list was better than my first reply gave it credit for. We stood up a credential-free live rig against Ollama and captured a real image rejection — and one of your guessed phrases is essentially real:

HTTP 400
{"error":{"message":"{\"error\":{\"code\":400,\"message\":\"Multimodal data provided, but model does not support multimodal requests.\",\"type\":\"invalid_request_error\"}}", ...}}

Two things the capture pins down:

1. It arrives as a 400, which confirms the structural point from my earlier reply — adding phrases to the current 404-gated matcher would not have caught it. The check has to hoist above the status dispatch. And Ollama's own 404 (model 'x' not found) means model-not-found even when the request carries an image, so the 404 classifications must stay as-is.
2. The body is doubly-encoded (the sentence is a JSON string nested inside error.message), which any structured matcher needs to know about.

The live rig also confirmed the recovery machinery in this PR works end-to-end against a real provider (a proxy rewriting that 400 to the OpenRouter-shaped 404 produces clean end_turn recovery on the same binary).

Sequencing: this PR lands as-is (correct for OpenRouter/DeepSeek, live-verified recovery), and the hoist + captured Ollama phrase + ordering tests come as a stacked PR tracked in #4899. OpenAI/Anthropic phrases stay out until someone captures real bodies from them.

[atishpatel]

LGTM other than comment above