TRANSCRIPTION workflow - How Claude saved me 2 weeks local compute for free: 1200+ podcast episodes transcribed in under 3h
Once in a while I want to transcribe a good podcast. For many reasons.
Then I thought, why not transcribe all the podcast episodes I have listened to in the last 3 years and put them in my obsidian second brain for occasional reference 
Well, Claude checked out local options and told me my Macbook Air M2 16 GB 1TB would need at least 2 weeks straight for the 1200+ (!) episodes and probably melt away. It found the number thanks to the new (?) API of the Pocketcasts app where it pulled all “played” episodes of the $timeframe I gave it.
I suggested we should explore maybe a paid options as I am sure AWS and Google must have a service for that. And I was easily willing to spend a whooping 10 USD maybe to have the work done. Then Claude suggested the MODAL.com GPU cluster instead (no ad here). It currently has 30 USD free credits every month as well as an API key.
Here comes the magic (at least from my vibe engineering point of view):
I had Claude handle it all. A single Python script defined everything: the container image (Debian + faster-whisper + model), the GPU type and the transcription function. The MODAL service comes with a work space where you deploy whatever program or even LLM model for the GPUs to feed on. So the script built the image in my workspace, started the GPUs, spread my episodes across them, sent the transcripts back to my Mac and shut everything down again.
And the 1200+ podcast source files you may ask? Claude made sure the image pulled it live into the work space straight out of the RSS feed information. Holy moly!
Where I ended up:
- TIME: less than 3 hours to process the entire batch.
- COST: 0 USD (In fact I still had 10 USD free balance left, just as claude predicted after a short test run.)
For the occasional single episode I’m back to local with mlx-whisper (built on Apple’s MLX), which runs the same model at about 10× real time on my M2 Air, so an hour of audio takes roughly six minutes. It’s free, and the audio never leaves my Mac. I now use Modal for big batches or when I’m in a hurry.
I faced a somewhat similar situation to @MacSparky and ended up going the opposite way.
I replaced my M1 Mac Studio with a new M5 Ultra Mac Studio. At the same time I also needed to replace my old 2018 Intel Mac mini home server. I considered trading in the old M1 Studio to get a M6 Mac mini. The trade in value would have been about the price of the base model mini. The M6 would have been much faster for most workloads, but I’d be giving up 4TB of storage for 256GB.
I decided to keep the M1 Mac Studio. It allows me to keep my photos library and all of my iCloud Drive on the internal SSD, which simplifies things quite a bit, especially when it comes to backups.
Just want to drop some color in on David’s comments about Docker. As a developer I’ve been using Docker for more than a decade. It’s primarily a developer tool, but has been widely accepted by tech-forward power users for certain things - especially self-hosting web-based services.
Docker is a container runtime. The simplest way to think of containers is like mini VMs, but that’s not technically true. A container can be large - and contain an entire linux operating sytem, or they can be tiny and contain only the necessary tools and software libraries to run a single application/service. Docker on MacOS actually runs your containers in a Linux VM because Docker depends on Linux runtime features that MacOS doesn’t have, but that’s unnecessary information for most people.
David seems to be conflating self-hosting services with Docker. All of the things he mentioned can be hosted outside of Docker if you want to do so. That said, Docker makes self-hosting web-based services incredibly easy. Docker did not invent the container, but it was the first product to really make them accessible and widely used.
It’s not without risk though. Most of the containers you’ll be running are open source, but vulnerabilities and security risks exist. Only run containers from trusted sources.
For those that want to explore, there’s other container runtimes for MacOS as well - some of which are faster and more efficient than Docker. They can all run the same containers. I would recommend Orbstack.
Thanks for the insight. I’m not a developer, but I read a lot of blogs and articles by developers. I’ve toyed with Docker a bit, I had a good run with Umbrel on an intel mac, but the mac is getting flaky (circa 2013 machine).
I’d love to hear a guest episode from a working IT admin/developer to go into the weeds more.
I was surprised there wasn’t a mention of GitHub on this episode as @MacSparky and @beardfm talked about their app development. It’s been hugely helpful for me.
I have been using Claude Code to develop several applications between a Mac Mini on my desk at work and a MacBook Pro that I use when not at my desk. Each application is a private repository in GitHub. These repos can be connected to the Claude apps in the Code tab as well as if you use the Claude Code terminal interface. You can also install the GitHub Desktop app to manually sync the repos to folders on your Macs.
I’m not a GitHub expert at all, but this process has taught me a lot about version control and its benefits. So while GitHub is a way to “sync” code between devices, it also keeps a history of all code changes so that you can roll back to a previous version if you ever need to. And those rollbacks can be very granular, unlike typical backups or version history you find in iCloud, Google Drive, etc.
I find the terms used in Git are confusing for someone who has never used it, and sometimes they mean the opposite as I would think. But thankfully Claude Code manages all of that and I just get to experience the benefits and peace of mind from proper version control.
If you’re doing app development (especially if you’re using multiple Macs), I think it is worth checking out GitHub. Or just ask Claude to help you determine if it would be a good fit for your situation.