Claude scheduled tasks: recurring work with your tools attached
Aimed at recurring work rather than reminders — tasks that pick up where the last one left off, with connectors to the systems the work actually lives in.
What it is
Claude can run tasks on a recurring schedule or on demand, in Cowork. The framing is deliberately about work rather than reminders: daily briefings drawn from your communications, weekly reports compiled from data, ongoing research on a topic, file organisation, team status updates.
Available on paid plans — Pro, Max, Team and Enterprise. Team and Enterprise administrators can gate access for their workspaces.
Setting one up
Two routes. Create with Claude is the conversational one: you describe the job, Claude asks clarifying questions, and the task is generated from the answers. Set up manually gives you the fields directly — task name, the prompt, approval mode, frequency, optionally which model, and which folders it can reach.
Schedules run hourly, daily, weekly, on weekdays, or manually when you trigger them.
Approval mode is the field worth thinking about. A task that only reads and reports can run unattended. A task that writes, sends or deletes should require approval until you've watched it behave for a while — the same discipline as any agent that can change things.
The caveat that catches people
⚠ Scheduled tasks run remotely, independent of whether your computer is on. That's the feature — but it means a scheduled task can't be tied to a folder on your computer. They work with connectors and cloud-stored files, not your local disk.
If your mental model is "it'll tidy my Downloads folder every Friday", that's the wrong shape. Work that touches local files needs to run locally; scheduled work needs to live where the cloud can reach it.
What connectors change
The meaningful difference from a plain scheduled prompt is reach. A task wired to your actual systems can compile a report from real data rather than describing what a report would contain. That moves it from "generates text on a timer" to "does a job on a timer", which is a different category of useful.
It also raises the stakes, which is why approval mode exists. A task with write access to your systems is an agent, with everything that implies about guardrails and logging.
The economics
Like every assistant-side schedule, this is bundled into a subscription, so individual runs feel free. And within its intended use — a few recurring pieces of work, running daily or weekly, where judgment is genuinely required each time — that's the correct trade. You're buying reasoning you'd otherwise do yourself.
The shape that doesn't fit is high-frequency, low-judgment work. Checking whether a number changed, every fifteen minutes, across dozens of sources, is not a reasoning problem — it's a comparison, and comparisons are free in code. Routing that through a model every time means paying for thinking that has already been done.
What it's good for
Recurring work with a genuine judgment component and a low run count: a Monday summary of what moved last week, an ongoing research thread on a topic you care about, a briefing assembled from several connected sources, a recurring report that needs someone to decide what's worth including.
These are the tasks where the model earns its place on every single run, and where the number of runs stays small enough that the per-run cost never becomes the point.
Where to draw the line
Use scheduled tasks for work that needs thinking each time. Use code on a schedule for work that needed thinking once. Most real systems end up with both — deterministic collection feeding an occasional piece of judgment — which is the shape worth aiming for.
The overview lays out how to decide between them.
One new build sheet a week
Guides like this one, plus a new build sheet every Thursday. Written by a person who built it.