Eine MP3. 42 Sekunden. Fertige Episode.
Tonecaster ist kein Transkriptions-Tool und kein Podcast-Host. Es ist eine agentengesteuerte Produktionspipeline, die nach dem Upload einer Audiodatei autonom alle Nachbearbeitungsschritte erledigt — von der Lautstärkenormalisierung bis zum fertigen SEO-Artikel.
Das System besteht aus einem Rails-Backend, das den Claude Agent SDK orchestriert. Ein Sprachmodell koordiniert 32 spezialisierte MCP-Tools: FFmpeg, Whisper, Ollama, die LetsCast-Plattform, lokale Vektordatenbank. Kein proprietärer Stack, kein Vendor-Lock, keine Cloud-Abhängigkeit für Kernfunktionen.
Die Pipeline ist konfigurierbar. Jeder Schritt kann aktiviert, deaktiviert, angepasst oder mit Bedingungen versehen werden. Pipelines können manuell gestartet, nach Upload getriggert oder nach Cron-Schedule ausgeführt werden.
Die Architektur ist SQLite-native. Vier Datenbanken: Primary, Queue (Solid Queue), Cache (Solid Cache), Cable (Solid Cable). Kein Postgres erforderlich. Deployment auf einem einzelnen Server möglich.
Der LetsDrop-Agent ist der Kern: Nach dem Upload einer Audiodatei übernimmt er die gesamte Nachproduktion. 8 sequenzielle Schritte, koordiniert durch den Claude Agent SDK, der 6 MCP-Tools in 8 Agent-Turns aufruft. Jeder Schritt ist messbar — in Zeit, Kosten und Tokens.
Das Transkript ist nicht das Ziel — es ist der Rohstoff. Sobald Whisper fertig ist, übernimmt Claude und generiert aus einer einzigen Audiodatei neun verschiedene Content-Formate: von HTML-Show-Notes über LinkedIn-Posts bis zum 1200-Wörter-SEO-Blogartikel.
Für kurze, präzise Outputs — Zitate, Social Posts, Titel — nutzt Tonecaster claude-haiku-4-5 (schnell, günstig). Für ausführliche Texte — SEO-Artikel, Newsletter-Blöcke — wird auf claude-sonnet-4-6 geschaltet. Das Modell-Routing ist im Pipeline-Builder konfigurierbar.
In dieser Folge analysieren wir den aktuellen Stand der KI-gestützten Podcast-Produktion: Was kann Whisper heute wirklich leisten? Warum kostet eine vollständige automatisierte Episode unter fünf Cent? Und was bedeutet das für den Job des Produzenten?
Die manuelle Nachbearbeitung einer Podcast-Episode kostet 2–4 Stunden. Transkription, Kapitel, Show Notes, Keywords, Social Posts — jeder Schritt ein eigener Workflow, jeder Schritt fehleranfällig.
Seit Whisper und Claude in Kombination verfügbar sind, hat sich das geändert. Nicht theoretisch. Gemessen: 42 Sekunden für eine vollständige Produktion einer 48-minütigen Episode — inklusive Transkript, 5 Kapitel mit Beschreibungen, HTML Show Notes, LinkedIn-Post, Twitter-Thread und einem 1100-Wörter-SEO-Artikel.
Die Kosten: $0.054. Das ist kein Schreibfehler. Fünfeinhalb Cent …
[ Artikel lesen → vollständig generiert, 1.100 Wörter ]
Der extract_identity-MCP-Tool ist mehr als ein Named-Entity-Recognizer.
Claude analysiert das vollständige Transkript und identifiziert fünf Tag-Typen (via STI),
erstellt zeitankerte EntityMentions mit Speaker-Zuordnung und berechnet
über den IdentityAggregator eine Relevanz-Gewichtung pro Episode,
pro Podcast und über die Zeit.
Tonecaster baut für jede Episode eine lokale Vektordatenbank auf.
Der EmbeddingService zerlegt das Transkript in Chunks,
berechnet via Ollama (oder LM Studio) einen float32-Vektor
pro Chunk und speichert ihn binary-packed in SQLite.
Das MCP-Tool semantic_search nimmt eine natürlichsprachige
Anfrage, berechnet ihren Vektor und findet via VectorStore.nearest()
die relevantesten TranscriptChunks — mit exakten Timestamps. Keine
Schlüsselwortsuche, keine manuellen Kapitelmarken nötig.
Das Modell: nomic-embed-text. Die Daten bleiben lokal. Kein externes API-Call, kein Datenschutzproblem, keine Latenz durch Netzwerk.
Der ComplianceChecker ist deterministisch: kein LLM, keine Heuristik, pure function. Er prüft Feed und Episode gegen fünf Standards und berechnet einen Score aus drei Gewichtungsstufen.
Die fünf Standards: RSS 2.0 (Pflichtfelder), iTunes (Apple Podcast-Namespace), Podcasting 2.0 (podcast:- und dcterms:-Namespaces), Podlove (psc:chapter), Spotify (spotify:- Requirements). Jede Prüfung ist als critical / recommended / optional klassifiziert.
Der apply_compliance_fixes-Modus schreibt fehlende Felder
automatisch — Episode-Titel vervollständigen, GUID generieren, Laufzeit
nachtragen, Encoding korrigieren. Keine manuellen Eingriffe.
Der Pipeline Builder ist ein visueller, 2-Panel-Editor: links die aktive Step-Liste, rechts die Konfiguration des ausgewählten Schritts. Jeder Step ist ein JSON-Objekt mit Tool-Referenz, Aktivierungsflag, Konfiguration, optionalen Bedingungen und Locked-Status (manche Steps können nicht deaktiviert werden).
Pipeline-Templates erlauben Clone und Anpassen. Drei Trigger-Modi:
file_upload (sofort nach Drop), manual
(auf Knopfdruck), scheduled (Cron). Der
Cost-Guard (max_cost_usd) bricht den Agent-Run
ab bevor das Budget überschritten wird. Der PipelineSchedulerJob
läuft jede Minute und evaluiert Cron-Expressions via fugit-Gem.
Der Cost-Guard verhindert unerwartete Kosten: sobald max_cost_usd
erreicht ist, bricht der AgentRunWriter den Run sauber ab und schreibt einen
RunReport mit Kostenstatus. Kein Agentenrun kann das Budget unbemerkt überschreiten.
Der DirectorySearchService sucht parallel in drei Verzeichnissen:
PodcastIndex, iTunes und Fyyd.
Gefundene Feeds durchlaufen eine Zustandsmaschine: discovered → fetching →
parsed → imported → failed.
Das Parsing ist robust gegen reale Feed-Qualität: gzip-Dekomprimierung,
UTF-8-Normalisierung, Feedjira als primärer Parser, Nokogiri als Fallback.
Podcasting-2.0-Namespaces (podcast:, dcterms:)
werden über einen Nokogiri-Overlay separat geparst — Feedjira ignoriert sie.
Der AudioDownloadService validiert Magic Bytes: MP3, OGG, FLAC,
M4A, WAV. Grenze: 500 MB. Encoding-Angriffe werden abgeblockt.
Jeder Pipeline-Lauf erzeugt einen AgentRun-Datensatz: Session-ID, Trigger-Art, Status, Anzahl Turns, Kosten in USD, Token-Verbrauch, aktuell aktives Tool, aktueller Stage. Der AgentRunWriter aktualisiert diesen Datensatz bei jeder Agent-Aktion — in Echtzeit über ActionCable.
Heartbeat alle 10 Sekunden. Ein Run gilt als „stale" wenn der letzte Heartbeat älter als 2 Minuten ist — dann wird automatisch ein Fehler-RunReport geschrieben. Das Live-Dashboard zeigt Tool-History, Token-Consumption, und Kosten pro Turn.
Jede Episode hat eine öffentliche URL: /player/:slug.
Der Web Player ist mehr als ein Audio-Element — er ist das
Ergebnis-Interface der gesamten Pipeline.
Ein persistenter Player-Bar bleibt über die gesamte Session aktiv. Pro Episode gibt es vier Tabs: Kapitel (Click-to-Seek), Topics (Identity Map, color-coded nach Tag-Typ), Transkript (live-synchronisiert mit der Wiedergabeposition), Show Notes (HTML-Output der Content-Generation).
Das Transkript ist mit der Playback-Position synchronisiert:
Ein player:timeupdate-Custom-Event triggert den
TranscriptController, der die aktive Zeile hervorhebt
und in den Viewport scrollt. Speaker werden durch Farb-Coding unterschieden.
Das Herzstück von Tonecaster ist die ClaudeStreamingBridge. Sie nimmt den Streaming-Output des Claude Agent SDK und verteilt ihn auf vier Writer-Implementierungen — je nach Kontext.
Zehn Event-Typen fließen durch die Bridge:
TextChunk, ToolUse, ToolResult,
Thinking, Usage, Result,
Error, Done, HeartBeat, CostUpdate.
Jeder Writer reagiert selektiv auf die für ihn relevanten Events.
Resumable Sessions: Die claude_session_id wird
in Rails.cache gespeichert. Bei einem Neustart einer Pipeline-Session kann der
Agent an der exakt letzten Position fortfahren — ohne Kontext-Verlust.
Tonecaster betreibt zwei MCP-Server: den Dropzone-Server (32 Tools für Audio, Transkription, Content, Compliance, Discovery) und den Command-Server (29 Tools für direkte Datenbankoperationen, Konfiguration und Administrative Tasks). Jedes Tool ist atomar, testbar, und hat einen definierten Input und Output-Typ.
| TOOL | PROVIDER | STATUS | FUNKTION |
|---|---|---|---|
| — AUDIO (4) | |||
| analyze_audio | FFprobe | live | Duration, Codec, Bitrate, Sample-Rate, ID3-Tags auslesen |
| normalize_audio | FFmpeg | live | EBU R128 Lautheits-Normalisierung, −16 LUFS, 192 kbps MP3 |
| transcribe_audio | Whisper | live | Timestamped TranscriptChunks, Speaker-Detection, Wortgrenzen |
| detect_chapters | FFmpeg | live | Silence-Detection >2s / −40 dB → Chapter-Candidates mit Beschreibungen |
| — IDENTITY (1) | |||
| extract_identity | Claude | live | 5 Tag-Typen (STI), EntityMentions, IdentityAggregator, TaggedTag-Hierarchien |
| — PUBLISHING (3) | |||
| list_podcasts | LetsCast API | live | Alle Podcasts des Accounts mit Metadaten |
| get_podcast | LetsCast API | live | Detail-Daten, Feed-URL, Subscriber-Stats |
| push_episode | LetsCast API | live | Episode + Audio-Datei hochladen, Metadaten setzen, veröffentlichen |
| — DISCOVERY (5) | |||
| search_podcasts | PodcastIndex / iTunes / Fyyd | live | Parallele Suche in drei Verzeichnissen, dedupliziert |
| import_rss_feed | FeedSource Service | live | RSS → Podcast + Episoden, Feedjira + Nokogiri, P2.0 Overlay |
| discover_letscast_podcasts | LetsCast / OP3 | live | LetsCast-Feeds via OP3-Analytics entdecken |
| list_feed_sources | DB | live | Alle bekannten FeedSources mit Zustand und letztem Sync |
| get_feed_details | HTTP | live | Feed-Vorschau ohne Import — Episoden-Liste, Feed-Metadaten |
| — COMPLIANCE (3) | |||
| check_feed_compliance | ComplianceChecker | live | RSS / iTunes / P2.0 / Podlove / Spotify — Feed-Level Score |
| check_episode_compliance | ComplianceChecker | live | Episode-Level Score, Feld-für-Feld-Prüfung, Label: Excellent/Good/Fair/Poor |
| apply_compliance_fixes | DB | live | Auto-Fix: GUID generieren, Laufzeit nachtragen, Encoding korrigieren |
| — CONTENT GENERATION (4) | |||
| generate_show_notes | claude-haiku-4-5 | live | HTML Show Notes mit Kapitel-Links, ~500 Wörter |
| generate_social_posts | claude-haiku-4-5 | live | LinkedIn, Twitter, Newsletter-Block — alle drei in einem Run |
| generate_blog_article | claude-sonnet-4-6 | live | SEO-Artikel, 800–1200 Wörter, Keywords aus Identity Map |
| extract_quotes | claude-haiku-4-5 | live | Top 3–5 quotable Momente mit exakten Timestamps |
| — SEMANTIC (3) | |||
| semantic_search | Ollama / VectorStore | live | Natürlichsprachige Anfrage → TranscriptChunks mit Timestamps |
| embed_transcript | EmbeddingService | live | Alle Chunks einer Episode → float32-Vektoren in SQLite |
| embed_all_transcripts | EmbeddingService | beta | Bulk-Embedding aller Episoden — für Nacht-Jobs |
| — REPORTING (1) | |||
| write_run_report | DB | live | RunReport: headline, outcome, protocol_log, assets, cost_usd_total, human_rating |
| — COMMAND SERVER (29 weitere Tools: DB-Ops, Config, Admin, Diagnose) | |||
Podcasting 2.0 ist kein Konkurrent zu RSS — es ist eine Erweiterung. Neue XML-Namespaces fügen Funktionen hinzu, die Spotify und Apple als proprietäre Features eingebaut haben, aber als offene Standards fehlen. Tonecaster unterstützt alle relevanten Namespaces — und prüft sie im Compliance Audit.
| NAMESPACE | PREFIX | GEPARST | FUNKTION |
|---|---|---|---|
| RSS 2.0 | – | ✓ | Basis: title, description, enclosure, guid, pubDate — Pflichtfelder |
| iTunes | itunes: | ✓ | explicit, author, category, image, episode, season, episodeType |
| Podcasting 2.0 | podcast: | ✓ | chapters, soundbite, transcript, person, location, funding, value |
| Dublin Core | dcterms: | ✓ | language, creator, rights, date — via Nokogiri-Overlay |
| Podlove | psc: | ✓ | psc:chapter — Kapitelmarken im Podlove Simple Chapters Format |
| Media RSS | media: | ✓ | media:content, media:thumbnail — Alternative zu enclosure |
| Spotify | spotify: | → beta | spotify:countryOfOrigin, Spotify-spezifische Feed-Anforderungen |
Feedjira parsiert RSS 2.0 und iTunes nativ. Alle anderen Namespaces werden über einen Nokogiri-Overlay nachgeparsiert — weil Feedjira unbekannte Namespaces stillschweigend ignoriert. Das ist kein Fehler in Feedjira — es ist der richtige Trennschnitt für zwei Verantwortungsbereiche.
Der Cost-Guard in jeder Pipeline definiert ein
max_cost_usd-Limit. Sobald der AgentRunWriter dieses Limit
erkennt, bricht er den Run sauber ab und schreibt einen RunReport mit
Kostenstatus. Kein Agentenrun kann das Budget unbemerkt überschreiten.
Tonecaster ist in Phase 1: ein Werkzeug, das Reibung eliminiert. Die Roadmap ist eine Progression in drei Phasen — jede Phase setzt mehr Verständnis über den Creator und sein Publikum voraus.