# Your Complete Guide to Fable 5.2 (When to Use It, Effort Levels, Prompting) **Channel:** Cole Medin **Source:** https://www.youtube.com/watch?v=fLjGgbW0Ki8 **Transcript page:** https://www.withtranscript.ai/video/fLjGgbW0Ki8 ## Chapters - 0:00 — Why Claude Fable 5.2 Matters - 1:52 — Benchmarks, Cost, and Model Split - 5:57 — Planning Workflows With Fable - 11:37 — Choosing Effort Levels Wisely - 14:09 — Prompting Tips and Final Advice ## Transcript **[0:00]:** All right, this is your quickest guide to Claude Fable 5.2. Anthropic just put this model out a couple of days ago, and it is incredible. Now, I know you're probably sick of everyone saying every new model is incredible, but there is something different about Claude Fable 5.2. The best way I can put it is Fable 5.2 just seems a lot more self-aware. As LLMs get better and better, it seems less and less like we're just talking to a machine that has those obvious and frustrating shortcomings. And Fable 5.2 is just a really big step up in those regards. I have a really silly example just to show you that quickly. And so if you ask any previous LLM to not reply to a message, it's going to do so anyway because LLMs are built to give you tokens no matter what your prompt is. But somehow Fable 5.2 actually passes this test. **[0:44]:** We have some thinking tokens, but the actual response is empty. Now, I know this example is pretty random and not very practical, but the point that I'm making here that you'll see throughout this video is Fable 5.2 is just built different. It's able to break past these barriers that have always made it seem like with these LLMs, we're just giving our work over to a stupid machine. And going to the benchmarks here, Fable 5.2 looks incredibly impressive. And from my own testing and what I've seen from other people testing, it definitely does match the hype that we have right here. But the problem is Fable 5.2 is incredibly expensive. It's twice as expensive as Opus 5.5, which is already a pretty expensive LLM. And so we have to be pretty strategic for how we use Fable. can't just use it for everything. And so what I want to cover in this guide here is first where does Fable 5.2 make sense to actually use versus where should we still use smaller LLMs like Opus 5.5 which is still incredibly capable by the **[1:39]:** way. And then I want to get into what effort levels should we use for both Fable and Opus when we combine them in our workflows. And then finally I have some general guidance for how we can prompt Fable and really take advantage of the new capabilities that we have here. **[1:52]:** So looking at the benchmarks here, Fable obviously has a pretty big leg up over Opus 5.5 and all the other best LLMs until now. And the biggest reason for this, this is my favorite part about Fable is it is so incredibly capable making those bigger and more complex decisions. In fact, what I was able to do recently that I'd highly recommend you do yourself is use Fable to help solve the things that we weren't able to fully with Opus 5.5. I have this happen all the time where I'm working on a bigger decision like trying to figure out the architecture for an application and I just go back and forth with Opus 5.5 cuz it's giving me decent solutions but there's holes in what it's proposing or it's not fully confident and so it asks me questions as well. Then we go in this back and forth and I'm never fully satisfied with its answer. **[2:34]:** But I literally just take that transcript, that conversation, I give it to Fable and I say, "Here's the problem. Here's how we've been ideating." And then it comes back with what seems like the perfect solution in just like 10 minutes. And that's what I mean when I say when you try Fable 5.2, you're going to notice a big difference right away. Not necessarily for everything, and we'll talk about that as well. But when you have it help you work through those larger decisions or you give it really open-ended tasks, it's just going to blow them out of the water compared to other LLMs. So, obviously, I'm pretty excited for Fable 5.2 and even third party benchmarks like artificial analysis show this model is incredibly capable. But there are two big things that we have to be aware of that will change how you use Fable. **[3:13]:** The first and most obvious is the cost. Claude Fable 5.2 on Max Reasoning, the average cost per task was $26.54 cents in these benchmarks. That is incredibly expensive. If we look at Claude Opus 5.5, also on Max Reasoning, it is less than half the cost. And we'll get more into effort levels in just a little bit. But one more thing here, Fable on High Reasoning, is still $9 per task. And Opus 5.5, also on high, is only $346 on average. And this is important to call out because sometimes when you have a more capable and expensive LLM, the actual cost per task is not that much different because the better LLM is more efficient. The interesting thing here is it doesn't really seem like Fable is more efficient than Opus. It's twice the price, but for a lot of these data points here, it's actually more than double the cost per task. **[4:03]:** And then the second big thing to consider here that Enthropic even talks about in their own resources is that for simpler tasks or things that are really well defined, there's not really even an advantage to using the better LLM. So when we have something so capable but also so expensive like Fable for a lot of things, Opus 5.5 is simply going to be good enough. And so we don't want to go for Fable a lot of the time. And a lot of what I'm seeing right now is people are sometimes disappointed with Fable because they have a task for cloud code that usually Opus just handles fine. Fable just takes it way too far. Like in this case for this person in particular, they used 100% of their 5h hour usage in less than 20 minutes on the $100 a month Claude Code plan. I know this is just one example, but I'm seeing this a lot right now. **[4:47]:** It just shows that we have to be careful with how we're using Fable. And let me tell you, there is a lot of research and blog posts that I've seen as well as my own experience that all converges on this idea where we need a split. We need the right task routed to the right model. Yes, Fable is so incredibly capable like we've been talking about, but also because of the cost, we do have to use cheaper models for a lot of things, and we're able to do so without sacrificing performance. Like this article says, Fable 5.2 2 is best for long horizon agent runs. Anything that requires a lot of big decisions or a lot of open-ended work. And so my main recommendation here, this is my biggest takeaway for you in this entire video. And I'll help you understand how to implement this as well, is you want to use Fable 5.2 to plan, search, and decide, and then use Opus 5.5 to execute the well-defined steps. **[5:35]:** And this pattern of having the better LLM as the planner and the cheaper one as the workhorse, it's been emerging for a while. So, this isn't brand new, but like they say here, the roles have sharpened. This is even more important with Fable 5.2 because it's that next level of both it's so incredibly expensive, but also just so good at making those decisions. And so, let's talk more about what that actually looks like in practice. **[5:57]:** The sponsor of today's video is Firecrawl, which gives your agents data from the web and beyond. Now, a lot of times when I'm using Firecrawl, it's fetching contacts for me when I ask for it. But sometimes I want firecrawl to be proactive, fetching context before I even know to ask for it. Like one example that actually happened to me recently is my AI second brains long range task started dying because there was an update to clawed code that was sending a message type that my version of the SDK didn't support and people were already reporting this on GitHub. The fix was actually already there, but I just had no idea. So now I have firecall watching for that. Their plugin, which I have connected here to Cloud Code, is able to create monitors, which run their search on a schedule. So, right here, I asked Cloud Code using the Firecrawl plugin to create a monitor that searches github.com every morning at 8 a.m. **[6:44]:** for new Cloud Code bugs. Just a plain English goal here, only flag issues that are filed in the Cloud Code repository that could break agents running in headless. So, exactly what would affect my AI second brain. And so, it built the entire monitor for me in just a couple of minutes. So now going to the firecall app, we can see it live as an active monitor. The last time it ran, it found 18 issues, but determined that only one of them was actually meaningful for me. An issue with the cloud code SDK that very much could have affected my AI second brain. So it's working exactly as intended. My agent can also read the results from the monitor using the plugin. So it can action on the things that are surfaced here. I can also have the monitor send me alerts to Slack, email, whatever I need. **[7:25]:** And this connection through the plug-in gets me Firecrawl Alexandria, over 100 million index sources and 400 plus data providers. Firecrawl is free to get started with a,000 credits a month, which is enough to run a daily monitor like this. It installs in one click to chat GBT, Claude Curser, other agents, and I'll have a link to them in the description. So, the easiest way to do this just within the harness of your coding agent like Cloud Code is to start with one session where you just do the planning. So, you have Fable 5.2 to load context around your codebase, search the web, help you make those bigger decisions around your architecture or whatever you're building, and then you codify that in some kind of handoff document. Usually, I just keep it simple with a markdown document like my plan.md. And then that is the end of this conversation. **[8:10]:** You then start a new conversation and you do /model the change to something like opus 5.5. You have it read this file and do the implementation and then any kind of validation and iteration that it wants to do. So now this workhorse is what takes the plan forward. You made all the big decisions. You did all the hard things in the first session. So now this one just has to execute. Now we've looked at some of the benchmarks already, but there's an insane amount of research that I put into this and also my own experience that shows this is the best setup. And so right here in blue is Opus 5.5 and then purple is Fable 5.2. And it pulls ahead in all of these tests where it's much more open-ended tasks it's dealing with where it has to make those bigger decisions. But this is when we're giving all of the work to Fable. **[8:54]:** Remember, we really don't have to. There's sort of the other side of the coin here where for certain benchmarks and tests where the scope is more well- definfined, there's really not a difference between Fable and Opus. Even for some of Anthropic's own testing, like this benchmark here with Frontier Code 2.0, Fable and Opus are pretty equivalent. Now, Opus was tested with max effort here with Fable just on high. But like we'll see in a little bit with effort levels. The difference for opus with max and high reasoning is not actually that much. So they're pretty equivalent here. But then fable is almost double the cost. That is why we always want to do the hard stuff first, like the researching, making those bigger decisions, put that in the plan document, and then send that off to the workhorse. Which, by the way, for most agent coding workflows and other kinds of flows, you don't even need something as good as Opus 5.5. **[9:42]:** It just makes sense here because it's really nice where at least if we're not using Fable 5.2, 2 for everything. We can still use the next thing below it which is still incredibly capable. Now the last thing I'll say here really just to put a bow on it is what we're doing in this first session is we're laying the groundwork in this handoff document so we can put Opus and Fable on the same playing field. We are making it so the task is well defined because we do the planning up front. So then it just makes sense to use Opus cuz we're not sacrificing any quality or performance finishing the work with it. Now, as you can imagine, there are a lot of different strategies and approaches out there for combining different models. Like Claude has their own cookbook right here that I'll link to in the description. **[10:21]:** The orchestration pattern, big models for planning, small models for execution. You can use this cookbook or just get ideas on it for how you're going to use these different models. My open- source harness builder archon also allows you to build workflows for this exact purpose. Like right here, this is a working archon workflow I could run right now. It does the planning in the first step with Cloud Fable 5.2. Here's the prompt. We're having it create that handoff document just like I showed in the diagram. And then for our second node here, a brand new session using Cloud Opus 5.5. It reads the document and then it does the building and the iterating. Within Cloud Code specifically, we also have the advisor tool which you can enable within any Cloud Code session. If you just do /advisor, then we are able to set the model for the adviser or turn it off. **[11:04]:** And so what this does is we have our workhorse like Opus 5.5, but is periodically going to advise using the more capable LLM. And so basically, Fable is the orchestrator we call upon when we need to make a bigger decision or just do anything that's more difficult. Now, Anthropic did a lot of studying where they showed that this actually doesn't save on costs that much. I think the adviser is pretty inefficient, but I'm just giving you some different ideas for how you can actually implement this in practice. However you want to do it, the important thing is just find some way to make it so you're not using Fable for everything, but you are using it for the planning. **[11:37]:** And of course, talking about what model to use would not be complete without covering the effort levels as well. And so for the first two rows here, I have Fable and Opus on more complex coding tasks using the artificial analysis benchmarks we looked at earlier. And so, of course, there's going to be a pretty big difference between Fable and Opus here because it's the more open-ended tasks. But the important thing to focus on is the difference between the effort levels for each model. This is what we're looking at here cuz we want to answer the question, what effort level is best as a default for each one of these models. And so for Fable 5.2, interestingly enough, there's a very big jump between medium and high reasoning. We go from a 56 average for these benchmarks to 62. It's quite a bit more expensive. It's like triple the cost, but usually that large of a difference is going to be worth it. **[12:26]:** But when we go from high to X high, there's actually no gain at all and it's only a threepoint gain when we go to the absolute highest max reasoning. And so there's a little bit, yes, but if we look at the cost difference here, $9 compared to 26 1/2, it is almost never going to be worth running Fable 5.2 on max effort. High is what I would generally recommend. And then for Opus 5.5, I actually don't really want to focus on this second row here because this is again for more complex tasks. We want to make things well- definfined using Fable for the planning. So I care more about how Opus 5.5 performs on more well-defined tasks. And because I love doing Agentic Engineering, that's my main use case for AI. That's why I'm focusing on coding benchmarks for a lot of the data that I'm showing you here, but also this does apply to other things besides AI coding as well. **[13:15]:** But anyway, Opus 5.5 here for simpler tasks. For medium, it's 92.8% that it scores on these benchmarks. and then jumping up to high and then X high, we gain a few percentage points, but also the cost goes up quite significantly once we get to X high. So again, for simpler tasks, I would generally recommend high or medium. In fact, because we're already above 90% for all three of these points, a lot of times you can get away with medium for Opus, especially if you're using Fable to really scope out the plans of attack. All right, so I know that was a bit long-winded because I did want to give you the actual statistics to go with my recommendations here. But in the end, I recommend for Fable 5.2 high reasoning. And then for Opus, a lot of times you can get away with medium. Sometimes you might want to do high, but never do X high or max. **[14:04]:** And really low is not going to ever be worth it either. And so with that, we've established the effort levels. **[14:09]:** We've talked about how we plan with Fable and build with Opus. The last thing I want to cover here is just some really simple but effective strategies to prompt Fable. Well, so a couple of these tips are new to Fable 5.2, and then the other couple are just good advice in general, but it applies even more to Fable 5.2, including this one right here, because Fable 5.2 just thinks differently. It's able to take ownership better. And so, if we explicitly tell it that, like you are the owner and long-term maintainer of this codebase, and its design is up to you, you actually get better results. I know it seems kind of silly to prompt this or include it in your rules, but this single line does make a decent difference with a lot of research that I've seen done around adding this kind of prompt. **[14:48]:** And so it cleans up duplicate code 70% of the time with this prompt, but under 10% of the time without it. And so you don't need this in the Opus build session because the cleanup is going to be defined in the plan. It's one of those larger decisions that we're making for how we're going to clean up code. But you definitely want to give this to Fable 5.2. I know this one is more coding specific, but the other tips here are going to apply to really anything we're doing with Fable. So, the second tip here is very important to be aware of. If you talk to Fable and Cloud Code, by default, the sub aents that it spins up are also going to use Fable. And this is not good. We've already talked about how expensive Fable is. And generally, the tasks that you delegate to sub agents are more around just context loading. **[15:29]:** We don't need a lot of reasoning capability. So, you're wasting your money, wasting your tokens if you're using Fable. And so the fix here is to set the model like using sonnet or opus for the sub aent. So for custom sub aents you can set this in the yaml front matter of the sub aent. But even if you're just talking to cloud code you can tell it for this sub aent or these sub aents I want you to use this model and it can set that dynamically before it invokes them. So make sure you take care of that. If you hit your rate limits extremely quickly with fable like even faster than you expect it's probably because this is happening. So for tip number three, as LLMs get more and more capable, sometimes we accidentally constrain them too much by describing these specific steps instead of the higher level outcome that we wanted to get to. **[16:12]:** And this especially applies to Fable 5.2. We've talked so much about how good it is at open-ended tasks. Sometimes we actually don't want to be specific. Now, if you know exactly what you're looking for and you're 100% confident in the steps to get there, of course, it is helpful to guide the model in that way. But for anything where even if there's a little bit of uncertainty in your own head, instead of trying to come up with the steps, you should just write down what the outcome should be and let the agent get there. And finally, ablate your rules. Prune the things from your claw.md and other context files that the LLM just doesn't need anymore. Because as LLMs get more and more capable, a lot of the rules that used to be important to guide previous LLMs are actually just wasted tokens now. And kind of like the last tip, it might actually constrain the LLM accidentally. **[17:00]:** And so every time a new LLM comes out, and this is especially true for Fable 5.2, you want to do this kind of audit to figure out what you can prune. And of course, I have an ablate AI layer skill to help you with this that I'll link to in the description. I'd highly recommend going through this really every time a new LLM comes out, but right now is especially important. Awesome. So with that, we have covered everything you need to know for Fable. when to use it and how, the right effort levels and some tips to help you prompt it effectively. And of course, a lot of data to back up everything that I'm giving you here. So, I hope that you found this helpful. Just 15 minutes of your time to save you hopefully hours and hours working with these models better in the upcoming weeks. **[17:36]:** If you appreciated this and you're looking forward to more things on getting the most out of your coding agents and new LLMs, I would really appreciate a like and a subscribe. And with that, I will see you in the next video.