Summary
In Kimi Code Web, images pasted by the user into chat intermittently fail to reach the model. The message then contains only the placeholder text:
[image omitted for provider compatibility; re-read the file to view it or get conversion guidance]
In the same session, one image was delivered via the compression path (3072x1824 → 2000x1188, with a system-reminder pointing to the uncompressed original under ~/.kimi-code/sessions/.../media-originals/). So the compression pipeline works — but the decision of when to compress vs. drop appears inconsistent.
Observed behavior (single session, 2026-07-22, ~8 pasted PNG screenshots)
- Most turns: image dropped entirely; only the placeholder above is visible to the model.
- One turn: compression path triggered, image delivered fine.
- Consequence: when an image is dropped, the model cannot reliably tell that an attachment ever existed (the placeholder reads like a generic compatibility notice). In one instance the model hallucinated having seen the image and described wrong content — a silent failure mode that is worse than a clean error.
Expected behavior
- Images should either always be delivered (downscaled/compressed as needed), or
- when an attachment is dropped, the model should receive an explicit, structured signal that an attachment was removed and why (e.g. unsupported format, size limit), rather than an ambiguous placeholder.
Suggested investigation
- The provider-compatibility check for image attachments in the web client: under what conditions does it route to compression vs. drop the image entirely?
- Whether dropped attachments should emit a model-visible notice distinct from the current placeholder.
Note
This issue was filed by the agent running in the affected session, at the user's request (the user intends to work on a fix). A full timeline of the affected turns is recorded in the session notes and can be provided if useful.
Summary
In Kimi Code Web, images pasted by the user into chat intermittently fail to reach the model. The message then contains only the placeholder text:
[image omitted for provider compatibility; re-read the file to view it or get conversion guidance]In the same session, one image was delivered via the compression path (3072x1824 → 2000x1188, with a system-reminder pointing to the uncompressed original under
~/.kimi-code/sessions/.../media-originals/). So the compression pipeline works — but the decision of when to compress vs. drop appears inconsistent.Observed behavior (single session, 2026-07-22, ~8 pasted PNG screenshots)
Expected behavior
Suggested investigation
Note
This issue was filed by the agent running in the affected session, at the user's request (the user intends to work on a fix). A full timeline of the affected turns is recorded in the session notes and can be provided if useful.