Quilltap was not designed with a plugin system bolted on afterward. The plugin system is the delivery mechanism. Every LLM provider, every theme, every authentication method, every tool, every search backend, every moderation service, and every system prompt arrives as a plugin. There are no hardcoded provider lists, no conditional imports based on which service you happen to use. Adding or removing a capability means adding or removing a plugin.

In 4.0 the Foundry concluded—after some thought, and over breakfast—that an estate which has grown to include a furnace room, a generating station, and a guest-facing parlour is no longer usefully one building. The desktop application moved to its own residence at quilltap-shell: the splash screen, the VM management, the auto-updater, the native window chrome, and the Electron-based packaging that produces installers for macOS, Windows, and Linux. The Foundry—this repository—produces what it has always been best at producing: the Next.js server, the API, the bundled plugins, and a standalone tarball that the shell consumes. Two buildings, one estate, cleaner responsibilities, simpler builds.

To keep the buildings from accidentally disagreeing about the state of the furniture, .dbkey files now carry a minServerVersion field. The shell reads it on startup and politely refuses to open a database created by a server it does not understand—better to tell you the lock does not fit than to let you in and discover the rooms have been rearranged.

The active runtime is displayed in the application footer alongside the data directory path, plus the shell version and the composite backend mode (Electron, Electron+Docker, or Electron+VM) when running under the desktop app. Localhost URL rewriting transparently routes localhost and 127.0.0.1 URLs to the host gateway IP in Docker, Lima, and WSL2 environments, so provider connections and MCP servers work without manual network configuration.

Quilltap runs on SQLite exclusively. No MongoDB, no PostgreSQL, no external database container. Your entire data store is a file in your data directory, encrypted at rest with SQLCipher (AES-256), and hardened with the quiet thoroughness of someone who has already lost data once and has no intention of doing it again.

All of Quilltap’s data—database, files, logs, everything—resides in a single directory on your machine. The desktop shell lets you manage multiple named data directories from its splash screen, switching between them with a stop-and-start of the runtime. Each directory is self-contained: back it up by copying a folder, migrate it by moving one.

Platform-specific defaults follow OS conventions: ~/Library/Application Support/Quilltap on macOS, %APPDATA%\Quilltap on Windows, ~/.quilltap on Linux, and /app/quilltap in Docker (mounted from host). A QUILLTAP_DATA_DIR environment variable overrides all of them.

Files are stored on disk as themselves—real directories, original filenames, no hashed artifacts, no sidecar metadata files. A filesystem watcher detects changes in real time. Backup archives capture everything in a single ZIP, including plugin configurations and npm-installed plugins. Since 4.6, backup and restore also preserve your global text replacement rules— the full rule set, not merely the master switch—so a restored instance arrives with all its editorial corrections intact. The Foundryman believes your data should be legible, portable, and yours.

The release workflow, triggered on version tags, builds everything the Foundry produces in parallel: a Turbopack-compiled standalone tarball (with native modules included), multi-architecture Docker images (amd64 and arm64), rootfs tarballs for the shell’s Lima and WSL VM modes, and the quilltap CLI npm package. A final job creates the GitHub Release with all assets attached, and the desktop installers are built downstream by quilltap-shell from the standalone tarball it consumes. The 4.6 cycle brought version bumps across every bundled provider plugin—Anthropic, OpenAI, Google, Grok, Z.AI, OpenRouter, and Ollama—for dependency updates and the cache-read normalization work described above.

All API access goes through /api/v1/ endpoints with an action dispatch pattern (?action=). Consistent response formats, centralized middleware, and Zod schema validation throughout. The API is the contract between the frontend and the backend—every feature, from chat streaming to plugin management to file operations, passes through it. 4.0 finished pulling ZodError formatting and unhandled-error catching out of sixty individual route files (some ninety-seven try-catch blocks, roughly 1,084 lines of boilerplate) and into the middleware itself. Routes that do nothing unusual with their errors no longer need to catch them.

The cheap LLM system orchestrates background work: memory extraction, context compression, chat titling, scene state tracking, danger classification, and housekeeping tasks, each routed to the lowest-cost provider path with live and fallback pricing data. Connection profiles carry capability flags, model metadata, and per-profile usage tracking (tokens, messages, estimated cost). Provider models are cached in the database and refreshed from provider APIs, so the model list is always current.

Each profile also carries a model class—Compact, Standard, Extended, or Deep—summarizing what the model can do in a vocabulary that does not require memorizing the context windows of forty different services. The class drives the budget-driven compression system: maxContext − 2 × maxTokens is the available room, conversation history compresses at 50% of that, recalled memories at 20%, and each phase reports its own status. An auto-configure button searches the web for your model’s specifications, sends the results through your default LLM for structured analysis, and applies optimal maxContext, maxTokens, temperature, topP, and class settings without your having to look any of it up. For reasoning models (gpt-5-nano, Gemini 3.x), a strictMaxTokens flag tells providers to cap the thinking budget so cheap-LLM tasks no longer return empty after burning thirty seconds on hidden reasoning. As of 4.6, cache-read tokens—prompt-cache hits—are excluded from normalized token usage across every provider plugin. Cached input no longer counts toward autonomous-room per-run token caps, daily user-token caps, or per-chat token and cost aggregates. Each plugin subtracts cache reads at the source according to its own convention (Anthropic reports them separately; the OpenAI family folds them in and the plugin subtracts). One caveat for the accountant in the back: the cost estimator carries no cache-discount tier, so estimated cost omits cache-read tokens entirely rather than charging them at full input rate.

The chat orchestrator—previously a single sizeable module responsible for routing, calling, tool-handling, failover, and persistence—was decomposed in 4.0 into five focused services (turn chain, message finalizer, danger routing, provider failover, streaming state). It also emits granular status events phase by phase: initializing, resolving, loading tools, gathering, generating recap, preparing, validating, sending. Long operations no longer look like hangs.

Quilltap is open source. The Foundry lives at github.com/foundry-9/quilltap-server (renamed in 4.1 when the desktop application moved to its own carriage house at foundry-9/quilltap-shell). The plugin SDK is published to npm. The theme development kit includes a Storybook preset. The API is documented. The help files ship with every installation. The Foundryman does not build things to keep them to himself—he builds things because building things is what he does, and open blueprints mean other people can build on top of them.

There is no Quilltap cloud, no analytics telemetry, no training pipeline consuming your conversations. This is not a philosophical stance masquerading as a feature. It is the architecture itself. The Foundryman built a machine that runs on your machine, stores its data on your machine, and connects to the providers you choose. Everything else follows from that decision.