Claude Code 2.0: Massive Upgrade with Agent Loops

Key Takeaways

Scheduled tasks. Cloud recently introduced them in Cloud Work and now in Cloud Code. And if you have been paying attention, you know this is a big deal. It's very similar to open Cloud. But here is what most people don't realize. There are now four completely different ways to schedule tasks across Cloud's ecosystem. Each one has different persistent rules, different limitations, and different things it can actually access. If you pick the wrong one, your task is going to silently die, install on permission prompt, or just never run at all. So, in this video, I'm going to break it down, show you exactly how each one works, and tell you which one to use when. Now, you can set two types of scheduled tasks within Cloud Desktop. One on Cloud Code CLI. And the last one runs in the Cloud, which is a lot more advanced and has a very different use case. Okay, so let me first walk you through Cloud Desktop. So, the introduced scheduled task within Cloud Work a couple of weeks ago. If you go to scheduled, here you can set a new task. You will need to define or provide a name, then a quick description, then a prompt, and at the end, you need to provide the frequency. You can run this hourly, daily, weekly, it's up to you. And then you define a folder. Right? So, the idea is that based on the cadence that you define, Cloud Code is going to run that prompt on that specific folder at a regular interval. And this will run as long as the Cloud Desktop app is open. Now, but the problem with this is that it runs within a sandbox where it doesn't have access to your machine. But now, they're bringing exactly the same concept to Claude Code within Claude desktop. So, if you click on code, now you can click on new task. Again, you can provide the name, description, what exactly this task is supposed to do. So, you provide instructions to Claude Code. You can select the model that you want to use, and also define the frequency exactly the way we do it with Claude Co-work. And you can also set the permission level, whether it's going to ask you for every action that it takes, or auto accept everything. Now, to add to this confusion, or feature list, they also released {slash} loop, which is a slash command, according to Boris Cherny, who is the creator of Claude Code. He says, {slash} loop is a powerful new way to schedule recurring tasks for up to 3 days at a time. Now, this is the most critical part. It will only run for 3 days. Now, this is specifically designed for Claude Code CLI. So, if you open Claude Code, and if you're on the latest version, then you can simply say loop, and define the interval, so let's say 5 minutes, and then I can say something like, "Check if the deployment has finished, and update the to-do list." So, now this is going to do this every 5 minutes. Okay, so these are three different ways in which you can schedule tasks. There is a fourth way as well, which we're going to look at the end of the video, because first I want to show you how each of them work, what are the use cases, what are the limitations, and then it will make sense to apply the fourth way. Now, in order to understand the differences of these different mechanism, let's look at the {slash} loop command first. Now, the way it works is that you're going to say {slash} loop, then define the interval. After that, you will provide your prompt. Cloud Code parses the interval plus prompt, and essentially creates a cron job run based on that specific interval that you had defined. Now, here is the interesting thing. It's going to check the cron job at a specific interval. However, if the agent is busy doing something else at that point, then it's going to wait for the agent to finish the current work, and once it's done, and it finds that the agent is free, then it's going to wait another 5 minutes from that point onward, and then fire that cron job. So, that means that it's not going to be always deterministic. There is no interrupt mechanism that is going to interrupt the current execution, and it's very important to keep in mind. Now, this has some limitations as well. So, first of all, if you close the current terminal, it's going to kill the process. If your computer goes to sleep, it's going to kill the {slash} loop command. It also has 3 days expiry. Also, it's connected to a specific Cloud Code session. So, if that session goes down, or you close that session, then the {slash} loop command is not going to execute anymore. So, this is really tied up to a session. You can't really use this for long-running tasks, because it's going to auto expire in 3 days. Now, you can't really use it for something like the tasks in Open Claw type of agents. Another thing to keep in mind is that you can define up to 50 tasks per session. That's the max that they have set here. Okay. Now, let's talk about how the desktop schedule tasks work in comparison to the slash loop command. Now, this one has persistent automation that survives restarts. And here's how it works. So, let's say if you schedule a task say you wanted to run it every minute. This applies both to Cloe Work and Cloud Desktop. You are going to define the task and then it's going to be persisted to the disk and this is going to fire up at the predefined time. Now, each one of them is going to be independent because these are scheduled tasks that run at the desktop. So, they're really not blocked by any other process. And every session is going to have full access to files, MCP skills is that you have access to. Now, this case here's how the life cycle looks like. So, when it wakes up or triggers the schedule task, it's going to read the prompt, does the work, the results are going to actually show up in the sidebar, and then it's going to finish that session. You can also define work trees. So, for example, you have your own main branch and then you can run a task on a separate work tree or separate branch. That way, you're not going to have any conflict issues. You can just look at those separate branches and if you're happy, you can merge them back to main. Something that you need to keep in mind. If you close the Cloud Desktop app or the computer goes to sleep, then it will not execute those scheduled tasks. So, let's say if the computer goes to sleep, you wake it up, then it's going to run only once and it's going to just catch up on the most recent missed time only. So, let's say if you have an hourly task, but your computer went to sleep for 4 hours, then it's going to only execute the last one, right? Now, here is one problem with these scheduled tasks. They are stateless in nature. They don't have memory, right? But, we can actually introduced memory so that the system is self-improving. Now, here's how it this is going to work. You are going to create a file, which is state.json, that is going to persist on the disk. And within the runs, we basically tell it to read that. So, after executing the task once, next time it's going to read that file. It is going to do the work, and then update the state.json. And this is going to persist on the on the disk. And that way, you're basically giving the system type of memory. Now, here's where this pattern is very useful. If a scheduled task is going to run once a day, and it doesn't have any memory, it's going to probably make the same mistakes, spend a lot of time correcting them in order to accomplish a task. If you can tell it what were the different errors that encountered, how they were fixed, and you keep updating those, it can just read that file and can run the task for much longer at much lower token usage. The agent generates a SQL query. You also want to include what worked and what did not work. That way, the system knows what it has tried before and what not to do again. Okay, the last pattern that we discussed applies both to Cloud Work and Cloud Code and Cloud Desktop. But, there's a big, and I mean a very big difference between how both of these work. Now, the Cloud Cloud Work tab runs in a VM sandbox that is on your machine. The Cloud Code tab, which is around Cloud Code, that runs on your machine. So, the Cloud Cocode has access to different connectors, plugins, tools like web search, calendar, Slack, and Gmail, depending on how what you have connected. But, it has access to local files, MCP servers, skills, terminal, work trees, Git and Bash on your local system. Right? So, when you're trying to decide which to use, you need to look at what type of access that you need for a given scheduled task. And later in the video, I'll show you a decision diagram that is going to help you decide when to use what. But, it's very important to keep in mind what type of connectivity and access your specific task needs. Now, all of these different patterns that we saw has one major limitation. And that is that you need to keep your computer on, you need to keep your terminal on, or your desktop app on. If any one of those is closed, these scheduled tasks are not going to run. Now, this is where the fourth way of running these scheduled tasks come into play. Now, the fourth way is to use something like GitHub Actions. For this, you don't really need to have your computer on anymore, because you're using the GitHub infrastructure. Essentially, this is going to be a cron job where you're going to be using GitHub Action Runner. You are going to be running an instance of Cloud Code. The main problem here is that the scope is limited to GitHub repo only. So, you can review PRs, fix CI failures, security audits, those kind of things can be run here. Now, irrespective of whatever mechanism or pattern you're using, you still need to think about permission or permissions that are going to be needed, right? The desktop app is going to keep asking you for permission prompts. You can do dangerously skip permissions, although I wouldn't have I would not recommend this because it can perform destructive operations. So, it's always great to manually test whatever schedule task flow that you're using first manually and then let it run at a regular cadence. Okay. So, if you're still here, I want to give you a framework of how to think about which schedule task pattern to use for your specific application. Now, in this case, we have two axes. One is time horizon, the other one is task type and business and life, right? So, let's first look at a short-lived and code and devops tasks. So, these are the things that you can easily use in the CLI using slash loop command. Essentially, these are going to be short-lived dev tasks. For example, simply pull the deploy status. If you're running a debugging task, you can just ask it to pull the debugging logs every few minutes. Then, we have long-running development tasks. So, for example, if you have daily code reviews, weekly dependency audit, or morning log sweeps, security scans that you want to run on a specific cadence, these are the type of tasks that you want to use the desktop scheduling mechanism for. The idea here is that you want everything to persist, which is going to survive restarts. And in some cases, you also want to use the work trees word. Now, you're going to use the code tab or cloud code in the cloud desktop if you want to have access to local files, locally installed MCP servers, skills, get terminal, everything. But, if you're mainly thinking about connecting to external systems through connectors or plugins, and these are not development-related tasks, then you can look at schedule tasks within co-work. Because co-work is essentially a system for non-developers to use a version of cloud code to do pretty complex tasks. The only difference here is it's running on a VM sandbox, but it still has persistent memory, and it has access to a number of different connectors, plugins. So, let's say, if you're working on report generation of any sort, then I would highly recommend to use schedule tasks in co-work. But then, there is a set of tasks that can go anywhere. So, for example, if you want to monitor API uptime every 5 minutes, if it's just limited to today or a couple of days, you can just use the {slash} loop command for a given session. If it's going to be ongoing, then just use the desktop, right? Similarly, for drafting emails type of things or summarizing Slack messages, the same pattern is going to apply. Now, at the end, I want to share the sentiment. Cloud code or cloud desktop is becoming extremely powerful. And here is a tweet from Fan, who said, "The more I use open cloud, the more I realize that 90% plus of the use cases can be covered by the latest version of Codex and cloud code app, especially with schedule task." If you look at cloud code, they recently introduced this feature called remote access or remote control where you can log in to your locally running session of Cloud Code, right? So, in terms of features, it's very very similar to Open Claw. And I would argue that if you have if you're a big user of Cloud Code and you don't want some of the extra connectors that Open Claw offers, you could just use these new tools with your existing subscription without paying for API cost if you want to use the cloud models. At the end of the day, these tools are becoming very powerful and now they can actually help you do some real work. Anyways, do let me know what you think and I hope you found this video useful. Thanks for watching and as always see you in the next one.