DEV Community: Kenji Sakuramoto

How long is my audiobook? Three numbers, and only one measured the audio

Kenji Sakuramoto — Sun, 25 Oct 2026 12:00:00 +0000

the wanting mind is a free book I wrote about why people want. It runs to 36 chapters and about 147,000 words, across neuroscience, economics, philosophy and anthropology. The question started when I lived in meritocratic Singapore and then came back to Japan, a country that runs on community and, in places, on a very clear hierarchy.

Every chapter has English narration in AI voices. The app and its store listing said that narration was about 12 hours long. When I checked in October, the files disagreed, and so did the word-timing data the reader uses.

12 hours: the copy

The in-app purchase screen said "Full 12-hour narrated audiobook with word-sync". Both App Store descriptions said "about 12 hours" (約12時間 in Japanese).

20.5 hours: the files

There are 36 MP3 files, one per chapter, 1,181,948,756 bytes in total. The first file's frame header says 128 kbps. If every file uses the same bitrate:

1,181,948,756 bytes × 8 ÷ 128,000 bit/s ≈ 73,872 s ≈ 20.5 h

That assumes a constant bitrate, so I checked it with ffprobe on every live file. It gave 20.52 hours. This is the number that measures the audio.

16.6 hours: the word timings

Each chapter has an alignment file with a start and end time for every word. The reader uses it to highlight the word being spoken. If the timings covered the whole file, the last word would end near the end of each file. Summed over all 36, the last end times came to 16.56 hours.

So I compared them chapter by chapter on 16 October. In 31 of the 36 chapters, the alignment file ended more than a minute before the audio did. The worst was the preface: its last aligned word ended at 2.9 minutes, in a 9.7-minute file. The other five ended within a minute of their audio.

The highlight is built from these files, so in those 31 chapters it had nothing to follow after the last aligned word. The fix was to regenerate them, and the check was the same sum: it had to come out within a few minutes of 20.5 hours. I re-timed them on 16 October, and on 17 October the sum came to 20.51 hours, with every chapter ending within a minute of its audio. In one chapter and the appendices, though, the audio still held more words than the word list (about 45% and 17% more), and the sum can't see that.

And 11.1 hours, which is something else

The chapters also carry a reading-time estimate. Summed, it is 666 minutes, about 11 hours. That is how long the text takes to read, not to hear.

What it says now

The purchase screen in the current code says "Full 20-hour narrated audiobook", and my posts say "about 20 hours". On 16 October both App Store descriptions still said 12. On 17 October, version 3.13.0 changed both to about 20 hours (約20時間).

The book, and the other ways into it (the concept map, the simulations, the references you can open from the line that cites them), is here: the wanting mind.

I wrote this post with help from an AI assistant. The figures come from the project's repository and the live audio files.

From "this is broken" to a draft PR: building Mushi Mushi

Kenji Sakuramoto — Thu, 15 Oct 2026 04:18:01 +0000

Correction, 2026-10-29. This post first promised "60 seconds" from report to draft PR. We never measured that, so the number is gone. What we do measure is on the proof page: where the owner's bugs came from (almost all from the owner's own checks, very few from users), fixes merged, and the median time from bug found to fix merged. The pipeline details below are corrected to match the code, and an unsourced judge-accuracy figure was removed. Since this post, Mushi Mushi added an AI review of agent PRs, which runs on the app's own AI key, and is building verified merge (roadmap): an agent PR merging without a click, only when you switch it on (off by default) and the PR passes a fail-then-pass test and two AI reviews.

Correction, 2026-11-03. Checked against the code again. The default models, the fix steps and the review step below now match it, and the merge gate has moved since this was written: see the update at the end of "Why we kept the human in the loop".

Sentry sees what your code throws. Mushi Mushi sees what your users feel.

This is the post I would have wanted to read a year ago, when I was staring at a Sentry dashboard that was perfectly green while three people in a row told me the login button on iPad Safari "did nothing." No exception. No 5xx. No console error. Just a user, frustrated.

That gap — between errors that throw and bugs that users feel — is what Mushi Mushi (虫虫) tries to close.

This post walks through the loop end-to-end, what each stage actually does, and why we kept a human in the loop for the parts that should not be automated.

The loop

A user opens our SDK widget on the site they're frustrated with. They type one sentence: "login button does nothing on my iPad." They hit send.

What happens next, in order:

Capture. The report lands in Mushi Mushi's reports table with the user's text, the page URL, the viewport, the browser, and the last console and network events. If the app captures screenshots, one comes along, and the reporter sees it and can remove it before sending. If the app turned session replay on, up to the last 30 seconds of it come too.
Filter. Claude Haiku 4.5 makes a cheap first pass and drops spam and noise. GPT-6 Luna is its fallback.
Group. Right after that first pass, the report is embedded and compared with earlier ones by cosine similarity in pgvector. Above 0.82 (the default; each project can change it in Settings), it joins the existing group instead of becoming a new row. Once the group has a diagnosis, a new report in it reuses that diagnosis, so it costs no new model call and does not count toward the monthly diagnosis allowance. The report list shows each group's blast radius: how many reports, distinct reporters and sessions it has. Until October 2026 the per-project threshold was saved but never read, so every project got 0.82.
Diagnose. Reports that pass go to a second model: Claude Sonnet 5.5 by default, with GPT-6.1 Sol as the fallback when there is no usable Claude key, or Claude refuses or returns unusable output. It writes a category, a severity, the likely component, a plain-English summary and a confidence score. If the repo is indexed, it reads code retrieved from it while it does this, so it is more likely to name a file it actually saw than to guess one. An organization can also switch its AI to OpenAI only. Mine has run that way since 31 October 2026, when my Claude credits ran low, so my own reports are diagnosed by GPT-6.1 Sol.
Fix. Auto-fix is off for each app until someone turns it on. Then Dispatch fix on the report starts the fix worker. It reads whole files from the repo at the commit the PR will branch from, and asks the model (Sonnet 5.5 by default, GPT-6.1 Sol as the fallback) for find-and-replace edits through a typed schema. The model gets no tools and no shell. If the edits don't apply, the worker retries once with the exact error, then stops. If any one file's diff would pass 200 changed lines (a per-project setting), the run aborts. Otherwise it opens a draft PR. The model calls are traced in Langfuse. Instead of the built-in worker, the fix can also go to a cloud coding agent (Cursor's, or GitHub's), which opens the PR itself.
Review. If the app has an AI key of its own, a second model reviews the PR: Claude Opus 5.5 on a Claude key, otherwise GPT-6.1 Sol on an OpenAI key. It never runs on Mushi Mushi's platform key; without the app's own key the review is skipped. The verdict is merge, fix first or hold. On merge or fix first the draft is marked ready, so a repo that skips CI on drafts runs its checks then. A hold stays a draft.
Merge. A person merges from the console, or adds the PR to the merge queue, which updates the branch and waits for CI. By default the queue batches an app's approved PRs into a release train and merges them together; an app can switch to one PR at a time. On merge, the report is marked fixed, a linked Sentry issue is resolved when the report came from Sentry, and the person who reported the bug gets a "fixed" notice when their report can receive one.

Separately, an LLM-as-Judge job re-reads classified reports in batches. It scores category accuracy, severity calibration, component tagging and repro quality from 0 to 1, and records whether it agrees overall. The scores are stored on the report and decide which candidate classifier prompt gets promoted. They never change a report's status.

Why we kept the human in the loop

The full PDCA loop could be fully autonomous. The agent has the context, the judge has the receipts, and a draft PR is technically reversible.

We chose not to do that, for two reasons.

1. The judge is good. The judge is not infallible.

Our LLM-as-Judge mostly agrees with the classifier. Mostly is not "auto-merge" good. The disagreements include the exact cases that an autonomous loop would silently ship wrong fixes for: ambiguous severity, mis-routed component paths, and duplicate-fix attempts that mask the real bug.

Keeping the operator as the merge gate let the rest of the loop get faster without removing the safety net.

2. The user's trust is the moat.

A user who reports a bug and watches the team respond — even with a one-line "we shipped this" — develops a kind of operational trust that tells them "this app is alive." That trust survives outages and slow weeks. It does not survive an automated reply that ships the wrong fix and silently breaks something else.

So the human stays in the loop. The loop just gets shorter.

Update (2026-11-03). The gate moved. On 30 October my eight apps had 607 open agent fix PRs for 584 reports. About 250 had a "merge" verdict from the review, and none of them was in the queue, because the queue waited for a person to add each one. That person was me, and I didn't. So each app now has a Decide for me switch, off by default. When it is on, Mushi Mushi queues the PRs the review approved and closes the ones it will not merge. The release train still requires the "merge" verdict on the exact commit and green CI before anything merges. A hold can only be overridden by a person in the console, with a reason that goes in the audit log. Verified merge, where an agent PR merges only with a test that fails without the fix and passes with it, is still in progress (roadmap).

What's actually open source

Every SDK is MIT: web, React, Vue, Svelte, Angular, React Native, Capacitor and Node on npm, plus the CLI and the MCP server. iOS, Android and Flutter SDKs are previews in the repo. It is all on github.com/kensaurus/mushi-mushi. The backend (Supabase Edge Functions + Postgres + pgvector for the embeddings) and the admin console are AGPLv3, which is OSI open source: self-host it free, fork it, modify it for your own org. Offer a modified server as a hosted service and you publish your changes (§13) or take a commercial license.

It's open-core: the core is open source (AGPLv3). What costs money is the hosted service beyond its free plan, and a small source-available enterprise edition (SSO, audit export, retention policies, region pinning) that a solo builder never needs. The hosted Free plan covers one app and 100 diagnoses a month; Builder is $29 a month and Studio $79 (pricing).

Try it

If you'd rather see than read:

Sample diagnosis (no signup): kensaur.us/mushi-mushi/docs/demo/diagnosis
One-command install (any web framework):

  npx mushi-mushi

Source + self-host docs: github.com/kensaurus/mushi-mushi

If Mushi Mushi's voice (slightly Japanese, slightly bug-themed, very opinionated about the difference between an error and a bug) clicks for you, the easiest way to support the project is to star the repo. The next dev who needs this finds it that way.

A 147,000-word interactive book as a free SPA, and the stack behind it

Kenji Sakuramoto — Thu, 23 Apr 2026 07:48:48 +0000

the wanting mind is a free 147,000-word interactive book: no ads, no account, in English, Japanese, Chinese and Thai. It is a React 19 SPA with Supabase behind it and Capacitor for the mobile apps. ElevenLabs reads the chapters, fal.ai made the chapter art, Veo made the hero videos, and Claude translated the chapters. This post covers what worked, what I'd do again, and the stack.

What it is

A long-form book about why we're never satisfied: the economics, neuroscience and Buddhist philosophy of taṇhā ("thirst"). At 147,000 words, reading it cover to cover takes about eleven hours. Most people won't do that, so the app gives them other ways in:

Narrated chapters. ElevenLabs voices, with 12 narrator personas.
A 3D knowledge graph of the concepts, people and chapters, built with react-three-fiber.
22 simulations you can play with: the Easterlin paradox, Minsky moments, r > g.
Four languages, switchable while you read.
An "essence" view: each chapter compressed to one quote over its chapter image, shareable as a card.

Read it: kensaur.us/the-wanting-mind

The stack

Layer	Choice	Why
Framework	React 19 + Vite 8	Fast dev loop; a prerender step after the build for SEO
Language	TypeScript 6	The book's content lives in typed data files, so a typo in a chapter reference fails the build
Styling	Tailwind CSS 4	Design tokens in one file, dark mode with `dark:`
3D	reagraph on react-three-fiber	The knowledge graph and the closing constellation scene
Mobile	Capacitor 8	The same React build for iOS and Android
Auth + DB	Supabase	Accounts and cloud sync, with row-level security
Audio	ElevenLabs	English narration of all 36 chapters, about 20 hours
Images	fal.ai (nano-banana-2)	Chapter essence images, batch-generated
Video	Veo 3.1	35 looping hero videos and a cover video
Translation	Claude	Chapter by chapter, into Japanese, Chinese and Thai
Hosting	S3 + CloudFront	Static files; no server to keep running
Errors	Sentry	Errors on readers' devices reach me without anyone having to report them
Push	Firebase Cloud Messaging	Notifications to signed-in readers' devices

Three things that mattered more than I expected

1. Prerendering chapter HTML

An SPA serves one HTML shell for every route. Google can render JavaScript, but other crawlers and link previews often read only that shell. So scripts/prerender-chapter-html.mjs runs after vite build. It copies dist/index.html once for every chapter and feature page in all four locales, and gives each copy its own <title>, description, canonical URL and OpenGraph tags. The deploy uploads each file to the matching S3 key, so a crawler or link preview asking for /ja/ch-4 gets that chapter's title and description in the first response. The chapter text itself still renders in the browser.

2. Quote cards drawn in the browser

Every chapter has an "essence", one sentence that sums it up. generateQuoteCardBlob in src/components/QuoteCard.tsx draws it as a 1080×1080 card on a Canvas: the chapter image as the backdrop, a translucent overlay, the quote, and the book's name. It runs in the browser with no server. Readers can save the card or share it with navigator.share() on mobile.

For social posts I call the same function from a Playwright script (scripts/generate-quote-cards.mjs), so the cards I post are the cards readers get.

3. Store listings from one file

The store listings exist in four locales on both stores, and editing them by hand is slow and easy to get wrong. Two scripts do it now:

scripts/asc-update-listing.mjs signs a JWT with the App Store Connect API key, reads the listing copy from docs/store-listings.md, and pushes name, subtitle, promotional text, description and keywords for each locale.
scripts/play-update-listing.mjs does the same through the Google Play Publisher API with a service account.

docs/store-listings.md is the one place the listing copy is edited.

If you build something similar

Pick one mobile shell (Capacitor or Tauri) and stay with it.
Prerender before you write growth posts. The posts link to pages, and the pages should show their content to whatever opens them.
Add error reporting on the first day, even for a personal project.
Generate marketing images from the app's own code, so they match what readers see.
Keep the content (chapters, essences, graph nodes) as plain TypeScript files in git. For a single author, that is enough of a CMS.

What's next

The source isn't public yet. If a translation reads wrong, the feedback button in the app reaches me directly.

I wrote this post with help from an AI assistant. The figures come from the project's repository.