Attaching Files and Images
Besides plain text, Ora understands images (screenshot, diagram, error dialog — anything the model can look at) and text files (logs, JSON payloads, configuration) that you attach to a message. Images require a vision-capable model; text files work with every model.
Quickest Scenario: Paste a Screenshot
- Take a screenshot.
- Paste it into the chat box. A thumbnail chip appears above the composer.
- Type your question ("what does this error dialog say?") and send. The model receives the image together with your text.
Vision-capable models carry a small eye glyph after their name in the model picker, and the attach button's tooltip says "Attach files (images need a vision model)". If the selected model cannot take images, the button is disabled with the tooltip "The current model does not support images — pick a vision-capable model in the model picker", and a paste attempt answers "The current model does not support image input. Select a vision-capable model to send images." Switch to a name with an eye after it and the button re-enables — no restart, no re-attach needed.
Screenshot: the Ora panel with an attached image chip above the composer, and the model picker showing the eye marker on a vision-capable model.
Other Ways to Attach
- File picker — click the attach button. The dialog filters for text files (
txt,json,xml,yaml,md,http,cs,py,js,ts,sql,env, …) and images (png,jpg,jpeg,gif,webp,bmp), multiple selection allowed. - Drag and drop — drag files from your file manager onto the chat area; a highlight shows the drop target.
- Paste an image file — an image you copied in your file manager pastes as an attachment too.
Text files and images can be mixed freely in one message.
What Happens on Send
Images are sent through the model's native image input. Ora prepares them for you:
- The long edge is downscaled to at most 1568 px and re-encoded as JPEG (quality 85). A small image is passed through unchanged.
- GIF files keep their original bytes so the animation survives.
- Formats: PNG, JPEG, GIF, WebP, BMP.
Text files are inlined into your message as labelled fenced code blocks —
[Attached file: swagger.json — 24 KB] followed by the file content. Ora knows the syntax of
json, yaml, xml, html, http, sql, csharp, python, javascript, typescript and
markdown and labels the fence accordingly; other files are inlined as plain text.
Limits and Error Messages
| Limit | Value |
|---|---|
| Attachments per message | 5 |
| Text file size | 50 KB per file |
| Total text size per message | 200 KB |
| Image size (raw file) | 20 MB |
When a limit is hit, the file is skipped and an error bubble states why:
- "File {name} is too large ({size} bytes). Maximum size is {limit} bytes."
- "Too many files. Maximum is {n} attachments per message."
- "Total attachment size exceeds the limit ({limit} bytes)."
- "Could not read the image '{name}'. Use PNG, JPEG, GIF or WebP." — also shown for images
whose declared dimensions are absurd (a decompression-bomb guard reads the header first, before anything is decoded).
Remaining valid files in the same batch are still attached.
After Sending
- Image thumbnails appear above your message in the transcript. Click a thumbnail to open the full-size image in a preview window; open its context menu for a Copy image item.
- Text files appear as regular message content once rendered.
- Images you attach travel with Ora's dispatches to its specialists too — a request-building specialist still "sees" the screenshot from the same turn.
What a Restored Conversation Keeps
Attachment payloads are session-scoped and never written to disk — neither file content nor image bytes. When you reopen an old conversation:
- The image chip remains as a placeholder (name, size), and the conversation history records a note like [Image attachment: {names} — image data is not retained across sessions] — so the model on later turns knows an image existed and why it cannot look at it again.
- A text file's chip remains with its first ~200 characters as a preview; the content itself was discarded (a resent reference shows "[content unavailable]").
If the model needs the file again, attach it once more — a restored conversation never silently re-uploads (and re-bills) old payloads.