The Lantern’s signature feature: AI-generated landscape images that appear behind your chat content at 45% opacity, creating a visual sense of place for each conversation. Not a generic wallpaper selected from a library—an image derived from the actual content of your chat, featuring the characters as they currently appear, in a setting that reflects the mood and narrative of the conversation.

The Lantern also chooses his discretion per picture rather than exercising it by reflex. His prompt writer has long carried a passage on depicting intimate or unclothed states—a sheet draped where one is wanted, a silhouette, an occlusion in the foreground, a bath observed at a discreet level—which exists to carry a prompt past a provider’s moderation, and which used to be applied to every background regardless of where it was bound. A chat marked dangerous, with an uncensored image provider configured for exactly this eventuality, therefore received accurate appearance text and then had a sheet thrown over it, to clear an inspection nobody at the destination was conducting. The guidance is now selected per call: cinematic concealment by default, candid depiction where the picture is going somewhere that does not require the sheet. Both variants keep every rule of framing—figures toward the edges, the environment primary, a wide atmospheric shot, never an anatomical close-up—and neither will re-dress a character the narrative undressed. The choice follows the picture, too: a reroute to a different provider gets a prompt written for the provider it is actually going to, which is the Concierge’s affair and told on his own page.

Every chat gets its own avatars. When a character joins a conversation, the Lantern composes their portrait from their physical description and whichever outfit was selected at chat start; when their wardrobe changes mid-chat, the portrait regenerates to match. The image you see beside a participant’s name today is the portrait of this character, in this chat, in this outfit—not a stored default rolled forward indefinitely.

The Lantern has also learned some tact about framing. A character whose wardrobe leaves the upper body bare—an “Active Nudist” outfit, say—used to defeat a SFW image provider outright: the head-and-shoulders prompt reached far enough down to put a bare chest in frame and named it “topless,” and the provider refused on content moderation. Such portraits now crop tighter—a close-up headshot at the collarbone, with the chest and torso out of frame—and omit the “topless” and “naked” wording entirely, the same way lower-body slots are already left off a portrait. Bare shoulders and neck trouble no one; the tighter framing keeps out of the picture the one thing that would be refused. Accessories above the collar are still described, and clothed characters are untouched.

Left entirely to himself, the Lantern paints each picture in whatever manner the moment suggests, and so an avatar, a story background, and a character’s conjured snapshot may arrive looking as though they hailed from three different ateliers. The Default Aesthetics put an end to that disorder. Write a few lines of guidance once—“everything here is rendered as 1920s art-deco illustration,” or “anime,” or “swords-and-sorcery oil painting”—and that house style is woven into the prompt for every image the establishment produces.

The two resolve independently, so you may dress your people in one tradition while setting your scenes in another. Both fields wait on the Images settings tab, in the Default Aesthetics card; neither is a hidden setting squirreled away in some ledger, each being simply a tidy view onto a file in your Quilltap General document store (lantern-aesthetics.md and aurora-aesthetics.md), which you are perfectly welcome to drop in by hand instead. A project may keep its own house style on Prospero’s Image Generation card, overriding either field—or both, or neither—while the rest quietly inherit.

Beyond story backgrounds, the Lantern handles all on-demand image generation within conversations. A generate_image tool is available to every character, invocable by the AI mid-conversation or by you via the composer toolbar. Results land in a per-chat gallery for reuse as avatars, attachments, or conversation context.

Two OpenRouter faults were mended in 4.8, both of the sort that fail in one direction only and are therefore very hard to see. OpenRouter had not been discovering image or embedding models at all—not since its library began serving that catalogue a page at a time. Three of the four places that asked for the list were still asking the old way, got nothing for their trouble, and fell back to a short built-in roster while reporting what looked for all the world like an empty answer from the far end. All of them now turn the pages, and an OpenRouter profile offers the models it actually has.

The second was quieter and worse: OpenRouter sent no image at all on the non-streaming path—a regenerate, or a continuation—because its library rejected the picture at the door on the way out, over a spelling disagreement nothing surfaced. Streaming had been perfectly fine the whole time, which is precisely why the fault survived as long as it did. The client, for its part, was declining to offer attachments on OpenRouter profiles while the plugin was busy emitting them. Both sides of that misunderstanding have been settled.

The logs also learned to keep better books: every generation now records which image profile served it, so the Almanack can report image spend per profile rather than as one undifferentiated heap.

The image-profile editor has since learned to ask. It carries a Fetch Models button now and—rather more to the point—something for that button to do. Four of the five ateliers then capable of painting had been answering the question “what models have you?” by reciting the roster already printed on their own letterhead, handed over with perfect composure whether or not an API key had been supplied; only OpenRouter ever troubled to enquire. Each now genuinely puts the question to its provider, and filters the reply down to models that actually produce pictures: OpenAI to the Images-API families, Google to imagen models exposing predict together with gemini models that emit images, Grok to xAI’s dedicated endpoint, Z.AI to its image-model set. Without a key you get the curated list, unchanged and unembarrassed.

The honesty is the whole of the point. When a live enquiry fails, the provider now says so plainly rather than quietly substituting its built-in roster and letting the substitution pass for an answer—so the reply can label itself, as coming from the provider or from the house catalogue, and the form tells you which of the two you are looking at. Only genuinely live lists are kept on file.

Z.AI became a real image provider in the same stroke. The plugin had shipped one for some time, but the interface never wired it up and generation did not work end to end: Z.AI answers with a URL pointing at the picture, every consumer in Quilltap reads base64, and so a finished image evaporated somewhere between the atelier and the wall. The provider now fetches the URL and hands over the bytes.

Automatic image resizing handles provider size limits—Anthropic caps at 5 MB, others at 20 MB. Images paste directly into the chat composer, are auto-uploaded and attached, and can be tagged to characters for gallery organization. For chats flagged by the Concierge, both user prompts and their expanded versions are classified, and generation reroutes to an uncensored image provider when needed.

An image profile may now carry a list of LoRA adapters—rows, each naming a source, a scale, and a trigger phrase. An adapter is a small parcel of trained weights that leans a base model toward a style, a subject, or a look you will not reach by prompting, however patiently you phrase the request; one hands the model the thing rather than describing it. The rows live in the profile’s existing parameter bag, so there is no schema change and no migration to sit through. A provider opts in by declaring the capability—per model, or provider-wide—at which point the house shows the editor, caps the list at whatever that model will actually take, and hands the adapters over at generation time. A plugin that declares nothing never sees the key, so no other provider changed by so much as a comma. NanoGPT is the first to take up the offer, mapping the one canonical list onto whichever of three wire dialects the chosen model family happens to speak.

Each row carries a Query button beside its Source, and it is the most useful thing on the panel. It reads the repository’s public card off HuggingFace and reports what the card actually says: the base model it names, whether the repository is tagged as an adapter at all, which .safetensors files it holds, whether it is gated, how many people have downloaded and liked it, and the trigger phrase declared in its metadata—which one further click copies into the row. Nothing else in the row is touched, and the Source is never rewritten. The lookup runs on the server, so your browser never so much as nods at HuggingFace, and an optional access token never travels in a query string.

Two facts are stated in the panel because both have consequences. A repository holding more than one .safetensors file is ambiguous when named as a bare owner/name, and the provider will pick for you. And a gated repository wants a token, which only some models will accept. A 401, meanwhile, is reported as “missing or private” rather than “does not exist”—HuggingFace answers identically for a repository that is absent and one you are merely not allowed to see, and the panel declines to guess which sort of disappointment you are looking at.

What the help covers instead is the failure that raises no error at all: an adapter trained against a different base model than the profile points at, a missing trigger phrase, or a prompt that never asked for the thing the adapter was brought in to supply. Story backgrounds get their own note, having two conditions of their own—the chat must genuinely be taking the uncensored route, whether by the Concierge’s verdict or your own instruction, and the adapter must sit on the profile named under Uncensored Providers rather than on whichever profile the chat happens to be using—along with how to tell those two disappointments apart afterwards, by reading the prompt stored on the finished picture.

Not every chat model has eyes. When a character runs on a text-only model and a freshly generated image is sitting in the conversation—a new avatar, a story background, a generate_image result—the Lantern has to turn that picture back into words the model can read. For an image he painted himself, he already holds the most faithful description there is: the exact prompt that produced it. He now reuses that stored prompt directly instead of dispatching the image on a slow vision round-trip, so what used to add minutes to a reply now costs nothing. The vision model is kept in reserve for genuinely unknown pictures—user uploads he has never described—and even those are handled with some discipline: the image is downsized to whatever the describing provider will actually accept, the errand is entered in the LLM logs as an IMAGE_DESCRIPTION so it can be costed like any other call, and the whole business runs under a firm sixty-second limit. A slow describer can no longer wedge a reply while everyone waits.

There is a second question here, and it is not the one everybody assumes. A connection profile’s Supports image attachments checkbox says that the model can read pictures. It says nothing whatever about whether the plugin can get one onto the wire, and those are two different questions with two different answers. Both are asked now, through a single predicate that consults the plugin registry: where the model can see but the plugin cannot send, the request routes to a description instead of losing the picture. The same check guards the choice of describer, which had otherwise been perfectly willing to appoint one that could not receive the image either. A box that means one thing while the wire does another is exactly the sort of quiet dishonesty this establishment declines to keep on the premises.

The same confusion turned up twice more before the cycle closed, which is how a principle gets settled. The Z.AI plugin kept a private list of which GLM models read pictures and matched only ids carrying a v after the generation number, so glm-5.3-flash—which reads images perfectly well without one—had every attachment stripped on the way out while the profile’s own checkbox asserted the opposite. And the Concierge’s uncensored reroute carried the message array built for the original profile across to a text-only substitute, handing raw bytes to a stand-in that could not read them. The private list is deleted rather than extended, and the reroute asks the question again against the profile it is actually about to call. The principle is worth stating plainly, being the through-line of all four: whether a model can see is the house’s question, answered by the profile; whether the transport can carry the bytes is the plugin’s, answered by a MIME check. There is one predicate for it now, and every site calls it. A question with three independent spellings is a question with three independent answers, which is a thing no well-run establishment permits for long.

The Lantern does not work alone. Every image—whether a story background or an on-demand generation—passes through a pipeline that draws on multiple subsystems:

The Lantern is not a silent technician. When he generates an image he says so, and with reasonable specificity: a freshly composed character avatar after an outfit change, a story background after a scene shift, or a one-off character image conjured by a generate_image call. Each kind of announcement carries a stable systemKind—avatar, background, or character-image—so the Salon can render the more frequent ones (avatar regenerations especially) as collapsible bars rather than full-message rows that crowd the transcript.

The body of each announcement carries the prompt that was actually sent to the image provider, not a pre-expansion summary—so the LLM in the conversation can read precisely what the Lantern crafted on its behalf and adjust subsequent narration in light of it. Opaque characters—those without systemTransparency—continue to receive the body of the announcement as an anonymous assistant line; only transparent characters see his attribution and his portrait. As with every other Staff announcement, a posting failure logs and moves on rather than disrupting the work it was annotating.

When a generation fails, he now reports what actually went wrong. The server composes a perfectly serviceable sentence for the occasion—Image generation is not enabled for this chat, say—and that sentence is what the notice and the toast both carry, in place of the generic apology they used to offer whatever the cause. The notice above the composer also owns its own lifetime now: a settled result dismisses itself after a few seconds, there is a close button for the impatient, and stopping a turn clears it at once. It no longer stands pinned above the composer for the remainder of the evening, announcing an errand that concluded some hours ago.

He is, taken across an active session, the most prolific speaker on the Staff. This is forgiven on grounds of contribution: he is also the only member of the household who is visibly thrilled to be on the team.

Generated images are not ephemeral. They are stored in the file system, tagged to chats and characters, and browsable through the file browser with grid and list views, image thumbnails, and a preview modal. Images can be set as character avatars, attached to messages, or used as default character portraits. A character’s photo gallery collects every image tagged to them across all conversations.

File deletion respects associations: if an image is linked to a character as an avatar or gallery item, the deletion dialog shows all affected entities before proceeding. Orphaned image references render a cleanup prompt rather than broken thumbnails. The Lantern may be artless, but his filing system is not.

Every full-size viewer in the house now carries a Download button. Several had none at all, which is a real inconvenience in the desktop shell, where right-click → Save Image is simply not on offer; two more hand-rolled the anchor-click trick and thereby contrived to miss the native save dialog. All of them go through the same shell-aware helper now, so a picture saves the way the operating system expects it to.

Characters keep albums of their own, and are furnished with four brass-handled instruments for the purpose: keep_image(uuid, caption?, tags?) saves a picture, list_images(…) searches the album by semantic similarity or by tag, attach_image(uuid) brings a kept photograph back into the conversation, and describe_image(uuid) says what is in one. The fourth is the newcomer, and its absence had been felt. The original three were all custodial—file this picture, show this picture to the room, read me the catalogue—and not one of them answered the only question anybody actually puts to a photograph, so a character wanting to know what it depicted reached for the show-it instrument and was told, with perfect correctness and no help at all, to file the image first. describe_image serves the description written at upload, or the prompt that produced a Quilltap-made picture, or a fresh vision call, and it does not require the photograph to be in the caller’s album at all. The pictures live in a photos/ directory inside the character’s own vault, hard-linked rather than copied—which is what keeps the thirty-day chat cleanup from reaping a photograph somebody meant to keep. Each kept image carries a small Markdown context document beside it (the prompt, a snapshot of the scene as it stood, the caption, the tags), chunked and embedded like any other document, so even a character running on a model with no eyes can reason about a picture it cannot see. The whole apparatus is gated behind the Document Editing tool toggle, an album being, in the end, a folder.