Version: Muesli 0.8.1 (Homebrew cask), macOS 26.5.1, Apple Silicon
Two related gaps, both about giving users control over what the meeting transcription pipeline does. Happy to split into separate issues if you'd prefer.
1. An option to disable diarization
There's currently no way to turn diarization off, no Settings toggle, no config key, no CLI flag. It always runs on meeting audio.
On a 49-minute, 3-speaker recording imported as a single mixed track, diarization produced 8 distinct speaker labels (Speaker 1-7 plus "Others") for those 3 people, across both Parakeet v2 and v3:
|
Reference transcript |
Muesli v2 |
Muesli v3 |
| Speaker labels |
3 |
9 |
8 |
| Turns |
376 |
257 |
267 |
I understand a single mixed track is the hard case, a live meeting gives you mic and system audio separately, which is a much better starting point. But when diarization isn't producing usable labels, I'd rather have a clean unlabeled transcript than an inaccurate speaker attribution, and today there's no way to choose that.
muesli-cli transcribe effectively provides this (it emits no speaker labels) and produces noticeably cleaner text, but it isn't reachable from the app, and the CLI can't save a diarization-free import into meeting history.
Ask: a Settings toggle under Meetings → Transcription, and a --no-diarize flag for muesli-cli transcribe --save-meeting.
2. Apply the personal dictionary to meeting transcription
The personal dictionary appears to apply only to dictation, not to meeting transcripts. With 45 entries configured, including proper nouns that recur constantly in my meetings, the imported transcript and generated notes still contained the uncorrected forms:
- "Wolf" where the dictionary has Rolf (threshold 0.85)
- "Jerry" where the dictionary has Jeri (threshold 0.85)
Measured against a reference transcript of the same audio, domain proper nouns land well short, and enabling the dictionary made no measurable difference:
| term |
reference |
Muesli (dictionary active) |
| Claude |
48 |
17 |
| organization name |
6 |
1 |
| organization 2 name |
5 |
0 |
| (three other org-specific names) |
2 / 1 / 1 |
0 / 0 / 0 |
Meeting transcripts are exactly where a personal dictionary pays off most, the same colleagues, projects, and acronyms recur in every single meeting. Right now that vocabulary has to be re-fixed by the summarization LLM on every run, which only helps the notes and leaves the stored transcript wrong.
Ask: run the existing custom-word correction over meeting transcripts too, ideally with a toggle if there's a performance cost.
3. An optional bring-your-own cloud ASR backend (e.g. AssemblyAI)
This one cuts against the local-first premise, so I want to be clear about the framing: off by default, opt-in, user-supplied API key, never a hosted service you have to run. Exactly the same shape as the existing Custom LLM setting for summaries, just for the transcription step.
The motivation is the two problems above. I already pay for AssemblyAI diarization in a separate pipeline, and on the same 49-minute file it returned 3 speakers where Muesli's on-device pass returned 8, plus materially better proper-noun accuracy. If I could point Muesli's meeting transcription at my own AssemblyAI key, I would use Muesli as my single capture-and-transcribe app tomorrow and retire the separate pipeline.
Concretely:
- Settings > Meetings > Transcription > Backend:
On-device (FluidAudio) (default) or Custom ASR
- Custom ASR takes a provider, an endpoint, and an API key, the same way the Custom LLM summary settings already do
- AssemblyAI first, since it is a single-request async upload-and-poll API and returns diarized, punctuated output that maps cleanly onto Muesli's existing turn model
- A
--backend flag on muesli-cli transcribe for parity
I recognize this changes the privacy story, so it should be loud in the UI: a clear indicator that audio leaves the device when the setting is on, and on-device staying the default forever. But the choice of whether my audio goes to a vendor I already have a contract with is one I would like to be able to make.
If you would rather keep the core app purely on-device, a narrower version solves most of it: let the post-meeting hook receive the raw audio path and write a replacement transcript back, so an external transcription step can be bolted on without the app itself ever talking to a cloud ASR.
4. Minor: CLI is behind the README
The README documents muesli-cli transcribe --dictionary PATH and a long --model list (sensevoice, qwen3-asr, nemotron35, whisper-*). The shipped 0.8.1 CLI rejects --dictionary outright and its usage string offers only parakeet-v3|parakeet-v2. Not a big deal, but it sent me down a wrong path for a bit, worth either shipping the flags or noting which are unreleased.
Really enjoying the app otherwise, the local-first design is exactly what I want, transcription speed is genuinely impressive (11 seconds for a 49-minute file), and custom note templates have been excellent.
Version: Muesli 0.8.1 (Homebrew cask), macOS 26.5.1, Apple Silicon
Two related gaps, both about giving users control over what the meeting transcription pipeline does. Happy to split into separate issues if you'd prefer.
1. An option to disable diarization
There's currently no way to turn diarization off, no Settings toggle, no config key, no CLI flag. It always runs on meeting audio.
On a 49-minute, 3-speaker recording imported as a single mixed track, diarization produced 8 distinct speaker labels (Speaker 1-7 plus "Others") for those 3 people, across both Parakeet v2 and v3:
I understand a single mixed track is the hard case, a live meeting gives you mic and system audio separately, which is a much better starting point. But when diarization isn't producing usable labels, I'd rather have a clean unlabeled transcript than an inaccurate speaker attribution, and today there's no way to choose that.
muesli-cli transcribeeffectively provides this (it emits no speaker labels) and produces noticeably cleaner text, but it isn't reachable from the app, and the CLI can't save a diarization-free import into meeting history.Ask: a Settings toggle under Meetings → Transcription, and a
--no-diarizeflag formuesli-cli transcribe --save-meeting.2. Apply the personal dictionary to meeting transcription
The personal dictionary appears to apply only to dictation, not to meeting transcripts. With 45 entries configured, including proper nouns that recur constantly in my meetings, the imported transcript and generated notes still contained the uncorrected forms:
Measured against a reference transcript of the same audio, domain proper nouns land well short, and enabling the dictionary made no measurable difference:
Meeting transcripts are exactly where a personal dictionary pays off most, the same colleagues, projects, and acronyms recur in every single meeting. Right now that vocabulary has to be re-fixed by the summarization LLM on every run, which only helps the notes and leaves the stored transcript wrong.
Ask: run the existing custom-word correction over meeting transcripts too, ideally with a toggle if there's a performance cost.
3. An optional bring-your-own cloud ASR backend (e.g. AssemblyAI)
This one cuts against the local-first premise, so I want to be clear about the framing: off by default, opt-in, user-supplied API key, never a hosted service you have to run. Exactly the same shape as the existing Custom LLM setting for summaries, just for the transcription step.
The motivation is the two problems above. I already pay for AssemblyAI diarization in a separate pipeline, and on the same 49-minute file it returned 3 speakers where Muesli's on-device pass returned 8, plus materially better proper-noun accuracy. If I could point Muesli's meeting transcription at my own AssemblyAI key, I would use Muesli as my single capture-and-transcribe app tomorrow and retire the separate pipeline.
Concretely:
On-device (FluidAudio)(default) orCustom ASR--backendflag onmuesli-cli transcribefor parityI recognize this changes the privacy story, so it should be loud in the UI: a clear indicator that audio leaves the device when the setting is on, and on-device staying the default forever. But the choice of whether my audio goes to a vendor I already have a contract with is one I would like to be able to make.
If you would rather keep the core app purely on-device, a narrower version solves most of it: let the post-meeting hook receive the raw audio path and write a replacement transcript back, so an external transcription step can be bolted on without the app itself ever talking to a cloud ASR.
4. Minor: CLI is behind the README
The README documents
muesli-cli transcribe --dictionary PATHand a long--modellist (sensevoice, qwen3-asr, nemotron35, whisper-*). The shipped 0.8.1 CLI rejects--dictionaryoutright and its usage string offers onlyparakeet-v3|parakeet-v2. Not a big deal, but it sent me down a wrong path for a bit, worth either shipping the flags or noting which are unreleased.Really enjoying the app otherwise, the local-first design is exactly what I want, transcription speed is genuinely impressive (11 seconds for a 49-minute file), and custom note templates have been excellent.