Fable 5 is NOT good
The no-buy case
- 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)
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. Ron observed the gap between planning and execution; the verification rule is an added safeguard. (source video 6DmJugJY4Z8, 02:41; source video 6DmJugJY4Z8, 05:19; source video 6DmJugJY4Z8, 09:18)
Watch the test
- 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.
Ron in his own words
“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
Planning worked; execution did not
The tests exposed 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. |
| Game build and debugging | Broke the game screen and claimed a fix that did not produce a runnable result. (source video 6DmJugJY4Z8, 08:00) | Run the result, test it, or check it in a browser before accepting “fixed.” |
| 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)
Check the artifact before accepting the task
- 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. Ron’s broken-game example shows why this extra check matters.
- 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)
Freshness note
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)