Fable 5 on Scripti: separate reported findings from a verified repair

Read the availability notice first

The published description begins “THIS MODEL IS NO LONGER AVAILABLE” and links to [this update](https://youtu.be/eL8V8awl3XI). Keep that notice with any summary of the June recording. This is a historical companion, not an instruction to select a currently available Fable 5 endpoint.

The video describes Mythos/Fable 5, discusses launch benchmarks and tests it on Luke’s production SaaS, [Scripti](https://scripti.ai). Its figures include 78% on Exploit Bench versus GPT 5.5’s 34%. These are claims attributed to the original description, not independent benchmark verification or a general ranking endorsed by this article.

Separate the four tasks

The source lists finding bugs, fixing them, redesigning the UI and performing a security audit. Each produces different evidence. A list of suspected bugs does not show that repairs were implemented, and an attractive pricing page does not demonstrate that billing behaviour is correct.

1. Use the real-code section at 4:53 to establish the project context.
2. Follow the bug hunt at 5:47 and keep findings separate from repair claims.
3. Compare the fixes and UI work at 8:56 with the specific problems they are meant to address.
4. Inspect the security-audit discussion at 10:11 as a distinct review, not a substitute for testing repairs.

Keep the reported issues in context

The description reports 23 bugs involving overcharging, double charges, credit gates and capped tiers. It also names a critical promo-code privilege escalation, credit-bypass race conditions and an unauthenticated debug router. These are historical reported findings on this codebase; this companion neither reproduces exploitation steps nor establishes their current status.

Luke says this run surfaced issues missed by Opus 4.7, 4.8, DeepSeek and Codex using GPT 5.5. That is a comparison of his reported runs. It does not prove every listed finding was independently confirmed or that another model could never identify it.

Turn findings into checkable follow-up

When using the video as a review example, ask what evidence supports a finding, what change addresses it and what check would establish the repair. Preserve unresolved or unverified status rather than treating the model’s confidence as acceptance. Keep sensitive production details out of public reports.

The value of the example is its separation of product behaviour, interface work and security review. Use the linked availability update when deciding which parts of the historical workflow remain relevant to your current tools.

The takeaway

Read this as a historical review of reported findings. Model preference, confirmed defect, implemented fix and successful verification are different claims.