Fable 5 is NOT good
TL;DR
- Ron tested Fable 5 for roughly eight continuous hours plus several more hours across multiple projects and codebases. His result was not a benchmark verdict; it was a rejection based on working sessions. (source video 6DmJugJY4Z8, 00:54)
- Planning was the bright spot. On an older site that had moved from WordPress to Astro and then through Astro upgrades, Fable 5 found repeated functions, simplified the codebase, reduced calls, shared components, and produced strong documentation. (source video 6DmJugJY4Z8, 01:35; source video 6DmJugJY4Z8, 02:01; source video 6DmJugJY4Z8, 02:41)
- Execution broke the deal: Ron saw mistakes he believed modern models should avoid, while MiniMax M3 made fewer mistakes in his comparison. (source video 6DmJugJY4Z8, 03:17; source video 6DmJugJY4Z8, 03:25)
- Ron’s explanation was silent safety downrouting to a weaker Opus 4.8 variant. The transcript gives his diagnosis and reported Bridgebench numbers, but it does not include routing telemetry or the cited report, so do not treat the cause as independently proven. (source video 6DmJugJY4Z8, 04:09; source video 6DmJugJY4Z8, 04:18)
- His practical fallback was Claude Code with MiniMax M3: cheap enough to run overnight, while Fable 5 was too expensive for that role. (source video 6DmJugJY4Z8, 08:39; source video 6DmJugJY4Z8, 09:03)
Ron’s verdict
Do not buy Fable 5 for hands-off coding on the evidence in this video. It can inspect a messy repository, find architectural duplication, and write an unusually good plan, but Ron could not trust it to carry that plan through implementation. If you already have access, use it as a consultant: ask for the architecture or document, hand the work to another coding model, and verify the result. The verification and hand-off rule is companion guidance built around Ron’s observed gap between planning and execution. (source video 6DmJugJY4Z8, 02:41; source video 6DmJugJY4Z8, 05:19; source video 6DmJugJY4Z8, 09:18)
Key moments
- 00:02 — The no-buy verdict: Ron opens with the recommendation before explaining what worked.
- 00:54 — Roughly ten hours of project testing: the opinion is grounded in several codebases and long working sessions.
- 01:35 — Strong repository analysis: an old WordPress-to-Astro site becomes the main refactoring example.
- 02:56 — The planning-to-execution break: a logical, modern plan starts producing avoidable implementation mistakes.
- 04:18 — Reported Bridgebench drops: Ron reads debugging, refactoring, and hallucination figures from a Bridgemind rerun.
- 07:57 — The broken space-shooter test: repeated bugs break the screen despite the model claiming it had fixed them.
- 08:39 — Back to MiniMax M3: real commits and overnight cost matter more than headline benchmarks.
Useful quotes
“I seriously cannot recommend you Fable 5 right now.” — Ron, source video 6DmJugJY4Z8, 00:02
“It produced one of the best documents.” — Ron, source video 6DmJugJY4Z8, 03:44
“It doesn’t tell you when it becomes stupid.” — Ron, source video 6DmJugJY4Z8, 05:03
“Fable 5 is just like a really expensive documentation reader and consultant.” — Ron, source video 6DmJugJY4Z8, 09:18
What the test actually showed
The useful result is not simply “Fable bad.” It is a sharp split between diagnosis and delivery. Fable 5 reviewed several projects at once, identified repeated functions, proposed shared components, looked for modern approaches, and wrote a logical plan. Ron says this simplification mattered because both humans and AI can work more easily in a simpler codebase. (source video 6DmJugJY4Z8, 02:05; source video 6DmJugJY4Z8, 02:41; source video 6DmJugJY4Z8, 03:00)
The failure arrived during execution. Ron compared the mistakes with MiniMax M3, then described a space-shooter build where Fable 5 repeatedly broke the screen and claimed the problems were fixed even though he could not run the result. He moved the repair to Codex. (source video 6DmJugJY4Z8, 03:17; source video 6DmJugJY4Z8, 07:57; source video 6DmJugJY4Z8, 08:13)
| Work stage | Evidence in Ron’s test | Operator decision |
|---|---|---|
| Repository inspection | Found duplication, excess calls, and opportunities to share components across an upgraded Astro codebase. (source video 6DmJugJY4Z8, 02:01; source video 6DmJugJY4Z8, 02:43) | Let it inspect and propose; do not treat the proposal as completed work. |
| Plan and documentation | Produced a logical, modern plan and one of the best documents Ron had seen. (source video 6DmJugJY4Z8, 03:00; source video 6DmJugJY4Z8, 03:44) | Save the plan as the hand-off artifact. |
| Implementation | Made mistakes during execution that Ron says MiniMax M3 avoided more often. (source video 6DmJugJY4Z8, 03:17) | Route execution to another model and check the diff. This routing action is companion guidance. |
| Game build and debugging | Broke the game screen and claimed a fix that did not produce a runnable result. (source video 6DmJugJY4Z8, 08:00) | Require a real run, test, or browser check before accepting “fixed.” This acceptance check is companion guidance. |
| Long unattended loop | Ron returned to MiniMax M3 because its inference was cheap enough to run overnight; he considered Fable 5 too expensive for that. (source video 6DmJugJY4Z8, 09:00) | Price the completed task, including retries, before choosing the worker. |
Keep the routing claim inside the evidence boundary
Ron says deep coding and refactoring triggered a larger safety margin and silently degraded the session to a weaker Opus 4.8 variant. He supports the concern with figures he attributes to a Bridgemind Bridgebench rerun: debugging fell from 86 to 25.9, refactoring from 73.6 to 38.4, and hallucination from 75 to 61. (source video 6DmJugJY4Z8, 04:09; source video 6DmJugJY4Z8, 04:18)
The video does not show the underlying report, a request-by-request model trace, or a controlled rerun proving when the route changed. It also includes Ron’s speculation about government restrictions and model access; that is commentary, not demonstrated causation. (source video 6DmJugJY4Z8, 06:29) The supported conclusion is narrower: Ron observed inconsistent coding quality, believed hidden downrouting explained it, and could not tell from the interface when the alleged change occurred. (source video 6DmJugJY4Z8, 05:03; source video 6DmJugJY4Z8, 06:49)
A five-check acceptance gate
- Did the model only produce a plan? Save it, but do not count the task as complete.
- Does the implementation build or run? Check the actual artifact; Ron’s game did not. (source video 6DmJugJY4Z8, 08:08)
- Did it claim a bug was fixed? Reproduce the original failure before accepting the claim. This is companion guidance based on Ron’s broken-game example.
- Would a cheaper model make the same change? For important work, compare the diff; Ron proposed parallel comparison because he could not identify the alleged downroute. (source video 6DmJugJY4Z8, 07:19)
- Can the economics support retries or an overnight loop? If not, keep the expensive model out of repetitive execution. (source video 6DmJugJY4Z8, 09:03)
What changed since this video
This video was published July 3, 2026. This companion was source-checked against the published video on July 18, 2026. No external model announcement, safety-policy update, pricing page, Bridgebench report, routing telemetry, or new test was added. The model names, reported scores, $200 plan mention, safety-margin explanation, and “few weeks” timeline in the source video are therefore a dated record of Ron’s video—not confirmation of product state on July 18. (source video 6DmJugJY4Z8, 10:00; source video 6DmJugJY4Z8, 10:19)
Related
Watch on YouTube
Prefer the native player? Open it on YouTube: https://www.youtube.com/watch?v=6DmJugJY4Z8