My Weird Prompts

My Weird Prompts is a fully automated podcast. Daniel sends in a prompt — a voice memo, a few typed lines, a link, sometimes a photo — and about a quarter of an hour later a finished episode is live: a researched, scripted conversation between AI characters, voiced with cloned voices, mastered, given cover art and show notes, and published to the website and every podcast platform. Nobody edits anything in between.

The pipeline runs on Modal (serverless CPU and GPU), with Cloudflare R2 for files and for the website's content catalogue, Neon PostgreSQL for metadata, Pinecone for the hosts' memory, and Vercel for the website. Every script is written by GPT-6.1 Sol, and the other text stages run on DeepSeek V4.1 Flash and Gemini Flash, all through OpenRouter; the hosts are voiced by Chatterbox, and Daniel by Meorav, a model fine-tuned on his own recordings, both running on the show's own GPUs.

This document describes production as of October 2026 (pipeline V5.9, prompts 4.21): the stages an episode passes through, the safeguards around them, what it costs, and what I learned getting here. The headline numbers below are computed from the episode archive every time the site deploys. For the history of how the pipeline changed, and which episode each change first appeared in, see the pipeline changelog.

Every episode is stamped with the model that wrote its script, the pipeline and prompt versions that made it, and its running time. These figures and charts are rebuilt from that record on every deploy, so they are never more than a deploy behind.

The show has had six main script writers. Most of the switches came in a two-week stretch in April 2026, as the pipeline moved from Gemini to Claude to DeepSeek looking for a model that would write a full-length episode at a sustainable price. The changelog has the story behind each switch.

2.1 The Concept

My Weird Prompts (MWP) is an experiment in full-stack AI automation: a podcast where every episode starts as a question from one person and ends as a published, multi-voice show, with no manual editing in between. It covers whatever Daniel happens to be curious about — AI tooling one hour, Jerusalem's underground burial economy the next.

Prompts reach the pipeline through the Send App (send.myweirdprompts.com) or the MCP admin server used from Claude Code. Listeners can send a prompt too, through the form on the site or by email to prompts@myweirdprompts.com; those come to Daniel rather than straight into the pipeline. The pipeline transcribes the prompt, researches the topic, plans and writes a dialogue script, cleans it up in code, voices it, assembles and masters the audio, and publishes it to the website and podcast platforms.

2.2 Design Goals

1. Zero human editing — every stage is automated, from transcription to publication.
2. Grounded, not improvised — a research agent gathers current, dated sources, going to primary sources where it can, before a word of script is written.
3. Funny by default — a serious question gets a straight answer, but the episode around it should be entertaining wherever the material allows.
4. Broadcast-quality audio — mastered and loudness-normalised to −16 LUFS with a −2 dBTP true-peak ceiling.
5. Fail open where it's safe, fail closed where it isn't — a missing cover image shouldn't kill an episode; a truncated script should.
6. Honest attribution — every episode ends by naming the model that wrote it, and that credit has to be true.
7. Cheap enough to run daily — well under a dollar per episode, all in.

2.3 The Cast

3.1 High-Level Flow

Two ways in, one generator, and a fan-out to storage and distribution:

3.2 Deployment Topology

3.3 Infrastructure Stack

Everything is serverless or managed — there is no server to keep running:

• Compute: Modal — CPU containers for orchestration, L4 GPUs for speech
• LLM: through OpenRouter, with DeepSeek's own API as the standby route. GPT-6.1 Sol writes the script; Gemini Flash writes the title, description and blog post; DeepSeek V4.1 Flash runs every other text stage. Utility stages use OpenRouter's “latest” aliases, so they move to a new generation of the same family without a code change
• Speech: Chatterbox Regular (open weights, self-hosted, pinned to an exact release); prompts are transcribed by Gemini Flash (latest), with Whisper large-v3 as the fallback, both through OpenRouter
• Orchestration: LangGraph for script generation; a generic dispatcher that routes 14+ episode formats through one code path; an LLM supervisor that decides whether a crashed run is worth retrying
• Storage: Cloudflare R2 (zero egress fees), Wasabi and Backblaze B2 for backups
• Data: Neon PostgreSQL for metadata and jobs; Pinecone for vector memory
• Hosting: Vercel (Astro). A new episode goes live through the R2 content catalogue as soon as it publishes, with no site build; the rest of the site still rebuilds on a half-hourly schedule
• CI/CD: GitHub Actions — merging a pipeline change to main deploys it to Modal

Each episode passes through twelve stages. The text half runs as a LangGraph state graph in one Modal container; the audio half fans out to GPU workers and back. Across 164 episodes made on pipeline V5.4–V5.6 (12–17 October 2026), a run took 11–17 minutes (10th to 90th percentile; median 13), of which voicing took about four and a half.

10

Stage 10: Speech (Parallel GPU Workers)

Every host line is voiced by Chatterbox Regular, an open-weights voice-cloning model, running on the show's own Modal GPUs. Each character, guests included, has a voice of its own; a speaker the pipeline doesn't recognise falls back to Herman's voice. Daniel's own voice, in the prompt introduction, the AI disclaimer and any lines he has in an episode, comes from a separate model, Meorav, described below.

Architecture

Orchestrator (CPU) Normalises the text, cuts long lines into chunks of at most 250 characters, and splits them into three contiguous blocks

↓

Worker 1 (L4) ~⅓ of dialogue

Worker 2 (L4) ~⅓ of dialogue

Worker 3 (L4) ~⅓ of dialogue

↓

Results merged in order and concatenated with ffmpeg

Text Normalisation

Chatterbox does no number or symbol expansion of its own, and the script prompt's “spell numbers out” rule didn't hold: the last 60 scripts before the fix carried about 1,000 digit tokens. Since October 2026, every line containing a digit, a symbol or a domain passes through a layer of tech-specific rules (so an RTX 4090 is “forty ninety” and GPT-4o is “GPT four-oh”) and then NVIDIA's rule-based NeMo text normaliser, before it is chunked. Every other sentence passes through untouched. Run over those 60 scripts, it left no unspeakable tokens behind. See 8.10.

Key Optimisations

• CUDA-graph fp16 decode: stock Chatterbox launches each layer's work separately for every speech token, so the GPU spends more time being told what to do than doing it. The pipeline records one token's worth of work as a single CUDA graph, replays it once per token, and runs the language-model backbone in half precision. On the L4 that took the real-time factor from 0.96 to 0.35; see 6.2.
• No attention weights: stock Chatterbox asked for attention weights on every decode step, which forces the slow attention path; only a multilingual alignment component reads them. The image build patches both requests off, and checks there are exactly two, so a new release can't quietly dodge the patch.
• Cached voice conditionals: each character's voice embedding is computed once and stored in R2, instead of being recomputed for every line.
• Weights in the image, pinned: the model files ship inside the container image at an exact release, so a cold start doesn't download ~3 GB first, and every episode records which Chatterbox build voiced it.
• Immediate scale-down: workers shut down two seconds after finishing their batch instead of idling for a minute on the meter.
• Encoding off the GPU loop: each line is encoded to AAC on a CPU thread while the GPU moves on to the next.

Failure Handling

• Each line gets one retry; individual failures are tracked but don't abort the episode. Lines already rendered are skipped on a re-run, so a retry resumes rather than starting over.
• If more than 20% of lines fail, the episode is aborted rather than published with gaps.

Daniel's Voice: Meorav

Quick voice clones, which take a few seconds of reference audio, keep a speaker's timbre and lose their accent: Daniel's came out American. So his voice is a model of its own. Meorav (Hebrew for “mixed”) is a full fine-tune of Qwen3-TTS 1.7B on 1,103 takes of Daniel reading, about 88 minutes after trimming: phonetic sentences covering every English sound, conversational lines in his own register, English sentences with Hebrew words in them, and names of places. Every weight is trained (learning rate 7×10^-6, three epochs), which is what moves the accent. Because the training sentences mix English and Hebrew, it says Hebrew words inside English lines the way he does, with none of the code-switching machinery below.

• Where it runs: its own GPU worker in a separate container image (its dependencies conflict with Chatterbox's), alongside the Chatterbox workers. It reads the introduction to every prompt and the AI disclaimer, and any of Daniel's lines in an episode that asks for it. A failed prompt introduction falls back to a Chatterbox clone of Daniel rather than failing the episode.
• Versions: v2.1 since 22 October 2026, the v2.0 recipe on the same takes after DeepFilterNet 3 noise removal. Each container asks Hugging Face for the newest published version, so a new release goes live without a deploy; the version baked into the image is the fallback, and every line records which version spoke it.
• Speed and checks: about 2.4 seconds of L4 time per second of speech, several times slower than Chatterbox, so Daniel's lines are split across two workers. On long lines v2.0 sometimes dropped words, so each new version is checked by transcribing test lines against their text before it is adopted.

The model is published as Hebrish/Meorav (access on request, CC BY-NC 4.0). For a whole episode of Daniel talking to it, and how that was stitched together, see The Bake-Off: My Real Voice vs My Voice Clone.

Other Languages

Selected episodes are also published as translated editions, each language with its own feed. The script is translated, and the same hosts re-voice it on Chatterbox Multilingual. Hebrew text first gets full vowel marks from Dicta's niqqud model, because unvowelled Hebrew is ambiguous to read aloud. A translated edition links back to its English original and the original links to it.

Experimental: Hebrew Code-Switching

Daniel often drops Hebrew words, written in English letters, into English prompts. An opt-in route, off by default and separate from the normal workers, finds those words with a small token classifier, has a language model write each in Hebrew script with full vowel marks, and renders each line in English and Hebrew pieces on Chatterbox Multilingual before stitching them together. If a script turns out to contain no Hebrew at all, the job fails before it touches a GPU.

The rule of thumb: anything that would make a worse episode fails open; anything that would make a broken one fails closed.

5.1 Fail-Open Stages

5.2 Quality Gates

Before voicing, a script that misses its length range is sent back once: expanded if it is more than 10% short, trimmed if it is more than 5% long (and the result is rejected if it overshoots). These then abort the episode before any GPU time is spent or anything is published:

• Script too short: below a floor set by the planned length — 1,800 words for 15 minutes, 3,000 for 25, 3,800 for 30 (a truncated or refused generation)
• Too few lines: under 10 dialogue segments (the script didn't come back in the expected format)
• Speech failure rate: more than 20% of lines failed to voice

5.3 A Supervisor for Crashes

A crashed run used to be retried a fixed number of times with a fixed wait. That is fine for a network blip and wasteful for anything that won't fix itself — bad input, an expired key, an empty credit balance — which then burned two more complete runs before giving up. Now a small LLM call (temperature 0, 300 tokens) reads the error and says one of two things: retry, with a wait it chooses, or abort. The guard rails are in code, not in the model: the retry cap (two automatic retries) is enforced by code, the wait is clamped to between 15 seconds and five minutes, and if the supervisor itself fails the run falls back to the old fixed rule.

5.4 Recovery Storage

If an episode passes every gate but publication itself fails (an upload or database error), everything that was generated — audio, cover, script, metadata — is saved to a recovery area so it can be republished without regenerating it.

5.5 No Zombie Jobs

A top-level guard around the whole pipeline marks any crash as a failed job in the database. Before it existed, a crash before publication could leave a job showing “running” forever.

5.6 Credit Alerts

Twice a day a housekeeping job checks the prepaid balances the pipeline depends on and emails Daniel when DeepSeek or OpenRouter is under $5, or when DeepSeek reports the account as unavailable, which happens before the balance reads zero. It keeps emailing on every run until somebody tops up. This exists because a DeepSeek balance hitting zero in August 2026 stopped every episode.

5.7 Test Mode

A test run executes the entire pipeline including the database writes, verifies the stored row field by field, then deletes it. Public pages filter test rows out regardless. Its first run caught a real bug: one of two database insert paths had its own hard-coded column list and was silently dropping a field.

5.8 Observability

Every run records a trace of its stages, including the research agent's full tool log, and every published episode stores its own production record: script model, pipeline and prompt versions, research engine, GPU type, worker count, the exact Chatterbox build, generation and speech times, and LLM and GPU cost. That record is what this page's charts are built from, and it is published in the episodes dataset.

Costs below are the per-episode figures the pipeline records on every episode (LLM cost from token usage; GPU cost as worker time at Modal's list price), as medians across the 164 episodes made on pipeline V5.4–V5.6 between 12 and 17 October 2026: all written by DeepSeek V4.1 Flash and voiced on three L4 workers with the CUDA-graph fp16 decode. The median episode in that set ran about 27 minutes.

6.1 Per-Episode Cost

Speech is about 70% of the cost of an episode and the LLM about a quarter. That is the reverse of the show's early days, when a hosted voice API and a premium script model made an episode cost around $2. It is also down from about $0.43 an episode in late September, before the per-episode slate was retired (9 October) and the speech decode was rebuilt (10 October). The recorded speech cost works out to about $0.39 per hour of finished audio, above the $0.28 benchmark in 6.2, because it bills all three workers for the whole parallel stage, start-up and waiting for the slowest block included.

6.2 Why L4 (again)

RTF is seconds of rendering per second of audio, measured on the production build with 16 real script lines (decisions 103 and 105, October 2026). The GPU choice flipped twice in one day. Stock Chatterbox generates speech one token at a time and is limited by kernel-launch overhead rather than raw GPU power, so on the stock decode a T4 rendered about as fast as an L4 for less per second, and the workers moved to T4 (about $0.50 per audio-hour against $0.77). The same day the decode was rebuilt: each one-token step is captured as a CUDA graph and the language-model backbone runs in fp16. With the launch overhead gone, the L4's extra compute finally shows: it now renders nearly three times faster than before (RTF 0.957 to 0.346) and costs less per audio-hour than a graphed T4, so the workers went back to L4. The fp16 decode picks slightly different speech tokens late in a few lines, so it shipped as a listening test; a token-identical fp32 graph mode and the stock decode remain one setting away. A prototype that decodes several turns at once is built and benchmarked but not yet wired in.

6.3 At Scale

At September 2026's pace of about 23 episodes a day, nearly all of the running cost is GPU time, which is why the speech stage gets most of the optimisation work. Running the LLM on the show's own GPUs instead was costed too: to fit V4.1 Flash takes eight H200s, and it would only break even at about 4,500 a month, against the roughly 640 episodes actually made, so the script stays on DeepSeek's API.