Agents tidy up folders after generating images (sort into subfolders, rename
revisions); the image records kept the old path, so /api/images/<id>/file
answered 404 and only the requesting device still showed them from its cache.
- Generated images get a copy in the image store (images.blob, kept by the
blob GC); existing ones are copied once on start-up.
- Records follow: after bash commands with mv/rename (missing images of the
owner from the last two weeks, found by name or by content hash), when moved
with the file manager (file or folder), and on access (served from the copy,
relocated in the background; without a copy found by file name).
- Chat gallery falls back to the preview the model saw when the file is gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Images of messages (pasted images, screenshots, generated images) were base64
inside the message JSON, so opening a chat downloaded all of them at once
(66 MB for a chat with 120 screenshots). They now live in a `blobs` table,
addressed by SHA-256; messages keep a reference (blob, size). The UI loads
them from /api/blobs/<hash> lazily with an immutable cache header, the runner
fills the bytes in before model requests, JSON exports stay self-contained.
- Store::add_message moves inline images out; large opaque PNGs become JPEG
(q85) when smaller. Older chats are converted once at start-up in the
background, unused images are removed (also after deleting a chat) and the
database is vacuumed when that frees 32 MB or more.
- Responses are compressed with gzip/brotli (not images, SSE streams or
binary downloads).
Example (copy of production): chat load 66 MB -> 1.5 MB (370 KB brotli),
database 90 MB -> 27 MB.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Richard ZinkandClaude Opus 5.5