Unlocking Unlimited Claude Usage: Deep Dive into Extreme AI Agent Workflows

Theo explains that this video deviates from his usual focus on practical development tips, instead offering a deep dive into extreme Claude usage. He describes projects that 'run for weeks' and 'lit hundreds of dollars on fire,' accumulating absurdly high compute and token costs.

He references prior work on 'token maxing' and introduces projects like TS Rust, which rewrites TypeScript in Rust for faster compilation (4 to 10 times faster), and Lust, a new Rust compiler designed to be a drop-in replacement for Cargo, compiling a subset of Rust 100 times faster or more. Theo admits these workflows are not recommended and are shared out of frustration that they work at all, despite their high cost and complexity.

Theo posits that the improved performance of personal AI agents is not due to models becoming cheaper or smarter, but rather because of the enhanced tools they can access. He argues that when models are given access to tools that allow them to browse the web and make real decisions, their inherent knowledge becomes less important than their ability to effectively use these tools.

He highlights Browserbase as a solution for providing agents with web access, addressing common issues such as CAPTCHAs, file management, and efficient resource provisioning. According to Theo, Browserbase helps overcome challenges like IP limits and navigation errors often encountered with self-deployed Puppeteer setups, allowing agents to search for data, fetch content from inaccessible pages in usable formats (HTML, JSON, Markdown), and navigate web pages effectively.

Theo introduces 'Skate 3 Bench,' a project distinct from his earlier 'SkateBench.' The original SkateBench, which involved models naming skateboard tricks, was privatized because AI labs were using it as training data, leading to models achieving perfect scores on public versions but failing on private, undisclosed problems.

Skate 3 Bench aimed to transcend simple benchmarking by tasking Claude with creating an entirely new game and engine from scratch, designed to replicate the experience of the Skate series. This ambitious project ran for over four days with minimal human intervention, primarily limited to typing 'continue' to reboot machines.

The project incurred significant costs, with inference alone amounting to nearly $5,000, using over 12 billion tokens. Despite the massive compute expense and minimal human input, the project demonstrated Claude's capability to undertake complex, generative development tasks.

Theo demonstrates a playable clone of EA Skate, which Claude created entirely from scratch. The game runs in a browser using a 3JS-based engine, also built by Claude. The character model was sourced from an asset store and then customized by the AI.

A notable feature is the recreation of Skate's 'flick it' control system, where tricks are performed by joystick movements rather than button presses, which Theo notes is a challenge to implement. He observes that the game's physics feel surprisingly decent, surpassing many other Skate clones he has played, despite some recent issues with specific animations like the inward heel flip.

Theo emphasizes that a simple prompt like 'make me a clone of Skate' would not yield a high-quality result from Claude. He differentiates his approach from 'hill climbing' on existing projects, which he considers relatively trivial.

His method focuses on creating something entirely new in an unconventional way. He introduces the concept of 'hill climbing' as crucial for understanding how models are optimized to achieve complex, non-trivial results, which involves iterative refinement rather than a single, perfect prompt.

Theo explains that models are trained using reward mechanisms, illustrating this with a tic-tac-toe analogy: successful moves are rewarded, unsuccessful ones lead to adjustments, making the model more likely to repeat successful actions. This process allows models to verify success or failure and modify their behavior accordingly.

Models possess two components: knowledge, acquired during pre-training from data, and behavior, refined through Reinforcement Learning (RL). RL teaches models to act and behave in specific ways, such as making tool calls for more information or testing theories by writing and validating code.

By default, models merely answer questions based on their knowledge; they don't test theories or experiment. RL training is crucial for enabling models to exhibit different behaviors, solve complex problems, and engage in longer, more elaborate tasks.

Theo introduces Reinforcement Learning with Verifiable Rewards (RLVR), a method where models are trained against tools that programmatically check for success or failure. This approach is highly effective for tasks with clear, verifiable outputs, such as TypeScript.

In RLVR, models are given tasks like transforming code (e.g., file A to file B) and matching specific compiler errors. By intentionally injecting errors into projects and comparing the model's output against the original TypeScript compiler, the model can verify if its code performs correctly.

This process is akin to the training environments models encounter, enabling them to consistently take input A and turn it into output B, provided the transformation is consistent. For the TS Rust project, this meant instructing the model to take real-world TypeScript projects, compile them with a pinned version of TypeScript, and then chase those exact outputs until the new Rust-based compiler produced identical results.

Theo asserts that clear, verifiable goals are critical for models to produce high-quality outputs efficiently. He highlights that the more a task resembles the way a model was trained, the better it will perform. The 'TS Rust' project serves as a prime example, where verifying inputs and outputs against the official TypeScript (TSGO) enabled rapid progress.

Once a project has verifiable inputs and outputs, models can be given more complex constraints, such as making the output 'two times faster than the official version' while ensuring 'all existing validation and tests still pass.' For TS Rust, the model continued iterating until it met the speed requirement because it could programmatically check both correctness and performance.

This iterative process, driven by explicit and verifiable goals, allows models to achieve results that would be difficult with less structured approaches. The simplicity of verifying text outputs in projects like TypeScript makes it an ideal candidate for this method.

Theo describes his method for creating a video game agent, starting with a 'slash goal' for Claude: "Create a compelling web game that replicates the physics and controls of EA's Skate 3." This initial instruction outlined core requirements, including controller input simulation (even if simulated by the AI), and an experience focused on skating in a small park, with an emphasis on accurate controls and physics.

He provided specific details about the game's core mechanics, such as not using buttons for tricks, but rather the right joystick to mimic real skater motions. The goal also included visual fidelity, instructing the model to aim for graphics quality similar to the original Skate 3, with the ability to use Blender for models where appropriate. Claude was also tasked with ensuring functional gameplay first, including clear readouts for trick names, and animating all tricks independently, continuing until the game felt like the original.

Theo implemented a novel verification method for the Skate 3 Bench project: he instructed the model to take screenshots of its game builds in specific states. These screenshots were then compared against actual footage from the original Skate games. The critical step involved a 'panel of judges' — other LLMs — that would compare the AI-generated game with the original and provide feedback on whether the visual quality was sufficient.

This feedback loop allowed the agent to 'hill climb,' continuously iterating on its visual output based on the judges' critiques. Theo admits his initial plan was more complex, involving recording his own controller inputs from Skate 1 and using those as replay values for his agents to test their game, but opted for the simpler screenshot comparison due to time constraints. He expresses surprise that this simpler method worked effectively, providing the model with a clear, alignable goal to pursue and improve upon.

Theo notes that while an alignable verification method allows AI agents to self-correct and achieve goals, the process can lead to strange issues and high costs. For instance, the agent spent approximately $800 in tokens trying to perfect the game's skybox to match the original Skate. The model's iterative attempts also led to unexpected visual problems, such as consistently making the game brighter because it was initially compared to Skate 3, whose graphics Theo found 'hideous.'

He corrected this by instructing the model to reference Skate 1's aesthetics instead. This experience underlines that success relies on defining a clear, alignable verification method, enabling the agent to continuously iterate and improve towards the desired outcome, even if it entails unexpected detours and significant compute expenditure.

Theo emphasizes the critical need for an automated, programmatic verification loop in AI agent workflows, stressing that human intervention significantly slows down progress. For the TS Rust project, this involved testing codebases against existing builds and intentionally introducing random errors to ensure the system could detect them, creating a 'pass or fail' mechanism.

He explains that the TS Rust project generated over 7,884 commits and 1,800 revisions, which would be impossible to manage with manual human checks. Therefore, agents require programmatic verification or at least a way for another agent to evaluate results autonomously.

After verification is established, the next step is to equip agents with the necessary tools to succeed. Theo argues that models like Chat GPT would fail at such complex tasks due to a lack of proper tools, like a computer with a GPU and GUI, which are essential for tasks involving asset generation and execution in environments like Blender for projects like Skate 3 Bench.

Theo recounts a major bottleneck in his agent development workflow: agents were spending up to 12 hours in a queue waiting for compute resources. He addresses this by integrating Blacksmith, a CI/build platform, into his process, despite acknowledging it's not explicitly designed for agent SSH access.

By offloading compute to Blacksmith, Theo managed to reduce agent wait times from 12 hours per run to a mere 1.2 hours. This dramatic improvement significantly accelerated the development of projects like TS Rust, for which he spent over $2,000 on Blacksmith compute, supplementing his local resources.

This shift highlighted how critical scalable compute platforms are for continuous agent operation, transforming a workflow plagued by idle time into a much more efficient development process, even though Rust's compiler itself is notoriously slow due to reasons beyond just the borrow checker.

Theo introduces boat.dev as a pivotal tool that he considers 'one of the coolest things I have used in years.' He explains that boat.dev provides an almost absurdly convenient way for AI agents to dynamically spin up virtual machines when needed, streamlining agent-based development workflows.

He highlights that this capability allows for faster development loops by efficiently handling ephemeral tasks, preventing bottlenecks caused by resource contention. Theo was so impressed with the platform that he invested in it, noting that it unblocked his agent workflow to such an extent that he started burning through his Claude accounts four times faster, necessitating an increase from six to seven accounts.

Theo explains that boat.dev simplifies the process of spinning up disposable VMs, ideal for tasks where compute needs fluctuate. The platform operates on a subscription model, offering a certain number of concurrent sandboxes, starts per minute/hour/day, and separate usage costs for compute.

Theo elaborates on the technical advantages of boat.dev, particularly its snapshotting feature. This allows an agent to clone a repository, pull down and build everything once, configure a hot-reloaded environment, and then snapshot it. Subsequent agents can then spin up from this snapshot without repeating the entire setup process, saving considerable time.

This capability dramatically improved development efficiency. Previously, with agents sharing four slots on a single VPS, code gate times ranged from 40 to 70 minutes under load. After implementing boat.dev, which enabled agents to trivially spin up multiple boxes from snapshots, the gate time dropped to just 6 minutes.

This optimization more than doubled, and nearly tripled, the amount of code Theo could land in a day, accelerating project advancement significantly. He expresses immense satisfaction with the platform, even becoming an investor due to its effectiveness.

Theo clarifies that platforms like boat.dev are designed for ephemeral, random tasks with fluctuating compute needs, rather than for hosting permanent, public-facing servers. He likens the challenge of managing agent compute to office desk management: providing enough resources for peak usage is expensive and leads to idle capacity, while under-provisioning blocks agents.

Boat.dev addresses this by offering the flexibility to scale compute resources up and down precisely as agents require them, preventing overpayment for unused capacity or blockages due to insufficient resources. This flexibility is crucial for efficiently managing the dynamic and unpredictable demands of AI agents.

Theo describes the operational loop for agent management as an iterative process akin to being a manager. This involves setting up an environment with a defined task, establishing a reliable verification method, and continuously identifying and resolving bottlenecks. He explains that agents, left unchecked, might crash systems by running too many processes simultaneously; his solution involved asking Claude to create a queue for Rust builds.

When progress slows, the manager's role is to ask the agent what is blocking its work and then provide the necessary compute or environmental adjustments. This iterative process, which often leads to increased token consumption as agent efficiency improves, necessitates obtaining more cloud subscriptions.

He emphasizes that the human role is not to micromanage every line of code but to set agents up for success, unblock their progress, and provide the optimal environment. This management style allows agents to move faster and tackle more complex tasks efficiently.

Theo suggests a paradigm shift in software engineering: the industry is moving away from directly engineering solutions and shipping them, towards engineering solutions that enable AI agents to perform complex tasks. He points out that as the cost of AI intelligence continues to decrease (four to five times cheaper per month), these complex agent-driven workflows will become increasingly affordable.

While acknowledging that this approach is currently 'hellish' and involves navigating numerous system vulnerabilities, Theo believes that developing these skills now will be invaluable. He emphasizes that everything in computing, from operating systems to compilers, is becoming 'malleable' and can be rebuilt or re-engineered to facilitate agent operations.

Despite the current difficulties, Theo sees a future where engineers primarily focus on building environments and tools that empower AI agents to do 'crazy things,' rather than just writing code themselves. His personal experience of building new OSs and compilers stems from a desire to remove obstacles for his agents, ultimately allowing them to build web apps more efficiently.