Claude Code Just Dropped Routines. 24/7 Agents.

Cloud Code has finally brought us routines, which basically means you can inject a prompt into Cloud 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, Cloud tweeted, now in research preview, routines in Cloud 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 that 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 cloudai 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 gonna 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 could configure all of your connectors. So if you need to connect Slack or Gmail or 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 permissions. So you can choose how Cloud 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 wanna 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 gonna try to bore you guys. But some of this is really important because when I first got this set up, 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 ClickUp. 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 HER2 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 HER2 project, 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, we 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 Hurt 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 ClickUp 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. 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 Cloud 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 HERT2 project, when I normally run this, it grabs all my API keys from the .env. And maybe it reads the cloud.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 routine that would work. Obviously, I need to update this. I'm gonna 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 school 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 gonna 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 prompt 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, 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 cookies that we've used in the last couple 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 an endpoint that takes authentication in the form of actual cookies or a header or 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 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 school community. The link for that is down in the description. So some of the stuff I might not cover, if you wanna 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 could 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 cloud code. Because of the fact that this is working off of a cloned repo, it's going to read the cloud.md 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 wanna put that repo into the cloud to be a routine run, because there's a lot of context in that cloud.md and in that whole GitHub repo that might not matter for this automation. So maybe you're better off setting up a specific GitHub repo per scheduled routine. But of course, cloud.md best practices, putting in the information that's important, because this stuff is going to drain your cloud code session limits the exact same way as it would if you were open up in cloud code, just talking to it. So once again, three trigger types, schedule, API, which I think is really cool. You can have a different 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 webhook based on new PRs, new pushes, new issues, new releases, things like that. So how does this compare to what already 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 Anthropx 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 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, could go every minute if you want. Okay, so let's talk about the environments. Obviously your .env is 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 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 guys 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 Cloud 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. 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 cloud chat or like cloud cowork, 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 the stock. 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 something, 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 Max, 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. But the actual cloud environment that gets cloned will be destroyed. Basically, the rule of thumb here is if something's local or if cloud 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 want it 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 WA and the T all running together because the agent is looking at the CloudMD, 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 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? 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, you know, 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. But anyways, that's gonna do it for this one. I hope that those tips and some of the examples that I showed you were helpful. And now you can go off and try to migrate your scheduled tasks or any other automations that you've been meaning to build into these web-based routines and not have to keep your hardware on. So if you enjoyed the video or you learned something new, please give it a like, it helps me out a ton. And as always, I appreciate you guys making it to the end of the video. I'll see you on the next one. Thanks everyone.