Artifacts, files & deliverables

Everything that arrives in your workspace — a website, a PDF, a cleaned-up dataset, an edited image — moves through the same small set of surfaces: the download card in chat, the artifact panel beside it, and the plain files underneath. Knowing the path matters twice over: it’s how you get your work out, and it’s how you stay sure that nothing is hidden behind an agent’s summary. In Sonderr the deliverable is a real file on your machine, served by a local API you can inspect — never a blob that lives inside somebody’s cloud session.

1 · From deliverable to download card

When the model finishes a deliverable it calls present_file, and the chat renders a download card — a compact, named representation of the file, served by the sandboxed local API that the workspace itself runs on. The card is not a screenshot of the work and not a description of it; it’s the actual file, one click away. This is a deliberate honesty mechanism: “done” claims are cheap, but a card backed by a real file either opens or it doesn’t.

Clicking the card opens the artifact panel: a side column that goes full-screen on mobile, showing a live preview of the deliverable with copy and download actions in the header. ESC closes it. The panel exists so that reviewing work doesn’t mean downloading everything just to look — read it in place, then decide.

2 · What the panel can preview

The preview body adapts to the file type instead of dumping raw bytes:

• Markdown renders as formatted text, so documents read like documents.
• Code arrives syntax-styled — review the diff-worthy details in place.
• JSON comes pretty-printed, so API responses and configs are actually readable.
• CSV / TSV render as a real table — data files become scannable instead of a comma swamp.
• Images show full-bleed on a checkerboard, so you can see exactly where the asset ends.
• Binaries — PDF, ZIP and everything else — land in a download-first state: the panel tells you what it is and hands it over, rather than pretending to preview what it can’t.

The download-first state for binaries is the same honesty rule applied to itself: the panel never fakes a preview. If it can’t render it, it says so and gets out of the way.

3 · Where files actually live

Nothing about this is magic. Your sessions, artifacts and store live under ~/.sonderr/ on your machine, with credentials kept owner-only. Files the agent creates land in your workspace directory like files from any other tool — which means normal file manager, normal backups, normal grep. The full data map, including the app folder and the launcher link, is documented in the CLI reference, and the local-first reasoning behind it is in Your data, your machine.

The practical consequence: deleting Sonderr does not delete your deliverables, and your deliverables do not depend on Sonderr staying installed. A website produced in a Studios run is a folder of files. A report is a PDF. Take them anywhere.

4 · Getting files in: uploads

The + menu in the composer has Upload from device, and the faster paths — clipboard paste and drag & drop — work too, with a drop overlay confirming the zone. Uploaded files are stored under .sonderr/uploads/<session>/ with name de-duplication and a 20 MB cap per file. The storage rule is per-session on purpose: an upload belongs to the conversation that needed it, not to a global pile you’ll never clean out.

What happens next depends on the type. Text files attach as context — the agent reads them like any other material in the task. Images switch Sonderr into Vision mode automatically, because an attached screenshot is usually the task: OCR the receipt, debug the error dialog, match this mockup. Binary files attach as readable references instead of being force-decoded into garbled context — the agent knows what the file is and can work with it honestly rather than hallucinating its contents.

5 · Artifacts stay attached to their task

Deliverables in Sonderr don’t float free of their history. Everything lands in the same live task-card machinery as normal work: the Build task that produced the file keeps its plan, its checkpoints and its evidence, and the artifact arrives attached to the todo item it justifies. When a marathon task runs for hours and produces ten files along the way, you can trace every one back to the step that created it — and every checkpoint forward from the brief that started it.

This is also what makes the checkpoint system more than a crash diary. “Show me the evidence for step 3” works because the evidence — including produced files — is recorded where the steps are. The deliverable and the work are one record, not two.

6 · Taking work out

Three exits, all boring by design. Download from the card or the panel header — the file lands in your browser’s normal download flow. Copy from the panel header for text, code and JSON — formatted output, not a re-render. Or skip both and take the file directly from the workspace directory with your own tooling; the local API serves previews, but it is never a gate around the bytes. Your data has no lock. That’s the point of local-first, and it applies to outputs as much as to sessions.