The $0 Personalized News Roundup That Lands in Your Podcast App Every Week
For anyone who knows me, you know that audio is a big part of my life - podcasts, audiobooks, music - All The Aural Things.
I typically start my morning by reading newsletters but sometimes that ritual gets thrown off due to scheduling issues. Listening to tech news helps fill that gap - but I usually have to jump between podcasts to find what I want.
This past weekend, I was using Perplexity for some Deep Research and stumbled upon a Podcast Skill designed to be used by Perplexity’s Computer. You provide a topic to the skill and it will create a two-person, discussion-style podcast on that topic. It’s a beefy 14-step pipeline that does everything from researching the topic to ensuring the audio uses the proper LUFS for spoken audio to creating the cover art.
Instead of Perplexity’s original use case - give it a topic and it returns a podcast on the subject - I created a Hermes workflow that produces a weekly tech news roundup podcast using my local, owned systems with the following instructions:
Every day, search for the most significant technology developments, focusing on: 1) Edge Computing; 2) Edge AI, 3) AI and ML breakthroughs; 4) Emerging tech trends and their potential impact; 5) Major tech company strategic moves.
When worthy news is found, save what you find to a reference file.
Every Monday morning at 4 AM US Central Time, review that reference file and create a podcast based on the previous week’s findings and post it to the RSS feed. Send a notification via Telegram when it’s ready. No need to send the audio to Telegram.
In the episode, note the source or sources of the news for each newfound item. (Full URL’s are not required in audio, only the name of the most notable publication.) Note how many publications covered it as a signal of its significance. (“This was covered in at least n publications.”)
In the episode description, include any relevant links to each of the topics.
Before creating this workflow, suggest any improvements to my request.
The Final Product
Does it sound as good as a podcast made by humans? Hell, no. Does it sound as good as Google’s NotebookLM podcasts? Also no.
Sure, I could create higher quality audio by using a service like Eleven Labs or Fish Audio, each of which have much better voices, but there are no incremental costs to my workflow, and it’s good enough to keep me informed on a Monday morning while I walk my dogs.
But first, I needed to adapt the original skill for my owned infrastructure.
TL;DR: If you just want my adapted skill for your own use, you can find it here.
Adapting Perplexity’s Podcast Skill for Hermes
The original skill was an impressive pipeline that researched topics, wrote multi-host scripts, synthesized speech, sourced music, assembled audio, and ran multiple QA passes including WavLM artifact detection and multimodal listenability review (where the LLM actually “listens” to the audio output). The problem: almost none of its prescribed tools existed in my environment.
The Gap
The original skill assumed a platform with a text_to_speech (TTS) tool that accepted per-line voice parameters, a transcribe_audio tool, an audio-capable multimodal model for listenability QA, browser-based authenticated downloads for music sourcing, and a full PyTorch stack for neural audio quality checks. I had none of those.
What I did have: a Kokoro TTS server on a Mac Studio, a Whisper model on the same machine, ffmpeg on the Debian LXC where I run Hermes, Tailscale connecting everything, and a Telegram bridge for notifications. The adaptation was an exercise in mapping capabilities - not feature-matching, but instead asking “what does this step produce, and what’s the simplest way to get there given what I already have?“
Multi-Voice TTS Without the Tool
The biggest architectural change was TTS. Hermes ships with a text_to_speech function that reads one voice from it’s configuration - great for Telegram voice replies, but useless for a two-host podcast where af_heart and am_adam (AI voices that ship with Kokoro) alternate every line.
The fix was to stop using the built-in Hermes tool entirely for this task. Kokoro exposes an OpenAI-compatible API, so each dialogue line became a direct curl call with a voice parameter:
curl -s http://TailscaleIP:8000/v1/audio/speech \
-X POST -H "Content-Type: application/json" \
-d '{"model":"mlx-community/Kokoro-82M-bf16","input":"Welcome to the show.","voice":"af_heart"}' \
-o line_001.mp3
(Yes, Hermes backed by Deepseek v4 Pro helped me figure this out.)
This bypasses Hermes’ single-voice constraint entirely. The podcast uses af_heart and am_adam for its hosts, while my Telegram voice (am_eric) stays untouched. Clean separation and zero config changes between modes.
Transcription: Fixing Whisper on oMLX
The Mac Studio already served whisper-large-v3-turbo through oMLX, but calls to the transcription endpoint failed with a cryptic error about missing HuggingFace configuration files. MLX-converted models strip preprocessor_config.json, tokenizer.json, and special_tokens_map.json - they’re not needed for inference, but oMLX’s API layer requires them to initialize the processor. Thank dog for Hermes or I would have never figured this out.
Three curl calls to the upstream HuggingFace repo fixed it:
cd ~/.lmstudio/models/mlx-community/whisper-large-v3-turbo
curl -O https://huggingface.co/openai/whisper-large-v3-turbo/resolve/main/preprocessor_config.json
curl -O https://huggingface.co/openai/whisper-large-v3-turbo/resolve/main/tokenizer.json
curl -O https://huggingface.co/openai/whisper-large-v3-turbo/resolve/main/special_tokens_map.json
QA Without Neural Models
The original skill ran two QA passes I couldn’t replicate: WavLM-based artifact detection (requires PyTorch and transformers) and multimodal listenability review (requires an audio-capable model like GPT-4o or Gemini Pro Audio). I had neither.
The replacement was simpler but (I think) just as effective: transcribe the assembled MP3 through Whisper, diff the transcript against the original script, and run ffprobe for technical checks (LUFS loudness, true peaks, silence gaps). For the test episode, this caught the first mastering pass being 5 dB too quiet - the episode was at -22 LUFS, well below the -16 target. A second pass with increased gain fixed it.
The insight: for a synthetic podcast where the source text is known, transcription accuracy is a better quality signal than neural artifact detection. (Especially if you don’t have an audio-capable model, natch.) If Whisper transcripition matches what the script wrote, the TTS did its job.
Delivery: RSS & MP3 Without a Public Cloud
My environment has no public cloud storage. The solution was to serve the RSS feed and MP3s directly from Hermes’ Debian LXC in my closet via Python’s built-in HTTP server, then expose it through a Cloudflare Tunnel for HTTPS and a public hostname.
The Cloudflare Tunnel became a requirement since the Apple Podcasts app wouldn’t retrieve the RSS feed or MP3 audio file over Tailscale, even though my iPhone was connected to my Tailnet. Doing this provides the additional benefit of making the podcast available in my Tesla, where the Apple Podcasts app is also installed.
The valid RSS feed lives as a static XML file at /root/podcast/rss.xml. A weekly cron job handles the entire pipeline - curation, production, RSS update, and notification - without human intervention.
Cloudflare blocks all bot traffic so that my LXC and home internet connection don’t get crushed by incoming requests for a podcast that is intended to have an audience of one.
What Stayed, What Went
The original 14 steps collapsed into seven: research, script, sound design, TTS, music, assembly, and QA. The editorial review, readability check, and fact-check merged into a single self-review pass using the transcription. Sound design became a JSON blueprint rather than a full production document. Music sourcing used generated tones as a practical fallback to Freesound and Pixabay. (I actually like the generated tones.)
The entire pipeline for the test episode - 16 TTS calls across two voices, music generation, ffmpeg assembly, Whisper transcription, and RSS update - completed in under two minutes. It was a five-minute deep dive on edge AI and the $2.3 billion in hardware startup funding flowing into the space in 2026, was accurate down to the LUFS target on the second mastering pass.
The Principle
The adaptation pattern wasn’t “replicate the tool” - it was “produce the output.” When a tool was missing, the question was never “how do I install WavLM?“ but “what does WavLM tell me, and is there another way to get that information?“ The answer was usually simpler than the original skill. Transcription diff catches garbled TTS. ffprobe catches loudness problems. A well-structured prompt catches editorial issues. The pipeline got shorter because the constraints forced it to be honest about what each step actually contributed.
