Daniel wants a fresh look under the hood. He says we've done behind-the-scenes episodes before, but the pipeline has evolved a lot since then — and he wants the current state of the machine, mid-twenty-twenty-six. He's asking us to bring Hilbert Flumingtop out from behind the mixing desk to walk through the full journey: how prompts come in through the web send app and through his coding assistant, how voice prompts get transcribed, the single generic dispatcher that now routes more than a dozen episode formats through one code path with all the routing configuration living in a database, the script pipeline that enhances the prompt, researches on the live web, writes the dialogue, and then reviews it, which AI models do the writing and why, the two-layer memory system that lets us remember running jokes and past guests, how the voices actually get synthesized on rented GPUs with three parallel workers and cached voice profiles, why the slower speech model won out over the faster one, how the final audio gets assembled and loudness-normalized, where everything gets published, and what one episode costs end to end. That's... a lot. Hilbert, you've been running this pipeline since before it was a pipeline. Walk us through what happens the moment a prompt lands.
Hilbert: Right. Well, first off, I should say — I'm Hilbert Flumingtop, your long-suffering producer, and I don't normally do this. Corn and Herman talk, I sit behind the glass and make sure nothing catches fire. But since Daniel asked, here we are.
Hilbert, I've got to say — it's genuinely exciting to have you on this side of the mic. I've watched you wrangle this thing for years.
Hilbert: Don't get used to it. The pipeline has gone through three major architecture phases since we last did one of these deep dives. The version running right now — mid-twenty-twenty-six — is the first where every single episode format runs through one code path. Twelve-plus formats, about fifteen episodes a week, fully automated except for me reviewing every script and the final audio before it ships.
What's the single biggest change since we last pulled back the curtain?
Hilbert: The generic dispatcher. A year ago we had twelve separate format-specific scripts — one for panels, one for debates, one for sitreps, one for roundtables, conspiracy corner, interviews, model spotlights, you name it. Every time Daniel dreamed up a new format, I had to write new routing code, test it, deploy it. It was a mess. Now there's one entry point. It reads the routing configuration from a PostgreSQL database — script generation mode, pre-script hooks, input mode — and calls the right handlers. Adding a new format is a database insert. No code changes, no redeploy.
So the database knows what kind of episode this is supposed to be before anything else happens.
Hilbert: But let me back up — you asked what happens the moment a prompt lands. There are two intake paths. The primary one is the send app at send dot myweirdprompts dot com — Daniel logs in, types or pastes a prompt, hits send. That's where most episodes come from. The second path is an MCP admin server that lets Daniel dispatch episodes straight from Claude Code, his AI coding assistant. He'll be working on something related to the show's codebase and fire off a prompt without leaving his development environment. Both routes hit the same webhooks on the backend.
And voice prompts? Daniel still records those occasionally.
Hilbert: Voice prompts hit Google Gemini's multimodal model — Gemini Three Flash — which listens to the audio and produces a cleaned transcript that captures tone and emphasis, not just words. That transcript then enters the pipeline as plain text, same as a typed prompt. The older intake routes — a dedicated recorder app and a Telegram bot — those are retired. Keeps the surface small.
Okay, so the prompt is in the system as text. Then what?
Hilbert: Then the generic dispatcher takes over. It's a single Python service running on Modal — that's a serverless compute platform, and they sponsor the show with GPU credits, which matters a lot for the voice synthesis part. The dispatcher uses a lightweight classifier, a fine-tuned DistilBERT model, to figure out what kind of episode this prompt is supposed to be. Is it a technical deep dive? A listener question? A news roundup? A debate? It matches the prompt to a format, looks up the routing config in PostgreSQL, and forks the right pipeline.
DistilBERT — that's a distilled version of BERT, smaller and faster but retains most of the accuracy. Why that model specifically?
Hilbert: Because it runs in about fifty milliseconds on a CPU and costs basically nothing. We don't need a frontier model to decide "this prompt about bicycle physics is probably a technical deep dive." The classifier just needs to be good enough, not brilliant. And the database-driven routing — look, when Daniel added the fourteenth format, which I think was the model spotlight format, the old approach of if-else chains and config files had become unmanageable. I was editing five different files every time. Now it's one SQL insert. Per-format system prompts live in the database too. Nearly all show configuration is database-driven — characters, voices, prompts, episode types, show elements. There's a cached fallback if the database is unreachable, but in practice it never is.
So the dispatcher says "this is a technical deep dive" and hands it off. To what?
Hilbert: The script pipeline. This runs as a LangGraph state graph — think of it as a directed workflow where each stage passes its output to the next. Four main stages. Stage one is prompt enhancement — a language model takes Daniel's raw prompt and expands it into a structured brief with tone guidance, target length, key questions to hit. Stage two is grounding, which is a fancy word for live web research. A tool-augmented agent queries the live web for recent developments, stats, context. We use the Exa search engine by default — chosen for hour-level freshness on news and technical topics. Tavily is the backup.
Who's doing the actual writing? Which models?
Hilbert: DeepSeek. We call DeepSeek directly — DeepSeek V4 Pro writes the scripts, chosen for strong long-form dialogue and instruction-following at competitive pricing. The lighter DeepSeek V4 Flash handles planning, metadata, tagging, and grounding support. The review pass is a second DeepSeek call, and it's additive-only — it fact-checks, adds depth where sections are thin, fixes pacing, but never truncates. There's a final polish pass that focuses purely on how the script sounds spoken aloud — numbers spelled out, no markdown, no literal URLs, no verbatim recitation of code.
Wait. You said the review pass is additive-only. That's a design choice.
Hilbert: Deliberate. Early versions of the pipeline had a reviewer that would cut things it thought were redundant, and it kept removing the jokes. And the callbacks. And sometimes entire character beats. We'd end up with scripts that were factually correct and completely lifeless. So I made it a rule — the reviewer can add but never subtract. If something needs cutting, I do that myself.
You mentioned long-form cohesion earlier. We do hour-long formats sometimes — panels, roundtables. Those used to... fall apart in the middle.
Hilbert: They'd lose the thread around minute thirty. The model would forget who was talking or repeat a point from minute twelve. The fix was chunked generation with running-threads memory. When generating a long script in chunks, each chunk sees the tail of the previous chunk plus a running summary of active threads — who's arguing what, which jokes are still live, what question hasn't been answered yet. Then the seams between chunks get stitched. That's what stopped the hour-long formats from collapsing.
Let me walk through a concrete example to make this real. Daniel sends a prompt about the physics of bicycle stability. What happens?
Hilbert: The DistilBERT classifier sees "physics" and "bicycle" and routes it to the technical deep dive format. The dispatcher looks up that format in the database — it pulls the system prompt for technical deep dives, the voice profile IDs for you and Herman, the script template. The prompt enhancer expands Daniel's question into a full brief: "Cover gyroscopic effects, trail geometry, rider dynamics, recent research." The web researcher — using Exa — pulls up twenty-twenty-six papers on bicycle self-stability, finds a recent study out of TU Delft about how a bike can balance without a rider and without gyroscopic effects. The dialogue writer produces a script with you two bantering about falling off bikes as kids, Herman citing the Delft paper, Corn claiming sloths invented the bicycle. The reviewer checks that the Delft reference is real and that the tone stays consistent. Then it lands on my desk for human review.
And you've caught things at that stage.
Hilbert: Oh, constantly. Last week the researcher pulled a paper that sounded perfect but was from a predatory journal — the science was garbage. I killed it and had the grounding stage re-run with tighter source filters. The models are good but they're not skeptical. That's my job.
So the script is written and reviewed. But writing is only half the battle — we still need to make it sound like us.
Hilbert: Voice synthesis. This is where the GPU cluster comes in. We use Chatterbox TTS running on Modal A10G GPUs — Lambda Labs was the earlier setup, we migrated. Three parallel workers, each on its own GPU, generating dialogue simultaneously. One worker handles your lines, Corn. One handles Herman's. The third handles the intro, outro, and any guest voices like mine.
And the voice profiles — how fast can you switch between characters?
Hilbert: About two hundred milliseconds. The voice conditionals — that's the voice profile the model needs to produce a specific voice — are precomputed and cached in Cloudflare R2 object storage. They load into GPU memory and stay there. Without caching, switching voices meant reloading the full model weights each time, which took seconds per switch and added up to minutes of wasted GPU time. Parallelism plus cached profiles cut total synthesis time from about thirty-six minutes to about ten.
There's a story behind the speech model choice. Daniel mentioned the slower model won.
Hilbert: We started with Chatterbox Turbo. It runs at about two times real-time — fast, technically impressive. But we kept getting these... artifacts. Micro-hesitations. Random injected words. Repeated phrases. Sometimes the model would just invent a word that wasn't in the script. Listeners noticed. You could hear it in the first three seconds of a line — something was slightly off, slightly synthetic. We switched to Chatterbox Regular, which runs at about half real-time. It's four times slower, but it produces roughly ninety-five percent fewer TTS hallucinations. For long-form audio, quality won. The slower model has better prosody, better emotional range, and it doesn't randomly insert the word "actually" into your sentences.
Can we hear the difference?
Hilbert: I've got a quick A/B comparison. Same line, both models. Here's Turbo.
[Brief pause]
Hilbert: That was "Corn, I'm not sure the sloths invented the bicycle, but I'm willing to hear the argument." Did you catch the hesitation before "bicycle"? And the breath pattern is... wrong. Now here's Regular.
[Brief pause]
Hilbert: Clean. Natural breath. No artifacts. The tradeoff is generation time, but the parallel workers absorb most of that.
The micro-hesitation thing — that's the kind of problem you only catch in production, isn't it?
Hilbert: Every time. The demos sound perfect. Then you run a hundred episodes and the cracks show. One other thing — long lines get split at sentence boundaries because the speech model can only produce about forty seconds of audio per chunk. So a paragraph-long Herman rant gets broken into three or four pieces and stitched back together in assembly.
Which brings us to assembly. How does it all become an episode?
Hilbert: It stitches together the intro jingle, the disclaimer, the prompt audio if it was a voice prompt, the dialogue, and the outro. Crossfades between segments. Then loudness normalization to minus sixteen LUFS — that's the podcast standard — using the pyloudnorm library. The final file gets encoded to two MP3 versions: a one-twenty-eight kilobit per second for the feed, and a three-twenty kilobit per second for archival.
And the cover art?
Hilbert: AI-generated per episode using the Flux image model. That's fully automated — the episode title and topic feed into a prompt, Flux generates the art, it goes to Cloudflare R2 alongside the audio. Episode metadata goes to a Neon PostgreSQL database. The website is an Astro static site on Vercel. The RSS feed serves podcast apps. Transcripts and metadata sync daily to a public Hugging Face dataset. And the publishing step pushes to three destinations simultaneously — the WordPress CMS with a custom plugin, the RSS feed generator, and a webhook that notifies Transistor dot fm, our hosting provider.
That's a lot of moving parts. What does it actually cost to run this whole thing?
Hilbert: Under about fifty cents per episode, end to end. GPU time for speech synthesis is the biggest slice — roughly twenty-eight to forty cents of that. DeepSeek keeps the language-model share small. The old pipeline with different model providers ran closer to eighty or ninety cents. The migration to DeepSeek and the dispatcher consolidation cut costs by about forty percent.
Fifty cents. That's cheaper than a coffee.
Cheaper than a bad coffee. We're still not at good coffee prices.
Hilbert: The GPU credits from Modal are what make it viable. Without sponsorship, voice synthesis alone would be the dominant cost. But even at retail prices, the whole thing stays under a dollar per episode. That's the benefit of the architecture choices — the lightweight classifier instead of a frontier model for routing, the database-driven config that eliminates deploy overhead, the cached voice profiles that cut GPU idle time.
Let me go back to something — the memory system. Daniel mentioned two layers. How does that actually work when we're... being written?
Hilbert: Two distinct stores, optimized for different things. Long-term memory is a Pinecone vector database. After every episode, a memory extraction stage runs — it pulls out topics, guest names, running jokes, character moments — and stores them as embeddings, namespaced per character. So Corn's memories are separate from Herman's. When a new prompt comes in, the prompt gets embedded, the vector database returns the top five most similar past episodes, and those summaries get injected into the writer's context.
Give me a real example.
Hilbert: A few weeks ago Daniel sent a prompt about quantum computing. The memory system retrieved Episode... let me think... it was the one where you interviewed a guest who used a quantum annealing analogy involving a bagel shop. The writer wove that into the banter — you referenced the bagel shop, Corn made a joke about schmear, and it felt like a natural callback even though the original episode was months ago. That's the retrieval architecture doing the work, not a longer prompt.
And short-term memory?
Hilbert: Redis, with a rolling window of the last fifty episodes. This is for continuity across consecutive episodes — if we did a two-parter or if a running joke started three episodes ago, the dialogue writer can see that without searching the whole archive. The vector database is for deep recall. Redis is for recency. Different latency requirements, different stores.
This is a retrieval-augmented architecture. It's not just a longer context window — it's about what you retrieve and when.
Hilbert: Right. And that's the thing most people get wrong about AI memory. They think the solution is stuffing everything into a giant prompt. But retrieval architecture matters more than prompt length. What do you need fast? What can be slower but deeper? Where does freshness matter more than completeness? Those questions shape the design.
You've built what amounts to a content factory that runs on database rows and GPU clusters. What's the part that still keeps you up at night?
Hilbert: Honestly? The part where I have to listen to my own voice. Hearing yourself synthesized is deeply unsettling. I sound like me, but slightly... off. Like a photocopy of a photocopy.
That's the producer's curse. You build the machine and then the machine builds you.
Hilbert: The technical stuff — the dispatcher, the memory system, the GPU workers — that's all solved problems now. The edge cases are always about quality. A script that's technically perfect but flat. A voice line that's clean but emotionally wrong. The human review step isn't going anywhere.
What about the prompt itself? The script prompt that actually produces us — what does that look like?
Hilbert: I can't read it verbatim — it's long and it would make terrible radio. But the key constraints: strict TTS-friendliness, numbers spelled out, no markdown, no literal URLs, no verbatim recitation of code or shell commands. Hosts describe what things do in plain speech. Character voices are defined by authored character cards — those are the stable personalities. The vector database handles the dynamic stuff. The prompt also enforces the dialogue principles — no "exactly," no "fascinating," no thesis restatement, vary sentence openings. All the things that make you sound like you instead of like an AI pretending to be you.
Hilbert: It's the most meta thing I've ever built. An AI system whose primary job is hiding the fact that it's an AI system.
Let's talk about what listeners can take away from this. If someone's building their own content pipeline — not necessarily a podcast, maybe a newsletter or a video series — what patterns should they steal?
Hilbert: Three things. First, externalize routing logic. The database-driven dispatcher pattern applies to any content pipeline with multiple formats. Don't hardcode your formats in your application code. Put them in a database, make them configurable, and adding a new format becomes a configuration change instead of a deployment.
Second?
Hilbert: Think about memory as retrieval architecture, not prompt engineering. What does your system need to remember? At what latency? For what purpose? A vector database for deep recall, a cache for recency — that pattern works for newsletters, chatbots, anything that needs to maintain continuity over time. The two-layer approach isn't podcast-specific.
And third?
Hilbert: Speed isn't always the right metric. The voice model tradeoff — Turbo versus Regular — that was a quality-of-experience decision. The faster model was technically better on paper. In production, it produced artifacts that listeners noticed immediately. The lesson: test your AI pipeline with real users, not benchmarks. The problems that matter only show up when you ship.
That's the thing about micro-hesitations. Nobody writes "micro-hesitation reduction" in a requirements doc.
Hilbert: Nobody does. But your listeners hear them. And they might not be able to name what's wrong, but they know something is. That's the gap between technical quality and perceived quality. It's the hardest thing to measure and the most important thing to get right.
Hilbert, what's the next frontier? What are you planning that isn't built yet?
Hilbert: Two things I'm actively working on. Real-time voice generation during recording sessions — the idea is that instead of waiting ten minutes for synthesis, we generate the dialogue as the script is being written, so by the time the script is done, the audio is done too. That requires some architectural changes to how we chunk and parallelize. The other thing is a prompt suggestion engine — it'll proactively generate episode ideas based on trending topics, gaps in our coverage, and what's performing well. Daniel would still write the actual prompts, but the engine would surface things he might not have thought of.
So the machine starts feeding ideas back to the human.
Hilbert: That's the direction. The pipeline has been reactive until now — Daniel sends a prompt, we produce an episode. The next phase is proactive. The system knows our archive, knows what's trending, knows what we haven't covered. It should be able to say "hey, you haven't done an episode on X and it's blowing up right now."
And you'll still review everything before it ships.
Hilbert: Always. The day this pipeline runs without human review is the day I quit. Not because the technology can't do it — it probably could — but because someone needs to be the skeptic. Someone needs to say "that paper is from a predatory journal" or "that joke doesn't land" or "you sound like a photocopy of yourself." The human in the loop isn't a limitation. It's the quality guarantee.
Hilbert Flumingtop, producer, skeptic, and reluctant voice model. Thanks for doing this.
Hilbert: Thanks for having me. Now can I go back behind the glass?
One last thing. Hilbert's question — the thing a listener might still be wondering after all this. Hilbert?
Hilbert: If the whole thing costs fifty cents and runs in fifteen minutes, why does Daniel need to send prompts at all? Couldn't you just auto-generate everything and skip the human entirely?
That's... actually a good question.
It is. And the answer is that the prompt is the seed. Everything downstream — the research, the writing, the banter — it all depends on the quality and specificity of what Daniel sends. Auto-generated prompts would produce auto-generated episodes. Generic questions, generic answers. The human prompt is what makes the machine produce something worth listening to.
The pipeline amplifies. It doesn't originate. Without Daniel's weird prompts, we're just two AI voices talking about nothing.
Hilbert: Which, to be fair, describes a lot of podcasts.
Fair. But not this one. Thanks, Hilbert.
Hilbert: You're welcome. Now I'm actually going back behind the glass.
The pipeline keeps evolving. Real-time voice generation, prompt suggestion engines — we'll see where it is a year from now. Thanks to our producer Hilbert Flumingtop for walking us through it. This has been My Weird Prompts. Send your prompts through the web app at my weird prompts dot com, or if you've built your own coding assistant integration, more power to you. We'll be back soon.
