transcribee: open source transcription with an automatic draft and a collaborative editor

What transcribee is, and the three things it does for you

transcribee aims to make the workflow for media transcription easier, faster and more accessible, and the feature list is four bullets that describe a product decision rather than a set of buttons.

It can automatically generate a draft transcript of your audio. It allows you to quickly improve the automatic draft and fix any errors. It is collaborative, so you can split the work with your friends or colleagues. And it is open source.

The first two bullets together are the interesting part. Transcription software has traditionally been either a raw speech-to-text dump that you then clean up in a word processor, or a paid service that gives you a transcript you have to accept. transcribee treats the automatic result as a draft in the editorial sense: something to be revised, with the tooling built for revision rather than for generation alone.

The third bullet is the one that changes the shape of the work. Splitting a two-hour interview transcript between two people is a real task, and a collaborative editor means the splitting happens in the tool rather than in a document passed back and forth. The README says the change is instantly synced with everyone working on the transcript.

The project is by bugbakery, the homepage is transcribee.net, the primary language is TypeScript, and the licence is AGPL-3.0, which is a deliberate choice for software that people will run on their own machines and that can talk to a server they do not control. The default branch is main and the last push was on 2026-10-19.

The release history is short and honest about where the project is. There is one release, v0.1.0, titled the first Transcribee desktop alpha release, dated 2026-08-24. The README says the software is certainly not finished or bug-free, but should be good enough for everyday transcription tasks, and asks people to try it and tell them how it goes.

So the state of the project in one line: an alpha you are invited to break.

The three step workflow, and what each step actually runs

The How does it work section describes three steps, and the footnotes at the end of the section name the libraries doing the work, which is the most useful detail in the README.

Step one is importing your media file. During import, the audio file is automatically converted to text using state-of-the-art models, and transcribee also automatically detects different speakers in your file.

The footnote gives the specifics: at the moment they use whisper.cpp for transcription, Wav2Vec2 for realignment and speechbrain for speaker identification. Three separate models for three separate jobs, and the middle one is the interesting one. Realignment is the step where the text is lined up against the audio, and it is what makes it possible to correct a word in the transcript and have the correction land at the right moment in the timeline. Speaker identification with speechbrain is what gives you the speaker labels, so you can distinguish two people talking in a room without a microphone that separates them.

Step two is manually improving the transcript. After the automatic transcript is created you can edit it to correct any mistakes the automatic transcription made, and you can also name the speakers. Since transcribee is collaborative software, you can do this step and all other manual steps together with others, with all changes instantly synced with everyone working on the transcript.

The second footnote names the editor technology: the editor is based on slate with collaboration using the automerge CRDT. Slate is the React editor framework, and automerge is the merge algorithm that makes the sync work. The choice of a CRDT rather than a central server with locking is what makes the collaboration instant and offline-tolerant, and it is also the source of the performance problem the project documents.

Step three is export, once you are happy with the transcript.

The whole sequence is therefore: a file goes in, a model-generated draft with speaker labels comes out, people edit it together, and you export. The editing is the centre of the product, not an afterthought.

The concurrency warning, and why it is the thing to read first

There is a note inside step two, and it is the single most important thing in the README for anyone evaluating the tool for a team.

Concurrent editing of transcripts is currently resulting in some very bad performance problems, with a link to issue 380.

It is easy to read past that note, because it is set in a callout in the middle of a description of the happy path, and the surrounding text sells collaboration as a feature. But the note is the honest counterweight, and the reason is visible from the stack. The editor is built on automerge, a CRDT, which means every keystroke produces a new version of the document state that has to be merged with whatever else is happening. A transcript is a large text document and every edit changes the whole operation log, so the cost of a merge grows with the size of the document and the number of people editing it.

That has a practical consequence for how you would use the tool today. If you are transcribing with one person, the CRDT is not doing much work and the experience should be the one the README describes. If you are splitting a long transcript between three colleagues at once, the performance problem is exactly the case the note describes.

The other thing the note implies is that this is a known, tracked problem rather than a mystery. It has an issue number, which means someone has measured it, filed it and is working on it, and the maintainers chose to put it in the README next to the feature it qualifies rather than leaving it to the issue tracker.

There is a related place the project is candid. The note at the top of the README says transcribee is certainly not finished or bug-free, and asks people to try it and tell them how it goes, with a link to open an issue. For an alpha with a single tagged release, that is the correct posture, and the issue link is an invitation to report a specific failure rather than a general impression.

Hosted beta or self hosted, and the privacy trade-off between them

There are two ways to try transcribee, and the README frames them as a choice about the underlying technology rather than about features.

The first is to sign up for the beta instance of transcribee hosted by the project, with a signup link on the about subdomain. The README describes this as the easiest way if you do not want to fiddle with the underlaying technology.

The second is to self host transcribee on your computer or a server, with a link to the self hosting document. The stated benefit is that if you do this your data will not be shared with any third parties, us included, and the cost is that it requires some technical knowledge to set up.

That framing is accurate for this project specifically, because the models named in the footnote, whisper.cpp, Wav2Vec2 and speechbrain, are the ones doing the work on your audio. Self hosting, the README notes, means your data will not be shared with any third parties, and it is you who runs the infrastructure that the hosted beta handles for you.

The repository layout shows what self hosting actually involves. There is a backend/ directory, a frontend/ directory, a desktop/ directory for the desktop application, a worker/ directory, a ui-common/ directory for shared interface code, and a proto/ directory for the protocol definitions between them. There is a.devcontainer/ directory and a.dockerignore, so a containerised development environment is supported, and a.envrc file for direnv.

The Nix files are the other sign of a specific approach to reproducible setup. There is a flake.nix and a flake.lock, which is the standard way to pin a development environment exactly, including the tool versions. There is a packaging/ directory, a.pre-commit-config.yaml for commit hooks, a.ruff.toml, which points at the Python side of the project even though the primary language is TypeScript, and a.vscode/ directory.

So self hosting is a stack rather than an application, and the documentation link in the README is the place to find out what it takes.

Who paid for it, and what the project says about its own maturity

The Acknowledgements section records the funding in a way that is unusual and informative. Transcribee was funded from March until September 2023 and from June until November 2026 by the Bundesministerium für Bildung und Forschung, the Prototype Fund and Open Knowledge Foundation Deutschland, with a logos image in the documentation folder.

Two funding periods, roughly six months each with a long gap between them, tells you something about the shape of the project. It was funded, then not, then funded again. That pattern is typical of research-adjacent open source work where grant money covers a development phase and the maintenance in between is done by other means, and the second period running from June to November 2026 is consistent with the alpha release in August 2026 being the output of that second period.

The funding bodies are also a signal about the intended use. A federal education and research ministry and an open knowledge foundation are not backing this for general commercial use, and the collaboration features and the export step both suit the kind of work a research or civil society team does with interviews, hearings and lectures, where several people need to produce a citable transcript of a long recording.

The project also asks contributors to read two documents first, the Code of Conduct and the Contributing Guidelines, both hosted in the bugbakery organisation rather than in this repository, which suggests a shared organisation level for the community rules across the group's projects.

For development, the README points at a development setup document in the doc/ directory, and describes it as the place to get started with developing or to try the current state of the project. There is also a doc/ folder alongside the other top level entries, which holds the self hosting, development setup and funding documentation, and a transcribee logo in a doc subdirectory, so the documentation is treated as part of the repository rather than as a wiki.

The overall picture is of a project with a real institutional funding history, a real technical stack, one alpha release, and an explicit invitation to report what breaks.

Editorial conclusion

Adopt transcribee if you need a transcript of an interview, lecture or meeting and want the drafting step handled for you, and you are willing to either use the hosted beta or run the stack yourself. Do not adopt it for a team editing one transcript simultaneously, because the project documents that concurrent editing currently causes serious performance problems. Before you self host, read the self hosting document and expect a stack rather than a single binary, since the repository is split into backend, frontend, desktop, worker, ui-common and proto directories.

Frequently asked questions

Official sources

1. bugbakery/transcribee on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases