Build a free Audible replacement in an afternoon with Claude Code

Here is the deal Audible offers. You pay per title, or you burn a monthly credit, and what you get is a license the store can revoke, playable only in the app that sold it to you. You are renting, and the landlord keeps the keys.

Meanwhile a large slice of what I want to listen to has been free and legal for decades. Not through a loophole. Through the public domain. You can take any of it and render a proper chaptered audiobook, cover art and all, that streams to your phone and remembers where you stopped. It took me an afternoon, and Claude Code wrote most of the pipeline. I call it Rhapsode, after the singers who recited epic poetry aloud to people who could not read it. A fitting name for a machine that reads books out loud.

Three steps. Find the books, from Standard Ebooks. Render them, with Kokoro, which runs faster than realtime even on a laptop. Serve them, with Audiobookshelf, on your own network. Before any of that, one boundary, because this is not the post it might sound like.

What "free" means, and what it does not

As of 2026, everything published in the US in 1930 or earlier is public domain.¹1The 1998 Copyright Term Extension Act set a 95-year term for pre-1978 works, expiring on 1 January after the 95th year. 1930 opened this year; 1931 opens 2027. Source: Duke Center for the Study of the Public Domain, Public Domain Day 2026. That is most of the canon you would reach for. Austen, Dostoevsky, Conan Doyle, Stevenson, Wells, the Brontës, Marcus Aurelius. All of it, free to read, convert, and keep.

Here is the honest part that most "free audiobook" posts skip. For a modern book still in copyright, the free and legal answer is usually not a render at all. It is Libby, with your library card, or LibriVox, where volunteers have already narrated a huge share of the public-domain canon by hand. Render your own when you want one consistent voice across a whole shelf, or when no human recording exists. Do not spend a GPU on a title a librarian will lend you for nothing.

Step 1: find the books

Three sources, in order of how clean their text is.

Standard Ebooks is the best input for text-to-speech, and it is not close. Every title is hand-typeset from a Project Gutenberg source, with the OCR errors corrected, semantic markup applied, and clean chapter boundaries.²2Standard Ebooks also uses a consistent house structure across the catalog: title page, imprint, the body, then endnotes, colophon, and an uncopyright page. Same boilerplate in every book, which means one strip rule covers all ~900 titles. Chapter structure is what a muxer needs to produce real chapters, so that clean markup matters more than raw catalog size. About 900 titles. Project Gutenberg gives you reach, roughly 78,000 books, at the cost of inconsistent formatting and OCR artifacts. LibriVox skips the pipeline entirely with free human narration.

The first thing Claude Code got wrong here was small and instructive. It tried to build the download URL from the book's slug. That fails, because some titles carry an illustrator or translator segment the slug omits, and because Standard Ebooks serves a "your download has started" interstitial unless you append ?source=download. The fix is to scrape the real link off the page.

The failure mode underneath it is the one to remember. A first render pass produced an 8.9 KB file named book.epub that was not a book. It was the HTML interstitial. curl had exited 0 the whole way, because a 200 response with the wrong body is still a 200. The file command caught it in one line:

$ file book.epub
book.epub: HTML document text

The exit code said success. The bytes on disk said otherwise. Hold onto that, because it is the whole post in miniature.

Step 2: render the audiobook

The model is Kokoro-82M. Apache 2.0, 82 million parameters, about 330 MB of weights. It hit number one on the Hugging Face TTS arena at launch, beating models 10 to 100 times its size, and it was trained for roughly $1,000 of compute.³3Kokoro-82M on Hugging Face, released as v0.19. The arena result is the launch-week community ranking, not a controlled study, but the model's size-to-quality ratio is the reason it became the default open TTS choice.

The number that reframes the whole project: Kokoro is not compute-bound. It runs faster than realtime on a plain CPU. One public benchmark converts Animal Farm, about 160,000 characters, in roughly 5 minutes on a cheap cloud T4 and about an hour on an M2 MacBook's CPU alone. On my DGX Spark it measured 27.4 times realtime, which puts a 10-hour book at about 22 minutes of GPU. You do not need my hardware.

The driver is epub2tts-kokoro, a small tool that handles the parts you do not want to write: EPUB chapter parsing, cover-art embedding, and muxing to a chaptered M4B that plays natively in Apple Books. Strip the publisher boilerplate first, then render.

Picking that tool was the heaviest part of the build, and it is its own story. Three wrong turns, each a way an AI coding agent will mislead you if you trust the wrong signal. side quest They share one lesson, plain enough to state on its own.

A CPU-only PyTorch wheel installs without a single error and runs 10 to 20 times slower, silently. Nothing warns you. pip exits 0, the import succeeds, the audio comes out correct and slow. So do not trust the install. Trust a real matmul on the GPU that returns a finite result.

Step 3: run the server

A folder of M4B files is not an Audible replacement. Audiobookshelf is. It is a self-hosted audiobook server, and it turns that folder into a library you stream.

Run it in Docker, and point its library at your renders folder mounted read-only.⁴4Read-only is the safety boundary. Audiobookshelf keeps its own state, users, progress, matched metadata, in separate volumes, so a bug in the server can never modify or delete the audio you spent GPU time producing. The library is a source it reads, never a scratch space it writes. Reach it from your phone over a private network, Tailscale or a plain LAN. New renders show up on their own, no import step.

flowchart LR
  A["Standard Ebooks<br/>EPUB"] --> B["strip boilerplate"]
  B --> C["Kokoro-82M<br/>via epub2tts-kokoro"]
  C --> D["chaptered M4B<br/>+ cover art"]
  D --> E[("Audiobookshelf<br/>read-only library")]
  E --> F["phone app<br/>stream / offline"]

The phone app is where it becomes a real replacement. Stream, or download for offline. Chapters, resume position, playback speed, sleep timer. Everything the Audible app does, over a library that is yours, on files you own outright. Whenever Rhapsode drops a new book in the folder, the app shows it the next time you open it.

What I could not verify

Two honest gaps, because a build log that only reports wins is marketing.

Long-form stability is unproven at length. I rendered books up to 5 hours 41 minutes and the audio held, no drift, no dropped chapters. Nobody in this build established what Kokoro does across a 10 to 20 hour render. "I could not measure it" is a finding. It is not the same as "it works," and I will not dress one up as the other.

Kokoro also has no prosody control. The entire tuning surface is the voice, the speed, and the pause length. No emphasis, no emotion, no per-line direction. Choosing the voice is choosing the inflection, and nothing else. For steady narration that is fine. If you want a performance, it is the wrong tool and you should know that going in.

One more, aimed at the research you will do next. The open-TTS comparison web is thick with AI-generated SEO farms that launder a vendor's own marketing numbers into "independent" benchmarks. The single most-repeated "beats ElevenLabs" figure in the space traces straight back to the vendor that ships the model. Distrust the too-clean stat, and trace every number to a primary source before you believe it.

What transfers

The pipeline is nice. The habit is what lasts.

Building this with an AI coding agent was fast, faster than I would have been alone, and every one of its mistakes was specific and catchable. A popular tool that could not do the job. A stray import that dragged a broken dependency. A container that failed at the one thing it existed to guarantee. A download that finished successfully and produced the wrong file. None of them threw an error. All of them were caught by looking at the actual artifact instead of the exit status.

That is the review discipline an exoskeleton needs. The agent moves fast and is confidently wrong in narrow, findable ways, and your job is not to write the code. It is to check the thing the code produced, every time, against what you actually wanted. Do that, and an afternoon buys you a library.

Related reading on this site: DGX Spark, week one: finding the right stackshippedAI Systems & Architecture·Oct 28, 2025DGX Spark: Week One Update - Finding the Right StackSystematic debugging reveals configuration fixes that transformed DGX Spark performance from frustrating to transformative with 3.6x speedups. for the same right-hardware-wrong-image trap on a bigger build, Claude Code best practicesshippedAI Development & Agents·Apr 20, 2025Claude Code Best Practices: Setup, Commands, and the Defaults Worth ChangingThe Claude Code setup, skills, subagents, and hooks I run in production, plus the defaults worth changing first. Updated for the 2026 feature set. for the artifact-first review habit generalized past this one project, and Building an AI research night shiftshippedPractical Applications·Nov 6, 2025My AI Research Assistant Works the Night Shift (A Claude Code Skill Story)How I built a Claude Code skill that researches AI developments overnight using intelligent automation that adapts, prevents duplicates, and provides instant answers. for another service you run yourself instead of renting.