Skip to content
Agent

Image attachments

Attach up to 10 images and the agent sees them — screenshots, designs, diagrams.


Image attachments ship with the next app release. If your build's + button doesn't open a picker yet, grab the latest version from the download page.

A screenshot of a broken layout, a photo of a whiteboard diagram, an error dialog you can't copy text from — sometimes the fastest way to explain a problem is to show it. The + button in the agent input footer attaches images to your next message, and the agent sees them. It also attaches PDFs, on the models that can read one — see PDFs and other documents.

Attaching images

Click + to open the file picker (multi-select). Each chosen image becomes a thumbnail chip above the input, with an to remove it before sending. Type your prompt alongside, or send with no text at all — an image-only message is fine ("what's wrong in this screenshot?" can literally be just the screenshot).

When you send, the thumbnails render inside your turn in the transcript, so the conversation reads back correctly later.

Limits and processing

RuleValue
Images per messageup to 10
Image sizeup to 50 megapixels each (an 8K screen capture is 33)
Source file sizeup to 128 MB each
Formatspng, jpg/jpeg, webp, gif (plus pdf — see below)
Downscalinglongest side reduced to 1568 px automatically

Everything happens locally before upload: Mel validates, downscales oversized images (1568 px on the longest side is the common vision-model limit — more pixels wouldn't help), and re-encodes efficiently. A big file is not a problem — a 40 MB Retina screenshot is a few hundred kilobytes once it has been through this, and when an image is downscaled Mel says so on one line above the input, so you always know the model saw a smaller version than you did. What Mel does refuse is an image with an unreasonable *pixel count*, which is about memory rather than bytes: a modest file can declare dimensions that would need gigabytes to open.

Files that don't qualify are skipped with a per-file message telling you why (too many pixels, unsupported format, not a valid image) — the rest still attach, and the message stays up until you dismiss it or send your next prompt. The total payload across all attachments is also bounded so the request always fits the backend's size limit; an image that would blow that budget is re-encoded rather than refused.

The picking and processing run in the background, so attaching a handful of multi-megabyte screenshots doesn't freeze the input.

Vision routing

Attaching images changes how model routing behaves for that turn:

  • With the chip on auto, the router picks a vision-capable model — and any fallback stays vision-capable, so your images are never silently dropped partway through.
  • If you've pinned a model that can't see images, the turn is upgraded to a vision model, and the router info in the transcript says so.
  • If no vision-capable provider is available at all, you get a clear error instead of an answer that quietly ignored the images.

Each image costs roughly a thousand tokens of context — visible in the context gauge like everything else. The wire format is documented in Agent streaming.

PDFs and other documents

The same + button attaches a PDF, and the agent reads it — the document itself, not a picture of a page.

Which models. Reading a PDF and seeing an image are two different abilities, and a model can have one without the other. Today PDFs travel to the Claude models. Leave the model chip on auto and it is handled for you: the turn is routed to a model that can read the document, and the transcript's router line says which one. Pin a model that can't, and the picker offers images only — with a line telling you to switch to a Claude model or back to auto. You will never pick a PDF that then gets silently dropped on the way out; that refusal is deliberate, and it is why the list of file types in the picker changes with the model you have selected.

What happens to the file. Nothing. Unlike an image, a PDF is sent exactly as it is on disk — there is no downscale to apply and no re-encode it would survive. It appears above the input as a labelled chip (name and size, no thumbnail — a PDF has none), and your sent turn records which file you attached.

A PDF counts against the same per-message payload budget as images, so a very large one may need to go on its own. A file named .pdf that isn't one is refused up front rather than sent and answered from nothing.

Good uses

  • UI bugs — screenshot the rendered page next to the expected design; ask the agent to find and fix the CSS.
  • Error dialogs and TUIs — anything where the text isn't selectable.
  • Diagrams — architecture sketches or whiteboard photos as context for "build this".
  • Before/after comparisons — attach both and ask what changed.
  • A spec, a datasheet, an invoice — attach the PDF and ask for the parts you need, instead of copying text out of it.