Support image attachments in prompts

[SamuelGaitkoski]

Problem
Reasonix currently support text-based prompts, but I could not find a way to include image attachments as part of a prompt.

This would be useful when working on tasks where visual context matters, for example:

• asking the agent to inspect a screenshot of an error
• sharing UI screenshots when requesting frontend changes
• providing diagrams, mockups, or visual references
• attaching images directly instead of manually describing them in text

This would be really helpful in coding workflows, where screenshots often contain important context that is hard or slow to describe accurately.

Proposed change
Add support for passing images along with a prompt.

Alternatives considered
The current workaround is to manually describe the image in text or paste OCR/extracted text from the image. That works for simple screenshots, but it loses visual context such as layout, spacing, colors, alignment, and UI state.

Another workaround is to upload the image elsewhere and paste a link, but that adds friction.

Scope check

• This belongs in core reasonix (not better as a separate npm package)
• I've read CLAUDE.md and CONTRIBUTING.md

[esengine]

Thanks for the careful writeup — the use cases are real and well-framed.

The actual blocker is upstream, not a Reasonix design preference: the DeepSeek chat API doesn't currently accept image inputs. Even if we wanted to ship this today, there's no DeepSeek endpoint that would receive the attachment. That's the root cause.

The follow-up question is "could we just route image prompts through a different provider?" — and that's where positioning comes in. Reasonix is DeepSeek-only on purpose, with every layer tuned around DeepSeek's prefix-cache pricing (the README calls this out as a deliberate constraint). Supporting image input via a second provider would mean:

• adding OpenAI / Anthropic / Gemini as a vision route
• restructuring `ChatMessage.content` from `string | null` into a block-array shape
• maintaining a parallel codepath that doesn't benefit from the prefix-cache optimization the rest of the loop is designed around

Each of those is a meaningful architectural shift, and together they'd dilute the "cheap by default" thesis that's the reason the project exists.

So this is "no, not while DeepSeek's chat API is text-only" — not "no, never." If DeepSeek ships vision on the same prefix-cache pricing model, the calculus flips and this becomes a natural feature to land. Until then I'd rather spend the surface area on things that compound on the cache thesis (tool-result handling, context budgeting, reconnect).

Leaving this open as a tracking issue for that future. If you need screenshot-to-context today, a multi-provider agent (Claude Code, Cursor, Aider with a vision model) is the right tool for the job — Reasonix isn't trying to be that.

Thanks for filing it cleanly — the scope-check + alternatives section is appreciated.