Runs, variants, references
One generation event becomes a Run, each output receives stable Variant identity, references stay linked, and project assignment can change without destroying original lineage.
We built Benji because image generation got fast enough that creation stopped being the bottleneck. The harder problem became preserving what made each image useful: the prompt, references, conversation context, project, variants, lineage, and a durable path back to the original work.
When image generation happens at high volume, the file is only half the asset. Without the prompt, source chat, references, variants, project assignment, and lineage, useful work quickly turns into a folder of orphaned images.

Benji is not an image generator. It is the continuity layer around one. The important decisions were about identity, provenance, storage, retrieval, diagnostics, and how to keep all of that out of the creator's way.
One generation event becomes a Run, each output receives stable Variant identity, references stay linked, and project assignment can change without destroying original lineage.
The image, generating prompt, source-chat evidence, references, notes, and detectable provider metadata are captured as one recreation package.
Canonical files remain durable while logical organization stays in application metadata. Search indexes and caches are rebuildable.
Saves carry traceable timing and outcomes so slow, partial, retried, or failed captures can be diagnosed without asking a creator to reproduce the problem manually.
These are the decisions that made Benji more than a download button and a folder.
A Run can contain multiple Variants, references, a source chat, prompt context, notes, and lineage. The image remains useful because its creation context survives with it.
TRADEOFF: richer metadata and identity management in exchange for reproducibility and continuity.Projects can change without physically moving canonical assets. Drive provides durable storage while the gallery owns the creator-facing organization model.
TRADEOFF: catalog/index complexity in exchange for stable files and flexible organization.Benji records structured save behavior, retries, partial captures, parser drift, and timing, while explicitly avoiding arbitrary keystrokes, unrelated browsing, cookies, credentials, or tokens.
TRADEOFF: more engineering around traces and issue states in exchange for debuggability without burdening creators.The shared gallery checks a tiny health endpoint, refreshes only when the catalog changes, preserves route/search/focus/scroll, dedupes by Run ID, and pauses polling while hidden.
TRADEOFF: careful client-state handling in exchange for a gallery that can stay open all day without reload churn.Generated images, prompt, source conversation, and references.
Parser, queue, local persistence, issue handling, sync, status dock, and diagnostics.
Project, Chat, Run, Variant, Reference, and future promoted-asset identity.
Originals and canonical metadata persist outside the browser.
Logical organization and optimized previews derive from canonical records.
Projects, Recent, Favorites, Unassigned, detail views, metadata editing, and live sync.


Run 04 focused on a deceptively hard interaction: new creative work should appear in the shared gallery automatically while somebody is already browsing it, without losing their place or causing duplicate content.
The implementation used a 45-second health poll, catalog revision checks, selective shard refresh, Run-ID dedupe, viewport anchoring, hidden-tab suspension, and recovery from background failures.
The product stayed deliberately focused on preserving and retrieving creative work rather than becoming a general browser monitor or an AI governance layer.
Benji is a workflow-engineering project disguised as an image library. The useful part is not the gallery alone. It is the chain that keeps an AI-generated asset connected to the context that made it valuable, while remaining durable, searchable, diagnosable, and lightweight enough to use every day.