How is a Scheduled Task different from a normal conversation with Claude?
A normal conversation is one you actively start, with Claude responding in real time; the session ends when the conversation ends. A scheduled task instead saves a prompt and sets a fixed trigger time or frequency, letting Claude run that task in the background without you opening a conversation each time.
The key difference is that every run is a fresh session — Claude doesn't remember the conversation from the last scheduled run. Instead, it re-reads the current files, connectors, and data state each time it triggers, then saves the output once the task completes. This makes Scheduled Tasks well-suited to structurally fixed, repetitive work that doesn't need context carried over from a previous run, rather than tasks that need context accumulated across multiple sessions.
Why was scheduling added to Claude, and what problem does it solve?
The most direct reason is the accumulated cost of repetitive requests: typing the same "summarize today's calendar and emails" prompt every morning looks like just a few seconds each time, but adds up to real time loss over the long run — and it's easy to forget to ask on a given day and miss that day's summary entirely.
The deeper reason is that Claude's product line is shifting from a passive "you ask, I answer" tool toward a proactive assistant model: "you configure it once, I execute it going forward." This lines up with how Claude Code's Scheduled Tasks have been described — replacing the vague concept of an "always-on personal assistant" with a structured, permission-bounded scheduler. The goal isn't for Claude to sit on standby guessing what you want, but to explicitly hand off clearly defined, repetitive work.
What does the actual process of setting up a Scheduled Task look like?
In Claude Cowork, the simplest path is: open an existing task or start a new one, type /schedule, and Claude walks you through a few questions to confirm the timing, frequency, and task content. Once confirmed, the schedule is set — no coding or extra configuration needed. All Scheduled Tasks then appear together in the "Scheduled" tab in Cowork's sidebar, where you can open any of them later to adjust the frequency or prompt.
Through Claude Code, the workflow is slightly different. A command like /loop 5m check if the deployment finished is suited to one-off, short-term polling — Claude parses the interval into a cron expression and confirms the cadence and job ID, but this kind of task only stays active while the current session is alive. To create a genuinely persistent schedule that keeps running even when your computer is off, use /schedule with a preset frequency or a custom cron expression (e.g., /schedule tomorrow at 9am, summarize yesterday's merged PRs), with a minimum interval of one hour.
Which task should I automate first, and what should I watch out for when setting it up?
Start with tasks that are structurally fixed, happen daily or weekly, and require little judgment — a morning brief or weekly report roundup, for example — rather than scheduling ten things at once. Automate one task first, watch the quality of the output over two or three runs, and confirm it matches expectations before gradually adding more. That's the more reliable approach.
When writing the prompt, assume Claude has no memory of anything you've said before — because every run is an independent session, any Output Format, file save location, or error-handling behavior you want fixed needs to be spelled out in the prompt itself, rather than relying on the assumption that "Claude should already know what I want." It's also worth periodically reviewing the actual output of Scheduled Tasks, especially in the first month — scheduling doesn't mean you no longer need oversight, it just shifts the manual work you used to do into manual review instead.
Opening Claude every morning to type the same "summarize today's calendar and unread emails" request, or manually asking for a weekly progress roundup every Friday — these repetitive requests can now be set up as Scheduled Tasks, letting Claude run them automatically at a fixed time without you asking each time.
Claude Cowork is currently the most intuitive entry point: type /schedule inside any task, and Claude walks you through a few questions to set the timing and content — no scripting required. All scheduled tasks appear together in the "Scheduled" tab in Cowork's sidebar, making it easy to adjust the cadence or prompt later. This feature is available on all paid plans: Pro, Max, Team, and Enterprise.
If you're a developer, Claude Code offers two additional layers of scheduling. /loop is built for short-term polling within a single session (e.g., "check every 5 minutes whether the deployment finished") and stops automatically when the session ends. /schedule creates persistent cloud-hosted tasks that run on presets — hourly, daily, weekdays, weekly — or a custom cron expression, with a minimum interval of one hour, and doesn't require your machine to stay powered on. That means scheduled tasks genuinely become "set once, forget about it," rather than requiring a computer left on standby.
A morning brief is the easiest first task to automate: schedule it to run at a fixed time on weekday mornings, and have Claude scan unread emails, sort them by urgency, pull today's meeting schedule, and compile it all into a summary. This kind of task has a fixed structure and happens daily — automating it saves the time cost of retyping the same prompt, not the judgment itself.
Weekly report compilation fits well on Friday afternoons: have Claude read through the past week's completed work and generate a consistently formatted progress summary. Because each run is a fresh session, Claude re-reads the current files, connectors, and data state each time rather than reusing stale data from the previous run.
The third scenario is recurring monitoring — checking a specific site or service daily for new announcements, or tracking a competitor's product updates weekly. These tasks are fundamentally about information gathering rather than judgment calls, making them well-suited to full automation, with your involvement needed only when something actually changes.
Write scheduled-task prompts more explicitly than you would in a normal conversation — because each run is an independent session, Claude has no memory of "what you told me last time" to fall back on. Any assumed Output Format, file location, or failure-handling behavior needs to be spelled out in the prompt itself, rather than assuming Claude will guess what you want.
It's also worth noting that persistence varies by entry point: Claude Code's cloud-hosted /schedule tasks can keep running even when your computer is off, while /loop only lives as long as the current session. Some third-party guides mention that "your computer needs to stay on for scheduled tasks to run" — that reflects older versions or specific entry points, and the exact behavior shifts with updates, so it's worth confirming the current execution mode directly in the interface before setting anything up.