My Weird Prompts

Abstract

My Weird Prompts is a fully automated podcast pipeline that transforms short voice recordings into polished, multi-voice podcast episodes. A user records a question or topic on their phone; within 15–20 minutes a complete episode is published with AI-generated dialogue between two fictional hosts, original cover art, loudness-normalised audio, show notes, and an RSS feed entry.

The system is built on a serverless architecture using Modal for GPU compute, Cloudflare R2 for object storage, Neon PostgreSQL for metadata, and Vercel for static site hosting. At current scale the pipeline costs approximately $0.33–0.45 per episode in compute.

This document describes the production architecture as of February 2026, including the 12-stage pipeline, the two-pass editing system, the parallel TTS strategy, the safety and fault tolerance mechanisms, and the cost model.

1. Introduction

1.1 The Concept

My Weird Prompts (MWP) is an experiment in full-stack AI automation: a podcast where every episode begins with a single voice memo and ends as a published, multi-voice audio show — with no manual editing in between.

The show features two AI hosts:

• Corn — a relaxed, knowledgeable sloth who leads the conversation
• Herman — an enthusiastic, curious donkey who asks follow-up questions

Prompts are typically submitted by Daniel Rosehill (the show's producer) via a mobile Progressive Web App. The pipeline transcribes the prompt, researches the topic, writes a full dialogue script, generates cover art, synthesises speech with cloned voices, assembles a broadcast-ready episode, and publishes it to the web and podcast platforms.

1.2 Design Goals

The pipeline was designed around several principles:

1. Zero human editing — every stage is automated, from transcription to publication.
2. Broadcast-quality output — loudness-normalised to EBU R128 (-16 LUFS), with proper intro/outro, disclaimer, and credits.
3. Fail-open safety — non-critical failures (cover art, polish pass) degrade gracefully rather than aborting the episode.
4. Cost efficiency — the entire pipeline runs for under $0.50 per episode, using commodity T4 GPUs and free-tier AI APIs where possible.
5. Full observability — progress tracking, email notifications, job queuing, and recovery storage for failed episodes.

1.3 The Cast

2. System Architecture

2.1 High-Level Flow

The production system consists of four deployed components connected by webhooks and shared storage:

2.2 Deployment Topology

2.3 Infrastructure Stack

The pipeline uses exclusively serverless and managed services, with no dedicated servers beyond the recorder VPS:

• Compute: Modal (serverless containers with GPU scheduling)
• Storage: Cloudflare R2 (S3-compatible, zero egress fees), Wasabi (archival)
• Database: Neon PostgreSQL (serverless, auto-scaling)
• Hosting: Vercel (static site generation from Astro)
• CI/CD: GitHub Actions (auto-deploy on push to main)
• DNS/CDN: Cloudflare (custom domains, caching)

3. Pipeline Stages

Each episode passes through 12 stages. The full pipeline runs in a single Modal container (orchestrator) that spawns GPU workers for TTS. Total wall-clock time is typically 15–20 minutes.

4. Safety & Fault Tolerance

The pipeline is designed to be resilient to partial failures. Most stages fail open, and critical failures are caught and reported.

4.1 Fail-Open Architecture

Several pipeline stages are non-critical and degrade gracefully:

4.2 Quality Gates

Hard failures that prevent publication:

• Script too short: < 2,000 words (model returned truncated or refused response)
• Too few segments: < 10 dialogue segments (script didn't match expected format)
• Episode too short: < 10 minutes duration (TTS failure produced short audio)
• TTS failure rate: > 20% of segments failed (systemic TTS problem)
• Audio download failure: File < 1 KB or download timeout > 120s

4.3 Shrinkage Guards

Both editing passes include shrinkage guards to prevent the LLM from accidentally truncating the script:

• Pass 1 (Review): Rejects output if more than 20% shorter than input
• Pass 2 (Polish): Rejects output if more than 15% shorter than input

This was implemented after early testing showed that review agents sometimes returned drastically shortened "corrected" scripts.

4.4 Recovery Storage

If an episode passes all quality gates but fails during publication (R2 upload failure, database error), the complete episode is saved to a recovery folder in R2:

• All generated files (audio, cover art, script, metadata) are preserved
• Recovery script (pipeline/scripts/recover_episodes.py) can republish failed episodes
• Error notifications are sent via email with recovery path details

4.5 Zombie Job Prevention

A top-level try/except around the entire pipeline ensures that all crashes result in the job being marked as failed in the database. Before this was implemented, pre-publication crashes would leave jobs in "running" status indefinitely.

4.6 Notification System

• Generation started: Email sent when script generation begins (includes title)
• Error notification: Email sent on any failure (includes error details and recovery path)
• Job status API: Real-time progress via /status/{job_id} endpoint

5. Cost Analysis

The pipeline is designed for minimal per-episode cost. All compute runs on serverless infrastructure with no fixed costs beyond domain registration.

5.1 Per-Episode Cost Breakdown

5.2 GPU Pricing Reference

The T4 was chosen as the cheapest GPU that can run Chatterbox Regular in acceptable time. Upgrading to A10G would roughly halve TTS time but double GPU cost.

5.3 Monthly Cost at Scale

At the current publication rate of approximately 5–10 episodes per week:

• Weekly compute: $1.50–4.00
• Monthly compute: $6–16
• Annual compute: $72–192

Modal's Starter plan includes $30/month in free credits, which covers most months entirely.

6. Technology Stack

7. Lessons Learned

Appendix: Pipeline Stage Summary