How To Give Claude Unlimited Usage

In case you haven't been able to tell by the chaos of my hair, my horrible sleep schedule, and all of the crazy things I've been building recently, plot has kind of oneshot me. Opus 5.5 is this weird balance of capability, focus, and a model, and price that I found to just be too fun and borderline addicting for me. Historically, I've tried to focus my advice on this channel less in the crazy token furnace stuff and more on realworld practical stuff because I'll be honest, that is still most of what I'm doing. But it's not all of what I'm doing and I want to indulge a little bit. This video is going to take everything I said in token maxing and go even further. This is not going to be a practical tips for getting the most out of Claude video. It's actually quite the opposite. All the advice I've given has focused on real projects like T3 Code or T3 OS. I know it's crazy making an OS, but I promise you it's going to make sense when it's out. Where the average cost per prompt I send is in the $8 range or cheaper. Sometimes as cheap as two bucks. I'm here to talk about these three. The projects where every time I send something, hundreds of dollars will be lit on fire. The projects that don't run for an hour when I send a message.

They run for weeks when I send a message. the projects that have cost me more in compute than they've cost me in tokens. But both numbers are truly absurdly high. The projects that go viral on Twitter and ruin my life and sometimes, very rarely, but sometimes come out actually useful. You probably already heard about my project TS Rust where I rewrote TypeScript in Rust to make the compilation and build times significantly faster, four to 10 times faster depending on your use case. What you might not have heard of though is Lust, my new Rust compiler, a drop in replacement for cargo that lets you compile a subset of Rust a 100 times faster or more. This video is going to be all about the projects that shouldn't work, that somehow do, but more importantly, the strategies that I use to let Claude run forever in hopes that it might actually pull off something that seems impossible because just weeks ago it was. This video is not meant to be a guide on how to replicate my workflows because I don't think anyone should be doing this, myself included.

This is meant to show the horrible things I've done to drain my seven cla accounts. I know it's six here. I'm lending one to Julius right now, but you'll understand in a bit. I'm mostly making this video out of frustration because these things shouldn't work and I just need to complain because they do. This video is not going to be for serious devs trying to get serious advice. I do have one piece of advice for you before we start, though. You should probably check out today's sponsor. I'm not sure if y'all have noticed, but personal agents seem like they're doing much better nowadays. I got a hot take about this, though. It's not because the models got cheaper or smarter or some other thing. It's actually because of the tools the agents have access to. It turns out if you give a smart enough model access to good enough tools to do things like, I don't know, browse the web and make real decisions on users behaves, the knowledge of the model matters a lot less and the ability to use these tools matters a lot more. Which means, of course, you should have a good way for your agents to access the web. Thankfully, Browser Base is here and they have you covered. These guys built the best possible solution for your agents to have access to the whole web.

Whether they're searching to find data they need, they are fetching from pages they can't normally access, of course, in formats that they can use like HTML, JSON, or even markdown. Or they're trying to actually navigate real web pages. Browserbase has you covered for all of this and more. You might be seeing this and think, "Well, Theo, I know how to deploy Puppeteer myself." Sure you do. I do, too. I used to do it a lot. I stopped because I ran into so many problems. Whether it was the over or underprovisioning that made it really expensive to run these boxes, or if it was all the limits I would hit with different IP addresses causing things to not actually resolve, or it was just the weird bugs and experience issues that my agents would run into when they were running those browsers. This includes all the annoying edges that you and your agents will hit. Whether it's getting through captas, managing file uploads and downloads, actually navigating forms, pages, and APIs that your stuff can't normally hit over curl. What I'm trying to say is simple. Agents do much better when they have access to the whole web the way you and I do. Give them that access today at soyv.link/browserbase. The projects that I'm talking about today have had Claude running for almost 4,000 hours across all of my different agents. I want to explain why and how and what this has resulted in. And I'm going to start somewhere you probably don't expect. Not TS Rust, not Lust.

Gonna start with Skate 3 Bench. This might be confusing because you guys have seen skatebench. It's a pretty simple benchmark. I describe a skateboard trick and then I see if the model can name the trick. I have two versions of skate bench. I have the original skate bench, which most models saturated, and then I have what's called skatebench private, which is effectively v2, which has a bunch of problems that are not public info because I noticed some of the labs. Yes, I actually did. I noticed some of the labs using my bench as data and getting perfect scores on the questions that were there and then bombing all the questions that weren't. So, I had to privatize SkateBench so that the models couldn't climb against it during training. But, I wanted to go bigger. I wanted to make something different. Especially after I saw that Gemini 4 Argan, despite being a show of a model, got a perfect score on my private version of Skatebench. I realized it was time to make something different. This is Skate 3 Bench. Well, this is the thread that I started this in. This thread ran for 4 days straight with basically no input from me separately.

But what is it? What did I possibly do with skateboards that took 4 plus days to run and burned thousands of dollars in inference? According to my rough math, the inference I used for this project would be nearly $5,000. It was over 12 billion tokens and only 25 prompts from me. And most of those prompts, by the way, were the word continue when I had to reboot machines. Well, in order to show what this is, I need something else. I need an Xbox controller because Skate 3 Bench is not a bench that names tricks. It's not even a bench that ports a game. Skate 3 Bench is a new game and engine created from scratch by Claude to replicate the experience of playing the skate games back in the day. This game was created entirely from scratch by Claude. I think it downloaded a rough model of a man from some asset store for Blender and then customized it to look kind of a little bit like me. I gave it examples of the controls I liked from Skate and said to recreate them to the best of its ability.

Told it what to include and not include to make a little park and get the gameplay working. And this is a actually playable clone of EA skate, which is not as trivial as it sounds because the control system in skate is a a challenge. You don't jump by pressing a button. Everything is based on a flick it system where the way you move the right joystick is what determines the tricks. This is all running in my browser in a 3JSbased engine that was built by the Clouds and the physics feel surprisingly decent overall. It's not perfect, but it's better than most of the skate clones I've played in my life. And I've played a lot of clones of the original skate. Some recent change screwed up the inward heel flip animation. It used to be a lot better. Yeah, I could sit here and just stick around doing silly tricks all day. This is the bad habit I have having played so much of these games in my life. The fact that it could make something that is this passible honestly is just kind of insane. But if you were to just go tell Claude, make me a clone of Skate, make no mistakes, it's not going to come out anywhere near this good. So, what the hell did I do that let it be this good? I had a couple tricks that I think will make it easy to understand. I do want to jump in front of something first, though. I'm not the only one vibing cool things with Skate right now. There's a project called Skate 3 Rust Engine, which is an attempt to rewrite Skate 3 itself line by line from the decomp to replicate all of the

physics in Bevy and recreate the game. This type of thing is actually relatively easy to hill climb. It's not far from how I set things up for TS Rust. But what I did here isn't that I'm not going through an existing project and trying to replicate capabilities one at a time. I'm doing something very different with this. I'm trying to make something that didn't exist in a way that doesn't exist. Recreating things is quite trivial to hill climb. And I'll show examples of that in a bit. But that idea of hill climbing is the important thing you need to understand. In order for any of this to make sense, we're going to have to talk a bit about hill climbing. What do I even mean by this? The way models are trained is through reward mechanisms. Easiest way I can think to describe this would be a game of tic-tac-toe. Let's say you're training a model to be the best in the world at tic-tac-toe. You give it a board that's already in a certain state. Let's say you have this clear obvious win where you put the piece here. You give the current state of things to a model that is being trained and you ask it where it thinks the next piece should go. If it picks one of the spots you don't want, like here or here, then the model failed. But if it picks the right spot, which would be here, the model is rewarded because it's succeeded. This is the simplest possible example of what I'm referring to here. But the idea is that the model has things that it can verify as success or failure. And then after it completes a run, the model can be adjusted so that it's more likely to

do the thing that worked and less likely to do the thing that didn't. Models kind of have two pieces. They have knowledge and behavior. knowledge is usually from the data that they are trained on like the things and the facts and the info that they are given in the pre-training process and then the behavior largely comes out of the RL which is teaching the model to act and behave in certain ways instead of just responding to a basic question it tries to make a tool call to get more info that it needs or it tests a theory and writes code to validate the theory and then when it fails it tries something else. By default a model is just going to answer your question. It's not going to test theories or try things out. is just going to answer based on its knowledge. So we do these types of training in order to make the model behave differently to get it to run for longer to solve problems to do stuff that we would want a model to do. This example is hilariously simple for this. It's play tic-tac-toe. The model should be shown what successful looks like and what failure looks like and then run until it succeeds. A simpler version of this would be a unit test. Let's say we have a test that is take x.ts ts and output it as x.js and also log these three errors that are error one, error two, and error three. If I had something set up this way where I had a specific file, a TypeScript file, and I had the output JavaScript after it compiles, as well as any of the errors that the Tyer

compiler would have had in this case, I now can make a thing or have a model make a thing. And it succeeds if I run the code it wrote and the right things come out and it fails if I run the code and something else comes out. The term for this is RLVR, reinforcement learning, which stands for reinforcement learning with verifiable rewards. What this means is that the model is being trained against tools that can check programmatically, did it succeed or did it fail? So during training, most of what the model sees is stuff like this. I have file A. I want you to write code that transforms it into file B and gives these errors. Here's five more examples. I have 500 examples that I will not show you. I want you to make all five examples pass and then I will tell you if you succeeded or not. And from there the model is morphed into the behaviors that we want. So what does any of this have to do with running really long tasks? Well, I kind of spoiled part of it here. Typescript is a really good example of something that you can use in this way. Since Typescript has a lot of verifiable outputs, you can just take any TypeScript project that exists and then compile it using the official TypeScript compiler and then you get a bunch of outputs as well as the final file that you can go use. If you then take those projects and intentionally insert random errors in them, run that against TypeScript, you will see where those errors are. And if you try to run this against your port and you don't see

those errors, then you know your code isn't working. This is very similar to the environments that the models are being trained in because they should be able to make code that can take value A and turn it into value B as long as that could be done consistently. So when I did TS Rust, this was pretty easy. I told the model, take this set of realworld projects, run with a pinned version of TypeScript, figure out exactly what the outputs are, and then chase that. You are not done until we can run on all of these projects and get the exact same outputs that we get with TypeScript the normal package with our package TS Rust. You would be amazed at how good models are when you give them clear goals like that. That's why TS Rust was able to start working in a day and get really good in a few weeks. Because after you get it working and you have verifiable inputs and outputs, you can do the next step. Instead of just saying, "Take this and make sure the errors match," you can go deeper. You can tell it something like, "Make it two times faster than the official version.

Make sure all existing validation and tests still pass." When I did TS Rust, the first working version was slower than TSGO, which is the official TypeScript. I told it, "Do not stop until you're two times faster." And it kept going until it was two times faster because it knows how to check if it worked, and it knows how to check if it's fast. The more you make your task similar to the ways the model was trained, the better it will do at completing those tasks. So, how do we do this for things that aren't so simple to verify? Like, as crazy as the TypeScript report is, it's relatively easy to verify it. The output should be exactly the same and the outputs are quite simple. They're just text. So, how would you do this for a video game? I had a complex way of doing this that I want to try in the future, but I went with a much simpler method for my first version. I know I've talked a lot of crap on slash goal in the past. I still don't think you should use it. It is a foot gun that doesn't work when you point it up. This is a tool that is only there to hurt you, but if you're trying to get hurt, it's actually quite fun.

So, slash goal. Create a compelling web game that replicates the physics and controls of EA's Skate 3. The game should work with controller inputs. You can simulate them if needed. The core experience is skating around in a small skate park. The most important things to get right in here is the controls and physics. I voice the text to this pretty hard, so a lot of things broke. The core mechanics in EA skate involve not using buttons for tricks. Rather, you use the right joystick to recreate motions similar to those of real skaters. These have been recreated in other games, and I want to make sure that you get those mechanics right. I had some details about the camera placement, details about all the core flip tricks that need to be included. And here is where I made it hill climbable. The game should look good. You should be able to take a screenshot of it, compare it to the original skate, and honestly say that the graphics quality is similar. You have access to Blender and you should use it for models where it makes sense. Get gameplay as functional as you can first with models that feel like skateboarding and clear readouts for the names of the tricks when I do them. You'll have to animate them all yourself. Continue until you have a game that feels like the original skate. So, the hill climb is here. You should be able to take a screenshot of it, compare it to the original skate, and honestly say the graphical quality is similar. At some point in here, I set an updated goal. I'm going to be real. I don't feel like scrolling through until I find it.

But what I eventually effectively did is I told the model that every time it has a build that it is happy with, it should take a bunch of screenshots of it in specific states, compare those screenshots to real skate footage from the real games, and then have a panel of judges compare the original game with my game and give feedback as to whether or not mine looks good enough. And now we can see how the model hill climbed. It grabbed screenshots of random moments throughout and then grabbed screenshots of similar moments in my game and then gave these to another LLM or set of LLMs to judge and give feedback saying whether or not the version it made was better. I want to be clear with what I'm showing here. I don't think this is good. I don't think this is even okay. I'm genuinely surprised that this worked. My original plan was going to be a bit more intense. I was going to actually play skate one, record my controller inputs, and then give that as a replay value that my agents could use to rerun and effectively like pass themselves with the game it makes and then compare how well my game behaves and how random frames from it compare with my game and the original. But I was lazy. I just told it to compare screenshots and that was enough. It gave the model something to pursue and work on. And as long as it has something it can check and decide if it's good enough

or not and then keep going if it's not, you can get the model running for a while. And as long as the thing it is checking is aligned enough with what your goals are, you're going to end up with something at least somewhat resembling what you asked for. It will have strange issues. Like I'm pretty sure this spent at least $800 in tokens trying to get the skybox to look more similar to skate. It also kept trying to make the game brighter because I was comparing it to Skate 3 originally and I think Skate 3's graphics are hideous. So, I reset it and told it like, "No, Skate One is the thing to reference. I like the way it looks much better." But like, I did this by bullying the model into creating screenshots, setting up a panel to compare with the original game, and then say what it thinks is better and worse and why, and then iterate accordingly. Now that you guys have the basics in mind, I want to break down how I set things up to hill climb with Claude the way that I do. Step one, you need to come up with something that you want. The more tedious, the better.

We're all engineers, and we optimize to skip and avoid tedium, and that's what makes us successful. We were willing to write code for an hour to save ourselves 30 seconds of work once a week. That's what makes us developers. But we have a bar of like something being too tedious. As much as we all used to like rewriting the tools we use in whatever language or stack that we like to use, we might not like rewriting some old codebase in a language we don't like into another language we don't like. That type of work is incredibly tedious and grading. And I'm sure I'm not alone here that I hate those types of things. So, I've had to rewire my brain a bunch here because I have historically done everything in my power to avoid tedious stuff. Now, I need to lean into it. The more tedious a task I can come up with, the more likely it is that the models can take advantage of that and do crazy things. Rewriting a 100,000 plus file codebase in Rust would be miserable as a human, but an agent doesn't care. So find something that you wish existed or that you want or that you're curious about and find a way to make it as tedious as possible. I should actually put a step zero at the top here. You have to get a lot of cloud subs you don't mind burning. None of this is worth it for the dollar value actually that I now I think about it. Um TS Rust only being $38,000 is worth it considering how many hours this will save us in build times for our real world work. 38 grand is actually a good deal for TS Rust. The rest of these are nonsense though. But like still don't pay the API prices. When I got the first like working build of TS Rust that was

2x faster. It was the equivalent of $500 of subscription usage through Claude. This is all API costs. That's not what we're paying. We're all paying sub prices. Don't do this over API prices. Do this with $200 Cloud subs that you can abuse because you're able to build something as crazy as TS Rust with just 10 weeks or so of usage. And if you're not willing to like burn a bunch of subs to the ground, then watch this out of curiosity, not out of plans to replicate. So get your cloud subs, come up with something that you want. The more tedious the better. Then step two, the most important piece, find some way to verify it. Something that you or an agent could do easily to look at the thing it made and be able to tell if it has succeeded yet or not. This is where being clever really starts to shine. There are lots of easy things here like with TS Rust, it was relatively trivial to say, take these code bases, make sure they work, then start making random errors appear in the codebase and make sure those work too. That is a relatively easy way to come up with a verification loop for an agent porting something like that. The ones I came up with for Skate 3 Bench are a little weirder and more clever and I'm quite proud of them. Ideally, they shouldn't need human intervention though cuz if it requires a human to look at the thing and say that's good or bad and here's why, it's not going to make a lot of progress. You're going to be spending so much time sitting there waiting. TS Rust had like 1,800 revisions or so. 7,884 commits were filed on TS Rust during the loops. You need some way to programmatically verify with code that

says pass or fail or at the absolute least a way that another agent can look at the results and decide if it's working or not. And then we have step three. You need to set your agents up for success. They know what they need to do. They know what success looks like enough. They know what failure looks like enough. Now they need the tools to succeed. If you asked Chat GBT to do any of the stuff that I've shown here, it would fail because it doesn't have the tools it needs. It probably needs a computer with a GPU and a guey in order to do something like Skate 3B where it has to run Blender, generate assets, put them in the browser, and then make sure that they come out correctly. But you need to figure out what it is that your agents need to succeed with the task. Another important thing to note is that this changes over time and the amount of need that the agents have can also shift over time, especially once you're getting into heavy parallelism. I got a real funny story and some good pro tips to show you about this. In particular, I have some things that have changed how I build with agents on a fundamental level that like actually broke my brain. I only just got permission to talk about these recently, so I'm very excited to and I bet you'll love them a lot. So, in order to explain this new secret trick I found to unblock my agents, I need to talk a bit more about TS Rust and the bottlenecks I hit as I ran. As I mentioned before, the whole port cost about 40 grand of API cost. For my earlier calculations, I got around $500 to maybe $800 of sub usage because

remember the subscriptions are massively subsidized. You get like 12 grand of usage for the $200 plan. So, at most I would have spent around $800 on my cloud subs to get TS Rust. How much do you think I spent on compute for this project? $500 of cloud subs. How much money do you think the compute cost me? I ask because I was in need of compute heavily during this project. I was like grabbing computers out of storage and installing T3os on them. I had a stack of minis forum machines that I was planning on giving to some founders that I've temporarily commandeered just to do all of my builds. Here you can see how much time my agents were spending just waiting in the queue before they could even run the build to test their changes. So I had like eight different computers on my local network as well as two VPSs that my agents could SSH into to run builds and checks. I'm not going to calculate how much the electricity cost or all the machines I had around cost. I'm just going to calculate when I moved to Blacksmith. And I want to be clear here. I love Blacksmith. They're a sponsor and they're a sponsor for a reason. We use them for our CI for everything. They are an incredibly cheap platform for running your CI and builds and agents and all of this. They definitely have optimized Blacksmith for running jobs you've already defined in your repo, things that are like GitHub actions and whatnot, not for your agent to just SSH into and do We use Blacksmith for all of T3 codec CI and it has saved us so much time and money.

It's hilarious. Which is why I need you to understand that this number is not meant to go after Blacksmith. It's actually the opposite. I spent over two grand on compute on Blacksmith for all of my tests for TS Rust. This isn't the CI bill to be clear. The CI bill was only a couple bucks, probably like under 30. But I was running out of compute on my local network. You can see here all of this time spent waiting. This means that if the model had to do a job that took 10 minutes, it was sitting in a queue waiting for compute to be available for up to an hour before it could even start running that work. This is because as fast as Rust itself is, Rust's compiler is incredibly slow. The reasons why it's slow have actually surprised me quite a bit. It's not the borrow checker, believe it or not. It's a lot of other things. And also, as I mentioned before, Blacksmith is not really a platform built for this type of work. It's much more for running programmatic jobs that already exist in your repo. But I was able to get it working here. I got my agents to unblock themselves using Blacksmith to create jobs and run things in the cloud. And you can see that the time that my agents spent waiting for compute to be available hit the floor as soon as I had Blacksmith set up for this. Before I switched to this blacksmith offloading compute strategy, my agents would per run have to wait upwards of 12 hours to have compute available to do their work.

This change knocked us down to 1.2 hours. And I immediately saw the difference. Code was landing so much faster. But each of these jobs was still taking way too long. We're talking 20 to 40 minutes for my builds just to get the code in a state where I can check if it worked or not. That inspired me to do my other insane YOLO project. And that's why Lust exists because I didn't want TS Rust to take so goddamn long to compile. But I promised you guys a secret. A thing that unlocked my chaos building with agents. And as much as I love Blacksmith, it isn't that. As great as Blacksmith is, Blacksmith is for serious projects that have serious verification systems, CI releases, etc. to make your bill reasonably low and your insights really good. I personally would not recommend that you tell your agents to use Blacksmith in their local dev loop unless it is just checking existing CI stuff. And here's where I have to hope I don't screw myself. So, we have to talk about boat specifically boat.dev. Boat is one of the coolest things I have used in years. And you know that because as soon as I mention it, Maria freaks out in chat. No, Theo, don't saturate it. I gave the team a heads up and I'm scared this is going to hurt things. I already have my team freaking out. The reason they're freaking out is cuz boat's one of those things that feels almost too good to be true. It is a very, very, almost absurdly convenient way to let your agents spin up VMs when they need

to. I would tell you what it did, but I could also just quote myself on the website. I DM' them this quote and told them to put it on the site. I haven't liked a new company this much in a while. Boat unblocked my agent so hard that I'm burning through my cloud accounts four times faster. I couldn't be happier. This is why I had to go from six cloud accounts to seven. So, what is boat? It's a really easy way to spin up a VM that you don't care about. I will show you how easy it is by running it locally. I install boat. Oh, they have a UI failure here. Uh, this should say one GitHub here. I don't know why it doesn't. Uh, I'll have my agent report that in a minute. I don't want to share the info that comes out of the terminal, but here I have my boat dashboard and CLI is now set up. I type in boat. I can see all the things that it gives me access to. I can also type boat limits and see what my current limits are on my $500 a month plan. Yes, I'm paying for a subscription for compute. The reason it's built this way is the way the compute itself works. You get a certain number of concurrent sandboxes you can run. A certain number of starts a minute, an hour, and a day. And then separately, the actual cost of the usage once the boxes are spun up. I start on the $20 plan. I bumped to the 100. Then I bumped to the 500. And honestly, I'm eyeing the $2,000 plan very, very tempted because of how much this has unblocked my agents. The magic of boat is how easy it is to just spin up boxes when you need them. Boat new. Now I have

my own sandbox on boat. If I want to connect boat SSH and now I'm in. I could install BTOP or any other tools if I want to. I'm so used to my having BTOP by default. And if you do need a guey, you can get that with the boat desktop command. And now I have a real Linux desktop with browsers, terminals, and more that I can use for whatever I'm working on. I don't think it's got a GPU. It's almost certainly not going to be like hardware accelerated, but you can use boat directly like this. More importantly though, your agents can too. And since everything is just through the terminal, it's pretty easy. Here I can list all of the boxes that I currently have. And if I want to kill one, I can. Vote stop ID. And now that box is dead. You might see all of these lust gate boxes. Those are the ones that the lust goal spins up whenever one of the sub aents needs compute. What there are so many little things they've built into both that make it really awesome for this use case. in particular, how easy it is to snapshot things and spin up a bunch of versions of a snapshot. Allows my agent to one time clone the repo, pull everything down, build it once, get everything like hot reloaded and set up pretty good, snapshot it, and now when other agents need it, they don't have to pull down the whole universe. They just spin up that snapshot and then add things on top to test the changes that they're making. Previously, before I set up boat, my agents were using four shared slots on this machine that they

were building on, which is a VPS that I use for a lot of my agent work. And the gate time was 40 to 70 minutes under load, sometimes even more. So, I was only able to land as much as like 70 changes a day and only like twoish changes per package per day. Once I set boat up, I was able to trivially spin up multiple boxes at any given time. And when I say me, I mean my agents. And it knocked the time per gate down from 70 minutes to 353 seconds, only 6 minutes. It more than doubled the amount of code I could land in a given day. It's actually closer to triple. And the project started advancing way faster. It is a bit absurd how much I've spent on boat, but when you see how hilariously cheap it is, yeah, it's a very good platform. I'm super happy with it. I will say I liked it so much that I invested. I bullied them into accepting a check. I like it a lot. Highly recommend. I want to be very clear that the point of something like boat isn't to spin up servers that you point things for your users at. The point of something like boat is when you need a bunch of random VMs for random work when the amount of compute you need for the things you're doing goes up and down over time.

Because when you accept your new job here, which is supply the agents with what they need, you'll quickly realize that their needs are flexible. If you're supplying the hardware at the office you work at for your team, you probably need one desk and one monitor per person. But if they just shifted the hours they worked and you had every person working eight hours and it was just when one person leaves, the next one comes in, you could cut the number of desks and monitors you need by 2/3. But obviously that doesn't work. you want everybody there working at once and as such you have to buy enough to supply your peak usage not your average usage. So if you're buying enough compute to let your agents do everything they might want to either you spent too much because usually your agents don't need all that compute or you spent too little and your agents are going to be blocked a lot of the time. The reason I'm liking both so much is it's really easy to flex up and down depending on what my agents are working on at any given time. But now we get into the most important step.

Step four, ask your agents what the biggest blockers are. I had two threads running for TS Rust. One was the infinite goal just constantly trying to make the TypeScript build in Rust faster. The other is a thread I would use to check in sometimes. I told it like read the history, give me an update on what's going on. Eventually, I noticed that progress was slowing. So, I asked the second thread, hey, what is currently bottlenecking the work being done? What are the biggest problems? to which I learned Claude had to build a queue to determine which run has permission to run the Rust stuff before it crashes. Initially, it would just run too many things at once. The computer would oo and die. So, I asked it how to fix that. It created the queue. I asked it how to speed things up and it told me it needed more compute. So, I brought all the computers I had around online, gave it SSH access and let it split the work across those. Helped. I moved over to Blacksmith cuz I wanted the compute back. Helped even more. And then, obviously, I went even crazier with Lust. But what I want to emphasize here is that three and four aren't one and done steps. This is a loop. Once you have set up the environment with the task that you want to have solved and a way that the agent can verify, you still have work to do. The work isn't read every line of code, verify everything going on. it is work with the agent to get it what it needs to do its job and then keep asking it what is slowing it down what's blocking it what's up what can I do to help and over time you will get the agent to move a lot faster and

as you do this you'll eventually also have to branch off and go up and get more cloud subs because if you get really good at this you're going to burn through those subs a lot faster when I had TS Rust running on just one computer I was only able to burn one to two quad subs a week once I had abstracted all the compute I was easily able to burn through all seven of my subs pretty quick. When people say that running agents is like being a manager, this is what we're referring to. It's not your job to check every single piece of work your employees do. It's your job to set them up for success, ask them what's slowing them down, and keep building the best environment for them to be in. And ready for the best part. I told you that this loop gets you back to step zero, which is buying more cloud subs. It also gets you back to step one. Because as you realize there are things that block your agents or make them slower, some of those might be hill climbable themselves. For example, when you're rewriting TypeScript in Rust, you'll start to realize how slow and heavy the Rust compiler is. And if you think about it too much, you see the opportunity to go a couple layers deeper, which is again why we ended up with Lustlang. And that's why this PR exists because the whole point of Lust was to unblock my other project TS Rust. Will this compiler work for other apps? Almost certainly not. It barely even works for TS Rust. I've had to reinvent so many features in Rust and Cargo and even LVM in order to make this build. But now it's able to take a build that took 17 minutes with Cargo and run it in 12 seconds instead. This one's still running cuz I gave it two very bold

goals. The first was make it so that builds and all CI is 100 times faster than cargo. And second, make sure that the resulting output binary is within 20% margin for performance. Because again, the RS compiler does a bunch of crazy I'm not verifying that the binary output is the same of the two things, similar to how I did with the TypeScript Rust project. These are going to be different binaries. So, I need to make sure they both work and are performant once they come out. And here we see it saying confidently that it managed to hit my target. These numbers are super close to 1.2x 2x because that was the bar I set for it. And now this truly insane project, this thing that just felt like lost, like it wasn't viable. It was chasing the dragon we shouldn't have, it's actually working. It's crazy. And as you start to think this way and you're willing to burn tokens this way, you'll see more and more of these things. And as you build these loops, you'll just see more opportunities to make more of them appear. And you realize everything that we work on, everything we use, everything we rely on every day is flexible. We can all play with these things. They're all malleable now.

They're all able to be changed and rebuilt. It isn't cheap. You'll need a lot of cloud subs, but you can do it now. And remember, intelligence gets four to five times cheaper a month right now, which means that around this time next year, loops like this are going to be pretty cheap, except for the compute that they're running on. So, if you can find the opportunities to build these skills today, they will be more and more useful over time because the way that we are moving as an industry is away from engineering a solution to a problem that we then ship. And it's much more like engineering solutions around how the agents are working to enable them to do crazy things. So, do I think y'all should be building this way today? Absolutely not. Like, seriously, don't. This has been hellish. I have found so many holes in so many things. And all I want to do all day now is build new oss and compilers because I just stare at these things that are slowing my agents down. And I want to destroy them. I want to destroy all of them. I want to unblock my agents so I can go back to building silly little web apps. But seriously though, it's crazy how you can just like look at where your agents spend time and then hill climb those things and then keep going deeper. And this whole rabbit hole started because I wanted to run an end toend TypeScript environment inside of an isolate on V8 on Cloudflare. And now I'm rewriting Rust itself and I'm building my own operating system. Am I going insane?

Yeah, I'll be real. This is also just so fun. I haven't enjoyed building and technical thinking the way I am today, possibly ever in my career. I'm learning more every day. I am diving into things that I've never had the balls to touch, much less try to understand. And it all feels it all feels achievable now. Like anything I look at and don't like can be fixed as long as it doesn't have an Apple logo on it. I could do a rant about how I don't trust anything that isn't open source at this point in my life, but I'll save that for another video. I think I've said all I have to here. I'm going to go burn a lot more claw. I hope that you guys can as well. Or maybe not. Use your own judgment here. I will not be held liable for anything that you use these techniques on and anything that you destroy in the process. This has been a chaotic journey for me and I'm very excited to bring you all on it with me so you can see why I've been staying up till 6 a.m. so much recently. This stuff is so fun and if you can't afford to do it, I understand. If you think this will drive you mad, I understand. But I hope you can enjoy watching the chaos as people like me do all of these things. Is that all I have to on this one?