[Bug] Model request fails with file attachment via proxy, session unrecoverable

Summary

When using Claude Opus (claude-opus-4-6) through a plugin proxy provider (Antigravity), sending a message with a file attachment (PDF, ~180KB) causes the model request to fail silently. The assistant response never arrives. Worse, the session becomes stuck in an unrecoverable error state — retrying in the same session always fails again, forcing the user to abandon the thread and start a new one.

Steps to Reproduce

1. Configure a plugin proxy provider (e.g., plugin:antigravity-auth:antigravity:claude-opus-4-6)

2. Open a new chat session and select this model

3. Send a message with a PDF file attachment (~180KB)

4. Observe: the request hangs, then fails. No assistant response is saved.

5. Try sending another message in the same session — it fails again immediately.

6. Even switching to a different message (without attachment) in the same session continues to fail.

Expected Behavior

• If the model request fails (timeout, payload too large, proxy error), Alma should show a clear error message indicating the failure reason.

• The session should remain usable — the user should be able to retry, edit the message, or send a new message without the attachment.

• Alma should not enter an unrecoverable state where the entire session is bricked.

Actual Behavior

• The request fails silently — no error message, no timeout notification, nothing.

• The session thread records only the user message; the assistant response slot is empty.

• Subsequent messages in the same session also fail, making the session completely unusable.

• The user has to create a new session and re-enter context to continue working.

Root Cause Analysis

Two separate issues are at play:

1. Proxy payload limitation: The PDF attachment is encoded as base64 in the API request body. When routed through a plugin proxy provider, the large payload (~240KB+ after encoding) likely exceeds the proxy timeout or body size limit, causing a silent failure.

2. Missing error recovery: When the model request fails mid-stream, Alma does not properly reset the session state. The conversation context appears to get corrupted or stuck, preventing any further successful requests in that session.

Impact

• Data loss: Any context built up in the session (previous messages, instructions, uploaded files) is lost when the user is forced to abandon the session.

• User confusion: No error message means the user has no idea what went wrong or how to fix it.

• Workflow disruption: Having to recreate a session and re-upload files is a significant friction point.

Suggested Fixes

1. Error handling: Catch proxy/model request failures and display a clear error message (e.g., "Request failed: timeout" or "Payload too large for proxy provider").

2. Session recovery: After a failed request, reset the session state so the user can retry or send a different message. Do not leave the session in a broken state.

3. Retry mechanism: Offer a "Retry" button on failed messages, similar to how ChatGPT handles failed generations.

4. Payload size warning: When a file attachment would make the request body exceed a configurable threshold (e.g., 100KB), warn the user or automatically compress/chunk the payload.

5. Fallback: If the primary model fails, optionally fall back to a direct (non-proxy) provider if one is configured for the same model.

Environment

• Alma version: 0.0.723

• OS: macOS

• Model: plugin:antigravity-auth:antigravity:claude-opus-4-6

• Provider type: Plugin proxy (Antigravity)

• File: PDF, approximately 180KB