Why I stopped uploading my meetings to the cloud and built my own transcriber

I used a cloud transcription service for a long time and I was mostly happy with it. Nothing bad happened to me. No breach, no scandal.

One day I just noticed that I couldn't answer a simple question about it: where is my audio?

Not the transcripts. Those were right there in the dashboard. I mean the raw recordings of every meeting I had put through the service. I didn't know where they were stored, how long they stayed there, or what the company was allowed to do with them. After that I kept thinking about it.

What bothered me

I don't think these services are evil. They are good products and they solve a real problem. But here are some questions I couldn't answer about my own recordings:

• Where is the raw audio stored, and for how long?
• If I delete a transcript, is the audio deleted too, or is it just hidden from my dashboard?
• Is any of it used for training?
• If the company gets acquired, or changes its terms, or gets breached, how much of my data is involved?

For most of them the answer is "it depends on a policy document that can change any time". I'm not saying something bad is happening. I have no evidence of that. But meetings are where people talk about salaries, layoffs, health, legal problems, and half-finished ideas. For me, not knowing was enough of a reason to stop.

The second problem was smaller, but I hit it every day. The notes were stuck in the dashboard.

My work lives in files on my machine. Code, docs, notes. And more and more, coding agents read those files for me. But the meeting summary was in a browser tab, so every time I wanted my agent to know what we decided in a meeting, I copied and pasted it by hand. A meeting transcript has a lot of context in it. Mine were behind a login.

The third problem was just annoying. I was paying every month for a job my laptop can do by itself.

So I built Fennec.

On-device first

My rule is small enough that I can actually keep it:

Recording, transcription, speaker diarization and translation all run on the local machine.

For recording, Fennec uses Core Audio process taps on macOS, WASAPI loopback on Windows, and PipeWire on Linux. It takes the system audio and your microphone as two separate streams, so you don't need to install BlackHole or VB-CABLE and route your audio through them. Transcription is whisper.cpp on all platforms, plus Apple's on-device speech recognition on macOS 26+ for the live view. Diarization uses sherpa-onnx. Live translation is on-device too, macOS only for now.

None of this is new technology. But together it means that once you have downloaded the model, you can turn on airplane mode and recording and transcription still work. I like this test because anyone can run it themselves.

I say "first" and not "only" because there is one step that leaves the machine, and I think it is better to say it clearly than to hide it in a FAQ. That step is generating the minutes. Fennec has no LLM of its own. It passes the transcript to a coding agent CLI you already have (Claude Code, Codex, Gemini CLI). If that agent uses a cloud API, then the transcript text goes to that API, on your account, with a vendor you already chose.

So the raw audio never leaves. The transcript leaves only when you press the button, and only to the agent you set up.

I want to close that last gap. Generating the minutes with a local LLM is on the roadmap, so that Fennec can be local from end to end and not just on-device first. Today the three backends are Claude Code, Codex and Gemini CLI, so this is the one part I can't promise stays on your machine yet.

Why I reuse your agent instead of building my own summarizer is a longer story. I'll write about it later in this series.

Everything is just files

I thought this would be a boring decision. It turned out to be the most important one.

One session in Fennec is one folder:

20260813_140000/
  system_<id>.ogg   the other side of the call
  mic_<id>.ogg      you
  transcript_<id>.txt   [MM:SS] Speaker: text
  minutes.md        the minutes
  session.json      metadata

That's all of it. There is no SQLite index that has to be healthy for your data to be readable, and no special file format. minutes.md is not an export of some internal record. It is the record. The app opens the same file you open.

So:

• grep -r "budget" ~/Recordings works
• your backup tool already backs it up
• your editor already opens it
• a coding agent can read the folder directly, with no API and no export step
• if I lose interest in this project, or you just don't like the UI, your recordings and transcripts are still there in normal formats

I have been a user on the other side of this, with apps where I "owned" my data but could not really get it out. Plain files cost me something as a developer. Search is slower, and I have to handle file conflicts myself. But it removes a whole category of lock-in. If my main claim is "your data stays yours", then putting everything into a database would work against that claim.

I could have built a version with nicer search and a custom session format. I decided not to.

Why MIT

I thought about this one for a while, but in the end the reason was simple.

My main claim is that your audio never leaves your machine. If you can't read the source, you just have to take my word for it. If you can read it, you don't have to. You can check the network code, or point Little Snitch at the app and watch it do nothing. Closing the source would mean asking people to trust me about the exact thing I built the app to avoid trusting anyone about.

So, MIT, and the whole core is in there. Capture, transcription, diarization, minutes generation, the CLI, the hooks. I didn't keep the good parts back.

What's next

This is the first post of a series about building Fennec in the open. Here is what I plan to write:

• The rewrite. Fennec started as a macOS-only SwiftUI app, with most of the features already working. In August I threw it away and rebuilt everything in Rust and Tauri. Cross-platform support was not the main reason. The main reason was that working with coding agents in Xcode kept hitting a wall. This is the next post, and the one I want to write the most.
• Coding agents as the minutes engine. Why the summarizer is something you already pay for.
• The CLI and hooks. A GUI app you can drive completely over a Unix domain socket, and what that makes possible.
• A one month retrospective. What happened after I shipped.

I'll put a progress snapshot at the bottom of every post. The numbers are small right now, but I think starting before they look good is the point.

Progress snapshot

As of 2026-09-01:

First commit	2026-08-04
Latest release	v0.0.2 (2026-08-19)
GitHub stars	1
Release downloads (all platforms, cumulative)	16
Contributors	1
Revenue	$0

Yes, the 1 star is me. I know how that looks. But I think it is more useful to start the log now than to wait until the numbers look good. Let's see where it is in a month.

---

Fennec is MIT licensed. It runs on macOS 26+ (Apple Silicon), Windows x64 and Linux x86_64: github.com/krgpi/fennec

If you built something similar, or you solved the "my meeting notes are stuck in a dashboard" problem in a different way, I'd like to hear about it in the comments. Also, English is not my first language, so if something here reads strangely, that is why.

About me

I'm Karaage, a developer in Tokyo. Fennec is not the only thing I make.

DeskStick is a sticky notes app for Mac, iPhone, iPad and Vision Pro that syncs over iCloud. I built it for myself as a scratchpad for AI prompts. The ones I reuse stay pinned on top of whatever I'm working on, and I park generated drafts there before moving them into a real editor. It's free.

If you want to follow this series, the easiest way is to follow me here on DEV. I also post releases and smaller updates on X: @krgpi. That is where the next post will show up first.