FrankenSuite research program · A shareable brief

FrankenTTS Voice Cloning With the Losses Filed

A shareable brief from the FrankenSuite research program. Every claim below traces to the assessed repository; sources are linked at the end. Assessment pinned September 19, 2026.

Assessment pinned September 19, 2026 (the assessed commit)·~1,118 words·5 sections·Every claim traceable to a source
Six definitions. NODUS is the program’s four-ring verdict scale (Invest, Pilot, Explore, Monitor) assigned per assessment packet. TRL is technology readiness level, scored 1 to 9 per packet. CI is continuous integration: the project’s automated test runs. The pin is the exact commit the assessment froze on; every claim is evaluated at the pin, not at HEAD. The rider is the license clause withholding all rights, including benchmarking and analysis, from OpenAI, Anthropic, their affiliates, and anyone acting for them. Bus factor is how many people can leave before the project stalls; it is 1 for every repo here.

01 · What it is

What text-to-speech is, and why it matters

Text-to-speech turns written text into spoken audio; voice cloning goes one step further and builds a synthetic voice from a short reference clip. A few seconds of someone speaking becomes a voice that can read anything. In January 2026, Alibaba's Qwen team released Qwen3-TTS, open-source under Apache 2.0, with 3-second voice cloning and, per its technical report, 97 milliseconds of first-packet latency. It matters because voice is becoming an agent interface: assistants that speak, accessibility tools, anything where audio must not leave the device.

The incumbent path is the upstream PyTorch package on a GPU, or the cloud APIs that sell voice cloning as a service. Both assume either a graphics card or a network connection. The gap this project occupies is the constrained corner: no Python, no machine-learning framework, no GPU at inference, no network. Private, on-device speech on an ordinary CPU.

02 · Why build it

Why rewrite it in Rust?

The maintainer's stated case is decoupling the model from its reference stack. The official path needs PyTorch and CUDA; a pure-Rust CPU runtime removes both, and fixing on a single model revision, Qwen3-TTS-12Hz-0.6B-Base, makes byte-level parity claims tractable. Rust gives memory safety on the hot path without a garbage collector. And the scope discipline is explicit: one fixed model, model-specific kernels, no pretense of being a general speech framework. The truth pack pins the oracle: the exact weights revision and the exact upstream source revision. Every parity claim can then be checked against the real model rather than asserted.

The counter-argument is model churn. Everything is Qwen3-TTS-12Hz-0.6B-Base-specific: the kernels, the parity receipts, the voice presets. A successor model means a new port; only the methodology transfers. And 96,057 lines of nightly-pinned Rust, maintained by one person who refuses outside contributions by policy, is a maintenance cliff, not a moat.

03 · What was built

What the project actually built

This is a "works today" artifact: ten crates, 96,057 lines of first-party Rust, and a distribution surface that looks like a product: 11 releases in 24 days with prebuilt binaries for macOS, Linux, and Windows plus SHA256 checksums, a Homebrew tap, install one-liners, 18 built-in voices, voice enrollment with a neural denoiser, a streaming conversation layer with a proven cancellation contract, a native iOS app, and a live WASM playground at frankentts.com. The signature artifact is the voice card: the voice's 1,024-float speaker embedding rendered as an error-corrected mosaic image. A picture you can speak from, designed to survive screenshots and messaging-app recompression.

The finding that matters is the evidence machinery. A truth pack pins the oracle revisions with a fetch-and-verify script. A discrepancies ledger carries six entries with claim IDs, measured impacts, kill switches, and review dates. source A negative-evidence ledger records killed hypotheses with the exact conditions under which they could be revived. A performance ledger admits a number only if it passes a coefficient-of-variation gate of 5 percent. The headline real-time figure fails it, so the README says so: "no certified RTF row exists yet.

Evidence · CI status

What the project’s own CI said at the pin

the pin = the commit the assessment was pinned to.

  • The same pattern repeated with the v0.1.10 headline, an int4 microdecoder pipeline: the arithmetic landed, but the ledger records routing as OFF after two failed speed gates (0.04×, then 0.52× the shipping int8 route).
  • The docs describe a CI (continuous integration: automated checks that run on every change) workflow whose configuration is not in the tree, so the "green main" behind the releases runs on owner infrastructure no outsider can audit.

The uncomfortable findings

Uncomfortable finding

The flagship optimization, FrankenMTP speculative block drafting, is dead. It was killed twice, with receipts. The sampled drafter managed roughly 0.01 acceptance per depth ("strictly worse" than sequential); the greedy drafter scored p_token = 0.0000 across 480 proposals. Both dispositions read REVERT. Yet the README's lead "solution" paragraph still presents speculative drafting as the architecture's payoff. An open obligation, not a shipped lever. The real-time story is provisional where it counts: 1.4–1.6× real time on one unloaded machine, uncertified by the project's own ledger; 0.66–1.05× under load; the browser build at 0.31–0.43× by the site's own measurement. The default int8 route carries an open listening gap — the ledger records a measured side effect, one enrolled voice's whole-utterance RMS shifting 0.019 to 0.221 ("audible LF drone risk"), and no blind listening test closes it. Zero independent validation of any kind was found. And the license is MIT plus a rider withholding all rights, including benchmarking and analysis, from OpenAI and Anthropic, the two labs building agent-voice infrastructure. The governance refuses a second maintainer by design: no outside contributions accepted, permanently.

04 · Where it stands

Where it stands

In our program's terms: TRL 7, NODUS ring Explore. In plain English: this is an operational prototype. It installs, it runs, it ships binaries. But it is Explore, not Pilot, for a precise reason: the only route fast enough for a real workload is the int8 default, whose quality is not listening-certified, while the certified-quality f32 reference runs six to seven times slower than real time and cannot serve one. There is no pilotable configuration.

Technology readiness

TRL 7 on a 1-to-9 scale.

NODUS ring

MonitorExplorePilotInvest

The program’s adoption ring for this project.

Verdict key

NODUS ring
Explore: The default for substantive-but-unproven work.
TRL
Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 7.
CI
Continuous integration: the project’s automated checks, run on every change.
The pin
The exact commit the assessment was pinned to. “At the pin” means as of that commit.

Evidence tiers

  1. Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
  2. Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
  3. Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
  4. Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
  5. Tier 5 · Inference — The analyst’s judgment. Always labeled; never presented as fact.

What this verdict rests on. Tier labels are the assessment packet’s own annotations.

  • Tier 1 · Verified: 10 crates and 96,057 lines confirmed from a fresh clone; 11 releases with prebuilt binaries for five platforms plus SHA256SUMS, verified via the releases API; no CI configuration in the tree.
  • Tier 3 · Maintainer claim: Nothing was compiled, synthesized, or benchmarked; the parity receipts rest on maintainer evidence.
  • Tier 4 · External: Zero independent validation of any kind.
  • Tier 5 · Inference: The Explore ring at TRL 7.

Should you use it?

Only as an experiment: a private, CPU-only voice on a machine you control, with the understanding that real-time is load-dependent and the default route's quality is uncertified. Not for anything production.

Should you learn from it?

Yes, and the lesson is the methodology, not the model.

The truth-pack recipe (pin the oracle, capture the seams, publish the receipts) plus ledgers with kill switches and revival conditions is a highly transferable model-runtime artifact: a recipe for how to claim parity with a PyTorch model and mean it.

What would change the verdict, in order

  1. a published blind listening test on the int8 default route
  2. a certified real-time row in the performance ledger
  3. a learned drafter clearing the ledger's own break-even bar
  4. any independent benchmark or listening test
  5. a license revision.

The license is the ceiling: the two labs most likely to validate and adopt it are legally barred from measuring it. source

05 · What it teaches

What this teaches about building with agents

Publish your optimization's death certificate.

The flagship idea here failed by the project's own pre-registered bar. The failure lives in the repo, with the probe commands, the measured numbers, and the do-not-retry predicate. That is the discipline: when an experiment dies, file the autopsy next to the code. Agents (and humans) will keep optimizing against goals that died quietly; a ledger with revival conditions and kill switches is the mechanism that stops zombie work from eating the roadmap.

The deeper cut is where this project slipped: the ledger recorded the kill, but the README's lead paragraph still sells the dead optimization. source A kill filed in the docs but not in the pitch is a kill half-filed. The lesson for agent-built systems: the self-audit machinery must fire on the marketing copy too. Gate the claims at the top of the funnel with the same machinery that gates the code — or the agents will keep shipping the story long after the evidence revoked it.

Evidence

This page cites selected evidence. The full claim-by-claim audit is in the assessment packet.

Open a panel to see what each source evidences. Full claim-by-claim audit.

Full claim-by-claim audit with evidence tiers lives in the program's assessment packet.

The repositorygithub.com/Dicklesworthstone/franken_tts
README

its README

LICENSE

LICENSE

CHANGELOG

CHANGELOG, docs/NEGATIVE_EVIDENCE.md, docs/DISCREPANCIES.md, and docs/PERF_LEDGER.md at the assessed commit

the release history via the GitHub ...

the release history via the GitHub releases API

frankentts.com (fetched 2026-09-22)

frankentts.com (fetched 2026-09-22)

arxiv.org/pdf/2601.15621v1.pdfarxiv.org/pdf/2601.15621v1.pdf

the Qwen3-TTS technical report (arxiv.org/pdf/2601.15621v1.pdf).