When you send a message, the LLM does not receive just your words. But it also no longer receives a single monolithic briefing re-assembled from a dozen subsystems on every turn—an arrangement that was correct in spirit and ruinous in practice, because every minor change to outfit, status, or memory invalidated the entire prompt’s cacheable prefix and forced the provider to re-process the character’s identity from scratch.

The current architecture is built around two stable system blocks and a transcript that does most of the talking. The first system block is the precompiled identity stack: preamble, base prompt, personality, aliases, pronouns, physical description, example dialogues, with {{user}}, {{scenario}}, and {{persona}} already resolved. It is computed once per participant when the chat is created (or when a participant is added or their selected prompt changes) and then cached on the chat row. The second system block is the static identity reminder (“you are X; do not write dialogue, actions, or thoughts for any other character”). Together they form a long stable prefix that providers can prefix-cache, with a third smaller block carrying the rolling conversation summary and a fourth carrying any compressed history.

Everything that used to live in the system prompt as a moving target—scenario, status, the user’s persona, the other participants in the room, who joined under what circumstances, silent-mode rules, the current outfit and the wardrobe behind it, project context and project instructions, the conversation summary, the timestamp, recently-mentioned but absent characters, out-of-band image attachments, the memory recap that anchors a character’s recall—is now a chat-resident message authored by one of the Staff. Aurora announces an opening outfit and any subsequent change. The Host announces participants, status transitions, scenarios, off-scene character introductions, time, and silent-mode entries and exits. The Librarian announces summary regenerations, document opens and saves, and renamings. The Commonplace Book whispers a per-turn briefing of relevant memories and the current scene state. The Concierge announces, with characteristic discretion, that he has rerouted the conversation to a desk better appointed to subjects of its particular character. And Prospero himself—more on this in a moment—announces project context and connection-profile changes.

The user sees these messages. The LLM also sees them, as part of normal conversation history. The same paragraph informs both parties, which is both more honest and dramatically cheaper: provider prompt caches now actually hit, because the bytes that change between turns are at the end of the transcript rather than woven through the system prompt. The Anthropic plugin places its cache breakpoint on the running summary so that when the summary changes, only summary-and-after re-prefills; the system blocks stay hot. OpenAI, Grok, and Z.AI profiles set prompt_cache_key so requests stick to the same cache partition across machines. Tool definitions are canonicalized (alphabetical by name, schema keys recursively sorted) so that two runs with the same enabled tools produce byte-identical bytes.

The identity reinforcement still lands at the end of the system portion, so the model’s final instruction before writing is “you are this person, and no one else.” It just doesn’t have to ride along with three thousand tokens of wardrobe inventory to get there.

In standard mode, the LLM responds once per turn. In agent mode it can use tools iteratively—calling a tool, reading the result, deciding whether to call another, verifying its own work, and self-correcting before delivering a final response. A dedicated submit_final_response tool signals when the agent considers its work complete, scoped explicitly to the current turn’s agentic effort. A guardrail in the orchestrator rejects ghost wrap-ups in which the model, on a fresh conversational turn, calls submit_final_response with a recap of the previous turn’s work and no actual prose; the rejection is fed back into the loop with an explanation, and the next pass produces a real response.

Quilltap ships with a substantial set of built-in tools. The document family (the doc_* family) lets characters read, write, edit, search, and reorganize files in document stores and project libraries: doc_read_file, doc_write_file, doc_str_replace, doc_insert_text, doc_grep, doc_list_files, doc_read_frontmatter, doc_update_frontmatter, doc_read_heading, doc_update_heading, doc_move_file, doc_copy_file, doc_delete_file, doc_create_folder, doc_delete_folder, doc_move_folder, the blob family (doc_write_blob, doc_read_blob, doc_list_blobs, doc_delete_blob), and doc_open_document / doc_close_document / doc_focus for split-pane Document Mode interaction. The Scriptorium-aware search and read_conversation tools cover memory, conversation chunks, and document stores under one ranked retrieval. There is a self_inventory tool a character can call without arguments to receive an introspection report—current Quilltap version, vault contents, memory totals, conversation totals, the assembled system prompt, last-turn LLM usage, the memory slate loaded this turn, and who has read or write access to the character’s vault in the current chat. There is a state tool for persistent JSON state on the chat or project, an rng tool for honest dice, a wardrobe family (list_wardrobe, update_outfit_item, create_wardrobe_item), generate_image for the Lantern, web_search for the open Internet, annotation tools for marginal commentary on conversation renderings, and terminal_read / terminal_list for read-only inspection of any open terminal session in the chat. The retired file_management tool is no longer present; the doc_* family covers everything it did and more.

doc_list_files now filters out operating-system cruft (.DS_Store, Thumbs.db, and their ilk) and auto-generated images (avatars, story backgrounds) by default, so listings reflect the documents you actually wrote rather than the detritus the machinery left behind. An includeAutomaticImages flag brings them back for the rare occasion you genuinely want to browse them. doc_open_document’s companion picker in the Salon toolbar is a two-column affair: the left column offers a new blank document, the current project library, the general library, and a cross-chat “Recent” list; the right column groups every accessible store into Character Vaults, Database-backed, and Filesystem-backed accordions so you can find the shelf you want without scrolling past shelves you don’t. A “Look everywhere” toggle widens browsing to all stores in the instance, not just those linked to the current chat or project.

For models without native function calling—or models that spontaneously emit XML instead of using their own tool-calling API—Prospero handles that too. Provider plugins implement text-marker detection and parsing, catching tool calls in DeepSeek XML, Claude-style XML, and several other formats that various providers have invented for the purpose of not quite following the specification.

A project is a container for related chats, files, characters, and scenarios with optional instructions that travel with every chat the project owns. If you are working on a novel, the project holds your drafts, your character roster, your worldbuilding notes, your starting scenarios, and the instruction that tells every LLM in the project to stay in-world.

In VM and Docker modes, characters can execute shell commands inside the sandbox. Six tools—chdir, exec_sync, exec_async, async_result, sudo_sync, and cp_host—provide the full range of command-line interaction, from running a Python script to installing packages to copying results back to your host filesystem.

Beyond one-shot commands, the Salon also hosts live PTY sessions in a dedicated Terminal Mode, with terminal_read and terminal_list tools that let the LLM inspect output read-only. That entire apparatus—Terminal Mode itself, session lifecycle, output narration, the read-only tool contract, and the personified terminal hand who runs it—is Ariel’s domain, and is documented on her own page.

The workspace is acknowledged via a modal before first use. Sudo commands require explicit approval through a dedicated dialog. An Electron workspace file watcher monitors changes with binary detection and OS quarantine markers, so files created or modified inside the sandbox can be safely surfaced to the host. The system includes command warnings for suspicious operations, because giving an LLM a terminal without guardrails would be the kind of decision one regrets at leisure.

This is why Direct mode—which runs the backend using Electron’s own bundled Node.js—is recommended for users who do not need shell interactivity. If you are here for conversation, companionship, or creative writing, Direct mode is faster and simpler. If you intend to give your AI a terminal, the VM or Docker sandbox ensures it cannot reach anything you have not explicitly shared.

A slide-over panel accessible from the chat toolbar or via Cmd+Shift+L / Ctrl+Shift+L shows every LLM interaction for the current chat in chronological order: chat messages, tool continuations, two-pass memory extraction (SELF and OTHER), per-character memory recap summarization, title generation, danger classification, scene state tracking, conversation rendering, image-prompt crafting, image generation, outfit selection, embedding calls, summarization folds, and every other background event that touches a provider.

Each entry is a collapsible card with a type-colored badge, provider and model identification, prompt and completion token counts, cache-read counts, and expandable detail views showing the full request and response. Per-tier prefix hashes (systemBlock1, systemBlock2, tools, the frozen-history tail) are recorded alongside every chat-message log so you can see at a glance which tier shifted between turns when a cache hit unexpectedly evaporates. Client-side filtering by category lets you see only what you are looking for. Opening the panel from a per-message “View LLM logs” button scrolls directly to the relevant entry. The Inspector is Prospero’s ledger—the complete record of everything the Estate says to the providers and everything they say back.

LLM logs live in their own dedicated database, separate from your chats and characters. They accumulate rapidly and write constantly, so isolating them means corruption in the logs can never threaten your actual data. Graceful degradation, not shared fate.

Long conversations inevitably exceed any model’s context window. The current scheme is a rolling window with a triple-gate fold cadence. Below ten interchanges, no fold fires and the LLM sees the entire conversation. From the eleventh turn onward, every five turns the cheap LLM produces an update-style summary covering the next batch of five and the Librarian posts a broadcast summary whisper to the chat; older USER and character messages whose content is now covered by the running summary are dropped from the LLM’s view of conversation history. The surviving tail begins with the most recent Librarian whisper and extends through the most recent five-or-so turns in full.

Two gates can also force a fold: an eight-thousand-token accumulation since the last fold, which catches dense workloads before they swamp the budget; and a fifty-turn ceiling that triggers a hard rebuild, recomputing the summary from scratch to absorb any drift the incremental updates have accumulated. Most turns return skip and reuse the existing summary unchanged.

The summary is update-shaped on purpose: four labeled sections (active threads, resolved decisions, emotional state, open questions) with explicit carry-forward, drop, and add verbs. That framing reduces the recursive drift earlier from-scratch-each-time approaches accumulated. The summary lives as its own system block, so when it changes only it—and the messages after it—need re-prefilling; the persona blocks and the tools array stay byte-stable and stay in cache.

Edits do not silently invalidate. When you edit, swipe-delete, or otherwise change a message that the current summary covers, the compaction generation bumps, the cached summary clears, and the anchor list resets so the next gate evaluation produces a fresh soft fold. Edits to messages outside the summary’s scope leave the summary intact. The compiled identity stack invalidates on the same generation bump, so character changes during an active chat propagate cleanly without requiring a full rebuild.

A request_full_context tool is always available as a safety valve—if the AI suspects it is missing something the rolling window has shed, it can reload the full conversation for the duration of a single turn. This tool cannot be disabled, because Prospero believes the model should always have an escape hatch from his own optimizations.

There is a further economy for tool-heavy conversations. Persisted tool-result messages older than three turns—counted by assistant messages, not clock time—are stubbed in the assembled context: only the tool name and a short preview of its arguments survive, accompanied by a note that the model may call again to re-read. The stored message and the Salon display remain untouched; this is a context-assembly optimization only, invisible to everyone except the LLM’s next request. The savings are not trivial: a 587 KB conversation dump or an 1,100-file directory listing that would otherwise be re-billed on every subsequent turn now costs a handful of tokens instead of thousands.

Prospero now speaks at the table on two specific occasions, both of them genuinely his concern. He posts the project-context announcement at chat creation and on its cadence, naming every linked document store with its mount-point identifier and store type so the LLM knows precisely which shelf each doc_* call is addressing. And he announces connection-profile changes when you reassign a participant from one profile to another from the sidebar—naming the participant, the new profile, and the one it replaces.

Both messages carry the prospero systemSender attribution, render with his portrait in the Salon, and follow the same never-propagate-failure contract as the rest of the Staff: a posting failure logs and moves on rather than disrupting the work it was annotating. Opaque characters—those without systemTransparency—continue to receive the body of these announcements as anonymous assistant lines, while transparent characters see them properly attributed and can reason about them directly.

He does not announce trivia. There is no Prospero ping for message edits, no Prospero greeting on chat open, no Prospero commentary on routine traffic. When his name appears in the transcript it is because something orchestrationally substantive has occurred and the rest of the table genuinely benefits from knowing about it.