# Ch 13: Cadence: GitHub, routines, /loop
Creator: Nate Herk (@nateherk)
Transcript of Nate Herk's 2h33m 'Build your own AI operating system' course, split into its chapters. All content and credit: Nate Herk (@nateherk), https://x.com/nateherk/status/2101656269056610682. Transcribed locally with faster-whisper; names may be misheard.

[1:34:30] But you can also create skills that are actually global. And you do that by doing that in a different directory, in your kind of overall home directory. And that's basically indicated by the little tilde right here. And so that means every product you use in Claude Code, no matter where you are, that skill would exist. So for example, I have a front-end design skill that is installed globally, so that whenever I'm anywhere, if I need to do front-end design, it just is able to use it. And just in case you wanna look at it in a different way, Right now what we're doing is we have our projects, right? So Herc 2, and then we have .cloud, and then within .cloud we have skills, and then your skill, and then your MD, your references, whatever, and then maybe another skill. But if it was global, you might not actually see it in your project, it would just be within your overall home directory. So the reason why you might wanna do this is if there's something very specific about you, your business, your workflows, that you want applied to every single project no matter what, maybe your company context, your company projects, your tone of voice, whatever, then you can install that globally instead. All right, great. So now that you guys understand skills a little bit better and you're excited to start building some, the last piece of the four C's is cadence. And what does cadence mean? Cadence means a couple of things in my mind. It means that because you can now turn off your laptop and things will still run, you have to figure out the different triggers and you have to figure out what are things that I should actually set up on some sort of cadence. Whether that means you wanna have a skill running in the background or you wanna have an actual deterministic automation running in the background, or it means you want to have some sort of dashboard with live data across all of your different connections.

[1:36:00] And you want to have one clean place to look at all of that. So let me address a lot of those things that I just mentioned and how you can start to work in a cadence around that stuff. So one of the very first things that you can do is you have this AIOS projects, right? You should probably be putting this onto a GitHub repo. You can keep it completely private. That's a hundred percent fine, but you should probably put that on GitHub. Now, if you're asking yourself, what is GitHub? Let me just explain that to you real quick. So basically, everything that you build in Claude Code is a bunch of folders and files, right? So in this example, we've got the AIS with our, you know, our read me, our cloud, we've got our references, we've got our dot cloud with our skills. This is basically what your project is at the end of the day. And this is all being stored locally, meaning if you have one laptop that you're working on this with, and then you open up your second laptop, they will not sync. You will only have that on one laptop. So GitHub is basically a place for you to upload your folders and files and basically your code base. So if you put this into a GitHub repo, short for repository, then you could basically just pull that repo in. So if you guys remember at the beginning of this video, when you cloned my repo, that's because I uploaded it there so anyone could go clone it. So you can upload one privately, meaning no one else can touch it, but you can because you have login access, right? So now if you open up your other laptop, you can pull in that GitHub repo and just keep working. So you have your AI OS no matter wherever you are. But the second thing you can do on top of that is you can actually use that GitHub repo

[1:37:30] with Claude Code on the cloud, or an Open Cloud agent, or a Hermes agent, or whatever of these other agent frameworks that you wanna use, a codecs even, you could plug that into any different AI harness. So if you wanted to be able to use your AI OS whenever you're out of town or if you are on the road and you don't have your laptop with you, you could connect it to like ClickUp. You could connect it to Telegram because you could put, you know, Claude Code on a VPS or you could have it running on a Mac mini or something. There's different ways that you can have access to your AIOS 24 seven. You know, you could use, like I said, a Hermes agent or an open cloud agent as well. But that is one thing that you can do. So you always have your AIOS with you no matter where you are. Now, what else can you do? You can actually start to schedule these tasks. You can start to schedule all of your capabilities. So all of your skills, you can have them run every hour. You can have them run every Monday at 6 a.m. You can even have them triggered on some sort of, you know, web hook. So those are the things that you can be looking at next. And you guys remember earlier, I mentioned that you could also use the desktop app of Claude, because in Claude, you have code, you have co-work, and you also have Claude chat, and you can use Claude code right here in the desktop app, and you can run your AIOS just fine. I just prefer VS code. But what's cool in here is that you have routines. And when you have routines, they can either be local or they can be remote. The difference here is that a local routine has to run with the desktop app open. But a cloud routine can run with your desktop app closed

[1:39:00] and with your computer off. As you can see, local routines only run while your computer's awake. But on my plan, which is 200 bucks a month max plan, I can only have 15 remote cloud routines running per day. And you can even open up the calendar and see, Okay, today's Thursday, here are all of the routines that I have running on a Thursday. On Friday, here are all the routines that I have running on a Friday. And this is where you really start to set up some nice cadence of things that actually happen while you sleep, which is just absolutely awesome. And what's cool about these is they actually run skills. So for example, this is my school wins engagement scheduled task or routine. What happens is the first instruction here is run the wins engagement skill. So a routine basically just injects this into a real cloud chat. It doesn't run some sort of Python script on the cloud. It runs a real cloud session. The same way that if I copied this exact prompt right here and I dropped this into my AI OS, it would do the same thing. So let me just real quick show you. Today at 10 a.m. when this ran, it did it like this. It dropped in this exact prompt, it ran the skill called wins engagement. And then you can see down here, Claude Code basically ran the skill, found all the results, and then it executed everything for me in my Skool community. So that is kind of the high level overall really cool aspect of routines. I'm gonna go ahead and play a clip right here just to dive into the cloud routines a little bit more because I think that those are very important to understand. And there's a few gotchas where if you don't watch this video, you might end up getting stuck. So I'm gonna play this video real quick and then you guys will be right back here with me.

[1:40:30] Cloud code has finally brought us routines which basically means you can inject a prompt into Claude Code, but it can be running on the web. So your laptop does not have to stay open. And I'm so excited about it. I've already been playing around with it. I've been migrating my automations over there, but there are a lot of little gotchas, so I'm here to explain exactly how you can actually set up these automations so that they work. So today, April 14th, Claude tweeted, "'Now in research preview, routines in Claude Code. You configure a routine once," which is basically like a prompt, and it can run on a schedule from an API call or in response to an event, and it runs on Anthropic's web infrastructure, so that's awesome. So you can call a routine from an API, you can have GitHub events trigger it, or they can be scheduled, which are like the scheduled automations we already have, but now they run on the web. So you really can create these from anywhere. You can do it right here as a scheduled trigger to run scheduled remote agents, which is in the terminal. You could also go to Claude AI slash code. So you could do it on the web. And right here, you see, I have three web based routines right here. Or what I'm going to be showing you guys today is just doing it in the desktop app, because right here, if I go to my scheduled tasks, you can see that I've got some like these four that are local. And then I've got these four that are running inside of a GitHub repository. So these are the remote ones. If I go up here and click on new task. This is where we could set up a new local task or a new remote task. It's very similar. You set up the name, you set up what cloud should do. And this is the actual prompt. So I'll talk more about that in a sec. But then you would configure your model, your repository, and your cloud environment. You set the cadence hourly, daily, weekdays. I think the minimum is once an hour. Like you couldn't go like every 10 minutes or something, but still not bad at all. This is where you

[1:42:00] could configure all of your connectors. So if you need to connect Slack or Gmail or, you know, know, whatever it is, you can connect them right here, but you can also just do your regular API endpoints with your API keys. And then of course you've got your permission, so you can choose how Claude should be acting. Now the one thing about these are, these are meant to be a one-shot prompt, you're not around. So you probably want to make sure that it doesn't ever have to stop and ask you questions. Otherwise what's the point of the automation? So like I said, there's tons of things to dive into here and I'm not going to try to bore you guys, but some of this is really important because when I first got at the setup, my automations weren't just migrating over and working. So I'm gonna tell you guys the issues that I ran into and hopefully answer everything that you need to know so that you won't have to go into the comments and ask these common questions. I can just answer them right here for you. So let me just first of all real quick show you guys what I tested out. The first thing I wanted to test out is if I came in here and I created a new routine for just shooting a message to my click up. Obviously that's not any value, but I just wanted to see how it worked. Because what I wanted to do is see if I could do this without adding my connector of ClickUp. And I was able to actually get this to fire off, but it didn't work right away. So let me show you guys what I ran into. So the way that this works is you need a GitHub repository to sync it to in order for this to actually run. So it's gonna clone my Herc2 project right here in the web. It's gonna be able to read my cloud.md. It's gonna be able to read my scripts and my skills. And then after it finishes the job, it basically just destroys that little cloud GitHub clone. But as you guys know, you don't push your secrets into GitHub because if you see here my Herc2 project,

[1:43:30] this is my .env file with all of my API keys, and this is listed in the gitignore, which basically says, hey, when you push to GitHub, you don't include these files. So what that means is, in here, if this is only looking at your GitHub repo, there's no .env. So how do you get your API keys into this routine that runs on the web? Well, what you do is inside of this scheduled task, you have a cloud environment. So if I click on this one, you can see this one is called nate-herc-cloud. So if I open up the settings, what do you see? You have the name of this cloud environment, you have the network access and you have environment variables. So right here is where I put in my YouTube API key, my clicker API key, any of the other API keys that I need to give this cloud environment access to. And then the other thing you have to do is you have to look at the access levels because right here you can see that this one is on full, but by default, this will be on trusted, I believe. And that means you can only download packages from verified sources from Anthropic. And when we talk about this later, I'll have a link which you can go see all of them. You can even do custom if you wanted to allow specific domains that aren't on that list. But in order for ClickUp to work in this case, I had to go on full because when I went on trusted, it said, hey, we can't actually do that. But when I changed this to full, it let me send a message to my ClickUp. And that is how I got this message right here that says just testing that the remote tasks work and the credentials work. So basically when these run, whatever you have here as your instructions is what gets prompted. And that's exactly the same way that the scheduled tasks locally work. So right here, you can see I say, send a message in the internal ClickUp channel. And right here, the actual thing that it says was send a message in the internal ClickUp channel.

[1:45:00] So think of a scheduled task or a routine as you basically typing in a prompt and then someone coming in to your laptop and typing it in for you. So it's the exact same type of interaction as you talking to Claude Code. But that's why once again, you wanna make sure it's specific enough so that it can basically one-shot it. Okay, so let's take a little deeper now. What I tried to do is I did another one, which I wanted it to be able to use the YouTube data API in order to grab some YouTube comments for me and give me a little analysis in ClickUp or whatever. So this is the prompt I said, right? Analyze 50 of my most recent comments from YouTube and give me a quick bullet rundown. My YouTube API key is available as an environment variable, use it directly from the environment, don't look for a .env. Because what happens is in your repo, right? So in this Herc2 project, when I normally run this, it grabs all my API keys from the .env and maybe it reads the clod.md and realizes that's where a lot of those live. So by default, it's maybe going to try to look in the .env and it's not gonna be smart enough to figure out. And so for ClickUp, it was fine, it figured it out. But for some reason with this YouTube one, it didn't. So I had to explicitly tell it, hey, look in the environment variable rather than in the .env. So you can see this first time I ran it, 1241, I didn't say that and it couldn't do it. It said like, hey, I can't find that, I'm getting an error. And I even tried to tell it here and it still didn't work. But then on this most recent run, when I updated the prompt a little bit, it was able to fetch it right away using the API key. And now I have a remote, you know, routine that would work.

[1:46:30] Obviously I need to update this. I'm going to migrate over my other automations, but this was just for testing purposes. And then another one that I do is I have some automations here, which basically opens up a browser using playwright CLI, and it does some stuff in my Skool community because there's no publicly accessible API. We've kind of figured out a way to automate it without using browser. I'm not really going to dive into that right now, but what I wanted to tell you guys about that is I tried to basically move over this school wins engagement post or sorry, automation into a remote session. So I copied the exact same prompts that was in my regular scheduled task. And then I just added this little snippet at the end. But what happened is this wasn't working because it basically said, hey, you know, like when you do this, it spins up a browser, but there's no cookies because all of this is running remotely. And all I have to look at is the GitHub repo. I can't look at the local, you know, cookies that we've used in the last couple of sessions of this automation. And so it doesn't seem like this would work because once again, it has no access to that stuff. So if I wanted to do an automation like this, I would have to use, um, an endpoint that takes authentication in the form of like actual cookies or a header or, you know, like an API key, because every single one of these runs is going to be stateless. And after the run, the GitHub clone just gets deleted. Now, the exception of that is if the automation is changing something in your code base or doing a review. If it does do that, it will create a new branch for you, or it will give you some sort of output and not just delete everything that it just did. But for an automation like this, it would just delete it. But hopefully after you guys have seen those examples, you now have the ability to come

[1:48:00] in and make some changes if you need in order to make sure that your automations are running. And what I mean by that is you understand this should be a very specific prompt. This is how you change the model. You have to have a GitHub repo. You can change the settings for your cloud environments right here. You set the schedule, you add any connectors you might need, which would honestly be a little easier if you added just like a Slack connector, and then you can set your permissions here. Now, the other thing to be aware of is you do have limits. So if I come over here to my settings, you can see if I go to my usage, we have our regular session limits, our model limits, but for additional features, we have daily included routine runs. And I haven't run any yet on the actual schedule. I've just been testing them, but we are at zero for 15. So I could only have 15 automations running with routines per day because I'm on the max $200 a month plan. Your limits would be less if you're on pro, I think maybe three or maybe five. I have that information later on, but just something to keep in mind. All right. So let's just dive into a little bit more of the details here that may answer some questions you guys have. I think it's pretty clear at this point what it is. I'm going to give you guys this entire doc as well as anything else I've talked about in my free Skool community. The link for that is down in the description. So some of the stuff I might not cover, if you want to read more about it, then just go ahead and grab that free resource. So we know what it is. I think we know how it works, right? Like you define a routine, which is a prompt, you connect a GitHub repo, you can also trigger it by APIs or by a GitHub action, and then you can connect your connectors. And basically it acts as you talking to your own Claude Code.

[1:49:30] Because of the fact that this is working off of a cloned repo, it's going to read, and read the Cloud.md, that would be file automatically every time. So if you have a massive project like a Herc2 project, for example, with tons of context and tons of stuff, Maybe you don't want to put that repo into the cloud to be a routine run, because there's a lot of text in that cloud that MD and in that whole GitHub that might not matter for this. So maybe, maybe you're better better for this. So maybe you're better better for this. So maybe you're better better for this. So maybe you're better better for-for-r. So maybe you're better better by per-routine. But of course, putting in the information that. That's important because this. This stuff is going to drain your. Claude Code session the exact same way as it would if you were open up. Up and Claude Code just talking to it. So once again, three trigger types schedule API, which I think is really cool. automation make a post request to some sort of routine. And then of course GitHub. So you can have it automatically fire off kind of on a web hook based on new PRs, new pushes, new issues, new releases, new releases. So how does this compare to what RDE exists? We have routines, which is the new feature. We have desktop scheduled tasks, and then we have something like just a slash loop command. So routines run on Anthopics Cloud and these other two run on your machine. Do you need the machine on? No, for routines, that's huge. But for desktop scheduled tasks and for loop you need your machine on. Do you need a session open? No, that's the same across all three. Do they survive across restarts? The first two do, but loop does not. That has to live within a specific session. Local file access? No, for the routines because it works off of the GitHub repo and for the next two, yes, you have

[1:51:00] local file access. Permission prompts with routines? It's fully autonomous and for these two, they are configurable. And then the minimum interval routines is one hour and these two are both, It could go every minute if you want. Okay, so let's talk about the environments. Obviously your .env is git ignored unless you push it into the GitHub repo. You know, ultimately if you push it into a private repo, you're probably okay, but you wanna be really, really, really careful because then, you know, there's history there and if other people, you know, end up collaborating on it, you just don't wanna do that. So you wanna put your API keys in the environment variable, like I showed you guys earlier. You want to look at the network access, whether that is full or trusted or none or custom, and potentially some setup scripts. So that's not something I showed you as yet. If you're creating a new remote task, you can do a setup script, which is basically just a script that will run when this new session fires up before Claude Code launches. So if you need to install any packages or anything like that. Okay, so what's the difference between Trusted and Full? So Trusted only reaches the known vetted services from Anthropic, which I thought I linked right here, but I just linked it there. This basically shows you all of the different domains that are allowed. So right here, you can see we've got Anthropic services, we've got version control. We've also got some cloud platforms like Google, stuff like this right here. These are the ones that are kind of already verified. So what is the risk of going on full? Well, if cloud reads malicious content during a run, then it theoretically could be tricked into sending data to an external server. And with Trusted, that outbound request would get blocked.

[1:52:30] Now, practical risk for private repos where you control the inputs is very low, but I definitely just wanted to at least acknowledge that. So connectors, this is different than just adding your API key. This is more of like the connectors you would add to your actual Claude chat or like Claude co-work where you would OAuth into like Slack or ClickUp or stuff like that. Here are some security details. I'm not going to go super deep into this. You could also do some more research and download this doc. But of course there are some things to be thinking about like your API triggers or what's going on with your GitHub repos and the branches. Because once again, everything is going to be running as you, so if you're not testing out these routines before you just kind of send them off every hour or you just have to be thinking about what could happen without permissions and stuff like that. Limits and quotas. So it looks like on Pro, you can have five runs a day. On Macs, you can have 15 runs a day. And on Team and Enterprise, you can have 25 routines a day. If you hit the cap, the orgs with extra usage enabled can exceed it on metered overage. And then we have the minimum scheduled interval, which is one hour. And there are also resource limits. So every one of these routines in the cloud runs on four VCPUs, 16 gigs of RAM, and 30 gigs of disk space. So once again, just be thinking about, Are you putting an absolutely massive GitHub repo up into the cloud right now to run? That could just be wasting resources for no reason. So what persists versus what gets destroyed? The cloud branches gets pushed to your GitHub repo and the session also stays. So as you saw, if I came into here and I looked at all of these tasks, I could see all of the past runs and I could go look at them to see if something's going wrong.

[1:54:00] But the actual cloud environment that gets cloned will be destroyed. Basically the rule of thumb here is if something's local, or if Claude Code can't reach it in your GitHub repo or via an API, then it won't work. We already talked a little bit about writing good prompts, but you definitely want them to be more specific. For example, with my scheduled automation here, this is much more specific, right? I have a skill that I wanted to run, I give it the order of operations, but something more like this YouTube comments one, this is not what you'd wanna put in there unless you were defining a skill to just let it run. Because once again, this is supposed to be a one-shot prompt, so you wanted to make sure it gets it right on the first try. Okay, so why is this so exciting? And why does this beat normal automation? Because we are actually keeping the agentic framework. If you know when I talk about the WAT framework where we have workflows and agents and tools, when we actually push those automations to the cloud and it's just sort of a Python script, we're losing the agentic piece. We're only sending off really the tools and the workflow. But in this case, we're keeping the WAT framework A and the T all running together because the agent is looking at the, you know, Cloud MD, it's looking at its scripts and it's figuring out what to do. And if it runs into errors mid run, it will self-correct. And if you configure it the right way, it will be able to sort of like leave a memory trail and it can leave like, you know, updates even though each run is stateless, you can still have them kind of continuously get better. And real quick, let's speed run through these common questions. Do I need to know cron syntax? Nope, you just can schedule a natural language, super easy. Can it access my local files?

[1:55:30] Nope, it only gets what's in your GitHub repo or your APIs. What model does it use? You can choose any of the models as you guys saw. Can you watch it work in real time? Yes, you can hit run now and then you can obviously watch it go right there same way you would in cloud. You can even talk to it after it's done or interrupt it and then continue going. Can it use my MCP service? Yes, that is what the connectors are. Can teammates use my routines? Nope, these belong to your individual account. You might be able to share those if you're on a team plan but I haven't actually yet tested that myself. What's the cost? It's just your normal subscription usage. So keep that in mind. What happens when a run fails? Every one of them will be stored in your history. So you can go see why they failed. You could maybe even have it at the end of every single routine, say, hey, if this does fail, just shoot me a Slack message to let me know, things like that. And can I test a run before going live? Yes, in fact, you should test it multiple times before it goes live. You just go into the routine, you hit run now, and then it will pop up as running. And then you just watch it, watch it go through its order of operations and you can inject and you can help it correct itself. So that you have confidence that once it shoots off the prompt next time, you won't have to get in the way at all. Claude Code can now remind you to do things, check on things practically for you and work for days straight without you ever touching it or needing to give any input. So here you can say, I just said, remind me at 10.23 AM to check on my project. It goes ahead and uses a cron create tool to set this reminder. There we go, 10.23 just hit, I didn't touch it. And it just said, hey Nate, This is the reminder to check on your project.

[1:57:00] So just shot off this one that says every 10 minutes, check my click up to see if there's any new developments on our project. It's using the loop skill, as you can see, which is a new built-in skill, and it creates a cron for every single 10 minutes. And now this would run for the next three days every 10 minutes until I told it not to. And this doesn't have to be every 10 minutes. It could be every hour, it could be every five minutes, it could be whatever interval that you want. And this is all thanks to the newly released feature or skill loop, which is a powerful new way to schedule recurring tasks for up to three days at a time. And this is so funny because less than 12 hours before this was announced, the scheduled tasks in Claude Code was also announced. So right off the bat, those two features might seem like they're the exact same thing, but they're actually super different in how they work and they have different use cases. So in today's video, I'm gonna break all of that down and tell you everything that you need to know about it. And by the way, if you haven't watched my new scheduled tasks video, then check that out right up here. And then hop back over to this one. All right, so as you guys just saw in the quick demo, we now have the ability to use loops, which means that we could say something like slash loop every five minutes, check on the deploy, Or we could just say that in natural language, which is awesome, because it invokes the loop skill, and then it creates that cron job right here in Claude Code. And you'll notice that this is in my VS Code. So this is available in your terminal, in Claude Code Desktop app, in VS Code extensions, wherever. This is just a core part of Claude Code now. So if you're not seeing this, just make sure you update your extension or you update Claude Code. And this lets you set up loop intervals or reminders. So reminders, like you saw that first demo, I just said, hey, at this time, just tell me this. And in that session, it will bump up a message without you triggering it. or you could have them be intervals. So you could say every two hours, you could say every 30 minutes,

[1:58:30] whatever you want that actual interval to be. And what's cool about it is it does it all in the same session. So if I leave this session up, every 10 minutes it would check everything right here, which means that it's able to continuously read through what happened in the past one and it continuously sees what we're doing. Now, obviously there are some pros and cons there, but just wanted to point that out. The major con there being your context, making sure that if something does go off every 10 minutes, you're not gonna get a huge report. And then every 10 minutes, you just, more tokens, more tokens, and then context rod. It's basically scheduling a prompt that you would be sending in here and then firing off, which means you can loop skills. So if you want every 20 minutes, for example, run a skill called review PR, you could tell it to every 20 minutes run the skill. It would run it, it would wait 20 minutes, and then it would do it again. And of course you could use actual slash commands to invoke both the loop and the skill, or you could just say every 20 minutes, run my review PR skill. And of course the one-time reminder feature. So at 3 p.m. or in 45 minutes, remind me to do this or check in on that. And Cloud will basically pin that time, it'll create that cron, and then once it's done, it'll just delete itself. So whether that's, hey, at 4.30 remind me I have to go do this, or every hour remind me to just stand up and look away from my screen for five minutes, it can do that. All right, so there's a couple things that I wanted you guys to understand about how this actually works, so let's just play around a little bit. Hey, at 10.40 a.m., can you please remind me to take out the garbage? Cool, so what that's gonna do is it's going to use the cron create tool, and it's going to create that basically schedule to remind me, take out the garbage. And what you can see here is the actual prompt.

[2:00:00] So at this interval, which is just how cron works, it's basically going to shoot a prompt into this window that says remind Nate to take out the garbage. You can see the recurring equals false. Now, of course the key is if the session is closed, then that cron is going to automatically be killed. So now something interesting, I'm gonna open up a new session and I'm gonna say, hey, every hour can you just remind me I need to stretch my neck. And I'm gonna shoot this one off and we'll see how this one is a little bit different. Because this once again creates a cron, we have a prompt, and you can see in this one we don't have the recurring equals false. We just know that this cron is gonna go every hour. But these loop jobs or task jobs are per session. So these two tabs are two different sessions. So if I came into this session and said, can you please tell me all of the scheduled loop tasks that we have today? It's going to use a tool called cron list and it only can see the 1040 AM take out the garbage. It cannot see the task that exists in this session because they're independent and they're separate. Now, one interesting thing to notice is that this session didn't actually invoke the loop tool. The loop tool basically tells it how to set up cron jobs and how to use the cron create. So if you don't see loop, don't worry. It's still actually doing this in a loop. It's just kind of about the actual wording. So if I was to open a new one, let's see if I actually call the loop tool right here. So I do loop and then I just say, you know, check my click up. This one is going to default. I believe to 10 minutes if you don't specify a time. And it might invoke the loop skill because we actually called it to, but looks like it didn't because it knows exactly what it needs to do already.

[2:01:30] So the point being, all that matters is that the cron is being created. It doesn't always matter if it invokes the loop skill or not. And then if you wanted to cancel one of these jobs, all you'd have to do is either close out of the terminal or just say, actually, I don't need this anymore, go ahead and cancel it. And that one invokes a different cron skill called crondelite. It shoots over the job ID and now that is canceled. And one final thing to keep in mind is in VS code, if you close out of a tab and then you just open up that conversation again, that still will kill those cron's. So you guys just saw how pretty much all of this worked. We have cron create to schedule. We have cron list to list them. And then we have cron delete to cancel them. And all of those can be invoked with natural language, which is awesome. So now let's get into some of the limitations and then I'm going to compare them to the actual scheduled tasks feature. So the first big one is that we have a three day loop expiry, which is just basically for safety. It auto cleans things up. If you forgot you had all of these loops running. So once you create a loop, it basically has a three day timer on it. It can run for day one. It can run on day two and then on day three, it can run up until that last fire and then it will auto delete. And if you want anything longer than three days, then you would either just recreate that loop, or that probably indicates that you should just turn this into a legitimate scheduled task. Now, the other thing that you can do is if you want to completely disable scheduling, so maybe in your natural prompting, it's accidentally creating all these cron's you could go into your environment variables and just disable that and it would probably be able to help you figure that out. So the other things here are that if you close the terminal, your tasks are gone. It doesn't have catch-up. So the scheduled tasks, if you opened up your desktop app and you

[2:03:00] missed a bunch, it would catch up automatically. This doesn't do that. And there's no persistence, meaning after your three days and you wanted to do that same loop again, it would be a fresh session. But obviously there's tons of things that you can do here with context management and reading different files in order to kind of Frankenstein your own fix there. So now that all the features have been explained and you've seen a demo, I think that probably you understand the difference between the loop and the scheduled tasks a bit better now. But let's just go over some of the key highlights. The loop has your three-day expiry. It's all done within one session and there's no catch-up. It's basically a help me now or help me on this project for today type of function. The scheduled tasks are disk stored, they're long-lived, they have catch-up, and these are like daily, weekly, monthly functions that can run indefinitely. Of course, with both of these though, the terminal or, you know, the app has to be open. And this one is only currently available in the desktop app. But I can imagine how fast and dropping shipping things. Maybe by the time you watch this video, scheduled tasks are already out for the terminal and extensions as well. The way that loop is available in Claude Code everywhere. So basically, it's one simple question. Do you need help right now on a project or do you need help with something every day or every week? And that's how you decide if you use the new loop feature or if you use scheduled tasks. So I thought I'd end off real quick by giving a few maybe practical ways that you could actually use loop rather than something scheduled. So maybe all day you're waiting on a very urgent email. Just set up Claude Code to check in on that email every five minutes. And if it's there, it can automatically let you know. Maybe you're working on a deploy and you want to just pull