Kokoro, F5, ElevenLabs: the TTS strategy that keeps me from burning credits

I burned through six hundred euros of ElevenLabs credits in four days, early 2026. Not from neglect — from ignorance. I had just launched my second channel, was working on episode hooks, and every script rewrite triggered a fresh full-episode audio render to check the prosody. Twenty iterations on episode 01. Fifteen on episode 02. Eleven on episode 03. At roughly three thousand characters per episode and the Liam voice priced per character, the bill arrived in time to remind me that ElevenLabs quality came at a price proportional to my poor working habits.

When I opened the billing dashboard that morning, I decided to stop improvising. A serious TTS strategy, sized for a production chain that iterates. Three engines, one per phase of a script's lifecycle.

The result, six months later, across eight active channels: zero ElevenLabs budget overrun, an intact publishable quality, and about twelve euros monthly in total voice synthesis instead of several hundred.

Here's the grid.

The fundamental misunderstanding about TTS engines

Public conversation around voice synthesis engines is almost always framed as a quality question. "ElevenLabs is better than XTTS", "Kokoro is free but more rigid", "F5 has better prosody on long takes". All those statements are defensible, and all miss the operational point.

For someone producing a continuous video channel, the relevant question isn't "which engine is best". It's: "which engine should I use at this precise stage of the production cycle". Iterating a script through ElevenLabs renders is using a Wagyu steak to taste a seasoning. Validating the final mix on Kokoro is the inverse — you risk publishing an edit that sounds good on the iteration engine and falls flat on the production engine. Both mistakes have the same apparent symptom ("my audio is less good than expected") and two opposite causes.

The grid below distinguishes three stages of a script's lifecycle and the engine that fits each.

Tier 1 — Kokoro for script iteration

The engine. Kokoro is an open-source voice synthesis model developed by Hexgrad, distributed under a permissive license. The ff_siwis voice I use for French channels is one of the more convincing in the free tier — not at ElevenLabs level, but easily good enough to hear the rhythm of a text and detect sentences that don't land right.

The cadence. Roughly one second per segment on a MacBook Pro M3. For a sixty-second episode split into twelve segments, that's twelve seconds of full render. At that compute cost, a loop of twenty iterations stays under five minutes of cumulative machine time.

When to use it. Every script write or rewrite. As long as you're working on the words — the phrasing of a hook, the linking of two segments, the rhythm of a sentence that doesn't fall right — Kokoro is the tool. It has no reason to be absent from your flow at this stage.

What it misses. Subtle prosody on long sentences, emphatic inserts, the breath between two ideas. A Kokoro voice tells you whether a script works; it doesn't tell you how well it works. It's the right tool for rejection, not for validation.

Tier 2 — F5 local for montage validation

The engine. F5-TTS is a zero-shot voice synthesis model released in 2024 — you give it a reference voice sample (fifteen seconds is enough) and it generates any text in that voice. The result is qualitatively very close to ElevenLabs on short content, with a substantial advantage: it runs locally, no credits required.

The cadence. Much slower. About three minutes per segment on a MacBook M3, more depending on length. A sixty-second episode renders in twenty-five to forty minutes. At that speed, it's ruled out for iteration.

When to use it. Once the script is locked, when you want to verify the audio render in near-final conditions before paying ElevenLabs. It's the test bench. You render the full episode once, you cut the final video on top, you watch the montage, you identify any segments that might need a different pronunciation or a different break.

What it misses. Long-form consistency. Across eight or ten segments, F5 can introduce a slight timbre drift that ElevenLabs wouldn't. That isn't blocking for montage validation, but it's the primary reason not to publish it as-is.

Tier 3 — ElevenLabs for the publishable version

The engine. The industry standard in 2026, unambiguously. The Liam voice I use for fr-quiz-host on Cocorico passes roughly the audio Turing test — an attentive viewer suspects synthetic voice, a viewer scrolling their feed notices nothing.

The cadence. About five seconds per segment, so one minute for a full episode. Compute time is trivial; the only limiting factor is credit consumption.

When to use it. Once and only once, on the definitive script version that will be published. Ideally after F5 has validated that the cuts and rhythm hold. The ElevenLabs render isn't an iteration stage — it's an act of publication.

What it misses. Very little. On short content (under ninety seconds), the quality is sufficient for fifty percent of your audience not to distinguish it from a human voice. On longer content, the "AI voice" signature starts to show — not a problem for Shorts, worth monitoring for podcasts or long YouTube videos.

The mechanism that makes iteration sustainable: hash-based cache

The table above is useless without the mechanism that underpins it. At twenty iterations per episode and eighty monthly episodes, that's potentially sixteen hundred audio renders. The only way to hold economically, even while staying mostly on Kokoro and F5, is to not re-render what hasn't changed.

My Python orchestrator computes, for each segment of each episode, a SHA-256 hash of the textual content concatenated with the target engine and the requested voice. That hash is the cache key. The logic fits in three rules:

1. If a segment's hash is already cached, the audio file is reused without re-rendering.
2. If I modify a comma in segment 7, only segment 7's hash changes, and only that segment is re-rendered. The other eleven stay intact.
3. If I switch from Kokoro to F5 on the same script, all hashes change (because the engine is part of the key), and the full episode is re-rendered on F5. Expected behavior.

The operational result is that a script iteration — typically, I modify one or two segments per pass — costs the render of one or two segments, not the whole episode. At scale, that's what makes the twenty Kokoro iterations per episode economically free and technically fast.

The summary table

| Tier | Engine | Cost | Cadence | Phase | Verdict | |---|---|---|---|---|---| | 1 | Kokoro ff_siwis | $0 | ~1s/segment | Script iteration | The right tool for rejection | | 2 | F5 local | $0 | ~3min/segment | Montage validation | The right tool for validation | | 3 | ElevenLabs Liam | ~$0.05 / 1000 chars | ~5s/segment | Publishable render | The right tool for publishing |

Real numbers across one month

Here's the exact breakdown of my TTS consumption in May 2026, which cost me precisely eleven euros and fourteen cents. Eight channels, seventy-four episodes published, an average iteration volume of sixteen passes per episode.

• Kokoro: 1,184 segment renders (seventy-four episodes × sixteen iterations × an average of nine segments effectively modified per iteration). Direct cost: zero. Opportunity cost: roughly three hours of cumulative compute.
• F5 local: 74 full renders (one validation per published episode). Direct cost: zero. Opportunity cost: roughly thirty-five hours of cumulative compute.
• ElevenLabs: 74 full renders on the Liam voice. About 230,000 characters total. Direct cost: eleven euros and fourteen cents.

Compare with a scenario where every iteration is rendered on ElevenLabs: 1,184 segment renders at about three hundred characters each, so 350,000 additional characters per month. At current rates, that would represent about seventeen extra euros per month — and we're talking about a relatively modest volume. On a production chain that iterates ten times more, the gap becomes absurd.

The edge case to anticipate

The three-tier strategy has a known weakness: prosody drift between F5 and ElevenLabs. You validate a montage on F5, you trigger publication on ElevenLabs, and a segment that sounded right on F5 suddenly sounds off on ElevenLabs (or the reverse). It's rare but it happens, typically on sentences ending with a rhetorical question or an unmarked emphasis.

My practical rule to limit the risk: critical segments — opening hook, key twist, final punchline — are systematically validated under production conditions on ElevenLabs before script lock. That represents a negligible extra cost (two or three segments rendered on ElevenLabs instead of F5), and eliminates 95% of observed drifts.

If you remember only one thing

The three-tier TTS strategy isn't a cost optimization. It's a conceptual reframing: a voice synthesis engine isn't a tool, it's an instrument calibrated for one stage of the production cycle. Iterating with a production instrument is misusing the gear. Publishing with an iteration instrument is misreading its role.

The right reflex for anyone starting to produce at volume: before optimizing the publish render, optimize the cost of iteration. The majority of the economic gain lives in the first half of the cycle, not the last.

---

The full pipeline — Python orchestrator picking the tier via a CLI flag, hash-based cache, MCP publication via Shortflow to six platforms — is described in the pillar post on running eight channels. If you want to test the publication layer without setting up your own pipeline, creating a Shortflow account opens a seven-day free trial with MCP enabled.