Why I open-sourced my Mac app, relay and all

Here is the pitch for Deiko, from the point of view of someone who has never heard of me.

"Hi. Please give my app four macOS permissions, Screen Recording, Accessibility and Microphone among them. It will take screenshots of whatever you point at, read the text under your cursor and record your voice. Some of that goes to a server I run. Trust me, it's fine."

I wouldn't install that. You probably shouldn't either.

Quick refresher if you're new: you double-tap Right Option, point at things on screen and talk, and Deiko turns that into a brief (your words, crops of what you pointed at, the text under the cursor) for Claude Code, Cursor, Codex or a chat window. On 30 September I put all of it on GitHub under the MIT licence. Not just the app. The relay too.

A screen-and-voice app asks for a lot of trust

Every app like this has a privacy page. Mine too. But a privacy page is a promise, words a company wrote about itself, and you can't check it.

Code is something you can check. Here is what Deiko says about your data, and where you can verify each line:

• Stored on your Mac, in ~/Library/Application Support/Deiko: sessions, crops, audio, the board, task notes.
• Sent for processing, nothing kept: your voice to Whisper on Groq (through my relay, or straight to Groq with your own key, or nowhere if you use Apple's on-device recogniser); the transcript for a one-line summary; titles and summaries for filing a brief into the right task.
• Never sent except inside the brief you hand your own agent: screenshots and on-screen text.

That last line is the one to doubt most. docs/architecture.md walks through the pipeline, and the code that builds a brief, redacts secrets and decides what goes where is in packages/core/src.

Why the relay is in the repo too

A lot of "open source" apps open the client and keep the server closed. That is backwards for a tool like this. The client is what runs on your Mac, where you could at least watch its network traffic. The server is where your audio actually goes.

So the relay, services/relay, is in the repo, about 2,400 lines of plain Node whose only dependency is the AWS SDK for DynamoDB. Here is what it does, straight from the code:

• Forwards. /v1/transcribe sends your audio to Groq's whisper-large-v3. /v1/summarize sends the transcript to a small Groq model for the one-line summary. /v1/classify sends titles and summaries to Jev through OpenRouter to decide which task a brief continues.
• Counts. Each install is identified by dev_ plus a salted SHA-256 of the Mac's hardware id (the id itself is never sent). Audio seconds are counted per device per UTC month: 2 hours for free, 10 for Pro. The counter is a DynamoDB row keyed by device and month that deletes itself after 40 days, so there is no reset job.
• Keeps nothing. Request bodies are held in memory and forwarded. A log line is a timestamp, method, path, status, duration and a 12-character fingerprint of the token. No audio, no transcript.

My favourite detail is a paranoid one. The upload is never forwarded as-is. The relay parses it, checks it is the app's own WAV (16 kHz mono, at most 40 seconds), and rebuilds the request from scratch. A verbatim body would let someone add Groq's url field and have Groq fetch an hour of audio off my meter. A privacy page would never mention that. A diff does.

And here's the honest limit of all this: reading the code tells you what the code does, not what is running on my Lambda right now. If that gap matters to you, and for some people it should, don't use my relay. You have two ways out:

1. Bring your own Groq key. Paste it in Settings and transcription goes straight from your Mac to Groq on your account. The relay never sees your audio.
2. Self-host the relay. make relay-dev runs it locally with in-memory metering; make relay-deploy puts it on AWS Lambda with a DynamoDB usage table. docs/self-hosting.md is about a page long, and the relay's README lists every setting.

A build made without a relay URL transcribes with your own key or on-device and files briefs locally, with no server of mine anywhere.

A closed Mac app from one person is invisible

The second reason is less noble, and I'd rather say it than pretend.

A closed Mac app from a solo developer has a landing page nobody visits. Developers don't find tools that way. They find them on GitHub, in MCP server directories, in awesome-lists, in someone's dotfiles. All of those point at a repo.

Deiko ships an MCP server (deiko-memory, five tools, runs only on your Mac) that coding agents use to search past briefs and report back what they did. An MCP server you can't read is a hard sell to exactly the people who install MCP servers. Open source puts it where they already look, and lets them read it before they do.

So what does anyone pay for?

Convenience. That's the whole answer.

Deiko is free, and free includes 2 hours a month of hosted transcription per Mac. After that it falls back to Apple's on-device recogniser. Your own Groq key has no cap on my side at all.

What does your own key cost? Groq lists whisper-large-v3, the model Deiko uses, at $0.111 per hour of audio, with a 10-second minimum per request. Deiko sends chunks of about 25 seconds, so the minimum rarely bites. Ten hours of talking costs about $1.11.

The same page lists whisper-large-v3-turbo at $0.04 an hour. Deiko can't use it: turbo doesn't translate, and Deiko asks Whisper to translate, because I narrate half my briefs in Hinglish and transcribing that gives Devanagari that can't be lined up with the on-device word timings. Translating gives Latin text that can.

Pro is $6.99 a month (or $69 a year, or $169 once) for 10 hours of hosted transcription. Yes, that's more than the raw Groq cost. What you're paying for is not making a Groq account, not keeping a key safe, and not thinking about any of this. Some people would rather pay a few dollars than do that. If you wouldn't, the free path isn't a crippled one.

What going open source actually took

Less than I feared, more than flipping a switch.

A layout a stranger can follow. The repo is a monorepo, and each folder is one thing:

A licence file that is just the licence. My first LICENSE had a note about third-party components tacked onto the MIT text. I moved that to a NOTICE file and left LICENSE as plain MIT. The app bundles a few things with their own terms (onnxruntime, the on-device search models, a tokenizer, the Bricolage Grotesque font), and their notices live under apps/macos/licenses/.

A history worth reading. Commits follow Conventional Commits, so the log reads like feat(grounding): add region crop and Vision OCR capture all the way back to the first week. So I could publish the real history, not one giant "initial commit".

Cleaning that history first. Two months of working in a private repo leaves private notes and business docs in it. They had to come out of every commit before anything went public, which is a slower job than deleting a folder, since a file removed today is still sitting in last month's commits.

The boring community files. CONTRIBUTING.md, SECURITY.md, a changelog, issue templates and a pull request template.

CI. A GitHub Actions workflow runs the Node tests (pipeline, relay, evals) and the Swift tests for the app's libraries on every push and pull request. The Swift job runs on GitHub's macOS 26 runner, because the app needs Xcode 26.

The gaps I'm not hiding

It isn't notarized by Apple. Notarization needs the Apple Developer Program, which is $99 a year, and I'll join when Deiko earns enough to cover it. Until then the app is signed with its own certificate, macOS quarantines the download, and the install line is:

curl -fsSL https://deiko.app/install.sh | sh

That script downloads the disk image, replaces /Applications/Deiko.app and clears the quarantine flag recursively. The "recursively" matters: the right-click-Open bypass can leave the Node runtime inside the bundle quarantined, and the app then sits at "Transcribing…" forever with nothing pointing at why. Piping a script from a stranger into your shell is exactly what you should be suspicious of, so read it first. It's short. Or skip it and build from source with make install.

It's Mac only. macOS 14 or newer on Apple silicon. Capture leans on macOS Accessibility, screen capture and Vision OCR, none of which travel. The pipeline and the memory server are plain Node working over a folder of files, so they could run somewhere else. I'm not promising a port. I'm saying the parts that would make one possible are readable.

If you want to poke at it

Bug reports, fixes and ideas are welcome. CONTRIBUTING.md has the setup (Xcode 26, Node 22, make setup then make install) and asks you to open an issue before anything bigger than a small fix.

If you find a security problem, please don't open a public issue. SECURITY.md says how to report it: email [email protected] or use GitHub's private reporting. A brief that carries a credential from your screen to an agent counts as a vulnerability, and I want to hear about it.

And if you just want to read the relay and tell me where I'm wrong about metering, I'm @Deiko_App on X.