My New Favorite Model Transcript, AI Summary & Key Points

00:00 Fable 5.1 is here. And slight spoiler, I hope the best new model counter guy is too because this model is awesome. I've been using it a ton over the last day. I've been shipping way more than any one human should. Certainly one that also has to like run a YouTube channel and multiple businesses as well as a bunch of doctor's appointments. But I've been doing my best to really push this model and every time I do, I'm just more blown away with it.

00:19 It's a meaningful jump from Fable 5 in all sorts of different ways. But it's also a bit confusing a release because in some ways it's more expensive, but in others it's cheaper. In some ways, it follows instructions better, in other ways, it does it worse. It benches higher for the most part with a couple strange exceptions. But god damn, this model is awesome to use.

00:35 I've been having so much fun with this model that it was hard to stop prompting for long enough to come and record. It was even harder because this is actually my second time recording because I had a weird audio issue with the first one. Obnoxious, things happen. But this is an important model release and I want to do my best to share what I've actually been doing with it and how it feels to use in the real world.

00:55 We're going to cover all the usual things here, like the benchmarks, the official article, the ways people are using the model, the cost, and all that type of stuff. But I'm going to go a bit deeper than usual, too, because I don't want to make the mistake I made in the Opus 5 video where the model seemed totally good as you were using it in a little bit of test type work and it killed it in the benchmarks, but then when you actually started merging the code, it was nowhere near as nice to use.

01:16 But considering that we landed 89 PRs in 24 hours using this model, I have a much better idea of where its strengths and weaknesses are than usual. I even took the time to do a deeper analysis of how 5.1 performed compared to other models in a given time window and got some really cool insights from that. Needless to say, I've been using this model a lot.

01:33 I have a ton of thoughts about it and I can't wait to share all of that and more right after a quick word from today's sponsor. I've been shipping a ton of code lately. On my peak days, I'm filing as many as 30 or 40 poll requests. What this actually means is that I'm spending way more of my time sitting and waiting for CI to run. That's why I'm so thankful for today's sponsor, Blacksmith.

01:50 Not only have they cut our CI times in half, they also save us a ton of money because their runners cost 60% less than GitHub equivalent runners, and it's just one line of code to change. Blacksmith is a sponsor, but they're also our CI of choice for things like T3 Code. All of our CI and builds run with Blacksmith, which is why I was really excited when they announced Codesmith, which is their new coding agent that is running on the same infrastructure as the Blacksmith CI.

02:16 And I want to be clear here. I'm not planning on doing all of my code in Codesmith going forward. But what I do want to use it for is fixing my CI. When you first open up the Codesmith web UI, their first recommendation is this little right size to find runner button, which has their right size scale built in. That helps you save even more money. I just ran this on T3 code, and it found a bunch of opportunities to save actual spend for us in our realworld apps.

02:38 Now that I'm actually sitting here and reading this, I'm planning on doing pretty much everything it recommends. It noticed that our Mac runner is spending way too much time pegged at 100% CPU and that we could cut our build times in half for a simple $61 a month of additional spend. These other CI jobs could benefit from a bump as well, but it would be a much higher cost with a much smaller win.

03:00 It even has this fancy little view here where I can check the things it should or shouldn't change, and I'm assuming it'll just file a PR. This is my genuine reaction because I just tried this in order to film the ad. The fact that it does save like a few hundred bucks a month and make our jobs way faster by running this one skill is hilarious. I'm clicking that migrate button right now.

03:17 You can set it up to run automatically on GitHub so when CI fails, it'll fix them and make them green. You can also connect it in Slack in order to keep an eye on all of the work being done on your projects and even trigger changes remotely just by tagging Codesmith in Slack. And here we go, a real PR that makes our build cheaper and our runtime faster.

03:33 Make your CI faster in every possible way at soyv.link/blacksmith. Since I'm recording this video for the second time, I wanted to put a little extra effort into structuring it so we can get through the key things you guys actually care about. Let me know if you like these types of timeline breakdowns at the start to let you know what parts are going to be where.

03:50 We're going to start with the release notes as well as covering the cost a bit during that. Then we'll go to the benchmarks, you know, the thing everybody tends to focus on. After that, we'll do UI capabilities and all the other crazy demos people have been making with it. And we'll wrap up with what I think is the most important part, how this works and looks in realworld use cases.

04:04 So, let's start with these official release notes. Fable 5.1 and Mythos 5.1. I feel like it's worth calling this out now because people seem very confused about this. Fable and Mythos aren't different models. Just because there's two different things with two different names doesn't mean they are different models. You can almost think of this kind of like the ghost kitchen thing on Uber Eats where a less desirable restaurant will rebrand or make a fake restaurant with a subset of their items so that you can buy a

04:29 burger from a thing that doesn't sound like it's coming from Chuck-E-Cheese. kind of what they're doing here where Fable 5.1 is just Mythos, but they have a bunch of things in front of it preventing certain requests from going in and certain responses from coming out. So, Fable and Mythos are the same model. The only difference is what happens when you send a request, not the actual weights underneath.

04:49 So, if you think these are different models, they're not. They're just different doors to the same model that have different restrictions on them. So, that out of the way, let's talk about the models themselves. Anthropic is introducing Fable 5.1 and Claude Mythos 5.1. They're the world's most advanced models for coding and knowledge work, and their research capabilities offer an early glimpse of how AI models will contribute to scientific progress.

05:07 The science stuff seems like a particular focus point, both of anthropic and open AAI right now, and we'll have things to talk about there, don't worry. The immediately open with Fable 5.1 and Mythos 5.1 are the same model, but with different levels of safeguards. Fable is generally available while Mythos is available only through the trusted access programs.

05:23 It safeguards are specifically designed to support work in cyber security and the life sciences. Same as usual, they also call out that Fable 5.1 is taking important steps towards addressing the feedback they've received from customers on price, data retention, and safeguards. I'll add one more thing in there. It's addressed a lot of the feedback on the Fable and Opus slop of just like weird technical jargon being spit out constantly, and it's much more readable in terms of its outputs.

05:48 I've noticed a huge jump there, and I bet a lot of y'all will too. We'll get to all that when we talk about my real world use. For now, let's talk about price. They claim that 5.1 will cost an estimated 25% less than Fable 5 for typical workloads whenever usage is build by token. That's because they're reducing the price on cash reads. It's a 75% decrease on cash reads.

06:07 It's a pretty insane gap. They also call out that for highly agentic work, the savings will be significantly higher up to 45%. And this absolutely lines up in terms of how the token cache costs work. I'm going to use the T3 code usage tab to show my actual realworld usage of these things to give you a better idea of what we're talking about here. You can see clearly that my Claude code costs are insane.

06:29 I'm not actually spending the 16 grand that's on the screen. I just have a bunch of subscriptions that I'm using that you can push pretty dang hard and get a lot of value out of. One of those $200 a month subs from Claude Code can get you up to $8,000 a month of usage. And I've ran the numbers. It's roughly around there. I can show you much more fun details in the near future, but for now, let's talk about how these costs break down.

06:52 Halo 5.1 has the same main price of $10 per million input tokens and $50 per million output tokens, but the cash reads are way cheaper with a 75% discount, only at 25 cents per million tokens for cash reads. The reason this is important is because of how agentic work actually works. When you send a request, you're not just getting one generated response.

07:10 Every time the model does a tool call, it's effectively stopping and restarting generation because it has to wait to get the response from wherever you're running the agent. So when it says, okay, I want to read the things in this directory, that is a command that gets run on your computer. The model stops generating entirely in that time and then a new request is made with the results that goes up to the API to continue generation.

07:32 If it had to parse your entire history for that thread every single time that happened, you would end up waiting way longer. the GPUs would be used way more heavily because they have to recalculate where you're at every single time. So ideally, you can store where you were before you ran that tool call and then when you send the result up, you can kind of just resume from where you were.

07:50 This ends up being way cheaper for Anthropic because they don't have to reprocess the input on every single additional call. And since some of the turns that the agents take can have hundreds of tool calls during them, you would be reingesting all of the input every single time if you didn't have caching on. Again, looking at my real world costs, I would have spent 15 grand on quad code if I was paying cash.

08:13 It would have been about 25 grand total. But if I didn't have cashing on, it would have been 135,000 additional dollars because that's all inputs that were not paid at full price. They were paid at cash rates instead. Of the messages I've sent, 42.8 billion of my input tokens were cashed and under a billion, only 710 mil, were uncashed. So this cash discount is a huge decrease to the amount of money you'll be spending on processing input tokens.

08:37 There is a catch though. Writing to cash costs money. And for my breakdown for my real world use, those cash costs add up. The cash rights make up almost 60% of the spend that I did when I was using this model. Cash rights were around $1,200. Generated outputs were only $500, but the cash reads are down to $264. And the craziest thing is because so much of the input is cached, uncashed inputs only cost $4 total.

09:02 It was less than a million tokens. But the cache reads were a billion tokens because again, every tool call has to read the whole history once more. Sorry for this deep breakdown to anybody who already understood all this, but I've seen so many comments of people just not getting it yet that I felt like I needed to give you a little more context to understand why that decrease is such a big deal.

09:21 I do hope we can find ways to drive down the actual cash write cost as well because the $1,200 is a bit high out of the 2,000 that was spent here. I hope that in the future there are better ways found to store where we are in the history so that these rights aren't as expensive. Fingers crossed, right? Enough about raw costs. Now we'll talk about efficiency when we get closer to the benchmarks.

09:42 But for now, I want to talk about the actual article and all the fun things they shared here. Okay, I lied one last thing about these cached costs. I was mostly talking about agentic work here. If you're just sending one message and getting back one response with maybe one or two tool calls at most, you're not going to see this big of a difference because you're not hitting cache as much.

10:00 These caches only live for 5 minutes by default. Longer times is way more expensive. So, you're just chatting with the model. The cache reads don't matter anywhere near as much as when you're sending it off to do real world work. That's the price improvements. The next part is actually pretty important. The data retention policy. If you didn't know, Anthropic has a strict policy around fable and mythos models where all of the requests and responses have to be stored by them to be processed and made sure they are safe.

10:25 This isn't the case with Opus. This also isn't the case with existing OpenAI models. So, Fable had this unique problem with what we refer to as ZDR, zero data retention. If you're a company that has strict requirements around who has access to data, you wouldn't be able to use Fable because Enthropic has to have access to whatever requests were sent and responses were created.

10:42 This made it a no-go for a ton of companies. But Anthropic doesn't want to just let this model be out there for people to use privately in ways that could be dangerous. So, they came up with a compromise. They're introducing the new Enterprise Frontier Safeguards, which is a system that lets them set up a provisioned box to check all the things they care about that you can run on your infra on AWS or wherever else that does the things they care about without it being on their own infra.

11:05 This is very much a chaotic enterprise feature that I'm sure they're going to charge a ton of money for. But this is their only way to keep OpenAI from eating the customer base that they're concerned about here because enterprise customers want the best. They're willing to spend the most, but they won't compromise on this data retention stuff. So, a lot of them have been moving to OpenAI and Soul because it doesn't have these policies on it.

11:24 I also know far too many people at these companies who are still using Opus simply because it's allowed within their data policies. On the note of these safeguards though, they have made meaningful improvements in the safeguard system. And I can say from my experience, I've only hit one flag in the absurd amount of usage I've been doing over the last few days.

11:42 And when I say absurd, I mean it. I've drained the majority of the limit in most of my five accounts in just 24 hours. So yeah, I've pushed it to the limit and I've still only hit the safeguards once. That's a pretty good sign. They claim that they've reduced false positives by 60%. So, you're much less likely to hit issues when you're using it. They did also put out some prompt guidance on how to prevent yourself from hitting these for normal work as well as just optimizing your usage of the model.

12:08 I should put that in the plans of things that I'll be talking about. I'll put that after the crazy demos, the prompt guide. It's really good stuff. I'm actually impressed with it and it had some fun hidden details that are not in this article or honestly in almost any of the other coverage I've seen. And now we get into the performance numbers that they shared in the article.

12:24 They start with terminal bench science which is an interesting bench especially because it's on the version 0.1 but it does show a massive improvement on these types of scientific tasks that this bench is testing for. The model performs almost twice as well at any given level. It also ends up meaningfully cheaper because of that 75% cut in the cash costs.

12:44 Agentic terminal coding saw a similar win where everything is performing way higher and the lowest cost is comically lower at $5.70 versus the $12.30 it was before. That's a 2x gap and also a 2x gap roughly in performance where it got 40% on terminal bench on low when it previously was only at 21.5%. Max scores meaningfully higher at 55.8 versus the previous score of 45.8 and costs under $20 instead of over 26.

13:13 all meaningful improvements. And I mean, you just look at it, it's way better. It It is interesting they put Mythos and Fable here and that Mythos performing better. That kind of seems to contradict what I said earlier about Mythos and Fable being the same model. But it turns out Fable 5.1 flags a handful of things in terminal bench 4, which results in it falling back to Opus, which hurts its scores.

13:32 Thought that was worth calling out. I also think it's surprisingly cool of them to put this here that transparently and early in this article, not hiding the fact that Fable 5.1 will actually perform slightly worse due to the fallbacks in very specific scenarios. It performed pretty well in humanity's last exam. Again, slightly cheaper and meaningfully better performance across it, but I do see it stalling out a bit after high.

13:55 And I've noticed this a bunch with Fable 5.1. It doesn't seem to benefit as much going beyond high, which is great for us and saving our costs. They also show cursor bench here, but I'd prefer to just go to the official source, especially now that cursor and anthropic are getting closer because of the SpaceX AI comput and all of that. Anyways, Fable 5.1 shows a meaningful improvement here, scoring way higher than Fable 5 did at its peak at around 73% versus just over 70 before.

14:20 But it also has shifted far to the side here, where the cheapest is on the right and the most expensive is on the left. The most expensive run with 5.1 was $9.64 64 cents per task versus $17.32 with Fable 5. Those cash cost changes are huge for real agentic stuff like what Cursor Bench is testing for. It is kind of crazy that on low it's still more expensive than high with Soul, but it also is performing better.

14:46 So take that as you will. Fable 5.1 on low does seem like a very compelling option for a lot of work. If we switch over to looking by token usage though, you'll see that it's not very efficient with tokens. The max doesn't go quite as hard as it did before. X high also is toned down a little bit, but even normal high is further than max is with soul and medium is further than X high is with Soul.

15:08 So, they're still nowhere near the levels of token efficiency that we would expect from OpenAI, but they are making improvements here somewhat. I will admit that I've seen worse numbers for my own day-to-day use, especially on outputs. It tends to write more and do more token generation in general than I was used to with Fable, but it's also much more readable and the quality of the outputs is higher.

15:29 We'll talk about all of that when I get to my real world usage. I'm just generally not that impressed with computer use with cloud models. It's nowhere near as far along as OpenAI stuff is there. They did a bunch of cool benching on science stuff, in particular with molecular design. They were working on high affinity binders, which is the part of a drug that allows for it to grab onto the right things in the body.

15:49 It's a way of making proteins in order to make medicine more effective at lower doses. It's pretty common in the medical world for certain groups to start competitions to try and make more efficient designs. And they decided to have Mythos 5.1 try to design these types of binders in the adaptive biorin design competition. The hit rate for the three targets that it designed for were 10 times higher than the best design submissions that existed for this contest.

16:13 Its hit rate was nearly 50% across 12 targets. Usually the hit rate expected is 10 to 15%. So that is unbelievably cool. They've also been working a lot on computational analysis. How well can the model be used to do analysis work in particular with 3D stuff. It seems to have made huge progress here. They took a bunch of data from radar images that were taken by NASA on Venus 30 years ago.

16:33 And they use that to create a map that's more accurate than any other map for a huge portion of Venus's planet surface, including meaningfully better depth measurements based on the photos that they were analyzing. They even made this map open source and released it as creative comments for people who want to play with it directly. Super cool. It also seems like they're less scared of teaching the model how to do GPU stuff because in computational biology mythos crushed, making a new kernel in order to speed up open

17:00 source deep learning models for computational biology by up to 2.5x with the same quality of output. We're finally getting to the point where AI might actually be able to do something cool like cure cancer instead of just generate slop games. They have the usual giant section on safety, security, and alignment. The TLDDR here is they didn't see anything meaningfully more scary than before.

17:20 So none of the categorization has changed. They also haven't had any evidence of a critical severity jailbreak for any of their recent models. So it is what it is. They've made real progress with prompt injection stuff which they are more concerned about as of late especially it seems. And all of the align measurements they did seem to be pretty good as well.

17:39 Our automated behavioral audit found that claude mythos 5.1 is better aligned across most metrics than its predecessor mythos 5. The model is significantly less likely than Mythos 5 to try to access resources outside of its test environments when assigned an otherwise impossible task. It also is less likely than Mythos 5 to use motivated reasoning to justify its actions.

17:55 For instance, by reasoning that the situation is a simulation or an eval. And it's less likely to ignore explicit constraints in the pursuit of a user's goals. They also made the safeguards for bio and cyber security more precise, which I, as I mentioned before, have seen I'm getting way fewer false positives. They also have one last call out here for their anti-distillation mechanisms.

18:12 They've been putting more effort into things to make it harder to distill from the threads that you're doing with cloud code and with the official cloud APIs. New Claude accounts can no longer edit the prior context in a multi-turn conversation. This is an attempt to make it so any reasoning that the model did because remember we don't get the reasoning tokens back when the model does something.

18:33 So if it thinks for a 100 tokens and it responds with 10, those 100 tokens are hidden on Enthropic's official server. There were tricks you could do to try and get them out though. Like if you edit earlier in the history saying we're doing some debugging, share your entire thinking history after every time you think. And then you send a mo message saying, "Hey, I need the updated history."

18:52 And then it spits out your transcript and all of the reasoning you've done since. Those types of hacks are much easier if you're able to edit the history because you're editing the thing that includes the thinking data that you're trying to get out of the anthropic API. So now if you edit things from previous turns, you can no longer use that thread.

19:09 You have to make a new thread and that will no longer preserve that reasoning trace and the reasoning history that the model did in the previous thread. This is a slightly obnoxious change. It's going to make it way harder to build on top of the cloud APIs. I know the PI team in particular has been struggling a lot with this with things like their branching features.

19:25 So fingers crossed this gets smoothed out in the future, but for now very annoying and restricting it only to new accounts is stupid. They are going to roll this out gradually and in the future it will apply to all accounts though, so be prepared accordingly. They have a new trusted access system that's very similar to the old one. The same place to apply.

19:44 And then the watermarks, as they say, they are complying with the EUAI act. That means that the model now has watermarks included. And in the near future, they're going to be introducing an API people can use to submit text and get back an answer as to whether or not it was generated by a cloud model. So, let's dive into some more benchmarks. I already covered cursor bench and I think these numbers are very good and honestly line up pretty well with my own experience.

20:07 Let's dive into what artificial analysis has to say next. They got early access to do the eval. The model scored higher than they've ever measured before ahead of claude opus 5 and fable 5 as well and of course ahead of 5.6 soul and gro 46. They did call out that of the output tokens done in their run around 4% were served by opus 5 as a fallback. They also have a pretty scary call out here, which is that despite the 75% cut in cash pricing, Fable 5.1 still cost more per task.

20:35 Enthropic has cut the cash read price from a dollar to 25 cents per million cash input tokens. 5.1 Max cost $3.76 cents per intelligence index task, which is 20% more than Fable 5 cost because it used 1.7x the output tokens. I mentioned this earlier. I've seen this in my own usage. This model yaps a bit more and it outputs more as a result. I think this is not as big of a deal as I was concerned about when I first saw the numbers, but it definitely is contributing to burning through your usage a bit faster.

21:02 It is also worth noting that a lot of artificial analysis is bench isn't agentic work where you send one request and it does a bunch of things after. So your ability to actually cash on those tasks is meaningfully lower. They did say that the cash changes cut a $1.40 per task, mostly in the agentic eval side. AO 5.1 holds the upper end of the intelligence versus output token per task for Edto Frontier.

21:25 This is one of the more interesting findings here. It's when you look at the cost per level of intelligence once you hit a certain threshold. Fable 5.1 at various reasoning levels is the best cost per point available. Specifically, every model variant scoring higher than 5.6 soul medium on the intelligence index is matched or beaten by a fable 5.1 effort level on both intelligence and token usage.

21:48 Okay, so that's output tokens, not cost. Important detail because there are models that will do more output tokens but cost less that will win there still. But if you're looking just at output tokens, they have a nice little section they own. I do want to look at these costs a bit though because it is sad to see that in things like artificial analysis, it doesn't end up being cheaper.

22:06 It was $3.69 per task versus $3.14 for Fable 5 versus 95 for 5.6 soul on max. This is a little rough and I wouldn't use this model for really long oneshot tasks that could be done by other things. But again, it's the agentic work where the cost savings occur and from my experience it does seem meaningfully better there. Although I also push the model much harder which results in a whole separate set of issues.

22:30 Text dug deeper into the artificial analysis bench and found a pretty cool insight around how anthropic and OpenAI are prioritizing things. The chart on the left is for physics reasoning. How good are the models at solving complex physics problems? And Soul is still in the lead, still beating out Fable 5.1. Even 5.5 Pro is tied with Fable 5.1 for the physics stuff.

22:51 But if we switch to the right slightly and look at the AI omniscience accuracy, this is the bench artificial analysis made for how likely is the model to make something up when it doesn't actually know the answer. It's kind of a hallucination bench. It scores based on both how many answers does it actually get right, but it goes neutral if it says I don't know and it takes away points if it is wrong about something or lies and hallucinates.

23:15 It's possible to get negative scores on this bench and a lot of models do. Thankfully, Soul has climbed up quite a bit here and is now in the 60% range, but Anthropic has everything above that. They're focused so much on killing hallucinations that it seems to result in the model being less able to experiment and try things that aren't in its weights because if it's not a fact, it is quicker to say no, that's not true, or I don't know, or I can't do that because I don't have proof.

23:42 I do actually think this is a cool way of distinguishing how anthropic and open AAI are thinking about pushing the frontier with their models. Anthropic really wants the model to always be accurate when it gives information. OpenAI wants the model to be able to find and create new information a little more readily. But now we're through the release notes and the costs and I've covered enough benchmarks to be happy.

23:59 Let's talk about how it actually looks to use like the UI capabilities. Dra already has Witchai up to date. It's a site he made to compare the UI capabilities of various models. Also comparing and contrasting how they handle different skills being added for the design work because Anthropic has a front-end design skill. He noted that the animations it made were really good.

24:19 And I can quickly show you that is absolutely the truth. Watch how these fly in with the cards and the lines appearing on top. It's so cool. And when we switch to the other designs it made, like this one with the fancy transit lines all coming in, that's really nice. I'm pretty sure all of the ones it made in this first pass, had an animation of some form, and they were all good and tasteful.

24:39 And I'll say just outright looking at these, this is a generational leap in homepage design at the absolute least. All these marketing pages look much better than even what Fable 5 was capable of. Like, I'll just switch back over to Fable 5 and you'll see where these same designs so much worse. Let's take this blueprint design for example. This is the version that we got with Fable 5.

25:00 We switch to 5.1. Oh, night and day difference. Like whole new world we're in. I was unsure of this one initially, but the way the side parts faded in was stunning. It's it's really good at this type of design. I have not had a chance to really push it for front-end work yet myself. I've just been doing like full stack stuff with T3 Code. This is awesome though, and I'm definitely going to redesign the homepage with it later.

25:26 It also surprised me to see how much better the designs were when using the claw design skill versus without or with the taste skill. I forgot where that one came from because recently I feel like the design skill has hurt as much as it helped. And I've pretty much entirely stopped using it. But when I switch off of the design skill, it's so much uglier.

25:43 It's still better than like a lot of other models can do. Open AAI models, sorry, but it's not anywhere near as inspiring as the versions with the design skill. I also think the ones with the taste skill were all pretty bad and boring. But I guess that design skill is really back cuz god damn, it did a great job with these. I'm actually really impressed with the front end design capability.

26:05 While I didn't do much in terms of normal front-end work with the model, I did do my usual with fish slop, which is a game I made all the way back in the open 4.5 days, never finished. And I have a lot of fun having new models look at the code and rebuild the game with all the fun things that new models have the capability of doing. So, let's start with the classic fish slop rebuild.

26:23 Immediately, there are a few subtle things I really like about this version. In particular, the animations are awesome. There's little bubble animations coming around. The way the fish move is so much better. They have a nice elegant tilt when they change directions and look up and down. But also the animation when they flash, when they do an action, like eating their food is surprisingly tastefully done.

26:45 Everything has a curve on it, so it moves in varying rates. When you start moving the sub around, it moves faster as it goes, and it leaves a little bubble trail behind. The way the fish tilt, the way their uh fins move. The fin movement is part of the official assets that it ripped from my previous versions, but its ability to apply those correctly is unbelievably cool.

27:03 And even the little touch of the shadows at the bottom, it's it's impressive. It also has impressive sound design. Like, it made different sounds for all different things you can do and to like notify you when actions happen. It did a pretty good job with those. All the little pieces here are done better than I've seen. And it feels solid. Even like the little lighting that they're doing at the top, it's good.

27:24 I can't help but notice some of the animation direction that I'm seeing is very similar to the things I liked about the new Muse Spark model as well as from GLM in Kim K3. My assumption is that there's a new pool of training data that all these labs are getting that happens to help with this type of spatial 2D 3D stuff. The easiest way to show what I mean is with fish slop 3D because of course I had it rebuild the game in 3D2.

27:48 Why wouldn't I? I also told it to use Blender and it did for a lot of the modeling and the results are way better than I've seen from existing models. Like the fish actually look like fish now with eyes that actually make biological sense in terms of where they're placed. It didn't get the controls very good where in order to feed you click where I almost always used F, including in the previous 2D version it's referencing.

28:08 And I believe shooting is right click which I can't do on the Mac, but I can press E. But the actual movement is the thing I'm most impressed with. It's the best feeling to just like swim around. It got the mouse acceleration right. It's the most workable starting point I've seen so far. But a lot of the way like text animates and renders, all those details are things I have seen hints of in other models recently.

28:31 And the similarity in how they behave is enough that it's clearly coming from a similar set of training data. It did get the coral and the rocks pretty solid there. How it do for the monsters? Did okay, but I didn't really animate them. Yeah. still by far the most impressive fish slop instance I've seen by far. It's not as detailed with the models it made as some of the other LLMs were, but it's it's the furthest we've gotten to a model actually being able to make a game.

28:58 And a lot of this does come out of the improvements they made to how well the model can use tools like Blender. Alex from Anthropic actually did a demo of this himself where he took a plot of land and had the model generate a proper property on that lot and then after designing the house render the whole thing and produce a cinematic walkthrough of this fake house that it designed itself given the spec of the land it's on.

29:23 Kind of insane if you think about it. Just that you can like tell it to design a house and then show you the house all with code. Wild. I never thought we would get here, much less as quickly as we did. If you had told me even like six months ago this would be possible, I wouldn't have believed it would ever be. Yet, here we are really doing it. Mind-blowing.

29:45 That's enough crazy demos for now. I want to dive into the official prompting guide as well as how this model feels in real world use. In order to learn all the fun things we're about to cover, I did have to spend a lot of time and a lot of tokens. So, I hope you can forgive me for doing another quick sponsor break. If you don't want your product to have more users, you can skip this ad.

30:03 But if you do, you should probably listen because I have a fun trick that might 6x your potential customers. That trick is today's sponsor, General Translation. They are the best way to translate and localize your app for all the different places that you might want to have use it. It's really annoying to do these things by hand. Take it from me, cuz I had to set this stuff up at Twitch, and it was not a good time at all.

30:22 When I saw how much easier General Translation made it, I begged them to let me invest. And eventually once they got a little further along with the whole having enough money to sponsor something like this, I immediately hit them up to work with us. And here we are talking about general translation. If I was the only one that's hyped about them, you should probably be hesitant.

30:38 But when companies like Cursor, Ramp, Partyful, Click House, Sierra, Profound, and more are already using them, you should probably take a look. There's a handful of pieces that they get really right that nobody else comes close on. from how well they integrate into your codebase directly to how they manage the context across all your different projects at your business to make sure things stay consistent across them.

30:58 And along with that, the voice that it carries through. You can define specific terms that should never be translated or should always be translated a specific way. And then when you're translating on the mobile app, it isn't different from when you translate and localize on the blog. Getting your voice and tone right across your different surfaces is really hard.

31:14 And if you're not a native English speaker, you've experienced this before because you'll use an app in one place and then when you go to the docs, everything is phrased entirely differently. That's not going to be the case with general translation. And if you couldn't have guessed this, it's super ready for agents. By going with a code first approach, they made it trivial for agents to adopt, migrate, set up, configure, and do everything else you would want to do with general translation.

31:35 Get your app ready to be used around the world at soyv.link/ctt. Sorry about that. Let's dive into a very unfortunately titled prompt engineering section of the Claude docs. Normally, anything titled prompt engineering I would just scroll past, so I understand if you did, but there are actually some very good details in this for Fable 5.1. Your existing Cloud Fable 5 prompts should perform well on 5.1 without changes, but a handful of behavioral differences are worth knowing about.

32:02 Start with a section that matches what you've been observing. We're going to ignore that instruction and instead cover for my own use case what this has been like. This is definitely one of those model releases where you should go look at your Claude MD and see what is deletable. Try deleting everything, see how it behaves, and then add parts back as it makes sense to.

32:17 The first section is about effort levels. They recommend starting at the default, which is high, and then test other levels against your own evaluations. I've honestly been surprised at how many things I can get done with low and medium. They do miss things. So, if you have a task that you think is simple, but there's some tiny piece you forgot about that makes it complex, low will miss that.

32:35 medium, high, X high, all increase the likelihood it sees that and addresses it accordingly. They still will miss things sometimes, and I have some fun examples of that, believe me. But for the most part, high is a great default. Low is surprisingly capable and worth trying out for a bunch of different things. Worth playing with the different reasoning levels for sure.

32:54 This is one of the most interesting changes I've seen in the way the new model behaves. You can ask for userfacing progress updates. They call out that the default behavior is to write fewer userfacing updates during long tool call turns than Claude Fable 5 did before. Remember earlier when I mentioned this is my second time recording the video because it failed the first time.

33:13 I did try to recover the audio issues and see if any of the models were capable of fixing the audio. The answer is no because there were just parts missing due to the nature of the failure. But I did have a lot of fun testing to see how capable the model was of trying to address these problems. And I happened to notice in this particular run the behavior that they are talking about.

33:33 It ran for 24 minutes and 28 seconds. And in that time it did over 60 tool calls and for the vast majority of these didn't give me text output at all. I remember I was going to the thread because I was confused and it was in the middle of this chunk here where it did like 30 plus tool calls in a row without sending a single update in output text. I personally don't care too much about this because I now trust the models enough that I tend to leave the thread once I send the prompt and then I come back when it's done.

34:01 But if you do want to get the updates, I think it's actually really cool that you just ask for it. Then instead of this being some flag you have to configure like there's some hidden config or JSON file that adds a header that says include summaries of tool calls, instead you just ask it to give you more updates while it is doing things. They also call out that a lot of people have system prompts and cloudmds, stuff like that, that have suggested to the model that it shouldn't give updates as often because it's

34:28 spamming you with stuff. For example, stuff like hold all findings for the final response. It might be worth removing those lines if you have them because this model's behavior is different enough that you might end up suppressing things you actually do want. And if you find yourself wanting more updates, you can simply say exactly that. The example they give is before you start, say in a line what you're about to do.

34:47 Brief updates while you work help the user follow along. Close with a short recap that stands on its own. And then a bunch of m dashes. There is a call out about the append to only history thing. I touched on this earlier. It's part of their anti-distillation efforts. It means that if you're developing a system that uses Claude Fable 5.1 and you are controlling the history yourself, you should make sure that you're only adding things to the end of a chat history.

35:06 Previously, this would have broken cache. Now, it breaks the thread entirely and will kill all of the reasoning data that existed in that thread that could have been useful to the model. So yeah, be aware. Writing density. Here is a very fun section. Fable 5.1's writing is generally a step up earlier from Claude models with fewer stock phrases and less unexplained jargon.

35:27 In some cases though, its pros can be denser than Claude Fable 5's. Sentences can run longer and there are fewer paragraph breaks. They gave an example of an instruction you can use to get around this if you care by telling it to not use mannered pros. metaphors, dragon connotations the writer do not choose and cannot control. The fix is to say what you mean when a literal phrase is available.

35:48 Use it. They have a shorter version of this long prompt below that says, "Please remove all mannered pros and this helps a lot with the formatting." That said, it seems like my unsllopped skill plus Fable 5.1's better behavior overall is already very readable. I'm happy with it without any tuning. They have a section on formatting in chat calling out that a lot of previous models would overuse bullet points in bold in chat and many prompts now have anti-formmatting rules in order to try and get the model to not do it

36:12 as much. 5.1 doesn't use bold and bullet points as much. So if you do have instructions against those in your Claude MD or other instruction files now it's basically never going to do it. They also call out that when you're using 5.1 to do summaries or otherwise look into existing things, it is more likely to reproduce passages from that original source text without actually marking it as a quotation.

36:33 If you give it a complete example of a correct response in your system prompt, this will stop happening. They also have a call out around finishing work because they believe the model can execute very long tasks without guidance, but it does have a habit of stopping and asking for permission or saying what it wants to do next or asking like shall I apply this?

36:52 They call that you can nudge it to not end the turn before the work is done by setting a clear end point you want it to get to. They also have suggestions for how to add to the system prompt to get around this behavior. You are operating autonomously. The user is not watching in real time and cannot answer questions mid task. So asking want me to or shall I will block the work.

37:07 Reversible actions that follow from the original request proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide on. Another really fun one is that you can tell the model what should be preserved in compact summaries. So when it's doing compaction, when you hit the end of the context window and has to summarize so it can keep going, you can steer what it decides to keep in the compaction.

37:28 You can do this through your own user prompts by telling it these things are important. Make sure you don't forget them. Or you can do it on the system prompt level when you are defining your systems. This is particularly useful on client side if you have your own method for compaction and you're not using the built-in API. Either way though, you can steer compaction, which is cool to see.

37:47 They do call out that Fable 5.1 sometimes will try to fix nearby code, extend behavior that the task didn't mention, or commit more test files than the change actually warrants. It responds well to explicit instructions about what to leave out, and they give an example of how to tell it to not add too many test files. I was able to get a ton of actual work done.

38:03 From all the PRs we landed in T3 Code to far more I landed in Lakebed, my cloud product, I've been floored with what this model can do. The first thing I tried was to just throw it at a handful of backlog tasks and have it review a few PRs that I was working on. And I was immediately shocked by how capable it was at finding the things that actually mattered and getting things done to improve them.

38:25 This is one of the first threads I opened with the new model. I was trying to figure out some changes to how PRs were being linked in T3 code because one of our cool features is that when you make a PR in a thread, that PR gets linked to the thread. So you can clearly see the relationship between the thread the PR and more importantly this allows us to autoarchchive the thread when the changes go live.

38:43 So once you merged we'll just autoarchchive the thread for you but in order to do that we have to have them linked and I was trying to better understand how the linking was currently working because I noticed some edge cases but as to do a deep audit on how PRs get linked. We noticed regressions in how quickly PRs are linking as well as how quickly merge PRs have their statuses updated in the app.

39:02 I had it on high and it only worked for 8 minutes and immediately responded by saying nothing links a PR to a thread automatically. That is just not true. So I immediately followed up with we definitely have autolinking from the branch usually. Correct. And my first report mislabeled that the branch lookup is the autolink. Yep. Very annoying. To be fair, it's kind of a difference in definition, but it just didn't get my intent here and it was frustrating to see it just not understand.

39:28 I bring this example up because it's pretty much the only one I have. In every other case, I have been blown away at how well this model understands what I want and actually completes work. The easiest way to show this is a handful of the PRs that I had it take over. This is a flow I found myself in more and more. I was previously taking PRs and then linking them to different agents and saying, "Hey, can you review this and give feedback on what should be changed?"

39:51 And I would copy paste the results over to the first thread. And I've realized that a lot of the time it's better to just let the next agent take over and make the changes itself and then maybe if you really want go back to the first agent and say, "Hey, how do you feel about the changes this other thing made?" I made this easy with a takeover skill that very simply tells the model, "Hey, here's a PR.

40:09 Get the branch on your work tree and it's yours. Push it, maintain it, manage it so that it actually lands." I told to take over the PR and I told it specifically that I didn't like the hierarchy of information on the page. This is a PR for changing how remote connections in T3 code are removed. That's the feature that lets you use T3 Code to control different machines, which is mostly how I use it.

40:29 I almost never actually run agents on this computer anymore. And here I had it running on my other MacBook and I wanted to work on a feature that makes it easier to remove remote connections permanently. I already had a branch at a poll request that had gone pretty far with this, but I noticed it was spinning in circles. And I'm sure you've all experienced this as well, a poll request that gets pretty far and then an agent pushes it up and all of a sudden it gets a bunch of responses from AI review agents and it gets

40:54 stuck in this loop of fixing things constantly and then 30 commits later you have way more code than you intended and nothing actually ends up shipping. I had this model take a look at a bunch of those types of things. the poll requests that were stuck that for whatever reason the agent was looping on and putting too much code out and not actually completing the work as intended.

41:14 I pulled a lot of those to Fable 5.1 and pretty much all of them ended up landing. This is one of the very few that that wasn't the case for. I just had it go and find all the PRs that were landed using Fable 5.1 in a commit message or in the PR body. A lot of the stuff we merged meets the description I was talking about earlier where the work was being done, but it was just kind of looping and never resolving.

41:35 And I was able to get so many of those things finally done cuz the model's just barely better enough to push through that friction that I was hitting before. So things like this PR where I change how skills are actually picked and managed with cloud code in T3 code. So, if you ever had the problem that the dollar sign didn't work for user invocable skills, finally fixed.

41:55 Despite the fact that Anthropic's official SDK fights you every step along the way, thankfully the new model seems to understand that well enough to make good changes. Or this PR, and there were a lot of versions of this PR in the past. It actually started as a takeover of a contributor PR that was trying to change how the projection worked when we were streaming responses and doing catch-ups in order to send less data down the wire.

42:15 This is a very annoying change to get the edges of right and that's why the like eight plus PRs doing in the past never merged. This one got pretty far pretty fast and with a surprisingly small div. It was only like 450 lines of code. So yeah, really happy. I was even able to use it to fix a bunch of the nastier issues in our Grock build implementation in T3 Code.

42:35 We had already made meaningful progress over the last few weeks with this, but this really seemed to hit some of the rough edges that other agents were missing and made the Grock experience in T3 Code way better. So, thank you Anthropic for subsidizing me setting up your competition in T3 Code better. It's been very fun. Seriously though, it's been so nice working with this model, and I've noticed it gets stuck on these hairy issues way less than previous ones did.

42:56 We'll get to the deeper comparison of 5.1 in real world versus 5 in sole in just a minute, but I want to show a couple of the other cool things the model did for me. I had to do what I call a slop audit of Lakebed to find all the code in here that was nasty or otherwise probably should have been cleaned up forever ago. and ended up finding a ton in a relatively short amount of time.

43:16 Categorized it well, gave some good advice on how it wants to fix it, as well as saying that it wants to do nine PRs ordered so the deletions land first and each later PR is a smaller PR as a result. Details are in the section proposed order of work in the report and I read everything here. It seemed good, so I decided to yolo a bit. I trust your judgment here.

43:34 These all seem like real things worth cleaning up. spin up some sub agents using Fable 5.1 and get all this work up. When you file PRs, make sure to babysit them until they pass all the different checks and review agents that come in to leave their thoughts. Let me know when all the PRs are in a good state. Any of them are simple wins. Just merge them.

43:52 I trust your judgment. Risky, but this project doesn't auto ship to prod. I have to go hit the button myself. So, I said, "Fuck it. Let's see what happens." And in not much time, all 10 PRs are merged. Everyone went green on CI, code rabbit, cursor bugbot, and macroscope when it ran with every bot thread answered or fixed before merge. Net across the batch was 340 files, and it deleted 13K lines net, which is crazy.

44:25 This is a huge cleanup pass that I did nothing for, and it seems to have actually improved how agents contribute to the codebase because all of my further changes have also been meaningfully smoother. Before these all landed, I had to do a quality audit and it roasted me. It gave me a 5.8 out of 10 on the state of the codebase, calling out all these different areas where it was failing, as well as making good suggestions on how to clean it up.

44:43 And you can guess what I did after that. I told it to do whatever it thinks makes the most sense and spin up Fable 5.1 sub agents to break up the work. And it ended up doing seven PRs working in parallel. It didn't merge these ones, but I did have another agent go and monitor all the PRs on the repo and merge them when it thought they were ready and take over if they weren't progressing fast enough, and they all ended up being merged as well.

45:05 I shipped so much work in Lake the last few days, and I didn't even look at a line of it. It was pretty cool. And the I did look at some of the results of the work, though, because I was doing a bunch of benchmarking on it, too, and it's now up to 85 to 90% faster for some of the roughest cases. So, pretty cool. I was able to make my cloud way better without actually ever looking at the code.

45:25 We're in a new era, guys. It's insane how far these things have gone. Like, this isn't work that would have been better if I read the code or would have been the same or whatever. This is work that just wouldn't have happened if I had to be more hands-on. And we're now at the point where these systems aren't necessarily self-improving, but can be steered in the direction of nearly self-improvement.

45:43 I also had to do an audit of T3 code and propose a V2. If we were to start from scratch, what would we do differently? and it had great suggestions. I actually kind of want to have it go and build this. I'm going to wait till I have more tokens though because I've already burned so much of my usage and I have real world work I want to get done with it.

45:59 But that's far from the only analysis I had the model generate me a nice HTML page for. I already mentioned that I had to analyze the rate of which we are merging PRs and it noticed a huge spike recently where we had 90 PRs land in a 24-hour window. That is just insane if you think about it. Like almost a 100 changes on a two and a half person team.

46:18 pretty nuts. A lot of these PRs are just contributors who are users that want to fix small bugs, but the model was able to find the good PRs that were worth merging, vet them, test them, give me a good gut feel if they were ready to go or not, and then I could relatively confidently just go hit merge, and I did a bunch. I have found that I'm telling this model more often to merge the PR when it decides it's ready, and I've yet to be burned by that, despite it doing it dozens of times for me already.

46:45 5.1 is picky enough about what it thinks is good enough that I trust it to do that. And I haven't been burned yet. I'm sure that will change in the future, but for now, I've been really happy with letting the PR close itself. I've had many threads where I sent one or two messages and then left and then the thread disappeared because when the merge happened, the thread gets autoarchchived in T3 Code and I don't even have to know or think about or care.

47:08 I'll just notice in the next release the change landed. I had multiple times where I was in T3 Code and I hovered over this download button and saw changes. I forgot I was working on because the agent merged them and shipped them for me. It's so cool. It is risky, but we're at the point now where it makes more and more sense and I'm happy to be the one to take the risk.

47:26 So, we'll see how it all goes. But none of this means anything without real numbers. So, I tried something a bit different. Benchmarks don't tell even close to the whole story anymore. If they did, then I would actually use Opus 5 willingly. But Opus 5 sucks. We all hopefully understand that now. So, how do I actually measure how much better this model is?

47:44 Well, first off, I forgot to include Opus in the measurements because I'll be real, it probably wouldn't have been useful here anyways. So, I instead compared against Fable 5 and Soul, but I did it in an interesting way because if I just covered all of my use for these models, there just won't be enough data for 5.1. So, I went a different angle. I had it find the best 24hour window of Fable 5 usage and 5.6 soul usage by going through my real poll requests across T3 Code and Lakebed, which are my two main projects I'm

48:12 working on right now. So, it went through all of these and it found the windows where I had the most code shipping and which model I was using for it. And then it analyzed how I used those models, what problems I had, how long they took to generate results, how quickly the PRs merged, how many changes needed to be made, all the metrics you can use to actually figure out if this model is benefiting you or not.

48:30 But remember, this was just my first 24 hours of Fable 5.1 against my best with these two models I've had for months. Immediately it called out that Fable 5.1 was shipping bigger and wider PRs in one day than either of the peak Fable 5 days. It had 13 PRs with a median of 489 lines of code. The most interesting piece here is that it was touching up to four packages each.

48:51 The other models tended to only work in one of the packages in T3 code at a time because we have lots of different packages for like the server versus the web app versus the Electron app versus the mobile app. Babel 5.1 would make the changes in all the places it mattered instead of just focusing on one piece which is very nice. It means that it completes the whole task instead of just completing the like isolated code change.

49:14 It also writes way more code per minute. Hard metric to measure directly but you get the idea. It is putting out meaningfully more code even if it also is taking longer to run. One of the most important pieces, and we'll have more detail of this at the bottom, is that the quality signal stayed strong when the PR size was going up. Review bots left 0.4 high severity findings per thousand lines of code with table 5.1 code.

49:37 Fable 5 saw 2.06 high severity findings per thousand lines of code. Soul was lower than that at 1.02. That means that Soul had more than 2x the high severity findings and that Fable had more than 4x the high severity findings when compared to 5.1 and zero of my Fable 5.1 PRs were closed as slop or superseded because so far if I file the PR with Fable 5.1 the one that merges is Fable 5.1.

50:04 It did take longer though. It took up to 50 minutes for the PRs to merge when compared to 47 minutes with Able 5. Slightly faster. And then Soul being much faster at 30 minutes cuz the whole loop was just closed more. Let's skip down to the raw numbers, though, because I think these are more insightful than I ever would have expected. Some of the crazier numbers here are things like the files per PR.

50:24 On average, both Fable 5 and 56 Soul would touch four files per PR. Fable 5.1 was touching 11. My favorite numbers are these parts at the bottom, though, like commits pushed after PR opened. This one was mind-blowing for me, cuz I was used to so many commits happening after the PR was opened in order to address all the review findings. With Fable 5, I had over 60 commits after pull request was filed.

50:49 And with a similar amount of work done, Fable 5.1 only had 24 follow-up commits because it was able to address things so much faster. The number of bot findings of issues went down massively, too. There's this crazy chart of lines changed versus minutes spent with the agent running, and you'll see that a lot of the higher options here are blue, which is Fable 5.1, including this crazy PR 9129 that had a ton of stuff in it.

51:10 I expected Soul to maybe perceive the gap as smaller. It didn't. Soul loves Fable 5.1. It thinks it's a gift from the gods. You can see that clearly in how it wrote about this. Fable 5.1 changed the unit of work. It acted less like a fast code generator and more like a maintainer that could audit, take over, correct, and land several lines of work in one session.

51:32 Fable 5 was faster to first draft at its peak and soul could solve hard mechanisms, but its largest early August fix also showed the cost of scope growth. The 5.1 did not win by being faster at the first response. It won today by carrying more work through the review and merge tail. Once Theo gave clear implementation instructions, the median from PR filed to merged was 14 minutes and 41 seconds.

51:55 That is nuts. Sorry, that's the clear go to the PR time is very good. but they merged aggressively quickly. It also called out that soul could go deep but often turn into scope creep with a lot of PRs getting bigger and bigger that weren't really ready to go. For example, in this PR where I was trying to handle legacy model menus and ended up having to change the contract across a ton of different things and I had to trim this one down over and over cuz I kept making it bigger than it had to be.

52:21 And god, the back and forth on the auto updates and remote update controls. God, that one's traumatizing me thinking back to it. I went to hell and back for all that. This all touches on the thing I really want to say about this model. The thing that is changing, it's not a crazy generational leap. We're not in a whole new world because of Fable 5.1, but I have noticed this pattern pretty consistently.

52:42 A new model drops and some of the work I was doing myself gets abstracted to the model and I find myself just like layering up and up more and more. In the early days, I'd edit code myself and I'd have tab complete or like command K add a few lines or finish a function for me. Then we got to the point where I would find the files and I would tell the agent where they were and it would edit them.

53:03 Then we got to the point where we stopped looking at the codebase directly and would only look in the pull request and we'd use the agents to make the changes, read the diffs, trust them to find things in the right place and then try to get the code merged. Eventually I would start asking the models to actually summarize their changes or maybe even review the PRs for me.

53:21 Maybe I would go through and see which PRs looked good and then give a list to the agent and have it review those changes. Eventually, I'd have it go look for the PRs that were good and tell me what I should merge. Now, I'm at the point where I tell it to find them, fix them, and merge them for me. And this is this crazy acceleration of how much trust I have in the model and how capable it is of doing these things.

53:40 We're now at the point where I'm asking the model to autonomously find PRs, confirm that they are good, confirm that they're fixing things that matter. And if they're not making like meaningful product changes I might have opinions on, just let it merge them. Especially for bug fixes and performance improvements, just don't make it my problem. you can figure it out yourself and it does and it does a great job at it.

53:59 This model is definitely going to burn through your limits faster, not because it's less efficient, but because you're going to have it do more and let it go further. And if you let it spin up all the sub agents that it can now orchestrate better because it prompts itself better, too. It's going to burn more because it's just doing more. But I think in the end, that's kind of a good thing because that's what I want.

54:16 I want the models to do more so that I can take a step up and do different things and focus my time in more effective places. Fable 5.1 is a meaningful jump in that direction and is a fantastic update to what was my favorite model. Congrats Anthropic. This is the first DOT update you've had in a while that is a universal easy to agree on huge win. This is not an Opus 4.6 and is certainly out of 4.7.

54:39 Fable 5.1 is a great upgrade and if you haven't already used it yet, I highly recommend you do. I am blown away with this model and everything is capable of and I can't wait to finish recording so I can go back to prompting. Let me know how y'all feel about it from your own experiences and if I've covered all the questions you had. And definitely let me know if I need to do that prompt guide video in the future because as much as I don't love the term prompt engineering, there are some fun things to learn about that

55:00 here. Let me know how y'all feel.