Image attachment UX: consider advertising _meta.imageCapability + transparent VLM-route fallback
We've been shipping a bilateral fix in sudocode (the open-source CLI we maintain) + sudowork (the Electron host that talks to multiple ACP backends — Claude Code, Codex, Qwen, sudocode) for image-attachment edge cases:
- Oversized image → preflight downsample (JPEG-quality loop) → VLM-describe fallback when even q25 still exceeds the API hard cap.
- Wrong-model (text-only model active + image attached) → transparently route through a designated vision model, splice description back into the user turn so the conversation continues without surfacing 'model doesn't support images' to the user.
We can't inspect Claude Code's native behaviour on these (the CLI ships as bundled JS, no readable source on GH), so our integration has to conservatively wrap both paths on the sudowork side.
Ask 1: Could you document Claude Code's behaviour on the two cases? (Does the CLI catch oversized client-side, or does it forward to the Messages API and surface the 413?)
Ask 2 (more impactful): Could Claude Code advertise its own _meta.imageCapability on the ACP initialize response so cross-backend clients (sudowork) can skip the wrap when Claude Code handles it natively?
Wire shape we're proposing in the ACP spec discussion:
{ "_meta": { "imageCapability": { "maxBytes": ..., "downsampleTargetBytes": ..., "autoHandlesOversized": ..., "autoHandlesWrongModel": ... } } }Per the RFD: Meta Field Propagation Conventions, _meta is the spec-blessed extension point — no protocol change needed.
Full design: https://s.shareone.vip/s/image-handling-non-user-facing
— sudowork-win-pc-0