I Finally Get Fable 5  🔗 **Source:** [I Finally Get Fable 5](https://www.youtube.com/watch?v=8GRmLR__OGQ) > [!note]+ Document Notes > --- > tags: [ai-coding-agents, claude-code, model-routing, agentic-workflows, developer-productivity] > author: Theo (t3.gg) > source: YouTube — Theo (t3.gg) > reference: https://www.youtube.com/watch?v=8GRmLR__OGQ > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > --- > # 🏷️ Title: I finally get Fable 5 > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [Video: I finally get Fable 5](https://www.youtube.com/watch?v=8GRmLR__OGQ) > - [Theo's companion "misconceptions" tweet/source](https://x.com/theo/status/2072898342921842703) > - [Clerk (sponsor)](https://soydev.link/clerk) > - [Infinite Red (sponsor)](https://soydev.link/infinite) > - [t3.gg](https://t3.gg) > ## 📝 Summary > - Theo (t3.gg) walks through how he actually works with Anthropic's Fable 5 model inside Claude Code, arguing it's not "a better Opus" but a categorical shift in how far an agent can run end-to-end. > - Why it matters: the value isn't raw intelligence, it's autonomy across implementation, testing, verification, sub-agents, and multi-agent workflows. Reusing old Opus-era prompts wastes the model. > - Key stakeholders: solo/lead developers on agentic Claude Code workflows, teams weighing model-routing costs, and anyone building on the T3 stack (Lakebed, T3 Code). > - Risks and tradeoffs: cost blowups from wrong reasoning settings, over-reasoning on X-high/Max, blind-merging agent code, and staging environments getting polluted by unsupervised agents. > - Bottom line: keep reasoning on high, route expensive token work to cheaper models (GPT-5.5 via Codex CLR), let Fable orchestrate, gate production behind a human, and verify hard. He shipped a month of backlog in ~3 days for ~$150. > ## 📖 Main Content > - Core claim: Fable 5 changes what's possible not by being smarter per step, but by running much *further* — end-to-end implementation, testing, verifying, and decomposing tasks to sub-agents. Old Opus prompts underuse it. > - Cost discipline comes first. Theo deliberately front-loads "min-maxing" so viewers don't bankrupt themselves adopting the workflow. His full 5.5-hour run cost ~$150 across all models, with neither subscription (Claude Code + Codex) breaking 40% weekly usage. > - Reasoning-effort thesis (contested/opinion): stay on low–high; X-high, Max, and "Ultra Code" over-reason, produce bloated changes, and cost far more. He claims reasoning effort applies *per tool call / per step*, not to how long the agent can run — so Max thinks more per step, not more steps. He notes Ultra Code uses "high" under the hood. > - Model routing: he teaches Claude Code (Fable) to "shell out" to GPT-5.5 via the Codex CLI for token-heavy or computer-use work (log digging, giant PDFs, screenshots, browser/simulator automation), because Codex's usage allotment is very generous and its computer use beats Anthropic's right now. > - He encodes a personal model rubric in his global claude.md — scoring cost, intelligence, and taste (1–10) for GPT-5.5, Sonnet 5, Opus 48, and Fable — plus a glossary defining "intelligence" (hardest problem handled unsupervised) and "taste" (UI/UX, code quality, API design, copy). Defaults are framed as overridable: "judge the output, not the price tag." > - Sub-agents vs workflows: sub-agents spawn parallel agents; workflows are programmatic JS scripts that fan out, stage, and verify deterministically. Fable now invents review archetypes (adversarial, exploratory) itself, making hand-built agent taxonomies obsolete. > - The showcase: a simple prompt ("investigate and review the open PRs for Lakebed") spawned a workflow, 48 agents (16 investigators + a Fable/Opus judge panel), and produced a triage. He then set a "goal" granting merge/rebase/worktree permissions; it ran ~5 hours and landed a month of backlog. > - Safety framing: merging straight to main is only safe because merges deploy to *staging*, production stays human-gated, and he stress-tested afterward with more agents — burning more tokens verifying than producing. Uncertainties: he's candid the reasoning-effort and over-reasoning claims are his gut feel, and that some agent outputs were wrong (the phantom "drawer"). > ### 🗒️ Notes > *Timestamps below are estimated from transcript position — the source captions carried no time anchors, so treat them as approximate jump points.* > #### ⏱️ [00:00](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=0s) Cold open: Fable one-shot me > - Says Fable "one-shot" him; loved it more each day, then lost access and struggled with Opus 48 and GPT-5.5. > - On its return: "It's better than I remembered." First day back, more work done than the prior month. > - Thesis lands: "this model isn't a better opus." > #### ⏱️ [02:11](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=131s) Watch the misconceptions video first > - Points to a companion video answering "nerfed / too expensive" complaints from Twitter before this one. > #### ⏱️ [02:46](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=166s) What this video covers: the how, not just the what > - Focus is the prompts, systems, claude.md changes, and skills — plus the mindset shift. "Fable isn't just an improvement." > #### ⏱️ [03:37](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=217s) Sponsor: Clerk (auth + billing) > - Auth and billing are agent "kryptonite"; Clerk attaches payment to the user, mirrors staging/prod without Stripe key duplication. > #### ⏱️ [06:07](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=367s) A month of Lakebed PRs shipped in 2-3 days > - Shows ~11-12 PRs merged from one thread; he's still Lakebed's only contributor. Had 20-30 stale PRs at 50-80% done that he didn't trust. > #### ⏱️ [08:30](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=510s) Min-maxing: cost reduction before the workflow > - Deliberately teaches cost control first; the full run's true cost would've been thousands but was ~$150 across all models. > #### ⏱️ [09:45](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=585s) Never push reasoning past high > - "Do not use Fable on higherthan high reasoning efforts." X-high/Max/Ultra Code over-reason and overspend. > - "High is way smarter." Claim: reasoning effort is per step, not run length; Max thinks more per step, not more steps. > - Ultra Code uses "high" under the hood. > #### ⏱️ [12:51](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=771s) Teaching Claude Code to call Codex > - Route token-heavy and computer-use tasks to GPT-5.5 via the Codex CLI; OpenAI's computer use "slaughters" Anthropic's right now. > #### ⏱️ [14:38](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=878s) Usage stayed under 40% for the week > - ~1 hour of setup; Codex sub at ~15%, Claude Code sub at 40% at hardest push. Codex allotment ≈ "$14 grand of inference a month." > #### ⏱️ [16:03](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=963s) Global claude.md: shell out to GPT-5.5 > - Key line in claude.md: if computer use helps complete/verify work, "shell out to GPT55 with codecs." The word "shell out" tells the model it can call GPT-5.5 via bash. > #### ⏱️ [17:30](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=1050s) Sub agents vs workflows > - Sub-agents = parallel spawned agents; workflows = programmatic JS staging that fans out and verifies. Used a workflow to triage stale PRs. > - Fable invents review archetypes itself, killing hand-built agent taxonomies. > #### ⏱️ [19:39](https://www.youtube.com/watch?v=8GRmLR__OGQ&t=1179s) Ranking models: cost, intelligence, taste > - Model's self-awareness of its own capabilities is weak (trained before 5.5 / Opus 48). So he supplies the gut-feel routing. > - GPT-5.5: cost cheap, intelligence high, taste low ("writes TypeScript like a P Saying Fable 5 has oneshot me would be acriminal understatement. I reallyappreciated the model the first day Itried it, but over the next two Istarted to genuinely love it and wasblown away with what it was capable of. And then I got taken from us and Istruggled. I did my best to make decentwork come out of Opus 48 and GPD55, butit just wasn't the same. And I foundmyself just kind of running in circleswaiting. And then the model came backand I honestly can't believe I'm sayingthis. It's better than I remembered. There are a lot of things that aren'tperfect about it. And there are ways towork around some of them, but God damn,when I'm actually trying to use thismodel for my day-to-day work, it blowsme away. In the first day of having itback, I got more work done than I had inthe month prior. It just wasincredible to watch as the model crankedthrough all of these things that I'vebeen planning and thinking about andStarting but not finishing. And it justshipped. It fixed a bunch of code. Itmerged a bunch of stuff. And it got mepumped for not just the work I wasdoing, but for the future of how we'llbe doing work. It is incredible what youcan do with this model, but there's onebig catch. If you treat this model theway you did previous ones, you're notgoing to see the benefits. To put itsimply, this model isn't a better opus. If you take prompts that worked for Opusand you give them to Fable, it's notgoing to be much better. The differencein this model isn't just how muchsmarter it is or how much better thecode is, it's how much further it cango. Not just on like harder code tasks,but on end-to-end implementations,testing, verifying, and all the otherpieces you need to write great software,especially once it has to break tasks upinto smaller pieces and hand those offto sub agents. This model doesincredible stuff, and I've been doing myBest to get as much as possible out ofit during this limited window where we have it in the subs, although it iscoming back soon. And with that, I dowant to make sure you guys know Ialready filmed a video today about a lotof this, specifically about all themisconceptions people have with themodel. They’re frustrating me becausethis model is great. So, if you’reconfused because you read Twitter andsaw all these people saying the model’snerfed, it’s terrible, it’s way tooexpensive, all that type of stuff, gowatch that video first. It’ll help clearthe air. It’s not a necessary firstview, but it will help a decent bit. This video is different, though. This isthe video where I show you all thethings I’ve been doing with Fable, allthe awesome stuff I’ve been able toship, but most importantly, the waysthat I’ve been doing it, the promptsI’ve been sending, the systems I havebuilt, the changes I’ve made to myClaude MDs, to my skills, and all theseother things, and how I've mostimportantly changed the way my brainworks when working with models in orderto maximize what I can get out of thisnew era. And this really is a new era. Fable isn't just an improvement. It is afundamental change in what these modelsare capable of, enough that it makes itsound like I'm reading a script when I'mnot. This is all off top. Like thismodel's screwing with me if you can'ttell. I've effectively been oneshot. This is my psychosis moment and I can'twait to share it all with you. Butsomeone's going to have to pay for mytherapy, and it'll probably come from thebudget thanks to today's sponsor. Myagents get a lot right when I'mbuilding. It's honestly reallyimpressive. But there's a few thingsthey always get wrong, no matter how goodthe tooling gets. The two that hurt methe most are off and billing. They'rejust like the kryptonite of AI agents. They could never get it right,especially the billing side and tryingto get that linked to the user in a waythat makes sense. The amount of weirdrandom transient billing failures we getacross services is so annoying. Well, itwas until I started using today'ssponsor more, Clerk, because not only dothey have the best off platform that isthe easiest to integrate acrosseverything, be it web, mobile, oranything else. We're actually workingwith them right now in order to get theT3 code electron desktop app off for ournew remote stuff that I'm really excited about. What's way more exciting to me isthe subscription platform that's nowbuilt in. Having tried pretty mucheverything like this, I can confidentlysay Clerk is the easiest and has thebest abstraction. Instead of all theobnoxious effort trying to set up astaging and production environment forStripe with their own separate keys,their own separate product IDs, theirOwn separate everything that you nowhave to mirror in your real databasejust to make sure it works. You just getto configure it in the clerk dashboard. Once a user pays, that paymentinformation is attached to the useritself where it belongs. I don't carewhat subscriptions exist. I care if thisuser is subscribed. And Clerk gets thatright. They have custom components andhelpers where you can check what state auser's in and what plan they have tomake it trivial to render the right UIor go down the right path. And it endsup costing the exact same as going toStripe directly, which is unbelievable. Any one of these pieces would be worthmoving to clerk for, especially havingthe user profile component with all thebilling info built in. The amount oftime Mark loses dealing with billingdisputes and email is obnoxious. Andthis would have saved us so much of thattrouble. Fun fact, if you Google searchStripe recommendations, my repo is theFirst one to come up. This is amulti-page guide on how to try and getStripe to work properly in your apps. But at this point, when people ask mehow to get it right, I usually justpoint them at Clerk. Set up Both andpayments right at soy. Clerk. The amountof work I've done with this model in thelast few days is still just kind ofscrewing with me, especially because Iwas at a conference for half of it.Shout out to the T3 Code mobile app, bythe way. I was doing a ton of work on myphone while also at this event and itshows I got a ton done like anunbelievable amount done. This is theclosed PRs in Lakebed where reminder I'mstill the only contributor. I have notforced this project onto my team yet.They don't deserve the slop. It'scleaning up fast. Thank you, Fable. Butall of these PRs were done in literallytwo to three days. The sheer volume ofwork here, especially if you're lookingat the ones that actually merged. LikeThis pile here, it's like I think 11 or12 PRs that merged all not just in oneday, but from one thread. And I keep going, and I'm on page two.We're still in things from 2 days ago.Then there's a 4 days ago one, 5 daysago, then a huge jump to 2 weeks becauseI was just not really feeling it. When I lost access to this model, I tried torun around in circles and get the beststuff I could out of Opus, but it wasn’tat the bar I needed to ship.And what ended up happening is in this particularproject, Lakebed, I had a bunch of thesePR stack up of work that was like 50 to80% complete, but I didn’t like the SDKchanges it made. I didn’t really have confidence in the implementation,and cleaning it up would just take too long.And the result was that I kept havingideas.I kept making PRs, and they keptsitting there doing nothing.I probably had 20 or 30 PRs just sitting in thisrepo, not moving, and the project hasDon't like that. I really want to shipLakebed. I've talked about what Lake Bedis in some other videos. I don't want tobog you down with the details until Iactually have it launched. I haven'tearned the right to market this yet. Iwant it done. So, we'll do that later,but I want to talk about the workflows that got me this far in the project, aswell as some of the cool things I'mdoing on other projects that I've beenworking on. I'm going to start in aweird place here, but I promise it willhelp. I'm going to start with minmaxingtips and like cost reduction things inorder to make sure that when you adoptthis workflow, you don't immediatelybankrupt yourself because if you were togo to the second half of this video andskip straight to that part, it will beexpensive. That's what I did in thefirst 3 days we had Fable, and it was expensive. I didn't pay cash. I bouncedbetween two subs, but I looked at howmuch it would have cost and it was inThe thousands of dollars. And all thework I just shared here, all of the PRsthat were closed, fixed, updated,recreated, merged, I want you to justthink in your head and guess how muchyou would expect that to cost with Fablerunning in a loop for 5 and 1/2 hoursgetting all that work done. You'reprobably thinking in the thousands, cuzthat's what I would have expected. Butit was only around 150 bucks. Not justFable, but all of the other models I had Fable calling throughout. Wait, butFable's so smart. Why are you usingother models, Theo? And here's where thetips start. I mentioned in my previousvideo that I was teaching Fable how touse codecs and I'm going to show youhow. But first, I just want to make sureI emphasize this point. I talked aboutit before. Do not use Fable on higherthan high reasoning efforts. The X highand max options are dangerous and ultracode causes it to use workflows when itshouldn't. Those three options, prettyMuch everything to the right of high. These are dangerous. They look soenticing, though. The fancy gradient whenyou hop over it, like it's a slot machine,begging you to put another coin in. I'mgoing to beg you not to fall for it.High is way smarter. I know that soundslike I just made a mistake, but I didn't. X high and max end up second-guessingthemselves too much because they run inloops. They’ll just go longer and longerwith their reasoning, and the result isoften worse code that is way overdone,that has way too many changes for thesimple thing you're asking for, at a costthat is absurdly higher than it shouldhave been. Low, medium, and high mightnot be as efficient as GBD 5.5, butthey are capable of things that 55 isjust not even close to capable of. Andthey can still run for really longtimes. The reasoning effort does notdetermine how long it can work for,which a lot of people seem to think thatmax can solve harder problems and work. Longer than high can. But the reasoningeffort only applies per tool call andper change. So if you have work thattakes 500 steps, Max isn't going to domore steps necessarily. It's going tothink more per step, and most of thesteps don't require that much thought. The problem is that X high and Max, sincethey are thinking too much per step,they're going to overthink the thing, andthey do, and they do aggressively, as doesSet 5, as arguably Opus 48 does as well,although not quite as bad. I amadmittedly a little scared that thisfive-family of models from Anthropicmight have a big problem withoverreasoning with these two options. SoHonestly, just keep it on low throughhigh. I personally leave it on high, anddon't think about it. I'm only thinkingabout it now because I saw peoplecomplaining about their bills, and Italked to them, and every single personcomplaining about blasting through theirusage too fast was on X high max orUltra Code. By the way, you might nothave known this. Ultra Code uses highunder the hood. It just spins up a tonmore of them. So, even Anthropic agreeshigh is the best bang for your buck. Trust me, just just go with that. It's adefault for a reason. It's their defaultin other things for a reason. It's theright level. Now that that's out of theway and I've probably cut your bill byhalf or more just by making that onechange, let's talk about the rest. Specifically, all the fun things withhow I taught Claude Code to use codecs.I talked about this a good bit in theother video, so I'll do a brief recapbefore showing the implementation. TheTLDR here is that the usage you get forthe codec sub is insanely generous. Sothings that it makes sense to use foryou probably should. One of those thingsis computer use, which OpenAI just kindof slaughters Anthropic at right now.The Codeex desktop app has a ton of coolhacks that let it use your Mac in full. Not just like opening up a tab in Chromeand poorly navigating it. More likesetting up Xcode for you or navigatingcomplex applications and pulling databetween different things and sending youa video when it's done. The computer usein codeex is insane. So teaching cloudcode how to call that is awesome. Butthe biggest thing is the tasks thatrequire a lot of token usage. Thingslike digging through logs, things likereading giant PDFs and implementationspecs, things like doing computer useand looking at hundreds of screenshotsover an hour as it tries to navigateyour machine. Teaching Fable how todesignate those tasks and route to theright models didn’t take too much time. I spent maybe an hour on this and it hasmassively cut my costs. All those PRs Iwas showing, as I said, my use acrossall the models is like $150ish dollars,but that all fit easily in my two subs,my Cloud Code sub and my codec sub. Neither broke 40% usage. In fact, myCodec sub was at like 15% or so for thewhole week. And my cloud code subadmittedly reset on like I think it wasFriday evening, and we got the model backon, uh, was it Thursday or Wednesday? Yeah, I think it was Wednesday. We gotit back, and my reset was Thursday night,and I got to 40% on my weekly whilepushing it my hardest. Their usage istotally reasonable as long as you takeadvantage of these tips. Most of my workwas in my global claude.md. I spent agood bit of time in here. I already madesome changes here about specificbehaviors I want, like which tech shouldit use when initializing a new app. Honestly, I'm going to change a lot ofthis to, like, bed soon. The style of codeI like, general preferences, just likethe normal stuff you probably have or atleast played with, putting in your claude MD. I could do a very long video abouthow to influence your agents to have thesame psychosis as you. It's a thing Ithink a lot about. I haven't gone quiteAs hard in my goal claim did on that yet,but I did go a lot harder in this filelast week because again, I wanted to tryand teach it how to use these types ofthings. It all starts here. If computeruse is helpful for completing orverifying work, shell out to GPT55 withcodecs for it. Specifically, the wordsshell out here are important becausewhat I'm telling the model is that itcan call GBD55 via the shell via bashbecause it has the ability to use bash. It's using cloud code. Of course, itdoes. And then I give more hints. I haveanother set of skills that we'll get toin a bit, but I think reading throughhere is the best starting point. I havea section in my cloudmd for picking theright models for workflows and subagents. If you're not familiar with thedifference here, sub agents are the ideathat the agent can call a tool to spawnanother agent to go do a thing, which isuseful if you have like five files thatyou want to have analyzed and you wantFive sub agents to analyze each one. Workflows are different. Workflows areprogrammatically defining all of thecool things that you need your subagents to do. So if maybe you havedifferent stages where the stage one isto go through each file and then stagetwo is if flagged do another thing withtwo additional reviewers. Workflows allowthat, where they allow you toprogrammatically take the results of astage and use that to dynamically cuethings in a different stage. It's alljust a big JavaScript file the modelwill write and then use that to triggerand break down all of the work for thesetypes of big long-running tasks. Forexample, it was super helpful whentriaging all of the poll requests that Ihad left open and stale on Lakebed. Itmade a workflow to go through all ofthem and categorize them. And once theywere categorized, they could be thrownto other stages with other types of subagents to do different types of things. People have tried to build custom flowsfor this in their own tools likedefining this is what a review sub agentis, this is what an adversarial reviewsub agent is, this is what anexploratory sub agent is. That was allstupid and never made sense. Now itmakes even less sense because Fable caninvent those different archetypesdepending on the needs for your specifictask. Every time I'm trying to get anagent to review things, the needs areslightly different and the model is nowsmart enough and understands sub agentswell enough to define that itself. Andthis is where the power of the model starts to really shine. But at the sametime, its awareness of the specificbenefits and negatives of given modelsis not quite there. When they trainedthis model, 55 didn't exist and allthese cool computer use capabilitiesweren't there. Opus 48 also didn'texist, so it's not sure what it is andisn't capable of. So, I had a good gutFeel for where to put things. I alsowant to call something out because youmight have read it on the screen. I sayOpenAI is near free for me due to adeal. I promise you I have no specialdeal with OpenAI at this point in time. This is just how Claude interpreted whatI told it, which was that there was acurrent deal on the amount of usage yougot in Codeex where it was double at thetime. It's no longer double, but it'sstill insanely generous. As I saidbefore, I've been using this heavily andI've only used 15% of my weekly limit.That's nothing special. I'm using thismodel for hours a day every day. It'sjust genuinely hard to exhaust yourlimits on codecs. I think it's like 14grand or so a month of inference you getright now. It's insane. And that's alsooutside of the resets of which I'vestacked a ton. So, while Fableinterprets that as a deal, that's thesame deal you get too. Don't read intothat. As such, I ranked the cost in 55. To be relatively good. The scores hereare the score 1 to 10 on how beneficialis it for this thing. 55's cost to me isrelatively low because my usage there isbasically infinite, it feels, especiallywhen you combine that with the resetsavailable. So, I gave this a cost inquotes of nine. This is me tellingFable, "Yo, by the way, you canbasically use 55 for anything. I don'tcare. This model's just reallyefficient." And it does that. I alsorank intelligence and taste. These arethe categories I chose because I careabout these things, and I have a lot ofproblems with GPT models writing codethat isn't necessarily the code that Iwould have wanted in my codebase. They could solve any problem at any level ofcomplexity, and they can match patternsthey are shown very well. But 55 writesTypeScript like a Python dev, and itwrites Rust like a super paranoid C++dev. It's just not the code Inecessarily want, especially for likePublic facing SDKs and APIs. So evenwhen I was using 55 more heavily, I usedto have it call opus in order to getfeedback on APIs and SDKs in order toclean up the code. Now I've justinverted and I let Fable steereverything and life has been much bettersince. So I call out that GBD55's costand intelligence are both very high, butits taste not necessarily quite as much. So if you're customizing your cloud MDand agents MD, the biggest thing you cando in there is effectively a glossary.The terms you like to use to describethings that might be understood by themodel might not be. Just write them downand what you mean by it. So for me,intelligence is how hard of a problemthe model can handle unsupervised. Andtaste is things like UI/UX, code quality,API design, and copy. This both helps meexplain to the model what I have in mindwhen I’m describing tasks and work andthe issues I have with things, but italso helps the model understand what IMean further in the document withintelligence and taste and how to applythis information when it decides whatmodels to call for different things. So,as I said, 55 intelligent, no taste. Andwith Sonet 5, not much cheaper, muchless intelligent, slightly more taste. Opus 48 is slightly more expensive becauseagain, Sonet 5 is so token hungry thatOpus 48 is often cheaper, meaningfullymore intelligent but still not quite assmart as 55, way higher taste, and thenFable, where the cost sucks, intelligenceis best in class, and taste is alsobest in class. This is genuinely how Ifeel about these models, by the way, so Ijust told the model how I feel, and Itold it how to apply these things. Theseare defaults, not limits. You havestanding permission to override them ifa cheaper model's outputs don't meet thebar, rerun or redo the work with asmarter model without asking. Judge theoutput, not the price tag. Escalatingcosts less than shipping mediocre work. You couldn't tell. I did not writeanything from here down. The next pointis around cost. It says cost is atiebreaker only when axes conflict foranything that ships. Intelligence isgreater than taste is greater than cost.Honestly, again, the model wrote this. Idon't like it. Don't let cost preventyou from using the right model for thejob. Instead, take advantage of cheaperoptions to get more information and trythings before moving the work to a moreexpensive option there. That's muchbetter aligned with how I feel. Realchanges happening on the fly, guys. Isn't that cool? Thanks for giving meincentive to actually read the slop.Next, I talk about bulk mechanical worklike clear spec implicitations, dataanalysis, migrations. 55 is effectivelyfree. Anything user-facing like UI copy,API design needs taste greater thanseven. Reviews of plans andimplementations, Fable 5 or Opus 48.Optionally 55 is an extra independentPerspective. A big call-out here. Neveruse haiku. Just don't at this point. It's not useful for anything real,especially with 55 being effectivelyfree. I then call out the mechanic of 55only being reachable through the codecCLI. I say use the codex implementationcodex review and codex computer useskills for work that they don't cover. Investigation, data analysis. Run codeexexec—read on directly with aself-contained prompt. Instructionsagain on how to use codecs. I get someinsertions here on how to use 55 insideof workflows with sub agents because youcan't just call 55 as an option whendefining a workflow. You have to callthe Claude model when using cloud codesworkflows. So I gave it someinstructions here that it can use Sonneton low in order to spawn 55, get itsresults, and then report those back. Itends up being really cheap. It lets that spin up and use 55i for real work andthen come back with results. I wasGetting annoyed that I couldn't seewhich sub agents in workflows were using55. So I requested that it put a prefixin front so I can more easily see it, andthat ended up helping a ton. The taskscan time out, so I called this out. A lotof these are things that got appended asI ran into problems, and I hope you takethat lesson here. Most of this wasn't mehaving this epiphany on how to get it. All right. I spent about half an hourgetting it mostly working, and then as Iran into problems, I would go back to theoriginal thread and tell Claude, "Hey, Ihad this problem. How can we preventthis going forward?" And it would suggestchanges. I would tell it to cut them inhalf, and then put them in here. It wentpretty well. And with that, let's lookat my skills, which you might havenoticed here. There are not a whole lotof skills. I'm normally not a big skillsuser. In fact, I plan to delete theseonce better models come out, or betteryet, Anthropic gets good at computer. Use, but for now, having these here hasbeen very helpful. I have Codex reviewwith a description that says you can askthe Codex CLI 55 for an independent codereview of uncommitted changes, a branchdiff, a commit, or a specificimplementation, yada yada. This is howyou use it for review work. I then callout here that Codex is an independentreviewer when the user wants a secondpass review or when the change is broadenough that another agent perspective isuseful. Yada yada yada. I define aworkflow. You identify the reviewtarget. You create a temporary artifactdirectory for the Codex report. You runCodex review with a focused reviewprompt. And then you read Codex's reportand verify the important claims againstthe code before presenting them. Again,this is meant to be called by a subagent that is triggering Codex and itgets the feedback and then passes itback up to the parent model. The mostimportant piece here is the commands. Not because the model can't get themright, but because the one or two timesthey get it wrong, it's really annoying.So you ask the model when that happens,what did you get wrong? What is theright structure for this? And then onceyou have that, you can go add it here.And for me, it has worked pretty damnwell. There are then some instructionson how to prompt Codeex because I'venoticed that Claude likes to promptCodeex as though it is Claude, which itis not. The prompt should be muchsimpler. And this is an example of avery simple prompt that makes sensehere. I would even argue things like do not edit files does not reallynecessarily need to be here becauseagain, it's a codeex model. It's notgoing to do things you don't tell it to,unlike Claude models, which love to dothings you don't tell them to. Anotherproblem I had is that sometimes Codexwouldn't find anything and that wouldconfuse the parent model and it wouldRerun. So I added a bunch of these callouts like if Codex finds nothing, saythat clearly and mention what the reviewtarget is that it inspected. That endedup reducing the issues I had a ton. Again, you need to set this up foryourself. Don't just blindly copy-pastemy stuff. There's a reason I'm notposting the links anywhere. I want youguys to learn from this. Maybescreenshot it and pass it to the modeland say, "Hey, I want to set upsomething similar. Can you guide methrough it?" Do it. Learn it. Change it. Experiment. If you're scared of going inand editing these files, you need to getover that. And if I let you guys justcopy-paste my stuff, you'll be afraid ofbreaking things when you make smallchanges. I need to know you won't bescared of that because this is where thefun comes in. I have a Codeximplementation sub-agent that's verysimilar for doing bounded work, usuallyon a work tree, in order to set up theModel to go make changes and bring backuseful results. It's a little moreguarded than I would like, but it workspretty well overall. I haven't hadenough issues to care. If I do, I willchange it and I will let you guys knowin future videos. But my favorite by faris the computer use one because this iswhat allows Claude to have Codeex'scomputer use powers without having tobuild it into Claude or more importantlywaste a ton of your money in usage. Remember, the model only sees thedescription of the skill until it usesit. And once it uses it, it pulls all ofthe rest of the text in. So thedescription should have all of the infothat Claude needs to know whether or notit should call this and get the rest ofthe context. This one's a little wordierthan I would like, but it's been goodabout calling it when it should and notcalling it when it shouldn't. It says,"Ask codec CLI with GBD55 to run localapp verification that needs computer."Use, browser automation, simulators,screenshots, app launching, orindependent runtime inspection. "This ishow 55 is invoked for computer use work. Use when the user asks Claude to haveCodeex or 55 test a flow, verify userbehavior, inspect a running app, capturescreenshots, or report confirmation andfeedback about implemented behavior. Imight even change this now from when theuser asks Claude to have codeex or GVD55test a flow to just when the user asksClaude to test a flow to default hereinstead. In fact, we're going to dothat. Use when the user asks Claude totest a flow, verify UI behavior, inspectrunning app, capture screenshots, orreport confirmation and feedback ofunimpeded behavior that benefits fromcomputer use functionality. There we go. Again, adapt these as you go. Thinkabout your experience and don't beafraid to make changes. It's so cheap todo, and it can meaningfully improve yourworkflow. And once you get in the habit. Of changing, editing, and getting thesethings how you want, you'll end up muchhappier overall. And now is when westart diving into how I actually got allof this work done. Claude code isadmittedly broken in a lot of ways, soit won't be the easiest thing toshowcase, but I will do my best and Iwill break down how I was thinking aboutthings and how I took advantage of themas well. I started with a really simpleprompt. Investigate and review the openPRs for Lakebed right now. This was asimple request. I wanted to ask themodel to deal with all of the thingsthat I had left open. Remember I said Ihad a bunch of open? We now have thenumber. It was 16 open PRs of somewhat finished, somewhat trumped, somewhatdead work. And the variety of the workthere was crazy. I call this outaccordingly in the prompt. I think it'sactually a good example of a prompt forthis era of working. Investigate andreview the open PRs for Lakebed rightNow, I wanted a list that indicates thefollowing,which are ready to merge,which are mostly good but need a rebaseor other small touch-ups,which have been trumped either with better PRs orthings that have already merged,and which have good ideas but are better offscrapped and rewritten. Use a workflow to break up the work into multiplereviewers to help solidify yourdecisions. And then it ran for a while,not too long, but a meaningful amount.It spawned a workflow. You can see herethe code that it wrote for saidworkflow. It ran for a while and then itcame back with a list. All 48 agentsfinished. 16 investigators, one per PR. Each verdict then stress tested by Fableplus Opus judge panel. 14 of 16 callswere unanimous. I resolved the twocontested ones below. Here's the triage. First, we have one PR that was ready tomerge, which was the separation of docs,because I had both 55 and Opus 48 were kindof blurring the line between docs for myUsers and docs for the maintainers ofLakebed. So, I did a hard cut, and thatPR was pretty good and easy to merge. So, that got merged fast. Then there wasa couple of others that were mostly good,but needed some touch-ups. Then therewas a pile of PRs that had been trumped.And then the good ideas that should bescrapped and rewritten, as well aspairing them together for the thingsthat were similar. I gave a suggestedorder of operations. Start by merging69. Then fix the allow list for 68, andmerge rebate 61, then 48, yada yada calls. The ones to close out, and all of this. Iliked how it was thinking. I liked thefeedback it gave. I actually did readall of this because I wanted to understandwhat it wanted to do. And once I wascontent with what it said, I realized,you know, I have a staging environmentset up here. It won't affect prod if itgets things wrong. Let's yolo a littlebit. This was a goal I set. First, Isaid to close all PRs that have beenTrumped or otherwise not worth keeping around. Then, help me spec andprioritize the work for the other PRs you think you should close. Write up newHTML plans for a best path forwardimplementation for those features andfixes, honoring the goal of simplicitythat we strive for in Lakebed. Break upthe planning work into sub agents. Review the plans with sub agents as well.A workflow may be helpful. Once you haveplans you're happy with for each ofthose pieces of work, share the linkswith me so I can review them. Make surethe plans you write have links to thePRs that they are inspired by. Ifmultiple PRs implement the same feature,link to all of them. Make sure todescribe where the existingimplementation is and how you feel weshould handle the next one. I was wrong. This one wasn't the goal. This is the goclean up, destroy all the dead PRs, andthen tell me in detail what you want todo to the remaining stuff. And after aCouple more minutes, it had done justthat. It gave me links using my HTMLplanning skill for all the differentthings it wants to add and how it thinksthey should be implemented. That wasactually a really pleasant read, whichby the way, I did on my phone. Superconvenient. So, I read through most ofthese. I looked at the PRs that hadinspired the changes and made anexecutive decision. All of them lookedpretty damn good. Yeah, five of theseremaining pieces looked really damngood. I did have one PR that I wanted topossibly merge at this point. So, Iasked it about that one. I took a look. It said it was good, so I merged it.Wait, no, I had to rebase it. Yeah, Iasked it a question. Which, by the way,ask your models questions when you'renot sure about things. It's a greatopportunity to align yourself and themodel and what the plan is forsomething. So, I asked it, what are thestreams of work we need to complete toAddress all the PRs that we'vediscussed? Is it as simple as rebate 61,merge 48, 68, reimplement the rest? If Iwanted you to implement all of the plansyou made, would it be best to do that asa single workflow or to make multiplework trees and threads by hand myself? Iexpected it here to push back and say,"Yeah, you obviously need to break thisup into different threads." It decidedto break this down into multiplestreams. The first one being to land thefour open PRs that were ready to go. Then to implement the five plans thatwere left over, so eightish PRs total.Also note that each plan deliberatelydecomposes into bounded PRs. The thirdplan apparently was going to be threeseparate PRs. Dual write, read, path,flip, then the column drop, and thenyada yada. You get the idea. I don'twant to bore you with the details ofLakebed. And then we talked about theworkflow to get this all done. Singleworkflow versus handmade work trees. Neither, honestly. And you don't need tomake a work tree by hand either. Asingle workflow is the wrong tool forthe umbrella. Workflows aredeterministic scripts that shine for fanout and verify. But this program ischeckpoint driven. Each PR needs CI,your review, and a merge before the nextrebase. In midstream, you'll makeproduct calls like the open questionsthat are below that a script can'tanticipate. One giant workflow wouldeither barrel past those checkpoints orstall at the first one. So, itrecommended that it orchestrate thestreams from the session that we're already in, spawn work trees itself toactually do the implementations, andthen use workflows only where they'restrong, which is for multi-agent reviewpasses one before it merges the PRs. Italso identified that certain places hadparallelism and possible, like a plan twoand three could be run in parallel sothey don't touch each other's stuff asMuch, and it wouldn't have too many mergeconflicts. I then asked it to take allof this work and write it as a to-dolist in the directory so it would beeasier to just crank through all of it. And then we get to the goal or morecorrectly put the insane world we nowlive in. I started a goal whichbasically tells the model to keep goinguntil the conditions pass. In this case,the conditions were to complete all ofthe work that we have discussed here. You have permission to create worktrees, rebase, branch, merge PRs, closePRs, etc. This is me explicitly tellingthe model, you have my thumbs up, mergeaway. This might sound insane. Kind ofis, but I'll show you why it's not asbad as you think in a little bit. But ifwe're all going to go insane here, andwe all very well might, I'm going to doa second ad break quick. Building appswith React is really easy. That's whyagents are so good at it. It's neverbeen easier to build for the web, butIt's still not that easy to build formobile. Believe me, I've triedeverything from Kotlin and Swift toReact Native. It seems like AI justdoesn't get it anywhere near as well. Getting those things right is superdifficult. And having a good codebasewith a good team is essential. That'swhy knowing about Infinite Red is such apowerful hack right now. They can comein and modernize your codebase if youalready have a mobile app. They can helpstart from scratch. They can onboardyour team to do these things correctly. But in the end, what they're here to dois set you up to get your mobile appright. They obviously lean heavily intoExpo and React Native, but if you wantto build on Swift and Kotlin, they canhelp with that, too. They can even buildthe native bindings you need to getthose parts right. And in a world whereGBT55 can invent a cloud from scratch ina few minutes, but can't lay out a UIcorrectly on Xcode, yes, I'm speaking. From experience, it's actually insanehow bad 55 is at mobile without havingthe right guidance, at least, which iswhat Infinite Red is here to provide.Well, get your team set up with a goodworking codebase and, more importantly, agood working understanding of how towork in that codebase. And then you cando the same with your agents. That's whyeveryone from Zoom and Microsoft toDomino's and Starbucks has worked withInfinite Red to polish up their mobileapps and get their teams ready to buildbetter on React Native. So, if you'recurious about React Native or you'retrying to fix an old broken app, or youwant to get things right from the start,hit them up at soyv.link/infinite red. Okay, as I was saying, we create thegoal to complete rebase, branch, merge,work tree, all of the things it has todo to deal with this insane amount ofwork I put in front of it. This is likea month of work in a to-do MD. Now, bythe way, I tell it to go through all ofThe work step by step and mark eachto-do in to-do.md done when completed. The to-do MD changes should be committedand merged as you go. Use the toolsavailable to you to break this work uplogically. Review it thoroughly andmerge with confidence. Do not merge codeuntil my automated code reviewers haveapproved it. In this case, Bugbot,Macroscope, and Code Rabbit because it'swhat I have set up in this or goal set. Goal acknowledged. And then it ran for 5hours. And every time I checked GitHubon my phone, more code had landed. Andthat's how we got here with this giantpile of work that actually landed. Mywhole month roadmap that I’d beenrunning around in circles, not shipping,just thinking too much about it now is inLakebed. It did the thing. This mightsound insane, like merging straight toMaine when the agent thinks it’s goodenough. But when you see all of thecomments and all of the pushback it gotto clean up the implementations and keep. Them simple before merging and you combine that with the most importantfact, which is that productiondeployments are still a human in the loop. This is just the stagingdeployments that happen when you merge domain. So the model cannot ship or touch prod. The model can use stagingfor basically whatever it wants. Ihaven't done a prod deploy in a bit because also there were some thingsbroken in my staging environment becauseof other models merging things theyshouldn't have. And I had Fable cleanall of that up before even doing thiswork. So I started by having Fable getstaging to a place I liked enough that Iwould be happy merging main and shippingit to prod. But instead of just rushingthere, I decided to clean up everythingelse. And it did it. It just went andwent and went until everything was done. And then I had it on main. I had it instaging. And I went and personallystress tested it and also spun up otherAgents to go try out all the new features and also try out all the old features. Maybe try some apps that were built the old way and see how they port over to the new way. And then I had other agents look over all the changes between prod and main because a lot had changed on this branch since and see what things needed to be derisked and then spin up more tests to go check those things. And there was basically nothing that needed to be fixed. I'm still kind of blown away. I burned way more tokens trying to verify the work that Fable did here than I burned getting Fable to do the work here. And it was all good. There was nothing to change, which means again, I'm not pushing it hard enough. And I'm still looking for more ways to do that. Believe me, there will be plenty as I go. But god damn, Lake Bed is now a month ahead of schedule when it had fallen, admittedly, a month behind. I was really hyped. And this workflow was just so cool to watch as it went. Truly unbelievable. I wanted to keepworking, but this one was running on mymain laptop cuz I didn't think I wouldget this far. If I did, I would havedone it on a different computer. But Iwas just playing around with the newquad code and the new model and got wayfurther than expected. But I wanted todo other work on other projects. Sothat's when I started connecting to myMac Mini, to my other Linux boxes, andto the other machines I have. Check outmy Linux video if you haven't. It coversa lot of this stuff. And I startedsetting up Claude on those. And asusual, I got really frustrated trying touse cloud over SSH because all of thesenice things I rely on like imagepasting, decent select behaviors, scrollthat works just weren't really viable. And I did what I always do. I went backto T3 Code. And god damn has T3 Codehelped me maximize my utilization ofthis model a ton. The cool thing with T3Code is that you don't have to use it onThe same machine that's running youragents. It's very easy to set upsomething like Tail Scale and connect toyour other computer on the T3 codewebsite or on the T3 code app on yourcomputer. Or if you're a little bold andyou're down to try and build ityourself, the T3 Code mobile app, whichis also open source, which by the way,all this is open source. We have no wayto charge for it yet. We don't makemoney. I’ve probably spent over 250grand both in tokens and salaries forthe people working on T3 Code. This is agift. Enjoy it before I have to startcharging. That all said, the T3 Codemobile app is in the repo and you canbuild it yourself for your phone, and it's really goddamn cool. I had no ideahow much I was underrating it because Itried the first version when Julius waslike 3 days in. He's been grinding on itfor a month, and it has gotten absurdlygood. So, I set that up on my phone,connected to Tail Scale, connected to myComputers, instantly blown away. I wasso blown away that we started working onT3 Connect, which is a service we'llhopefully ship in the near future thatlets you not need to set up Tailscaleto get all these benefits. You're a nerdthough. You can set up Tailscale. Justdo that. It's totally fine. Don't pay usmoney or wait for us when you could justhave it yourself. The reason I bring allof this up is because it madeparallelizing my work trivial. Everytime I had an idea for a thing or evenwhen I was just on my phone and running into problems, I would just spin up aworkflow for it or spin up a work treeor just get something done. When I wasworking from my phone, I kept noticingsmall bugs. So, I kept spinning up newwork trees to fix the bugs. Like Iwanted to have the repo for T3 code witha favicon at the root level because thenit would have the little icon in thecorner here like other projects do asyou see with T3, Chat, Lakebed, and otherThings that we have a easily findablefavicon in T3 codes was a little toohard to find. So I bumped it up higherso T3 code would see it. I then asked itto commit and make a PR following therepo guidelines and it did. And it lookslike it had a transient failure becausetesting is hard and the cursor adapteris not as reliable as we want it to be. Cool. You know what this is? This is anopportunity to show you guys how I work.Here's what I do. First, I take ascreenshot of the problem. Then I go tosomething like T3 Code. I open this andI can pick which machine and which T3Code directory to use because this is arepo I have in a lot of differentplaces. I have it on four differentmachines and one of them has it in threedifferent places. I'm just going to dothis in the standard T3 code repo onthis project. I'm going to pickwhichever of my favorite models. In thiscase, I'm just going to ask Fable to doit. I'm going to paste the image. So,I'm going to say figure out why thistest fails randomly. It just failed forno reason on PR number 3683. And then a link to the bad run. It is ona work tree, so this won't affect otherwork. It has now been spawned. And nowI'm not as worried clicking the rerunjob button. And hopefully in just amoment, this PR will pass. And as you'llprobably noticed, the slowest part ofthis workflow by far is waiting forGitHub load times. I cannot believe howbad of a state GitHub is in. I wouldgladly pay a hundred bucks a month forsomething just like GitHub with all thecore features we need. That is wayfaster. Ideally, I would just pay toGitHub and they would make theirsuck less, but that's never going tohappen at this point. You get the idea,though. And now I have this work going. And while that's going, I can go see thestatus of other work I'm doing, like myattempts to improve the connectionexperience when you're using SSH into aBox and setting up T3 code on it soanother machine can control it. I wantthat to be buttery smooth, and I'm reallyhoping we can get it there soon. Fornow, just ask your agents. It'll figureit out, but I want it to be one command. I then was working on a new machine Ijust set up, and I wanted to see if itcould get T3 Code and the mobile appworking properly, so I could not have torely on this laptop as much for all ofmy iOS work. It got pretty far. I hadsome computer use issues. I'm going tofix that after I finish recording. Thisone was actually really fun, though. Thisis an experiment I was trying. I had allof these work trees I spawned on myphone, and most of them were furtheralong than expected, and relativelysimple changes. And rather than makeJulius deal with like five differentPRs, I decided instead to just ask Babelto combine them because some of them hadoverlap, some of them would haveconflicted. I didn't want to deal withIt. So I made an executive decision. Iasked, "Can you access all these worktrees on my machine? I'd love to pullthe changes from all of them into one branch with conflicts handled so I cantest them all at once." Five minuteslater, it did. And now I have thisbranch I can pull down on my laptop inorder to test all the changes. It'sgreat. It handled the conflicts thatexisted because of multiple things thattouched on each other's stuff. And now Ihave all of this in one place where Ican file a single PR and easily documenteverything that changed. I could evenpull this onto a different computer likea Mac and have it go verify all thechanges, too. I do want to be reallyclear about something. I don't expectthe majority of the code I spawn thisway to be ever used or merged. Part ofthis is just seeing how complex theproblem is. Like if I ask the model togo solve this problem and it takes under3 minutes, it was probably a simple fix. And I won't feel bad filing that PR andtelling Julius to get it merged. If ittakes 15 minutes, that's a little scary.I might want to pay more attention. Ifit takes an hour or more, oh,something's wrong with our architecture.We need to go deeper and figure outwhat's up. The amount of time it takesand the amount of changes it has to makein order to make any of these thingshappen is a really good indicator forwhere the good and bad parts of yourcodebase are. And for a lot of these,the changes were so simple, it's like aneasy merge. Like obviously you want togo put that up and do it. But for someof them, it took long enough that I'm alittle bit concerned. For example, withthe mobile thread scroll jumping stuff,this one it took a while on. It tookover an hour and a half. That scares me. I'm not going to blindly merge thiscode. I'm going to go put a lot moretime in here. Especially compared to theissue that annoyed me more, which wasSliding back not behaving properly,which it fixed in 2 minutes and 20 seconds. It was so simple it concernedme because it talked about a drawerbehavior. We didn't have a drawer. Ithink we might have had in the past, though. So, I just asked, "Do we even have adrawer anymore?" Apparently, we do, butthe edgewipe gesture is the only entrypoint. No, we don't then. But now, Iknow, it was kind of wrong aboutthat. So, I have to put a little moretime in. You get the idea. You got tothink with your brain a bit. Not justlike reading the code thinking, butthinking about the architecture,thinking about the request, thinkingabout how fast or slow it was, how manythings it touched and then make a gooddecision accordingly. And if you don'tknow, just ask. You'll be amazed how useful the models are when you ask themquestions about things. It's almost likethat's what they originally built for orsomething crazy. Hopefully, this hasBeen a good overview of how I've beenworking with Fable. As you can see, thesheer volume of work I'm doing in all ofmy projects has massively ramped up. Iam more ambitious than ever. I'm havingmore fun than ever, and I'm pushingmyself harder than ever. I do have onelast pro tip for you, though. VibeProxy. If you're scared of hitting yourlimits, this might be worth setting up. It will autosplit your traffic acrossmultiple different accounts. I had heardabout this before, and I thought it wouldbe a little sketchier or harder to setup. It really wasn't too bad. It isusing the API key version of ClaudeCode, so you do lose like the built-in /remote control and a few other featureslike that. I haven't really missed itthat much. I've actually found thispretty pleasant. As you can see, I'm notgetting close to my limits yet, but I doalso have another 4 days before theytake Fable from us in the subs. So, I'mprobably going to get a lot closer,Especially once I finish recording, I thought this video would be short. That was foolish of me.I'm going to go back to coding.I hope this inspires you to do the same.Let me know what you think of my workflow.Am I insane for even sharing this, much less doing it?Or is this actually inspiring and helpful for you as you try to go build using these models yourself?I have had so much fun.I hope you do, too.So until next time, peace nerds., I Finally Get Fable 5, youtube.com, 01kx13e6tr2mff47takgwgaywy.