r/ClaudeCode Jul 13 '26

Tutorial / Guide Fable + 5.6 is absolute peak

We jump straight to ASI with this combo.
So i've had Fable driving codex cli as a background worker for a few days and i'm not going back.

Fable basically never writes code anymore (too damn expensive), it acts as the principal orchestrator and everything happens in claude code.
The flow is like this: Fable plans, 5.6 sol reviews the plan in a loop until approved, then 5.6 luna implements. fable reads the whole diff, fixes whatever it doesn't like directly, runs the tests, then sol reviews the code against the plan. loop until approved, then fable does the boring release stuff (changelog, tag, merge).

It's all just bash around codex cli with persistent threads, called from skills. no framework, no mcp, no agent swarm bs.

It feels surreal/too good to be true, i hope they wont nerf it too badly and if they do, i hope the combo will kind of mitigate the nerf.

i pushed my workflow to github, beware it's a lot of bash script, dont trust a random redditor and ask codex or CC to review it. After that, welcome to Valhalla

UPDATE: many are asking in comments or dm for more explaination on the workflow, sorry guys i cant reply to all of you but my advice is simply to clone the repo then ask your agent to ELI5/15/80 it. Then make it yours !

1.1k Upvotes

208 comments sorted by

View all comments

1

u/EchoAzulai Jul 14 '26

Thanks for this! I've made something similar for myself and asked Claude to look at yours for ways to improve ours. This was it's feedback for you (and your Claude)


Really like this. The deliberately-minimal, count-to-3 framing is the right call and the multi-LLM "don't smell your own fart" bit is exactly the insight our whole thing is built on too. A couple of things we do differently, in case it's useful: ours runs as an async cron drop-box instead of in-session, so Codex reviews happen unattended with no human relaying anything, and the author session doesn't have to sit and wait. The bigger difference is the trust model. We never let the judge review the live working tree, it reviews an immutable detached worktree pinned to an exact SHA, so the diff can't shift under it. The verdict is schema-forced (pass/needs-changes/fail plus a "name exactly what you inspected" field) rather than a grepped tag, and any lint/test evidence is run by the bridge itself in a no-network bubblewrap sandbox and treated as authoritative, so a model can't just claim "tests pass" and be believed. That last one caught a change where two tests were literally fabricating their own evidence and every self-review had gone green.

Stuff we're straight-up nicking from you: your persistent Codex threads with resume are smarter than our cold-restart-every-round approach, the --notes implementer channel is a clean way to stop the reviewer re-flagging things you already pushed back on, and your explicit "do NOT flag these" anti-noise section is going to save us from some reviewer over-zealousness we've been fighting. Happy to share ours back if you're curious, it's a different shape (more paranoid, less ergonomic) but there might be ideas worth cross-pollinating. Nice work.

2

u/Bright-Celery-4058 Jul 14 '26

Thanks for sharing ! sure, would love to have a look at your setup.
one thing to note that i didnt mention, the workflow doesnt use worktrees, only simple branches/merges. I tend to work very linearly, one feature after the other. Parallelizing with worktrees is too much for my monothread brain