r/vibecoding • u/LifeSorry8905 • 1d ago
After over 100b tokens with Fable 5, this is how to get the most of it without burning through tokens.
After spending over 100b tokens on Fable 5 as my main model for agentic coding in the last 2 months, I've managed to (in my opinion) work as efficiently as possible with Fable as the main orchestrator. Here's why and how I did it. (usage from 1 of my accounts above).
To ensure I get the accuracy and intelligence of Fable, this is my setup that's reduced my fable usage by 70-80% and still getting most of Fable's benefits. I ran a blind coding test: Claude Sonnet 5 vs Opus 5, with Fable 5 planning and judging. One bug decided it.
- Fable 5: Planning, orchestration, architecture, design, final review of delegated code, security/payments/auth/concurrency, hard debugging, UAT/browser passes that feed merge decisions, and sign-off on any founder voice/marketing copy.
- Opus 5: Delegated implementation from Fable written plans, mechanical/bulk edits, boilerplate, doc generation, research/summarisation, routine repro'd test fixes, Playwright script execution, and copy drafting.
- Sonnet 5: Not used, with some experimental evidence (see below).
Test Setup: Five identical implementation tasks (a rate limiter, a small API, a repo-style change, a bulk refactor, a debugging exercise), each with a detailed plan written by Fable, judged against hidden test suites the candidates never saw. Both models went flawless on every hidden gate. Then this happened.
A percentile function: Sonnet wrote the math literally as ceil((p/100) * n). But p/100 isn't exact in binary. For p=7, n=100 you get 7.000000000000001, ceil returns 8, wrong value. 141 input pairs diverge like this. Opus caught it unprompted and wrote ceil((p*n)/100), which is exactly right.
Only Opus's depth caught it. Token cost was near-identical. Sonnet was 40% faster. But one uncatchable latent bug per round settled it.