20:34Nate Herk | AI Automation · Review
Claude Code vs. Codex: An 8-Site Head-to-Head Design Test
Same prompts, same brand kits, two coding agents — one landing page built by each, eight times over, scored on design and on the bill.
August 26thThe argument in one line.
When two AI coding models get the identical orchestration prompt, the more expensive one can score higher on a blind rubric and still lose, because a 0.7-point quality edge rarely justifies paying more than double and waiting three times as long.
Read if. Skip if.
READ IF YOU ARE…
- You're running (or considering) multi-agent Claude Code orchestration where one model manages workers instead of writing code itself.
- You've wondered whether the newer, pricier model version is worth it for a real build versus a quick benchmark.
- You want a template for writing a delegation-only orchestrator prompt that forces a model to plan, assign, and review instead of doing the work itself.
- You're building internal tools and want a concrete way to judge 'is this AI-built app actually done' beyond a plausible demo.
SKIP IF…
- You only use a single model for single-shot code generation and have no interest in multi-agent delegation setups.
The full version, fast.
The creator ran a controlled test: the exact same long orchestrator prompt, identical target app (a visual incident-response workflow tool), given to Fable 5.1 and Fable 5, with the only difference being which model name the prompt named. Both models were told to delegate all engineering to Opus and Sonnet workers rather than build anything themselves. A third AI (Codex) blind-judged the two finished apps on a weighted six-category rubric and scored Fable 5.1 higher, 9.1 to 8.4. But Fable 5.1 cost $1,220.24 and ran 36 hours, while Fable 5 cost $519.44 and ran 12 hours, a $700 and 24-hour gap for a 0.7-point quality difference. The creator's conclusion: on value, Fable 5 wins this specific test, even though he personally prefers 5.1 for daily driving.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 00:17
01 · Same Prompt, Different Results
Cold open stating the conclusion up front: same prompt to both models, very different apps, one cost $1,200 and worked for a day and a half, the other cost $500 and worked for half a day.
00:17 – 01:22
02 · Test Setup And Prompt
Explains the only variable changed between the two runs was the model's name in the prompt; everything else, including a long delegation-only orchestrator prompt, was identical.
01:22 – 06:03
03 · Side-By-Side App Test
Walks through both finished apps blind (not yet revealing which model built which), testing node creation, connecting workflow blocks, running simulations, and expanding run panels on each.
06:03 – 07:43
04 · Fable 5 And 5.1 Revealed
Reveals which app came from which model, imports a larger workflow JSON into both, and discovers the two apps use incompatible import schemas.
07:43 – 09:09
05 · Blind Test Results
Has Codex blind-review both apps on a weighted six-category rubric without knowing which model built which; Fable 5.1 wins 9.1 to 8.4.
09:09 – 11:30
06 · Cost And Model Breakdown
Breaks down session cost, build time, worker-model mix (Opus/Sonnet/Haiku), and context-window usage for each run.
11:30 – 12:12
07 · The Winner
Argues that a $700, 24-hour cost gap isn't justified by a 0.7-point quality edge, and calls Fable 5 the winner of this specific test on value.
12:12 – 12:37
08 · Final Thoughts
Closes with a personal caveat that he still prefers Fable 5.1 for daily driving, and points to a follow-up video on using it for website design.
Lines worth screenshotting.
- Fable 5.1 scored 9.1/10 and Fable 5 scored 8.4/10 on a blind six-category rubric, but Fable 5.1 cost $1,220.24 versus Fable 5's $519.44 for that 0.7-point edge.
- Fable 5.1 took 36 hours and Fable 5 took 12 hours to finish the identical build brief.
- Fable 5.1 spent 57% of its work on Opus and 40% on Sonnet; Fable 5 spent about 80% on Sonnet and only 12% on Opus.
- Heavier Opus usage tracked directly with both the higher cost and the longer build time in this test.
- Fable 5.1 used under 40% of its context window (about 404,000 tokens) over the full 36-hour run; Fable 5 used about 26% (260,000 tokens) over 12 hours.
- An orchestrator-only prompt that bans the lead model from personally engineering, debugging, or designing forces it into pure strategy, delegation, and acceptance review.
- A third, unbiased AI (Codex) blind-scoring two competing builds on a weighted rubric is a cheap way to remove your own preference bias from a build comparison.
- Fable 5 beat Fable 5.1 specifically on workflow authoring depth (more condition operators, live payload preview, explicit import/export/timeline controls) despite losing overall.
- Fable 5.1's UI won on information hierarchy and canvas readability, but its node labels visibly grew unreadable when zoomed out, which Fable 5 avoided.
- Two models given the same prompt built the workflow importer with incompatible JSON schemas, so a file exported from one app couldn't be imported into the other.
- The creator's real baseline question was: if you capped Fable 5.1's budget at what Fable 5 spent, would 5.1 still win? He believes the answer is no, which is why he doesn't think 5.1's extra quality was worth the extra $700.
A quality win doesn't automatically justify the price gap that produced it.
WHAT TO LEARN
A controlled same-prompt test showed the pricier model scoring higher on a blind rubric, but the honest question is whether that edge is worth double the cost and triple the time, not just which score is bigger.
02Test Setup And Prompt
- Isolate one variable at a time: keeping the prompt, target app, and delegation rules identical is what makes a model comparison mean anything.
- A prompt that forbids the lead model from writing code itself and forces it into strategy, delegation, and acceptance review reveals how well a model manages work, not just how well it codes.
03Side-By-Side App Test
- Testing a finished AI-built app blind, before knowing which system built it, is the only way to judge the UI honestly instead of confirming what you already expect.
04Fable 5 And 5.1 Revealed
- When two AI builders produce incompatible schemas from the same brief, that's a real interoperability cost worth flagging, not just a stylistic difference.
05Blind Test Results
- Use a third, unbiased judge to blind-score competing outputs on a weighted rubric before revealing which system built which, to strip out your own preference bias.
06Cost And Model Breakdown
- Track which worker model did the work, not just the total bill: heavier use of the more expensive model tier tracked directly with both higher cost and longer build time.
- Context-window usage over a run is a cheap efficiency signal: the run that used less of its window relative to its length was also the cheaper, faster one.
07The Winner
- Before crowning the higher score the winner, ask what the same budget would have bought the losing side; a 0.7-point edge bought with double the money is a different question than a 0.7-point edge at equal cost.
- A model you personally prefer for daily work isn't automatically the right pick for a specific, budget-constrained build; separate those two judgments explicitly.
Terms worth knowing.
- Orchestrator prompt
- A prompt that instructs the lead AI agent to only handle strategy, planning, delegation, and final review, explicitly forbidding it from personally writing code, debugging, or designing.
- Worker model
- A smaller or cheaper model (like Sonnet or Haiku) that an orchestrator model assigns specific implementation, testing, or debugging tasks to, rather than doing that work itself.
- Context window
- The total amount of text (measured in tokens) a model can hold in memory during a single run; using less of it over a long task generally means a more efficient session.
- Cache hit rate
- The percentage of a model's input that was reused from a prior turn instead of reprocessed fresh, which lowers the effective cost of a long-running session.
- Weighted score
- A single comparison number built by scoring several categories individually, then combining them using a percentage weight assigned to each category's importance.
Things they pointed at.
07:43toolCodex (OpenAI)
Lines you could clip.
00:00
“So I just had Fable 5.1 and Fable 5 build me the exact same app, and it wasn't even close.”
09:54
“I'm not convinced that this one was $600 worse.”
10:13
“If Fable 5.1 only spent 519 bucks, we probably wouldn't have gotten something this good.”
11:35
“But in this scenario, Fable 5, I think, definitely wins. When you look at the cost, the time, the efficiency, and the actual end result.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
analogy
So I just had Fable 5 .1 and Fable 5 build me the exact same app, and it wasn't even close. Not only did these apps look and feel very different, but one cost me $1 ,200 and one cost me $500. One worked for a day and a half, one worked for just half a day.
So today I'm going to be breaking all of this down for you guys, so let's not waste any time and just get straight into the video. All right, so I thought that I would start with the prompt that I gave these two agents. Now this was a big slash goal prompt, please don't roast my prompting, but I gave them both the exact same prompts.
The only difference is that this one said you are Fable 5 .1 and you work inside of this folder. whereas the other one said you are Fable 5 and you work inside of this folder. That's the only difference.
Everything else, word for word, the exact same. And I'm gonna show you guys how interesting it is because they interpreted it so differently. But here's something that I think is key.
I didn't have Fable 5 .1 build the entire app and Fable 5 build the entire app. I wanted them to basically delegate everything. I said, you own strategy, planning, delegation, sequencing, quality standards, and final acceptance.
Do not personally perform engineering, research, debugging, testing, or visual design production. Preserve your context by delegating execution through dynamic workflows. Primarily use Opus workers for architecture, product, and design direction, difficult problem solving, and independent reviews.
Primarily use Sonnet workers for implementation, research, testing, debugging, and iteration. Give workers clear ownership, prevent conflicting edits, place or redirect workers when results are weak.
Worker failure is still your responsibility. So I'm not gonna read this entire prompt, but this is kind of the gist of it. I gave it bullets on the required product and I gave it the definition of done and I told it to not stop at a plausible implementation, but continue orchestrating until you have objective evidence that the complete product works and is presentation ready.
So essentially what these agents are building is they are building OpsFlow, which is a local first visual automation studio for designing and simulating incident response workflows. So it's not an... workflow automation platform like nnn it is just meant to visually show and kind of like rehearse it's for the person who owns what happens when production breaks so in layman terms it lets you draw your emergency plan as a flow chart and then you can actually visually watch how that plays out so now that that boring stuff is out of the way let's take a look at the actual apps that they built.
Okay. So here is the first one. I'm not going to tell you who made this one yet.
I want you guys to try to form your own opinions and then I'll reveal that after we look at both of them. But this is what we're looking at. This is the UI.
The first thing I'm thinking about is, is this overwhelming? I am just starting to look at this. I've never ran either of these, but I'm just taking a look now and let's see what we've got.
So we've got triggers on the left -hand side. We have trigger, condition, action, approval, resolution. We can drag them into the canvas here and we can hopefully start to connect them into things.
Okay. That looks, seems like it works good. We can connect the trigger into this section over here.
Okay. So, so far the UI is responsive and I can use this. Let's see.
Can I close this? Okay. There we go.
So this is kind of node -based workflow, but it is vertical rather than horizontal. So what I'm going to do is see if I can delete that connection, delete this connection, delete that. Okay.
So let's go ahead and run this. So I'm just going to click run right here. We can visually see this stuff happening.
That's pretty cool. We're seeing this stuff being processed. And now what do we get at the end?
We have a completed run and we're basically able to see what happened. Can I move this up? So I'm not able to expand this.
I think that what you should be able to do is grab here and drag this up so you can look at this full screen because this is a little bit hard to actually look at right here. So there was three that got skipped in this branch and there was seven that got executed. The resolution was mitigated by rollback.
Okay, run has been completed. Okay, awesome. So that's kind of how this one flowed.
This seems to work just fine. We can not zoom in on that. If we wanna zoom in on this thing, oops, sorry guys, we have to go like this, but then we can navigate from there.
Okay, so far, so good. Let's go into the other version now. So this is what the other one looks like.
This is the UI. If you think it's better, if you think it's worse, I personally think that this UI, is a little bit better because I don't know if you guys have realized this sort of card where you've got like the rounded crop color, that is just, that screams AI generated to me.
Now I'm not saying this looks like AI slop, but that screams AI generated. Whereas over here, this doesn't look as bad. Like I think that this looks a little bit more clean.
Let's see if I can drag something in, okay? And I like how it did me a little zoom right there. Let's see how I, oh, that's a resolution block.
So that's not gonna let us connect anything. Let's do another. I guess condition, since that's what we did in the other one.
We can grab the trigger, route it to there, or can we not? Okay, connection refused. API error spike detected.
Already has an ongoing connection. Okay, so one trigger only lets you connect to one thing in this version, as you can see. So that's interesting to note.
We'll connect that back in there. I can drag this and connect to there. I can drag this and connect to there.
And that gives us a false branch. Okay. Cool.
So that works as expected. Let me delete these. We can zoom in down there and I can move this around.
So everything over here as well seems pretty responsive. Can we move this up? Aha.
So in this one, you can expand this a little bit. You can also make this part. Oh, you can kind of zoom that in and we can also close this tab if we want to.
Okay, cool. So let's go ahead and give this version a quick run. I see the run in the top right.
I also noticed that we can go on light mode here. So sorry if I just blinded anybody, but let's go ahead and do a run. So we see visual processing here as well.
We can see this node is waiting. It's waiting for approval here. So approve production rollback needs sign off from this email waiting for decision.
I'm gonna go ahead and approve real quick and see what happens. It goes down the path. Okay, cool.
I'm gonna run that again and see what happens if I decline that. I'm gonna reject. Okay, it just goes ahead and stops.
But now, if you guys notice, it keeps going down the true path. So I'm trying to look, how do I actually change that? Oh, I can view the node, by the way, that aired.
But if I go to the payload, I can choose minor degradation and hit run again. And now it goes down the false. Okay.
So that's cool. That's cool. If I click into a node, by the way, on the right -hand side, we can have a label.
We have the action type, we have the target, and we have all this information to configure it. And similarly on this one, when you click on a node, you get all of that information over here to tweak, I guess. Okay.
So I do like the UI of this one better. So what I want to do real quick is paste in different workflows so we can just see how they look. But I wanted to reveal...
This one is Fable 5 and this one is Fable 5 .1. So we'll get into how much they cost and which one I think is the winner overall. But just wanted to tell you guys, this is Fable 5, this is Fable 5 .1.
And what's really interesting to me is that they accept different schema for the way that we upload new workflows. So if I delete this and I want to import a workflow from JSON, this schema, which now works in here, if I try to import that into this version, doesn't work. There's nothing on the canvas.
So I don't know why, but they decided to build it in a way that's different. But anyways, I imported this. Let's just go ahead and run this real quick to see what this looks like to process a much larger workflow.
There's different paths. I'll go ahead and improve this. I do think that this one visually, it does look good.
I like the way that this feels and looks as we go through the automation. Oh wait, that was waiting on me again. We'll go ahead and approve.
So anyways, that seems to all be working as expected. This is an action. Cool.
Okay. Now let's go over to the other version and let me paste in this prompt. Go ahead and get that in there, import.
Okay, cool. So now we have another one. I will say, I honestly think that Fable 5 looks better when you're zoomed out because the text doesn't grow.
You see here as I zoom in and out, it stays consistent. Whereas here, this looks, I think this looks very cheap for this to be getting larger. I think it looks cheap.
I guess that's a preference thing. Some might disagree, but I think it looks cheap to be like that. So anyways, let us...
Continue going down this branch just to make sure everything looks good. Overall though, I just overall like the UI of this one a little bit better. Except for that zoom thing.
I don't love that at all. Okay, cool. So this is done.
Now let's talk about some results stuff. So what I did next is I had Codex open these two up and I didn't tell which was which. That's why in this chart it says port 4382 and port 5321.
And I said, hey, I gave these two agents the same prompt and here's what they built. test the heck out of them. Tell me what you like about each one better.
Overall, you can see the weighted score is that Fable 5 .1 got a 9 .1 and Fable 5 got an 8 .4. So it looked at visual design and hierarchy, Fable 5 .11. First run ease of use, 5 .11.
Workflow authoring, you can see here, dry run experience, Fable 5 .1 in workflow authoring, as well as validation and safety, which is important, but very, very close. And then Fable 5 .1, ultimately, like I said, one by seven. points or 0 .7 points and after looking at this testing them and having codex review this is kind of the chart of what they thought was better about each one fable 5 had deeper authoring controls clear autosave timestamp it included useful negative test presets like missing severity excellent live preview against the current payload i think that that is very true whereas 5 .1 had stronger information hierarchy and more readable canvas i do think that that is true as well except for when you zoom out Strong run summaries and downloadable run logs.
Clear visual states for succeeded, failed, skipped, and waiting. Rejection currently fails the run instead of falsely claiming mitigation. So anyways, that is a little bit of differentiation here.
Let's talk about the cost. Okay, so I think this is super interesting because 5 .1 cost a little over double of what Fable 5 cost. And it also took about three times as long.
which I honestly was not expecting. On top of that, what I think is really, really interesting is look at the breakdown of models here. 5 .1 used Opus for about 57 % of the work, Sonnet for about 40 % of the work, and itself was only about 3 % of the total work slash tokens.
Whereas on this side, Fable 5 used Sonnet for 80 % of things, which maybe is why some of the stuff is so much cheaper and was quicker, but also a little bit worse in some cases. But I'm not convinced that this one was... $600 worse.
And what I mean by that is if I spent, what would it be? Like, you know, 700 bucks more on this one to improve it just to get where this one currently sits. I think that this one would be better, which is the one that Fable 5 built.
And keep in mind with the majority of the workers here being Sonnet and then 12 % being Opus and 7 % being Fable 5. I thought that was extremely interesting. I was not expecting that.
Do you know what I mean? Like, I think it's good to try to find some sort of baseline. And the baseline for me would be if I spent the exact same amount of money on each of these models, where would we be?
And so if Fable 5 .1 only, or like if this workflow only spent 519 bucks, we probably wouldn't have gotten something this good. You know what I mean? So that is why I am trying to, you know, I'm making that justification there.
Look at the tokens too. On the input, Fable 5, I don't know. I really don't know if this is real.
I don't know if there's any way that Fable 5 only took in. 256 tokens. So maybe something's a little bit off there.
But when you look at the output tokens, this seems to make sense. Now, I think because a lot of this were, you know, dynamic workflows, sub workflows, things like that. But, you know, it's clear that Fable 5 took much longer and cost about double, a little over double, 700 bucks more than Fable 5.
And if we take a quick look at the actual context window from these sessions, here's the Fable 5 .1 that was running on localhost 5321, as you can see. And if I go into here, it only used 404 ,000. of this context window.
So this ran for, like I said, a day and a half, 36 hours, and it only used a little under, you know, 40 % of the context window. If I go to Fable 5, you can see this one was running on 4382, and this one used 260 ,000, so 26 % of the context window. So I just wanted to show you guys what that actually looks like in the desktop app when we look at the actual pricing numbers that I just showed you.
This honestly leads me to conclude... But I think Fable 5 won this challenge. I'm not saying I think Fable 5 is a better model.
I've had a lot of success playing with 5 .1. And I will be honest, when I'm doing a lot of my general knowledge work and I'm driving my day -to -day, I do notice Fable 5 .1 being more efficient and just feeling like it understands my intent a little bit better. So overall right now, I like Fable 5 .1 a little bit more.
But in this scenario, Fable 5, I think, definitely wins. When you look at the cost, the time, the efficiency, and the actual end result, I think that these apps at the end of the day are pretty similar. And for 700 bucks, like, would you pay 700 bucks more for this?
I don't think so. But anyways, that is what I got for you guys today. That's what I found.
I really hope you found it insightful. But if you want to see how I use Fable 5 .1 to design websites, specifically things like my AI Automation Society site, which I think is just absolutely beautiful, and my personal site, and a lot of different styles of websites that have these really premium animations and just scroll elements, then definitely check out this video right here.
I hope to see you guys over there. And yeah, thanks for making this end of this one. See you guys.
The Hook
The bait, then the rug-pull.
The creator handed two versions of the same AI model the identical orchestrator prompt and let them each build the same app end to end. The apps came out looking and working differently, one cost more than double the other, and the more expensive one only won a blind quality test by seven tenths of a point.
Named ideas worth stealing.
00:45concept
Delegation-only orchestrator prompt
- Own strategy, planning, delegation, sequencing, quality standards, and final acceptance
- Do not personally perform engineering, research, debugging, testing, or visual design
- Preserve context by delegating execution through dynamic workflows
- Use Opus workers for architecture, product/design direction, hard problem solving, independent reviews
- Use Sonnet workers for implementation, research, testing, debugging, and iteration
- Give workers clear ownership and prevent conflicting edits
- Replace or redirect workers when results are weak; worker failure is still the orchestrator's responsibility
- Don't stop at a plausible implementation; keep orchestrating until there's objective evidence the product works and is presentation-ready
The exact structure of the prompt given to both models: the lead model is barred from writing any code itself and is judged only on how well it plans, assigns, and verifies work done by cheaper worker models.
Steal forany multi-agent Claude Code or agentic-coding session where you want the lead model to manage a build instead of hand-writing it
08:27list
Blind weighted scorecard
- Visual design and hierarchy (20%)
- First-run ease of use (15%)
- Workflow authoring (20%)
- Dry run experience (25%)
- Validation and safety (10%)
- Accessibility and quality (10%)
A third AI (Codex) was shown both finished apps without being told which model built which, and scored each on these six weighted categories to produce a single comparable number (Fable 5: 8.4/10, Fable 5.1: 9.1/10).
Steal forcomparing two AI-built prototypes, or two contractor deliverables, without your own bias toward whichever one you already like
How they asked for the click.
VERBAL ASK
12:12next-video
“if you want to see how I use Fable 5.1 to design websites... then definitely check out this video right here”
soft, low-pressure pointer to a follow-up video rather than a hard sell; sponsor links are only in the description, never read aloud
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
AFFILIATECommission earned if you click.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
