A proper guide to Fable 5

Speaker A

Saying Fable 5 has one shot me would be a criminal understatement. I really appreciated the model the first day I tried it. But over the next two, I started to genuinely love it and was blown away with what it was capable of. And then it got taken from us and I. I struggled. I did my best to make decent work come out of Opus 4. 8 and GPT 5. 5, but it just. It wasn't the same. And I found myself just kind of running in circles, waiting. And then the model came back and I honestly can't believe I'm saying this. It's better than I remembered. There are a lot of things that aren't perfect about it, and there's ways to work around some of them, but goddamn, when I'm actually trying to use this model for my day to day work, it blows me away.

In the first day of having it back, I got more work done than I had in the month prior. It just, it was incredible to watch as the model cranked through all of these things that I'd been planning and thinking about and starting, but not finishing. And it just shipped. It fixed a bunch of code, it merged a bunch of stuff, and it got me pumped for not just the work I was doing, but for the future of how we'll be doing work. It is incredible what you can do with this model, but there's one big catch. If you treat this model the way you did previous ones, you're not going to see the benefits. To put it simply, this model isn't a better opus. If you take prompts that worked for OPUS and you give them to Fable, it's not going to be much better.

The difference in this model isn't just how much smarter it is or how much better the code is, it's how much further it can go. Not just on like harder code tasks, but on end to end implementations, testing, verifying, and all the other pieces you need to write great software. Especially once it has to break tasks up into smaller pieces and hand those off to sub agents. This model does incredible stuff and I've been doing my best to get as much as possible out of it during this limited window where we have it in the subs. Although it is coming back soon. And with that, I do want to make sure you guys know I already filmed a video today about a lot of this. Specifically about all the misconceptions people have with the model. They're frustrating me because this model is great. So if you're confused because you read Twitter and saw all these people saying the model's nerfed.

It's terrible, it's way too expensive, all that type of stuff. Go watch that video first. It'll help clear the air. It's not a necessary first view, but it will help a decent bit. This video is different though. This is the video where I show you all the things I've been doing with Fable, all the awesome stuff I've been able to ship, most importantly, the ways that I've been doing it, the prompts I've been sending, the systems I have built, the changes I've made to my Claude MDs, to my skills and all these other things, and how I've most importantly changed the way my brain works when working with models in order to maximize what I can get out of this new era. So, and this really is a new era, Fable isn't just an improvement, it is a fundamental change in what these models are capable of.

Enough that it makes it sound like I'm reading a script when I'm not. This is all off top, like this model screwing with me. If you can't tell, I've effectively been one shot. This is my psychosis moment and I can't wait to share it all with you. But someone's going to have to pay for my therapy, and it'll probably come from the budget. Thanks to today's sponsor, my agents get a lot right when I'm building. It's honestly really impressive, but there's a few things they always get wrong, no matter how good the tooling gets. The two that hurt me the most are Auth and Billing. They're just like the kryptonite of AI agents. They could never get it right, especially the billing side, and trying to get that linked to the user in a way that makes sense. The amount of weird, random, transient billing failures we get across services is so annoying.

Well, it was until I started using today's sponsor, More Clerk, because not only do they have the best AUTH platform that is the easiest to integrate across everything, be it web, mobile or anything else, we're actually working with them right now in order to get the T3 Code Electron desktop app offed for our new remote. Stuff that I'm really excited about. What's way more exciting to me is the subscription platform that's now built in. Having tried pretty much everything like this, I can confidently say Clerk is the easiest and has the best abstraction. Instead of all the obnoxious effort trying to set up a staging and production environment for Stripe with their own separate keys, their own separate product IDs their own separate everything that you now have to mirror in your real database just to make sure it works. You just get to configure it in the Clerk dashboard.

Once a user pays, that payment information is attached to the user itself where it belongs. I don't care what subscriptions exist, I care if this user is subscribed and Clerk gets that right. They have custom components and helpers where you can check what state a user's in and what plan they have to make it trivial to render the right UI or go down the right path. And it ends up costing the exact same as going to Stripe directly, which is unbelievable. Any one of these pieces would be worth moving to Clerk for, especially having the user profile component with all the billing info built in. The the amount of time Mark loses dealing with billing disputes and email is obnoxious and this would have saved us so much of that trouble. Fun fact, if you Google search Stripe recommendations, my repo is the first one to come up.

This is a multi page guide on how to try and get Stripe to work properly in your apps. But at this point when people ask me how to get it right, I usually just point them at Clerk set up auth and payments right at soydev Link Clerk the amount of work I've done with this model in the last few days is still just kind of screwing with me. Especially because I was at a conference for half of it. Shout out to the T3 code mobile app. By the way, I was doing a ton of work on my phone while also at this event and it shows I got a ton done. Like an unbelievable amount done. This is the closed PRS in Lakebed where reminder I'm still the only contributor. I have not forced this project onto my team yet. They don't deserve the slop.

It's cleaning up fast. Thank you Fable. But all of these PRs were done in literally two to three days. The sheer volume of work here, especially if you're looking at the ones that actually merged, like this pile here that's like I think 11 or 12 PRs that merged all not just in one day but from one thread.

And I keep going and I'm on page two. We're still in things from two days ago, then there's a four day ago one, five days ago, then a huge jump to two weeks because I was just not really feeling it. When I lost access to this model. I tried to run around in circles and get the best stuff I could out of Opus, but it wasn't at the bar I needed to ship. And what ended up happening is in this particular project, Lakebed, I had a bunch of these PR stack up of work that was like 50 to 80% complete, but I didn't like the SDK changes 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 having ideas, I kept making PRs, and they kept sitting there doing nothing.

I probably had 20 or 30 PRs just sitting in this repo, not, not moving. And the project has been sitting there as a result. And I don't like that. I really want to ship Lakebed. I've talked about what Lakebed is in some other videos. I don't want to bog you down with the details until I actually have it launched. I haven't earned the right to market this yet. I want it done. So we'll do that later. But I want to talk about the workflows that got me this far in the project, as well as some of the cool things I'm doing on other projects that I've been working on. I'm going to start in a weird place here, but I promise it will help. I'm going to start with min maxing tips and like cost reduction things in order to make sure that when you adopt this workflow you don't immediately bankrupt yourself.

Because if you were to go to the second half of this video and skip straight to that part, it will be expensive. That's what I did in the first three days we had Fable and it was expensive. I didn't pay cash. I bounced between two subs, but I looked at how much it would have cost and it was in the thousands of dollars. And all the work I just shared here, all of the PRs that were closed, fixed, updated, recreated, merged. I want you to just think in your head and guess how much you would expect that to cost. With Fable running in a loop for five and a half hours, getting all that work done, you're probably thinking in the thousands, because that's what I would have expected. But it was only around 150 bucks. Not just Fable, but all of the other models.

I had Fable calling throughout. Wait, but Fable's so smart. Why are you using other models, Theo? And here's where the tips start. I mentioned in my previous video that I was teaching Fable how to use codecs and I'm going to show you how. But first I just want to make sure I emphasize this point. I talked about it before. Do not use Fable on higher than high reasoning efforts. The X High and Max options are dangerous and ultracode causes it to use workflows when it shouldn't. Those three options pretty much everything to the right of high. These are dangerous. They look so enticing though. The fancy gradient when you hop over it like it's a slot machine begging you to put another coin in. I'm going to beg you to not fall for it. High is way smarter. I know that sounds like I just made a mistake.

I didn't X High and Max end up second guessing themselves too much because they run in loops. They'll just go longer and longer with their reasoning and the result is often worse. Code that is way overdone, that has way too many changes for the simple thing you're asking for at a cost that is absurdly higher than it should have been. Low, medium and High might not be as efficient as like GPT 5.5, but they are capable of things that 55 is just not even close to capable of and they can still run for really long times. The reasoning effort does not determine how long it can work, for which a lot of people seem to think that Max can solve harder problems and work longer than High can. But the reasoning effort only applies per tool call and per change. So if you have work that takes 500 steps, Max isn't going to do more steps necessarily.

It's going to think more per step, and most of the steps don't require that much thought. The problem is that X, High and Max, since they are thinking too much per step, they're going to overthink the thing. And they do, and they do aggressively, as does Sonnet 5, as arguably Opus 4:8 does as well, although not quite as bad. I am admittedly a little scared that this five family of models from Anthropic might have a big problem with over reasoning with these two options. So honestly, just keep it on low through high. I personally leave it on high and don't think about it. I'm only thinking about it now because I saw people complaining about their bills and I talked to them and every single person complaining about blasting through their usage too fast was on X High, Max or Ultra code. By the way, you might not have known this ultracode uses high under the hood.

It just spins up a ton more of them. So even Anthropic agrees High is the best bang for your buck. Trust me, just go with that. It's a default for a reason. It's their default in other things for a reason. It's the right level now that that's out of the way and have probably cut your bill by half or more just by making that one change, let's talk about the rest. Specifically, all the fun things with How I taught Claude code to use codecs I talked about this a good bit in the other video, so I'll do a brief recap before showing the implementation. The TLDR here is that the usage you get for the codec sub is insanely generous, so things that it makes sense to use for you probably should. One of those things is computer use, which OpenAI just kind of slaughters anthropic at Right now the Codex desktop app has a ton of cool hacks that let it use your Mac in full, not just like opening up a tab in Chrome and poorly navigating it.

More like setting up Xcode for you or navigating complex applications and pulling data between different things and sending you a video when it's done. The computer use in Codex is insane, so teaching Claude code how to call that is awesome. But the biggest thing is the tasks that require a lot of token usage. Things like digging through logs, things like reading giant PDFs and implementation specs. Things like doing computer use and looking at hundreds of screenshots over an hour as it tries to navigate your machine. Teaching Fable how to designate those tasks en route to the right models and didn't take too much time. I spent maybe an hour on this and it has massively cut my costs. All those PRs I was showing, as I said, my use across all the models 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 my codec sub was at like 15% or so for the whole week and my cloud code sub admittedly reset on like I think it was Friday evening and we got the model back on. Was it Thursday or Wednesday? I think it was Wednesday, we got it back and my reset was Thursday night and I got to 40% on my weekly while pushing it my hardest. Their usage is totally reasonable as long as you take advantage of these tips. Most of my work was in my global Claude md. I spent a good bit of time in here. I already made some changes here about specific behaviors I want, like which tech should it use when initializing a new app. Honestly I'm gonna change a lot of this to lake bed soon. The style of code I like general preferences.

Just like the normal stuff you probably have or at least played with putting in your clotmd I could do a very long video about how to influence your agents to have the same psychosis as you. It's the thing I think a lot about. I haven't went quite as hard in my global clotmd on that yet, but I did go a lot harder in this file last week because again I wanted to try and teach it how to use these types of things. It all starts here. If computer use is helpful for completing or verifying work, shell out to GPT55 with Codex for it. Specifically the words shell out here are important because what I'm telling the model is that it can call GPT5.5 via the shell via bash because it has the ability to use bash, it's using Claude code. Of course it does. And then I give more hints.

I have another set of skills that we'll get to in a bit, but I think reading through here is the best starting point. I have a section in my Cloud MD for picking the right models for workflows and subagents. If you're not familiar with the difference here, subagents are the idea that the agent can call a tool to spawn another agent to go do a thing which is useful if you have like five files that you want to have analyzed and you want five sub agents to analyze each one. Workflows are different. Workflows are programmatically defining all of the cool things that you need your sub agents to do. So if maybe you have different stages where the stage one is to go through each file and and then stage two is if flagged, do another thing with two additional reviewers. Workflows allow that where they allow you to programmatically take the results of a stage and use that to dynamically queue things in a different stage.

It's all just a big JavaScript file the model will write and then use that to trigger and break down all of the work for these types of big long running tasks. For example, it was super helpful when triaging all of the pull requests that I had left open and stale on lakebed. It made a workflow to go through all of them and categorize them and once they were categorized they could be thrown to other stages with other types of subagents to do different types of things. People have tried to build custom flows for this in their own tools like defining this is what a review subagent is. This is what an adversarial review subagent is. This is what an exploratory subagent is. That was all stupid and never made sense now it makes even less sense because Fable can invent those different archetypes depending on the needs for your specific task.

Every time I'm trying to get an agent to review things, the needs are slightly different and the model is now smart enough and understands sub agents well enough to define that itself. And this is where the power of the model starts to really shine. But at the same time, its awareness of the specific benefits and negatives of given models is not quite there. When they trained this model, 5.5 didn't exist and all these cool computer use capabilities weren't there. Opus 4.8 also didn't exist, so it's not sure what it is and isn't capable of. So I had a good gut feel for where to put things. I also want to call something out because you might have read it on the screen. I say OpenAI is near free for me due to a deal. I promise you I have no special deal with OpenAI at this point in time.

This is just how Claude interpreted what I told it, which was that there was a current deal on the amount of usage you got in Codex, where it was double at the time. It's no longer double, but it's still insanely generous. As I said before, I've been using this heavily and I've only used 15% of my weekly limit. That's nothing special. I'm using this model for hours a day, every day. It's just genuinely hard to exhaust your limits on Codex. I think it's like 14 grand or so a month of inference you get right now. It's insane. And that's also outside of the resets of which I've stacked a ton. So while Fable interprets that as a deal, that's the same deal you get too. Don't read into that. As such, I ranked the cost in 5.5 to be relatively good. The scores here are the score 1 to 10 on how beneficial is it for this thing.

5.5's cost to me is relatively low because my usage there is basically infinite, it feels, especially when you combine that with the resets available. So I gave this a cost in quotes of 9. This is me telling Fable, yo, by the way, you can basically use 55 for anything. I don't care. This model is just really efficient and it does that. I also rank intelligence and taste. These are the categories I chose because I care about these things. And I have a lot of problems with GPT models writing code that isn't necessarily the code that I would have wanted in my code. Base. They could solve any problem at any level of complexity and they can match patterns they are shown very well. But five five writes typescript like a Python dev and it writes Rust like a super paranoid C dev. It's just not the code I necessarily want, especially for like public facing SDKs and APIs.

So even when I was using 5.5 more heavily, I used to have it call Opus in order to get feedback on APIs and SDKs in order to clean up the code. Now I've just inverted and I let Fable steer everything and life has been much better since. So I call out that GPT5.5's cost and intelligence are both very high, but it's taste not necessarily quite as much. So if you're customizing your Claude MD and AgentsMD, the biggest thing you can do in there is effectively a glossary. The terms you like to use to describe things that might be understood by the model might not be just write them down and what you mean by it. So for me, intelligence is how hard of a problem the model can handle unsupervised, and taste is things like ui, ux, code, quality, API design and copy. This both helps me explain to the model what I have in mind when I'm describing tasks and work and the issues I have with things.

But it also helps the model understand what I mean further in the document with intelligence and taste and how to apply this information when it decides what models to call for different things. So As I said, 5.5intelligent, no taste and with Sona 5 not much cheaper, much less intelligent, slightly more taste. Opus 48 slightly more expensive because again Sonnet 5 is so token hungry that Opus 4.8is often cheaper, meaningfully more intelligent, but still not quite as smart as 5.5. Way higher taste and then Fable where the cost sucks. Intelligence is best in class and taste is also best in class. This is genuinely how I feel about these models by the way. So I just totally told the model how I feel. Then I told it how to apply these things. These are defaults, not limits. You have standing permission to override them if a cheaper model's outputs don't meet the bar, rerun or redo the work with a smarter model without asking.

Judge the output, not the price tag. Escalating costs less than shipping. Mediocre work. You couldn't tell I did not write anything from here down. The next point is around cost. It says cost is a tiebreaker only when axes conflict. For anything that ships, intelligence is greater than taste is greater than cost. Honestly, again, the model wrote this. I don't like it. Don't let cost prevent you from using the right model for the job. Instead, take advantage of cheaper options to get more information and try things before moving the work to a more expensive option. There that's much better aligned with how I feel. Real changes happening on the fly guys. Isn't that cool? Thanks for giving me incentive to actually read the slop. Next I talk about bulk mechanical work like clear spec implementations, data analysis, migrations. 5. 5 is effectively free. Anything user facing like UI copy, API design needs taste greater than 7 reviews of plans and implementations.

Fable 5 or Opus 48 optionally 5.5 is an extra independent perspective. A big call out here. Never use haiku, just don't at this point it's not useful for anything real, especially with 5.5 being effectively free. I then call it the mechanic of 5.5 only being reachable through the Codex cli. I say use the Codex implementation, Codex review and Codex computer. Use skills for work that they don't cover. Investigation, data analysis Run Codex exec s read only directly with a self contained prompt. Instructions again on how to use Codex. I give some instructions here on how to use 5.5 inside of workflows with sub agents. Because you can't just call 5.5as an option when defining a workflow. You have to call a claude model when using claude codes workflows. So I gave it some instructions here that it can use Sonnet on low in order to Spawn5.5, get its results and then report those back.

It ends up being really cheap. It lets that spin up and use 5. 5 for real work and then come back with results. I was getting annoyed that I couldn't see which sub agents in workflows were using 5. 5, so I requested that it put a prefix in front so I can more easily see it and that ended up helping a ton. The tasks can timeout so I call this out. A lot of these are things that got appended as I ran into problems and I hope you take that lesson here. Most of this wasn't me having this epiphany on how to get it all right. I spent about half an hour getting it mostly working and then as I ran into problems I would go back to the original thread and tell Claude hey, I had this problem. How can we prevent this going forward?

And it would suggest changes. I would tell it to cut them in half and then put them in here. Went pretty well. And with that let's look at my skills which you might have noticed here There are not a whole lot of skills. I'm normally not a big skills user. In fact I plan to delete these once better models come out or better yet, Anthropic gets good at computer use. But for now having these here has been very helpful. I have Codex Review with a description that says you can ask the codec CLI5.5 for an independent code review of uncommitted changes, a branch diff, a commit, or a specific implementation. Yada yada. This is how you use it for review work. I then call out here that Codex is an independent reviewer when the user wants a second pass review or when the change is broad enough that another agent perspective is useful.

Yada yada yada. I define a workflow. You identify the review target, you create a temporary artifact directory for the Codex report. You run Codex Review with a focused review prompt and then you read Codex's report and verify the important claims against the code before presenting them again. This is meant to be called by a sub agent that is triggering Codex and it gets the feedback and then passes it back up to the parent model. The most important piece here is the commands. Not because the model can't get them right, but because the one or two times they get it wrong. It's really annoying. So you ask the model when that happens, what did you get wrong? What is the right structure for this? And then once you have that you can go add it here. And for me it has worked pretty damn well. There are then some instructions on how to prompt Codex because I've noticed that Claude likes to prompt Codex as though it is Claude, which it is not.

The prompt should be much simpler and this is an example of a very simple prompt that makes sense here. I would even argue things like do not edit files does not really necessarily need to be here because again, it's a Codex model. It's not going to do things you don't tell it to, unlike Claude models which love to do things you don't tell them to. Another problem I had is that sometimes Codex wouldn't find anything and that would confuse the parent model and it would rerun. So I added a bunch of these callouts like if Codex finds nothing, say that clearly and mention what the review target is that it inspected that ended up reducing the issues I had a ton. Again, you need to set this up for yourself. Don't just blindly copy paste my stuff. There's a reason I'm not posting the links anywhere.

I want you guys to learn from this, maybe screenshot it and pass it to the model and say hey who? I want to set up something similar. Can you guide me through it? Do it, learn it, change it, Experiment. If you're scared of going in and editing these files, you need to get over that. And if I let you guys just copy paste my stuff, you'll be afraid of breaking things when you make small changes. I need to know you won't be scared of that because this is where the fun comes in. I have a Codex implementation sub agent that's very similar for doing bounded work, usually on a work tree, in order to set up the model to go make changes and bring back useful results. It's a little more guarded than I would like, but it works pretty well overall. I haven't had enough issues to care.

If I do, I will change it and I will let you guys know in future videos. But my favorite by far is the computer use one, because this is what allows Claude to have Codex's computer use powers without having to build it into Claude or more importantly, waste a ton of your money in usage. Remember, the model only sees the description of the skill until it uses it, and once it uses it, it pulls all of the rest of the text in. So the description should have all of the info that Claude needs to know whether or not it should call this and get the rest of the context. This one's a little wordier than I would like, but it's been good about calling it when it should and not calling it when it shouldn't. It says ask codec CLI with GBD55 to run local app verification that needs computer use.

Browser automation simulators, screenshots, app launching, or independent runtime inspection. This is how 5.5 is invoked for computer use. Work use when the user asks Claude to have Codex or Five5 test a flow, verify user behavior, inspect a running app, capture screensh, or report confirmation feedback about implemented behavior. I might even change this now from when the user asks Claude to have Codex or GBD55 test a flow to just when the user asks Claude to test a flow to default here instead. In fact, we're going to do that use when the user asks Claude to test a flow, verify UI behavior, inspect a running app, capture screenshots, or report confirmation and feedback of unflinched behavior that benefits from computer use. Fun functionality. There we go again. Adapt these as you go, think about your experience and don't be afraid to make changes. It's so cheap to do and it can meaningfully improve your workflow.

And once you get in the habit of changing, editing and getting these things how you want, you'll end up much happier overall. And now is when we start diving into how I actually got all of this work done. Claude code is admittedly broken in a lot of ways, so it won't be the easiest thing to showcase, but I will do my best and I will break down how I was thinking about things and how I took advantage of them as well. I started with a really simple prompt. Investigate and review the open PRs for lakebed right now. This was a simple request. I wanted to ask the model to deal with all of the things that I had left open. Remember I said I had a bunch of open we now have the number. It was 16 open PRs of somewhat finished, somewhat trumped, somewhat dead work and the variety of the work there was crazy.

I call this out accordingly in the prompt. I think it's actually a good example of a prompt for this era of working Investigate and review the open PRs for lakebed right now I want a list that indicates the which are ready to merge, which are mostly good but need a rebase or other small touch ups which have been trumped either with better PRs or things that have already merged and which have good ideas but are better off, scrapped and rewritten. Use a workflow to break up the work in multiple reviewers to help solidify your decisions. And then it ran for a while. Not too long, but a meaningful amount. It spawned a workflow. You can see here the code that it wrote for said workflow. It ran for a while and then it came back with a list. All 48 agents finished. 16 investigators, one per PR each verdict then stress tested by Fable plus Opus judge panel.

14 of 16 calls were unanimous. I resolved the two contested ones below. Here's the triage. First we have one PR that was ready to merge, which was the separation of docs because I had both 5.5 and Opus 4.8 were kind of blurring the line between docs for my users and docs for the maintainers of Lakebed. So I did a hard cut and that PR was pretty good and easy to merge, so that got merged fast. Then there was a couple others that were mostly good but needed some touch ups. Then there was a pile of PRs that have been trumped and then the good ideas that should be scrapped and rewritten as well as pairing them together for the things that were similar. It gave a suggested order of operations. Start by merging 69, then fix the allow list for 68 and merge rebase 61 then 48 yada yada calls the ones to close out.

And all of this. I liked how it was thinking. I liked the feedback it gave. I actually did read all of this because I wanted to understand what it wanted to do. And once I was content with what it said, I realized, you know, I have a staging environment set up here. It won't affect prod if it gets things wrong. Let's yolo a little bit. This was a goal I set first. I said to close all PRs that have been trumped or are otherwise not worth keeping around. Then help me spec and prioritize the work for the other PRs you think you should close. Write up new HTML plans for a best path forward implementation for those features and fixes, honoring the goal of simplicity that we strive for in Lakebed. Break up the planning work into sub agents. Review the plans with sub agents as well.

A workflow may be helpful once you have plans you're happy with. For each of those pieces of work, share the links with me so I can review them. Make sure the plans you write have links to the PRs that they are inspired by. If multiple PRs implement the same feature, link to all of them. Make sure to describe where the existing implementation is and how you feel we should handle the next one. I was wrong. This one wasn't the goal. This is the go, clean up, destroy all the dead PRs and then tell me in detail what you want to do to the remaining stuff. And after a couple more minutes, it had done just that. It gave me links using my HTML planning skill for all the different things it wants to add and how it thinks they should be implemented. That was actually a really pleasant read, which by the way, I did on my phone.

Super convenient. So I read through most of these. I looked at the PRs that had inspired the changes and made an executive decision. All of them looked pretty damn good. Yeah, five of these remaining pieces looked really damn good. I did have one PR that I wanted to possibly merge at this point, so I asked it about that one. It took a look, it said it was good, so I merged it. Wait, no, I had to rebase it. Yeah, I asked it a question, which by the way, ask your models questions when you're not sure about things. It's a great opportunity to align yourself and the model and what the plan is for something. So I asked it, what are the streams of work we need to complete to address all the PRs that we've discussed? Is it as simple as Rebase 61, Merge 48 and 68 reimplement the rest.

If I wanted you to implement all of the plans you made, would it be best to do that as a single workflow or to make multiple work trees and threads by hand? Myself, I expected it here to push back and say, yeah, you obviously need to break this up into different threads. It decided to break this down into multiple streams. The first one being to land the four open PRs that were ready to go, then to implement the five plans that were left over. So 8ish PRs total. Also note that each plan deliberately decomposes into bounded PRs. The third plan apparently was going to be three separate PRs. Dual write, read, path, flip, then the column drop, and then yada yada. You get the idea. I don't want to bore you with the details of lakebed. And then we talked about the workflow to get this all done.

Single workflow versus handmade work trees. Neither, honestly. You don't need to make a work tree by hand either. A single workflow is the wrong tool for the umbrella. Workflows are deterministic scripts that shine for fan out and verify. But this program is checkpoint driven. Each PR needs CI your review and a merge before the next rebase. In midstream, you'll make product calls like the open questions that are below that a script can't anticipate. One giant workflow would either barrel past those checkpoints or stall at the first one. So it recommended that it orchestrate the streams from the session that we're already in. Spawn work trees itself to actually do the implementations, and then use workflows only where they're strong, which is for multi agent review passes before it merges the PRs. It also identified that certain places had parallelism possible, like a plan 2 and 3 could be run in parallel because they don't touch each other's stuff as much and it wouldn't have too many merge conflicts.

I then asked it to take all of this work and write it as a to do list in the directory so it'd be easier to just crank through all of it and then we get to the goal. Or more correctly put the insane world we now live in. I started a goal which basically tells the model keep going until the conditions pass. In this case, the conditions were to complete all of the work that we have discussed here. You have permission to create work trees, rebase, branch, merge PRs, close PRs, etc. This is me explicitly telling the model, you have my thumbs up. Merge away. This might sound insane. Kind of is But I'll show you why it's not as bad as you think in a little bit. But if we're all going to go insane here, and we all very well might, I'm going to do a second ad break Quick.

Building apps with React is really easy. That's why agents are so good at it. It's never been easier to build for the web, but it's still not that easy to build for mobile. And believe me, I've tried everything from Kotlin and Swift to React Native. It seems like AI just doesn't get it anywhere near as well. Getting those things right is super difficult, and having a good code base with a good team is essential. That's why knowing about Infinite Red is such a powerful hack right now. They can come in and modernize your code base. If you already have a mobile app, they can help start from scratch. They can onboard your team to do these things correctly. But in the end, what they're here to do is set you up to get your mobile app right. They obviously lean heavily into Expo and React Native, but if you want to build on Swift and Kotlin, they can help with that too.

They can even build the native bindings you need to get those parts right. And in a world where GPT 5.5 can invent a cloud from scratch in a few minutes, but but can't lay out a UI correctly on Xcode, Yes, I'm speaking from experience. It's actually insane how bad 5.5 is at mobile without having the right guidance at least, which is what Infinite Red is here to provide. Well, get your team set up with a good working code base and more importantly, a good working understanding of how to work in that code base. And then you can do the same with your agents. That's why everyone from Zoom and Microsoft to Domino's and Starbucks has worked with Infinite Red to polish up their mobile apps and get their teams ready to build better on React native. So if you're curious about React Native, or you're trying to fix an old broken app, or you want to get things right from the start, hit them up at soydev Link.

Infinite Red. Okay, as I was saying, we create the goal to complete, rebase, branch, merge, work, tree, all of the things it has to do to deal with this insane amount of work I put in front of it. This is like a month of work in a to do md. Now by the way, I tell it to go through all of the work step by step and mark each to do in to do MD done When completed to do md, changes should be committed and merged as you go. Use the tools available to you to break this work up logically, review it thoroughly and merge with confidence. Do not merge code until my automated code reviewers have approved it. In this case Bugbot, Macroscope and Code Rab because it's what I have set up in this org Goal set. Goal acknowledged. And then it ran for 5 hours and every time I checked GitHub on my phone more code had landed.

And that's how we got here with this giant pile of work that actually landed my whole month. Roadmap that I'd been running around in circles, not shipping, just thinking too much about now is in lakebed. It did the thing. This might sound insane like merging straight to main when the agent thinks it's good enough, but when you see all of the comments and all of the pushback, it got to clean up the implementations and keep them simple before merging. And you combine that with the most important fact, which is that production deployments are still a human in the loop. This is just the staging deployments that happen when you merge domain. So the model cannot ship or touch prod. The model can use staging for basically whatever it wants. I haven't done a prod deploy in a bit because also there were some things broken in my staging environment because of other models merging things they shouldn't have.

And I had Fable clean all of that up before even doing this work. So I started by having Fable get staging to a place I liked enough that I would be happy merging Main and shipping it to produce, but instead of just rushing there, I decided to clean up everything else. And it did, just went and went and went until everything was done and then I had it on main, I had it in staging and I went and personally stress tested it and also spun up other agents 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 de risk 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 goddamn Lakebed 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, like truly unbelievable. I wanted to keep working, but this one was running on my main laptop because I didn't think I would get this far. If I did, I would have done it on a different computer. But I was just playing around with the new Claude code and the new model and got way further than expected.

But I wanted to do other work on other projects. So that's when I started connecting to my Mac mini, to my other Linux boxes and to the other machines I have. Check out my Linux video if you haven't. It's covers a lot of this stuff and I started setting up CLAUDE on those and as usual I got really frustrated trying to use CLAUDE over SSH because all of these nice things I rely on like image pasting, decent select behaviors, scroll that works just weren't really viable. And I did what I always do. I went back to T3 code and goddamn has T3 code helped me maximize my utilization of this model a ton. The cool thing with T3 code is that you don't have to use it on the same machine that's running your agents. It's very easy to set up something like Tailscale and connect to to your other computer on the T3 Code website or on the T3 Code app on your computer, or if you're a little bold and you're down to try and build it yourself, the T3 code mobile app, which is also open source, which by the way, all this is open source, we have no way to charge for it yet.

We don't make money. I've probably spent over 250 grand both in tokens and salaries for the people working on T3 code. This is a gift. Enjoy it before I have to start charging. That all said, the T3 code mobile app is in the repo and you can build it yourself for your phone and it's really goddamn cool. I had no idea how much I was underrating it because I tried the first version when Julius was like three days in. He's been grinding on it for a month and it has gotten absurdly good. So I set that up on my phone, connected it to tailscale, connected it to my computers, instantly blown away. I was so blown away that we started working on T3 Connect, which is a service we'll hopefully ship in the near future that lets you not need to set up tailscale to get all these benefits.

You're a nerd, though. You can set up tailscale. Just do that. It's totally fine. Don't pay us money or wait for us when you could just have it yourself. The reason I bring all of this up is because it made parallelizing my work trivial. Every time I had an idea for a thing, or even when I was just on my phone and running into problems, I would just spin up a workflow for it or spin up a work tree or just get something done. When I was working from my phone, I kept noticing small bugs, so I kept spinning up new work trees to fix the bugs. Like, I wanted to have the repo for T3 code with a favicon at the root level because then it would have the little icon in the corner here like other projects do. As you see with T3 chat, lakebed, and other things, that we have a easily findable favicon in T3 codes was a little too hard to find, so I bumped it up higher so T3 code would see it.

I then asked it to commit and make a PR following the repo guidelines, and it did. And it looks like it had a transient failure because testing is hard and the cursor adapter is not as reliable as we want it to be. Cool. You know what this is? This is an opportunity to show you guys how I work. Here's what I do. First, I take a screenshot of the problem. Then I go to something like T3 code. I open this and I could pick which machine and which T3 code directory to use. Because this is a repo I have in a lot of different places. I have it on four different machines, and one of them has it in three different places. I'm just gonna do this in the standard T3 code repo on this project. I'm gonna pick whichever of my favorite models. In this case, I'm just gonna ask Fable to do it.

I'm going to paste the image. I'm going to say, figure out why this test fails randomly. It just failed for no reason on PR number 3683. And then a link to the bad run. It is on a work tree, so this won't affect other work. It has now been spawned and now I'm not as worried. Clicking the rerun job button and hopefully in just a moment, this PR will pass. And as you've probably noticed, the slowest part of this workflow by far is waiting for GitHub load times. I I cannot believe how bad of a state GitHub is in. I would gladly pay a hundred bucks a month for something just like GitHub with all the core features we need that is way faster. Ideally I would just pay it to GitHub and they would make their shit suck less, but that's never gonna happen at this point.

You get the idea though. And now I have this work going and while that's going, I can go see the status of other work I'm doing. Like my attempts to improve the connection experience when you're using SSH into a box and setting up T3 code on it so another machine can control it. I want that to be buttery smooth and I'm running really hoping we can get it there soon. For now, just ask your agents. It'll figure it out. But I want it to be one command. I then was working on a new machine I just set up and I wanted to see if it could get T3 code and the mobile app working properly. So I could not have to rely on this laptop as much for all of my iOS work. And it got pretty far. Had some computer use issues. I'm going to fix that after I finish recording.

This one was actually really fun though. This is an experiment I was trying. I had all of these work trees I spawned on my phone, and most of them were further along than expected and relatively simple changes. And rather than make Julius deal with like five different PRs, I decided instead to just ask Fable to combine them. Because some of them had overlap, some of them would have conflicted. I didn't want to deal with it, so I made an executive decision. I asked, can you access all these work trees on my machine? I'd love to pull the changes from all of them into one branch with conflicts handled so I can test them all at once. Five minutes later it did, and now I have this branch I can pull down on my laptop in order to test all the changes in. It's great. It handled the conflicts that existed because of multiple things that touched on each other's stuff.

And now I have all of this in one place where I can file a single PR and easily document everything that changed. I could even pull this onto a different computer like a Mac, and have it go verify all the changes too. I do want to be really clear about something. I don't expect the majority of the code I spawn this way to be ever used or merged part of this is just seeing how complex the problem is. Like, if I ask the model to go solve this problem and it takes under three minutes, it was probably a simple fix. And I won't feel bad filing that PR and telling Julius to get it merged. If it takes 15 minutes, that's a little scary. And I might want to pay more attention if it takes an hour or more. Oh, something's wrong with our architecture.

We need to go deeper and figure out what's up. The amount of time it takes and the amount of changes it has to make in order to make any of these things happen is a really good indicator for where the good and bad parts of your code base are. And for a lot of these, the changes were so simple. It's like an easy merge. Like, obviously you want to go put that up and do it, but for some of them, it took long enough that I'm a little bit concerned. For example, with the mobile thread scroll jumping stuff, this one, it took a while on. It took over an hour and a half. That scares me. I'm not going to blindly merge this code. I'm going to go put a lot more time in here. Especially compared to the issue that annoyed me more, which was sliding back, not behaving properly, which it fixed in 2 minutes and 20 seconds.

It was so simple. It concerned me because it talks about a drawer behavior. We didn't have a drawer. I think we might have in the past, though. So I just asked, do we even have a drawer anymore? Apparently we do, but the edge swipe gesture is the only entry point. No, we don't then. But now I know, like, it was kind of wrong about that. So I have to put a little more time in. You get the idea. You gotta think with your brain a bit. Not just like reading the code, thinking, but thinking about the architecture, thinking about the request, thinking about how fast or slow it was, how many things it touched, and then make a good decision accordingly. And if you don't know, just ask. You'll be amazed how useful the models are when you ask them questions about things. It's almost like that's what they were originally built for or something crazy.

Hopefully. This has been a good overview of how I have been working with Fable. As you can see, the sheer volume of work I'm doing and all of my projects has massively ramped up. I am more ambitious than ever, I'm having more fun than ever, and I'm pushing myself harder than ever. I do have one last pro tip for you, though. Vibe Proxy. If you're scared of hitting your limits, this might be worth setting up. It will auto split your traffic across multiple different accounts. I had heard about this before and I thought it would be a little sketchier or harder to set up. It really wasn't too bad. It is using the API key version of Claude code so you do lose like the built in slash remote control and a few other features like that. I haven't really missed it that much. I've actually found this pretty pleasant.

As you can see, I'm not getting close to my limits yet, but I do also have another four days before they take Fable from us in the subs, so I'm probably 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 and I hope you do too. So until next time, be nerds.