Multimodal in the terminal: screenshots, PDFs, and Gemini CLI

The terminal is a text pipe, so terminal agents inherit a text worldview, and a surprising amount of what breaks in real development is not text. It is a screenshot from QA, a vendor spec locked in a PDF, a photo of a whiteboard that stopped existing the moment everyone left the room. Gemini CLI accepts all of those as input, and almost nobody uses it that way.

The mechanics are one character. Type @ and a path (@bug.png, @vendor-spec.pdf) and the file rides into the prompt, straight into a natively multimodal model. No OCR pass, no describe-the-image-in-words step. The models behind the CLI were multimodal before they were coding models, and the @ syntax quietly exposes all of it; the quickstart covers the basics.

Bug-from-screenshot

The workflow that converted me was a layout bug I could not describe. Words are lossy: the dropdown clips oddly under the sticky header at medium widths. But the screenshot is ground truth. So I attach it, point a second @ at the component source, and ask what in this code would produce exactly this rendering. The model maps pixels to code better than it has any right to: z-index wars, overflow clipping, flex children refusing to shrink. For visual bugs, the screenshot is the only faithful bug report.

The same move works on pixels you did not produce: the error dialog a user photographed with a phone, a frame from a QA screen recording, the dashboard chart you want turned into a hypothesis about last night's deploy.

Spec-to-scaffold

PDFs are the sleeper feature. Integration work runs on documents nobody will ever re-type: vendor API specs, compliance checklists, sample invoices you need as fixture data. Attaching the spec and asking for every endpoint, auth requirement, and limit it mentions, then for a typed client scaffold, collapses the worst afternoon of an integration into a review job. The extraction will not be perfect. It does not need to be; it needs to be ninety percent done and checkable.

Whiteboards close the loop. A phone photo of the architecture sketch, attached with a request for a written design doc and a ticket breakdown, produces a draft while the discussion is still warm. It is the fastest path I know from decision to document, and it pairs naturally with using AI for documentation.

The killer feature: your terminal can finally show it the things you could never paste.

The tax

Two caveats keep this from becoming a default habit.

• Pixels are context-hungry. Images cost real tokens and PDFs cost more, so a long spec occupies a meaningful slice of even the million-token window. A conversation re-sends its attachments every turn, so a session carrying five screenshots gets slow and expensive without announcing it. Attach deliberately, and start a fresh session rather than letting images accrete.
• Vision misreads with confidence. Small text in screenshots, dense diagrams, and exact literals (hex colors, error codes, port numbers) are where the model quietly guesses. Treat every extracted literal as unverified until confirmed against a text source, and ask the model to flag anything it could not read cleanly.

The judgement call is simple. The moment you catch yourself transcribing an image into words (describing a layout bug, re-typing a PDF table, summarizing a whiteboard), stop and attach the thing itself. That reflex is the entire adoption curve. Budget the tokens like the real cost they are, verify anything that must be exactly right, and keep image-heavy sessions short. The capability has been sitting in your terminal for a while now. The bottleneck is remembering that the terminal can see.