38:05Theo - t3․gg · Essay
Why I'm Moving to Linux (For Real)
A Mac loyalist explains why agentic coding broke macOS for him -- and how a fleet of $400 Linux mini-PCs fixed it.
July 3rdThe argument in one line.
Fable 5's real advantage over prior models isn't raw intelligence, it's how far it can be trusted to run unsupervised across long, multi-agent, multi-repo workflows, but only if the reasoning effort stays at 'high' and cheap models absorb the mechanical work.
Read if. Skip if.
READ IF YOU ARE…
- You use Claude Code (or a similar coding agent) daily and want a concrete cost-control and model-routing setup, not just hype.
- You maintain a CLAUDE.md or agent config file and want a real example of a model-ranking table and delegation rules to adapt.
- You're comfortable letting an agent merge to a staging branch unattended and want to see what guardrails make that survivable.
- You already use or are considering Codex CLI / GPT-5.5 alongside Claude and want a working cost-routing pattern between them.
SKIP IF…
- You want a neutral product comparison, this is one user's enthusiastic personal workflow, not a benchmark.
- You don't run agentic coding workflows at all; the specific tips (reasoning-effort slider, workflow vs sub-agent distinction) won't apply.
The full version, fast.
After losing access to Fable 5 mid-project and struggling with Opus 4.8 and GPT-5.5 as substitutes, the model returned and cleared a month of stalled pull requests in about three days. The core mechanism is model routing: keep Claude's reasoning effort at 'high' (never xhigh/max/ultracode, which overthink and balloon cost), and delegate bulk mechanical work, computer-use verification, and log/PDF-heavy investigation to GPT-5.5 through the Codex CLI, invoked via two custom skills. A CLAUDE.md table ranks cost, intelligence, and taste per model so the agent can self-select which one to call for a given task, with instructions to escalate to a smarter model rather than ship mediocre output. Applied to a real backlog of 16 stalled PRs, this let a single unattended 5.5-hour agent run merge real code to a staging branch for around $150, with production deploys still gated behind a human.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 02:25
01 · Cold open: the model came back
Theo recounts losing access to Fable 5, struggling with Opus 4.8 and GPT-5.5 as substitutes, and the model's sudden return outperforming his memory of it. Sets up the core warning: treating Fable like a smarter Opus won't work.
02:25 – 03:13
02 · Sponsor: Clerk
Auth and billing praised as the two things agents consistently get wrong; Clerk pitched as the fix, with a callback to Theo's own popular Stripe-recommendations repo.
03:13 – 05:08
03 · Proof: a month of PRs closed in days
Screen recording of the Lakebed GitHub PR dashboard shows a backlog of 20-30 half-finished PRs clearing rapidly; Theo explains why they piled up while he was stuck on weaker models.
05:08 – 08:22
04 · Min-maxing tip #1: never exceed 'high' reasoning effort
The central cost-control claim: xhigh, max, and ultracode overthink every step and blow up cost; 'high' is the correct default and Anthropic's own choice.
08:22 – 10:32
05 · Teaching Claude to call Codex/GPT-5.5
Explains the Codex sub's generous usage as the reason to offload heavy-token tasks (log digging, PDF specs, computer use) to GPT-5.5, cutting combined weekly usage to well under 50%.
10:32 – 16:40
06 · The CLAUDE.md model-selection table
Walks through the literal cost/intelligence/taste table for gpt-5.5, sonnet-5, opus-4.8, and fable-5, plus the 'escalate rather than ship mediocre' policy, showing a live edit to soften a line the model wrote.
16:40 – 20:00
07 · Skills: codex-review and computer-use delegation
Shows the actual SKILL.md files that let Claude shell out to Codex for independent code review and for OpenAI's computer-use capability, with the description-only-until-invoked mechanic explained.
20:00 – 27:30
08 · Live triage: 16 open PRs, 48 review agents
The actual first prompt used to triage a stalled PR backlog, the workflow it spawned (16 investigators, cross-checked by a Fable+Opus judge panel), and the resulting merge/rebase/scrap categorization.
27:30 – 29:30
09 · Sponsor: Infinite Red
Mobile app development pitch, framed around agents being far better at web UI than native mobile layout.
29:30 – 35:00
10 · The five-hour unattended goal run
Theo sets an explicit 'keep going until done' goal with standing permission to create work trees, rebase, and merge; the agent runs for 5.5 hours merging real PRs to staging, gated only by his own automated reviewers (BugBot, Macroscope, CodeRabbit) and a human-gated production deploy.
35:00 – 39:10
11 · Remote and mobile agent access via t3 code
Demonstrates connecting to other machines (Mac Mini, Linux boxes) over Tailscale through the t3 code app/mobile client to keep parallel agent work running while away from the main laptop, including a live GitHub CI-failure fix triggered from a phone screenshot.
39:10 – 43:15
12 · Judging agent work by how long it took
Closes with a heuristic for deciding whether to trust a sub-agent's fix: under three minutes is a safe merge, over ninety minutes is a signal the architecture needs real attention, plus a quick mention of Vibe Proxy for splitting traffic across accounts near usage limits.
Lines worth screenshotting.
- A five-and-a-half-hour unattended agent run that cleared a month of stalled PRs cost about $150 in total model spend, not the thousands a naive estimate would suggest.
- Reasoning effort above 'high' (xhigh, max, ultracode) makes Claude overthink each step and ship overdone, more expensive code, the fix is to leave it on 'high' and stop touching the slider.
- Reasoning effort only changes how much the model thinks per tool call, not how many steps or how long it can work for overall.
- Ultracode uses 'high' effort internally, it just spins up more agents in parallel, which is why Anthropic's own default is a better cost-to-quality bet than the flashier options.
- Routing bulk mechanical work (clear-spec implementation, data analysis, migrations) to GPT-5.5 makes that category of work effectively free.
- A working CLAUDE.md instruction was simply: judge the output, not the price tag, and escalating cost is less bad than shipping mediocre work.
- GPT-5.5 is only reachable through the Codex CLI, so a Claude workflow spawning a sub-agent must wrap it as a Sonnet-low agent that shells out to Codex and reports results back.
- GPT-5.5 writes TypeScript like a Python developer and Rust like an overly defensive C++ developer, which is why 'taste' is tracked as a separate axis from raw intelligence in the model-selection table.
- Never use Haiku for real work at this point, especially now that GPT-5.5 is cheap enough to functionally replace it for cost-sensitive tasks.
- Workflows (deterministic scripts for fan-out-and-verify) are the wrong tool for checkpoint-driven work like a PR-by-PR merge campaign, where each step needs CI, human review, and a merge before the next rebase can happen.
- The safety net for letting an agent merge PRs unsupervised for hours is that merges only land on staging, production deploys stay a manual human step.
- Wall-clock time an agent spends on a fix is a real signal for code-base health, a two-minute fix is a safe merge, a ninety-minute fix on something that should be simple is a sign the architecture needs attention.
- Reviewing the agent's own verification work burned more tokens than the original implementation work did, and it still found nothing that needed changing.
Route work by model strength, keep reasoning effort at high, and let autonomy loose only behind a staging gate.
AGENT WORKFLOW DESIGN
The gains from a more capable coding agent come less from raw intelligence and more from disciplined cost routing, a fixed reasoning-effort ceiling, and clear autonomy boundaries that make long unsupervised runs safe.
- Reasoning effort settings above a model's 'high' tier tend to cause overthinking per step rather than better results, so raising the slider further usually just raises cost without raising quality.
- A model's 'cost' rating should reflect what a task actually costs to run well, not sticker price alone, since a cheaper model that needs rework can cost more than a pricier one that gets it right the first time.
- Writing an explicit per-model ranking (cost, intelligence, taste) into a shared config file lets an orchestrating agent self-select the right model for each sub-task instead of defaulting to whichever one is already running.
- Bulk, clearly-specified mechanical work (data migrations, boilerplate implementation) is the cheapest category to delegate to a lower-cost model, freeing the higher-cost model for judgment calls.
- Deterministic multi-stage 'workflow' scripts are the wrong shape for work that needs a human checkpoint at each step; that kind of work needs a standing goal plus review gates, not a script that barrels through them.
- Letting an autonomous agent merge to a staging branch for hours is a different risk profile than letting it touch production, and keeping the production deploy behind a manual step is what makes the former tolerable.
- How long a sub-agent takes to complete a fix is a usable proxy for how healthy that part of the codebase is: fast fixes suggest simple, well-isolated code; unexpectedly slow fixes suggest a structural problem worth investigating directly.
- When unsure whether an agent's account of a system is accurate, asking it a direct clarifying question is often faster and more reliable than trying to verify by reading code alone.
Terms worth knowing.
- Reasoning effort
- A per-tool-call setting (low, medium, high, xhigh, max) that controls how much a coding agent thinks before each step; it does not extend how many total steps or how long the agent can keep working.
- Ultracode
- A Claude Code mode that runs the 'high' reasoning effort across many parallel agent instances rather than using a higher, slower thinking setting per call.
- Workflow (agentic)
- A programmatically defined script the model writes to fan work out across multiple sub-agents in stages, using the results of one stage to dynamically queue the next.
- Sub-agent
- An agent spawned by a parent agent via a tool call to independently complete a bounded piece of work, such as reviewing one file among several.
- Work tree
- An isolated git checkout used so an agent can make changes to a branch without those changes touching the shared working directory or colliding with other in-flight work.
- Codex CLI
- OpenAI's command-line coding agent interface, used here as the invocation path for GPT-5.5 and for OpenAI's computer-use (screen/simulator control) capability.
Things they pointed at.
41:55toolVibe Proxy
35:00toolt3 code (t3.chat coding client, incl. mobile app)
36:00toolTailscale
Lines you could clip.
00:00
“Saying Fable five has one shot me would be a criminal understatement.”
07:50
“If you take prompts that worked for Opus and you give them to Fable, it's not gonna be much better.”
14:50
“Judge the output, not the price tag. Escalating costs less than shipping mediocre work.”
29:15
“The model cannot ship or touch prod. The model can use staging for basically whatever it wants.”
41:10
“If it takes fifteen minutes, that's a little scary. If it takes an hour or more, oh, something's wrong with our architecture.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphoranalogystory
00:00Saying Fable five 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.
00:13I did my best to make decent work come out of Opus four eight and GPT five five, 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.
00:25It'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.
00:40It just, it was incredible to watch as the model cranked through all of these things that I've 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.
00:58It 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 gonna see the benefits. To put it simply, this model isn't a better Opus.
01:09If you take prompts that worked for Opus and you give them to Fable, it's not gonna 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.
01:28Especially 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.
01:41And with that, I do wanna 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.
02:01It'll help clear the air. It's not a necessary first view, but it will help a decent bit. This video is different though.
02:07This 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.
02:28And this really is a new era. Bable 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.
02:39Like, this model's 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 gonna have to pay for my therapy, and it'll probably come from the budget, thanks to today's sponsor.
02:51My 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.
03:01They're just like . 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.
03:13Well, was until I started using today's sponsor more, Clerk. Because not only do they have the best off 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 t three CodeElectron desktop app off for our new remote stuff that I'm really excited about.
03:29What'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.
03:53Once 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.
04:17Any one of these pieces would be worth moving to Clerk four, especially having the user profile component with all the billing info built in. The amount of time Mark loses dealing with billing disputes in 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.
04:34This 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.linkclerk.
04:47The 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 t three 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.
05:04This 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.
05:13It'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, it's like, I think 11 or 12 PRs that merged all, not just in one day, but from one thread.
05:34And 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.
05:46When 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 PRs stack up of work that was like 50 to 80% complete, but I didn't like the SDK changes it made.
06:04I didn't really have confidence in the implementation, 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.
06:14I probably had 20 or 30 PRs just sitting in this repo, not moving, and the project has been sitting there as a result. And I don't like that. I really want to ship Lakebed.
06:24I'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.
06:31I want it done. So we'll do that later. But I wanna 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.
06:41I'm gonna start in a weird place here, but I promise it will help. I'm gonna 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.
06:58That'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.
07:22You're probably thinking in the thousands, because that's what I would have expected. But it was only around a $150, not just Fable, but all of the other models I had Fable calling throughout.
07:31Wait, but Fable's so smart. Why are you using other models, Theo? And here's where the tips start.
07:36I mentioned in my previous video that I was teaching Fable how to use codecs, and I'm gonna show you how. But first, I just wanna make sure I emphasize this point.
07:44I 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.
07:54Those three options, pretty much everything to the right of high, these are dangerous. They look so enticing though, .
08:06I'm gonna beg you to not fall for it. High is way smarter. I know that sounds like I just made a mistake.
08:11I 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.
08:29Low, medium, and high might not be as efficient as like, g b d 5.5, but they are capable of things that five five 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 Hi can.
08:48But the reasoning effort only applies per tool call and per change. So if you have work that takes 500 steps, Max isn't gonna do more steps necessarily.
08:58It's gonna 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 gonna overthink the thing.
09:09And they do, and they do aggressively, as does Sonnet five, as arguably Opus four eight 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.
09:24So 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.
09:38By the way, you might not have known this, ultra code 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.
09:47Trust me, just 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.
09:54Now 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.
10:09The TLDR here is that the uses 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.
10:29More 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 using Codex is insane, so teaching Cloud Code how to call that is awesome. But the biggest thing is the tasks that require a lot of token usage.
10:47Things 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 didn't take too much time. I spent maybe an hour on this, and it has massively cut my costs.
11:07All those PRs I was showing, as I said, my usage across all the models is like 150, but that all fit easily in my two subs, my quad code sub and my codec sub. Neither broke 40% usage.
11:19In fact, my Codec sub was at like 15% or so for the whole week. And my ClaudeCode sub admittedly reset on like, I think it was Friday evening and we got the model back on was it Thursday or Wednesday?
11:31Yeah, 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.
11:47Md. 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.
11:55Honestly, I'm gonna change a lot of those to Lakebed 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.
12:09It's a thing I think a lot about. I haven't went quite as hard in my global quadMD 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.
12:22If computer use is helpful for completing or verifying work, shell out to g p t five five with codecs for it. Specifically, the words shell out here are important because what I'm telling the model is that it can call g p d five five via the shell, via bash, because it has the ability to use bash. It's using Cloud Code.
12:39Of course, 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.
12:46I have a section in my Cloud MD for picking the right models for workflows and sub agents. If you're not familiar with the difference here, sub agents 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 wanna have analyzed, you want five sub agents to analyze each one.
13:04Workflows are different. Workflows are programmatically defining all of the cool things that you need your sub agents to do.
13:11So if maybe you have different stages where the stage one is to go through each file, 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.
13:37For 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 sub agents to do different types of things.
13:52People have tried to build custom flows for this in their own tools like defining, this is what a review sub agent is. This is what an adversarial review sub agent is. This is what an exploratory sub agent is.
14:03That 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.
14:15And 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, it's awareness of the specific benefits and negatives of given models is not quite there.
14:29When 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.
14:41I also wanna 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.
14:52This 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.
15:08That'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.
15:15I think it's like $14 or so a month of inference you get right now. It's insane.
15:19And 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.
15:29As such, I ranked the cost in Five Five to be relatively good. The scores here are the score one to 10 on how beneficial is it for this thing.
15:39Five Five's costs 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 nine. This is me telling Fable, yo, by the way, you could basically use Five five for anything.
15:54I don't care. This model's just really efficient. And it does that.
15:58I 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.
16:13They 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 plus plus dev. It's just not the code I necessarily want, especially for like public facing SDKs and APIs.
16:30So even when I was using Five Five 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 gbt five five's cost and intelligence are both very high, but its taste, not necessarily quite as much so.
16:49If you're customizing your ClotMD 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.
17:03So 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.
17:13This 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.
17:30So as I said, Five Five, intelligent, no taste. And with Sonic Five, not much cheaper, much less intelligent, slightly more taste.
17:37Opus four eight, slightly more expensive because again, Sonic Five is so token hungry that Opus four eight's often cheaper. Meaningfully more intelligent, but still not quite as smart as Five Five, way higher taste.
17:49And 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 told the model how I feel. Then I told it how to apply these things.
18:01These 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.
18:09Judge 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.
18:18It 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.
18:28I 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.
18:40There. That's much better aligned with how I feel. Real changes happening on the fly, isn't that cool?
18:45Thanks for giving me an incentive to actually read the slop. Next, I can talk about bulk mechanical work, like clear spec implementations, data analysis migrations. Five five is effectively free.
18:53Anything user facing like UI copy API design needs taste greater than seven. Reviews of plans and implementations, Fable five or Opus four eight, optionally, five five is an extra independent perspective.
19:03A big call out here, never use Haiku. Just don't at this point. It's not useful for anything real, especially with five five being effectively free.
19:09I then call it the mechanic of 5.5 only being reachable through the Codec CLI. I say use the Codec implementation, Codec review, and Codec computer use skills for work that they don't cover. Investigation data analysis.
19:20Run Codec exec dash s read only directly with a self contained prompt. Instructions again on how to use Codex. I gave some instructions here on how to use five five inside of workflows with sub agents because you can't just call 55 as an option when defining a workflow, you have to call a Claude model when using Claude codes workflows.
19:38So I gave it some instructions here that it can use Sonnet on low in order to spawn Five Five, get its results, and then report those back. It ends up being really cheap. It lets that spin up and use Five Five for real work and then come back with results.
19:53I was getting annoyed that I couldn't see which sub agents and workflows were using Five Five, 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 time out, so I called this out. A lot of these are things that got appended as I ran into problems, and I hope you take that lesson here.
20:10Most 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?
20:23And 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.
20:33I'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.
20:43I have Codex review with a description that says you can ask the Codex CLI 5.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.
20:54I 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 user 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 Again, this is meant to be called by a sub agent that is triggering Codecs, and it gets the feedback and then passes it back up to the parent model.
21:23The 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?
21:34What 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.
21:41There are then some instructions on how to prompt codecs because I've noticed that Claude likes to prompt codecs 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 gonna do things you don't tell it to unlike Claude models, which love to do things you don't tell them to.
22:03Another 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 codecs 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.
22:18Again, you need to set this up for yourself. Don't just blindly copy paste my stuff.
22:22There'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, I wanna set up something similar. Can you guide me through it?
22:31Do 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.
22:43I 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.
22:59I 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.
23:15Remember, 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.
23:29This 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 GBD five five to run local app verification that needs computer use, browser automation, simulators, screenshots, app launching, or independent runtime infection.
23:45This is how 5.5 is invoked for computer use work. Use when the user asks Claude to have Codex or 5.5 test a flow, verify user behavior, inspect a running app, capture screenshots, or report confirmation feedback about implemented behavior. I might even change this now from when the user asks Claude to have Codex or gvd 5.5 test a flow to just when the user asks Claude to test a flow to default here instead.
24:07In fact, we're gonna do that. Usually when the user asks Claude to test a flow, verify UI behavior, inspect a running app, capture screenshots, or report confirmation and feedback of unfulfilled behavior that benefits from computer use functionality.
24:21There we go. Again, adapt these as you go. Think about your experience and don't be afraid to make changes.
24:26It'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.
24:41Cloud 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.
24:51I started with a really simple prompt. Investigate and review the open PRs for Lakebed right now. This was a simple request.
24:57I 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.
25:04It was 16 open PRs of somewhat finished, somewhat trumped, somewhat dead work. And the variety of the work there was crazy.
25:13I 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.
25:21I wanted a list that indicates the following. 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.
25:38And then it ran for a while. Not too long, but a meaningful amount. It spawned a workflow.
25:44You 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.
25:5216 investigators, one per PR, each verdict then stress tested by Fable plus Opus judge panel. 14 of 16 calls were unanimous.
26:00I 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 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.
26:14So 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.
26:22Then there was a pile of PRs that had 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.
26:32Start 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.
26:41I 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.
26:51It won't affect prod if it gets things wrong. Let's yolo a little bit. This was a goal I set.
26:58First, I said to close all PRs that have been trumped or 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.
27:15Break up the planning work into sub agents. Review the plans with sub agents as well. A workflow may be helpful.
27:20Once 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.
27:30Make 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 to the goal. This is the go clean up, destroy all the dead PRs, and then tell me in detail what you wanna do to the remaining stuff.
27:44And 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.
28:00Super convenient. So I read through most of these, I looked at the PRs that had inspired the changes and made an executive decision.
28:07All 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.
28:16It took a look. It said it was good. So I merged it.
28:20Wait, 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.
28:26It'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 forty eight and sixty eight, reimplement the rest?
28:39If 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.
28:54The 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 eight ish 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.
29:12You get the idea. I don't wanna bore you with the details of Lakebed. And then we talked about the workflow to get this all done.
29:18Single workflow versus handmade work trees. Neither honestly, and you don't need to make a work tree by hand either. A single workflow is the wrong tool for the umbrella.
29:26Workflows are deterministic scripts that shine for fan out and verify, but this program is checkpoint driven. Each PR needs CI, your review, and emerge before the next rebase. In midstream, you'll make product calls like the open questions that are below that a script can't anticipate.
29:41One 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 were 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 one before it merges the PRs.
29:58It also identified that certain places had parallelism possible, a plan two and three could be run-in parallel, so 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.
30:13And 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.
30:26You have permission to create work trees, rebase branch, merge PRs, close PRs, etcetera. This is me explicitly telling the model, you have my thumbs up, merge away. This might sound insane, kind of is, but I'll I'll show you why it's not as bad as you think in a little bit.
30:40But if we're all going to go insane here, and we all very well might, I'm gonna do a second ad break quick. Building apps with React is really easy.
30:48That'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.
30:54Believe 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.
31:06That'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.
31:14They 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.
31:29And in a world where GPT five point five can invent a cloud from scratch in a few minutes, 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.
31:52That'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.
32:07Linkinfinitered. 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.
32:20I tell it to go through all of the work step by step and mark each To Do in To Do. MD done when completed. The do.
32:26Md 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.
32:37In this case, BugBot, Macroscope, and CodeRab because it's what I have set up in this org. Goal set, goal acknowledged, and then it ran for five hours.
32:46And 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.
33:03It 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.
33:21This is just the staging deployments that happen when you merge to main. So the model cannot ship or touch prod. The model can use staging for basically whatever it wants.
33:31I 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 prod.
33:47But instead of just rushing there, I decided to clean up everything else. And it did it. It just went and went and went until everything was done.
33:57And then I had it on main. I had it in staging. And I went and personally stress tested it.
34:03And 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 risked and then spin up more tests to go check those things.
34:23And 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.
34:32And 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.
34:38Believe 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.
34:47And this workflow was just so cool to watch as it went. Like, truly unbelievable.
34:53I 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've 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.
35:05But 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.
35:14It 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.
35:29And I did what I always do. I went back to t three code. And goddamn, has t three code helped me maximize my utilization of this model a ton.
35:38The cool thing with t three 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 your other computer on the t three code website or on the t three code app on your computer.
35:51Or if you're a little bold and you're down to try and build it yourself, the t three code mobile app, which is also open source, which by the way, all of this is open source, we have no way to charge for it yet, we don't make money. I've probably spent over $250 both in tokens and salaries for the people working on t three code.
36:07This is a gift. Enjoy it before I have to start charging. That all said, the t three code mobile app is in the repo and you can build it yourself for your phone.
36:15And 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.
36:26So I set that up on my phone, connected to Tailscale, connected to my computers, instantly blown away.
36:31I was so blown away that we started working on t three 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.
36:43It'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 paralyzing my work trivial.
36:52Every 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'd kept noticing small bugs, so I kept spinning up new work trees to fix the bugs.
37:08Like I wanted to have the repo for t three 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 t three chat, lake bed, and other things that we have a easily findable favicon in. T three codes is a little too hard to find, so I bumped it up higher so t three code would see it.
37:26I 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.
37:37You know what this is? This is an opportunity to show you guys how I work. Here's what I do.
37:41First, I take a screenshot of the problem. Then I go to something like t three code. I open this, and I could pick which machine and which t three code directory to use because this is a repo I have in a lot of different places.
37:53I 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 t three code repo on this project.
38:01I'm gonna pick whichever of my favorite models. In this case, I'm just gonna ask Fable to do it. I'm gonna paste the image.
38:06I'm gonna say, figure out why this test fails randomly. It just failed for no reason on PR number three six eight three, and then a link to the bad run.
38:18It is on a work tree, 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.
38:34I cannot believe how bad of a state GitHub is in. I would gladly pay a $100 a month for something just like GitHub with all the core features we need. That is way faster.
38:43Ideally, 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 t three code on it so another machine can control it.
39:01I want that to be buttery smooth, and I'm really hoping we can get it there soon. For now, just ask your agent, they'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 t three 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.
39:18And it got pretty far, had some computer use issues. I'm gonna fix that after I finish recording. This one was actually really fun though.
39:23This 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.
39:40Because some of them had overlap, some of them would have conflicted, I didn't wanna deal with it. So I made an executive decision. I asked, can you access all these work trees on my machine?
39:48I'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.
39:59It'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.
40:10I could even pull this onto a different computer like a Mac and have it go verify all the changes too. I do wanna be really clear about something. I don't expect the majority of the code I spawn this way to be ever used or merged.
40:22Part 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 fifteen minutes, that's a little scary.
40:37I might wanna 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.
40:44The 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 wanna go put that up and do it.
40:58But 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.
41:09That scares me. I'm not gonna blindly merge this code. I'm gonna go put a lot more time in here.
41:13Especially compared to the issue that annoyed me more, which was sliding back not behaving properly, which it fixed in two minutes and twenty seconds. It was so simple it concerned me because it talked about a drawer behavior. We didn't have a drawer.
41:25I think we might have in the past though, so I just asked, do we even have a drawer anymore? Apparently, do, but the edge swipe gesture is the only entry point. No, we don't then.
41:34But 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.
41:43Not 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.
42:00It's almost like that's what they originally built for or something. Crazy. Hopefully, has been a good overview of how I have been working with Fable.
42:07As you can see, the sheer volume of work I'm doing in 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.
42:20Vibe proxy. If you're scared of hitting your limits, this might be worth setting up.
42:25It 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.
42:35It 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.
42:45As 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 gonna get a lot closer, especially once I finish recording. I thought this video would be short. That was foolish of me.
42:59I'm gonna go back to coding. I hope this inspires you to do the same. Let me know what you think of my workflow.
43:03Am 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.
43:12So until next time, peace nerds.
The Hook
The bait, then the rug-pull.
Theo opens by admitting the model's return has him half-delirious with how much it shipped in a single day, then spends the next forty minutes proving it wasn't hype: a real CLAUDE.md, real skill files, and a real five-and-a-half-hour unattended run that cleared sixteen stalled pull requests for about $150.
Named ideas worth stealing.
10:32model
Model cost/intelligence/taste table
- gpt-5.5: cost 9, intelligence 8, taste 5
- sonnet-5: cost 5, intelligence 7, taste 5
- opus-4.8: cost 4, intelligence 7, taste 8
- fable-5: cost 2, intelligence 9, taste 9
A CLAUDE.md table scoring each model 1-10 on cost-efficiency, intelligence, and taste (UI/UX, code quality, API design, copy), used by the agent to self-select which model to call for a given sub-task.
Steal forany multi-model agent setup where different tasks warrant different models
05:08concept
Reasoning-effort discipline
Keep reasoning effort at 'high' for all coding work; treat xhigh/max/ultracode as a cost trap because they cause the model to overthink individual steps rather than complete more of them.
Steal forany Claude Code or similar agent workflow where usage cost is a concern
15:00concept
Workflow vs. sub-agent vs. goal
- sub-agent: one spawned agent doing one bounded task
- workflow: a deterministic script fanning work across many sub-agents in stages
- goal: a standing instruction to keep working autonomously until stated conditions are met
Three distinct primitives for structuring agentic work, each suited to a different shape of task; workflows are wrong for checkpoint-driven work like a merge campaign, which needs a goal plus human-reviewed checkpoints instead.
Steal fordeciding how to structure any multi-step agentic task
How they asked for the click.
VERBAL ASK
42:20next-video
“Go watch that video first... this is the video where I show you all the things I've been doing with Fable.”
Soft cross-promotion to a companion video about Fable misconceptions, positioned as optional prior context rather than a hard gate; no explicit subscribe ask at the close, just a sign-off.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
