Spool

Situation

People who carry several long-running projects, such as researchers, graduate students and developers working alone, pay the same cost in every new AI conversation. The assistant starts cold, so they rebuild the project by hand: which source mattered, which approach already failed, what changed since last week.

Spool keeps each project as a time-ordered log on the user’s Mac and packs it into plain text any AI can read. The harder problem was control: what an AI may read, what it may write, and what may leave the machine. It is not a team workspace or a sync service.

Role

I am Spool’s sole developer. I made the product decisions, including the red lines the architecture enforces, and did the on-device acceptance checks. I set the rules for the evaluation rounds and settled disputed answer keys; a coding agent ran and graded them.

Constraints

Project notes are personal, so the default had to be that nothing leaves the Mac. Every AI feature therefore had to run on the user’s own key or subscription, with no Spool server, account or telemetry.

Models also fail quietly: a shortened draft can lose a date, and a confident answer can cite a line that does not exist. I treated that as a design input: drafts are checked before the user sees them and saved only on approval.

As a solo developer, I needed safeguards that a test or a real build could check.

Process and architecture

Spool v0.6.2 has three entry points: a desktop app, an MCP server, and a CLI engine slot. (the CLI engine slot runs the user's own Claude Code, Codex or Gemini CLI as a subprocess; Spool has no command line of its own) The diagram shows which process starts which, where data lives, and every route off the Mac.

Network stays at the process boundary

I kept every network call out of the main app and put AI requests in a small subprocess the user switches on. The alternative, calling the model from the app, is simpler but leaves the privacy claim as a promise. Spool's main process links no HTTP or TLS library; the only network client in the app is an opt-in subprocess, spool-ai. (MCP clients and the user's own CLI make their own network calls)

AI writes need a second consent

AI clients get no access until the user turns on the MCP server, and writing has a second, separate switch. (the write switch is on by default once the MCP server is on) I rejected letting an AI edit blocks in place: projects would stay tidier, but no one could tell who said what. AI-written blocks are append-only and carry the client's name; an AI cannot edit or delete what the user wrote.

Drafts are checked before they can be saved

A compressed draft that dropped a number or date cannot be saved, and the original text stays on each block. (compression is opt-in, off by default and uses the user's own API key; keeping originals can be turned off) I rejected a confirm button that overrides the number check, because a lost figure is easy to miss in a shorter text.

Results and evidence

Spool v0.6.2 shipped on 2026-08-24 as a Developer ID–signed, Apple-notarized build for Apple Silicon Macs. 769 tests passed at the v0.6.2 tag: 627 TypeScript, 129 main-crate Rust and 13 sidecar Rust, with 4 skipped by design. (run on 2026-09-23; two timing-sensitive Rust tests failed on the first of 11 main-crate runs)

Before v0.6.2, six evaluation rounds made 557 real API calls. (2026-08-20 to 08-24) The six pre-release evaluation rounds cost at least ¥29.37. (token usage times the vendor's price list; failed calls reported no usage, so this is a floor) Compressing two projects by 30% and 38% kept 39 of 40 answers correct; the uncompressed baseline scored 40/40. (round six: 20 questions, each asked twice per arm; one model; answers graded by the coding agent; the gap is within noise)

Four release blockers found in pre-release testing were fixed and re-tested before v0.6.2 shipped. (found in round five on 2026-08-23; re-tested in round six on 2026-08-24) They were a retry that sent the same request again, a truncated reply marked as success, an overwritten link and broken quote matching. Two envelope defects from the last round shipped unfixed: failed calls report no usage, and one empty reply was marked ok. (still open as of 2026-09-23)

Each project lists what to watch; a follow-up runs the user's own Claude Code with web search and queues sourced findings for approval. The screenshots come from a later, unreleased build, but the feature itself shipped in the release above.

Reflection and next

A pre-release round replayed the out-of-date check on a copy of my library and found that accepting a proposal could silently overwrite an existing link. A fix passed its tests but covered one of two relation types; the next offline re-check found 20 exposed blocks. (round six, on a copy of the library; the complete fix landed before the v0.6.2 tag) It would have let one click rewrite a citation unnoticed; I rebuilt both guards around whether a block already points somewhere, with unit tests.

Other results argued against features I wanted. A linear cost estimate landed within ±30% for only 46% of 89 real bills, so the app shows no price. (round five; the bar set in advance was 90%) Medium reasoning gave no compression gain over low; it was 3.5× slower and 3.4× costlier. (n = 5 vs 10 runs on one project and one setting, round five; a 5-point gain was required in advance)

A passing test is evidence about the test, so I also check each guard against real data. The longer development story, with earlier failures, is on the Spool site (opens in a new tab).

A follow-on study of project memory across AI clients is under way. It asks whether a governed project memory helps AI assistants more than a plain pack, full text or a rules file. It also measures harm: stale rules, leaks between tasks, and injected instructions carried from one client to another.