thE-noteTaker

The problem it's solving

Meeting note takers are a crowded category, and almost all of them work the same way: a bot joins your call or a background service captures your audio, ships it to a server, and hands you back a summary a few minutes later. That model has two costs. One is obvious: your conversations leave your machine and sit on someone else's infrastructure under someone else's retention policy. The other is less talked about: transcription quality on these services is frequently mediocre, and the "AI" doing the summarizing is often an older or cheaper model than what's actually available, because running the good stuff on every user's call is expensive.

thE-noteTaker removes both costs by moving the entire pipeline onto the machine that's already sitting on your desk.

The core loop

The app lives in the menu bar as a lowercase e. The interaction model is deliberately boring:

1. Click the icon. Recording starts, capturing microphone and system audio simultaneously.
2. Click it again. Recording stops. Audio is written to disk immediately, and transcription kicks off asynchronously.
3. A new recording can start right away without waiting for the previous one to finish transcribing, since the transcription queue runs independently of the recording state.
4. Once transcription finishes, the recording shows up in a library view with status, metadata, and options to retry, re-transcribe, or edit.

A "wrap-up" flow can prompt for sensitivity level and any AI actions right after a recording stops, so triage doesn't have to wait on the transcription job to complete.

Recording and audio capture

Audio capture handles two independent streams: microphone input and system audio output, so both sides of a call get captured, not just one voice. These get mixed and also preserved as separate WAV files, so the raw source is still there if the mixed track has problems. Device selection runs through a dedicated audio device manager, since macOS's audio device model, combined with system-audio capture entitlements, has more edge cases than it looks like from the outside.

Transcription

Transcription runs through one of two local engines:

• parakeet.cpp: the default, using NVIDIA's Parakeet model architecture compiled for local inference
• whisper.cpp: an alternative backend, useful as a fallback or for comparison

Both are bundled as native binaries the app shells out to, rather than reimplementing inference in Swift. A model downloader handles pulling the actual model weights on first run, since they're too large to ship in the app bundle, with a setup window so this doesn't turn into a manual terminal exercise. Speaker diarization is available as an optional pass when enabled, so transcripts can be labeled by speaker rather than presented as one undifferentiated block of text.

Transcription jobs run through a queue, decoupled from the recording session, which is what allows back-to-back recordings without blocking on processing time.

Output format

Everything lands in ~/thE-noteTaker/output/:

queue/
  transcript/
    Recording-2026-06-29-14-30.md
  audio/
    Recording-2026-06-29-14-30-combined.wav
    Recording-2026-06-29-14-30-microphone.wav
    Recording-2026-06-29-14-30-system.wav

Transcripts are markdown with a YAML frontmatter block (model used, duration, speaker count, and similar metadata) followed by the transcript body. This is a deliberate choice: no vendor lock-in, no database the app needs to read, and your files stay readable if the app goes away. Anything that understands markdown and frontmatter can read these files directly.

Local AI passes (optional)

For summaries and action items, the app can optionally use Ollama, or call out to a local Claude CLI or Codex CLI installation rather than a hosted API. Ollama keeps the whole step on your machine. The CLIs reuse your existing login, but their models still run on Anthropic's or OpenAI's servers, so the transcript text leaves your Mac when you pick one. Audio never does. This is opt-in: the core record/transcribe loop doesn't depend on it at all.

Sensitivity and data handling

Recordings can be flagged with a sensitivity level that controls whether they're eligible to be used as context for AI features at all. This isn't just a UI label. Flagged recordings are physically moved to a different location on disk, so "excluded from AI context" is enforced by where the file actually lives, backed up by app-level controls, rather than left to a checkbox the app has to remember to respect every time it reads a file.

The stack

• Swift / SwiftUI for the app itself: menu bar controller, main window, and all four primary screens (Home, Recordings, Recording Detail, Settings)
• AVAudioEngine and ScreenCaptureKit for mic and system audio capture
• parakeet.cpp / whisper.cpp as bundled native transcription binaries
• Plain markdown + WAV as the only persisted output formats
• A small internal design system (color tokens, typography scale, layout constants) so the four screens share one visual language instead of drifting independently

What it deliberately doesn't do

No account system. No telemetry. No network call required for the core recording-to-transcript loop. No proprietary storage format. The bet is that a note-taking tool people actually trust with sensitive conversations has to be verifiable by inspection: point it at a folder, watch what gets written there, confirm nothing else happened.