digimata/quill: a local macOS meeting recorder that tags speakers by track

The problem quill solves, and who it is for

Meeting transcription usually means one of two compromises. Either audio goes to a hosted service, or you assemble a local pipeline yourself: a virtual audio device for system sound, a recorder, a diarization model, and a script to stitch the pieces together. quill collapses that into a single Swift executable with a menu-bar item as its entire interface. The README describes it as "a minimal, fully local macOS meeting recorder + transcriber" and states that nothing ever leaves the machine.

The intended user is someone on macOS 15 or later who records calls regularly and wants the transcript on disk without a cloud account. Apple Silicon is recommended for transcription speed. The design also assumes a two-party call: your microphone is one side, everything the Mac plays is the other. That assumption is load-bearing, and it is what makes the speaker labels cheap.

Two tracks instead of a diarization model

The core mechanism is capture, not inference. One menu-bar click starts recording the default input device and all system audio as two separate files. The README gives the reasoning directly: speech models do better on clean single-source audio, and mic versus system is "free two-party diarization" producing me and them without a speaker-identification model.

System audio comes from a Core Audio process tap, the README naming AudioHardwareCreateProcessTap with macOS 14.2+ and a private aggregate device, so there is no virtual device and no kernel extension. The mic is captured through AVAudioEngine. Both are encoded to AAC inside CAF containers by AVAudioFile. CAF is chosen because, unlike m4a, it needs no finalization pass: if the process dies mid-meeting, what was already written is still readable.

Each session lands in ~/Recordings/<yyyy.MM.dd-HHmm>/ with mic.caf, system.caf, meta.json, transcript.json, transcript.md and transcribe.log. meta.json holds start and end timestamps, duration, and per-track start offsets. Transcription runs per track, shifts each by its offset so both share one clock, and merges by timestamp. That offset handling is the part that decides whether the merged transcript reads in the right order, so meta.json is worth keeping alongside the audio.

Installing quill and recording a first session

The README gives a build-from-source flow. There is no app bundle and no release artifact mentioned, so you need a Swift toolchain and the repository itself.

cd quill
swift build -c release
sudo cp .build/release/quill /usr/local/bin/quill
quill install --launch-at-login   # optional - runs in the background on login

The build produces a single binary that you copy to /usr/local/bin. The install subcommand is optional and registers a LaunchAgent so quill runs at login. To check the environment before relying on it, run the doctor command; the README says it checks permissions, the recordings folder, and whether the transcription models are cached.

quill doctor

Then start the daemon and click the feather in the menu bar. First use prompts for microphone and System Audio Recording permissions. While recording, the icon turns red with a running elapsed counter, and macOS shows the purple recording indicator.

quill
quill run --out <dir>   # custom recordings root (default ~/Recordings)

Stopping recording starts transcription automatically, with progress in the menu and a notification when the transcript is ready. Jobs run in a serial queue, so you can start a new recording while the previous one transcribes. Unfinished jobs resume on next launch, because the filesystem is the queue: a session directory with meta.json but no transcript.json is treated as pending, and failures append to that session's transcribe.log without blocking later jobs.

Config keys and the on_stop hook

Configuration is optional and lives at ~/.config/quill/config.json. The README shows this shape:

{
  "recordings_dir": "~/Recordings",
  "transcription": { "enabled": true, "engine": "parakeet" },
  "on_stop": "my-hook"
}

recordings_dir resolves in the order --out flag, then config, then ~/Recordings. Setting transcription.enabled to false leaves you with recording only. The on_stop key is the integration point: a shell command spawned with the session directory as its argument, after the transcript is written, or right after recording if transcription is disabled. That is where summarization, filing or indexing belongs, and the session directory as the single argument keeps the hook simple.

One key in the README's bullet list, mic_voice_processing, is not shown in the JSON example. It enables Apple's echo cancellation on the mic and defaults to off. Turn it on when recording meetings through the speakers, so playback does not bleed into the mic track and get transcribed twice as me. The README is explicit about the trade: while the voice unit is live, macOS ducks other playback slightly, and the configured .min ducking cannot be zeroed. On headphones there is no echo to cancel, so raw capture is the stated better default.

Where quill is the wrong tool

The speaker labels are the main limitation. The README calls mic versus system "free two-party diarization", and that word two-party is accurate. A three-person call where two remote participants share the system track produces one them label for both voices, and quill has no speaker-identification model to separate them. If you need per-person attribution beyond you and the call, this design does not provide it.

The global tap is the second constraint. The README warns that a tap records everything the Mac plays, notification dings and music included, and suggests not playing Spotify during meetings. There is no per-process picker; the gotchas section says to ask for one if it bothers you, which is an acknowledgement rather than a feature.

Language is the third. Parakeet TDT 0.6B v2 is English-only per the README, and the Whisper engine (WhisperKit large-v3-turbo) that would cover other languages is described as planned, not shipped. The repository shows no releases, so there is no packaged version to fall back on. And the platform floor is real: macOS 15+ for the Core Audio process tap path, with no Windows or Linux story anywhere in the README.

How quill differs from a cloud transcription service

The obvious alternative is a hosted meeting-notes service that joins the call or ingests an upload and returns a transcript with speaker labels. The difference in approach is where the audio goes and how the labels are produced. A hosted service typically runs a diarization model over a mixed stream, which can distinguish several speakers but requires the audio to leave the machine and usually a subscription. quill keeps the audio local, writes raw tracks and a timed transcript to a directory you own, and gets its labels from the capture path instead of a model. That is cheaper and more predictable for two-party calls, and structurally unable to label a third voice.

The closer comparison is the sibling project the README names, parrot, from the same author and described as the same skeleton. That suggests overlapping capture code; the README does not compare the two beyond that, so the choice between them is not documented.

On the transcription side, the README positions FluidAudio's Core ML port of Parakeet as the default engine behind a small protocol, with WhisperKit large-v3-turbo planned as the fallback and re-transcription option. The protocol boundary is the part that matters if you care about swapping engines later; the README states the intent but does not document the protocol's surface.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-07-30. There are no retrieved releases, so the README's build-from-source instructions are the installation path rather than a convenience. Anyone adopting quill should expect to rebuild from source and copy the binary themselves when they want a newer version; the README does not document an upgrade command, a version check, or a rollback procedure. The install subcommand covers launch-at-login and uninstall, not updating.

Two ongoing costs are worth naming. The Parakeet models are roughly 600 MB and download once on first transcription, so the first run after a fresh install needs network access even though the product is otherwise local. quill doctor reports whether they are already cached, which is the check to run before a meeting you cannot afford to delay. Second, the binary embeds its Info.plist in __TEXT,__info_plist so TCC can attribute permissions to quill when it runs as a LaunchAgent. That is a packaging detail with a practical consequence: if you move or replace the binary, permission attribution is tied to it.

The licence is MIT, which permits commercial and private use and modification. This is a description of the licence text, not legal advice; review the LICENSE file in the repository for the terms that apply to you.

Editorial conclusion

quill fits engineers and privacy-conscious users on macOS 15 or later who want meeting audio and transcripts to stay on the machine, and who accept English-only transcription and a global system-audio tap. It does not fit Windows or Linux users, anyone needing non-English output today, or anyone who wants a per-application audio picker. Before adopting it, run swift build -c release, then quill doctor to confirm permissions and whether the roughly 600 MB Parakeet models are cached, and check that ~/Recordings is the right destination or set recordings_dir in ~/.config/quill/config.json.

Frequently asked questions

Official sources

1. digimata/quill on GitHub
2. Issues
3. License: MIT
4. README