Reference Guide

Cowork Tasks vs Routines

Tasks run now, Local Routines run on your machine, Cloud Routines run with the laptop closed. Where each one runs, what it can reach, and how to pick.

← Back to Reference Hub

Best for: One-off, interactive work that needs your local files, your open apps, and your judgment in the loop.

  • Runs immediately in your open Cowork session
  • Full local context: working folders, open-app awareness, Dispatch/computer use
  • You stay in the loop — approve folder access, confirm risky actions
  • Can be fired once on a delay (a one-off "in an hour" is still a Task, not a recurring routine)
  • No persistence beyond the conversation — the work is the output, not a saved schedule

Limitations: A Task is gone once it runs — there's nothing to fire again tomorrow. If you find yourself re-typing the same prompt every morning, that's the signal to promote it into a Routine. Tasks also need you present (or at least the session open) to act on anything that requires confirmation.

Do it now

Best for: Daily/weekly work that needs your local files or open apps and runs around hours when your laptop is on.

  • Recurring — runs on a cron-style cadence or natural-language schedule
  • Keeps local file access and open-app awareness, like a Task
  • Created and managed with /schedule (list, edit, disable)
  • Output lands back in a conversation — no separate inbox
  • Missed runs queue and fire when you reopen Cowork

Limitations: Desktop-bound. If your laptop is closed at 6am, the 6am run does not happen on time — it fires when you reopen the app, which may be hours late. That's fine for a morning briefing you read at 8am; it's wrong for anything that must land on a strict clock or while you're away.

Recurring · local

Best for: Must-run-on-time, off-hours, or always-on jobs that can get everything they need from connectors.

  • Runs on Anthropic infrastructure — fires on time even with the laptop shut
  • Best for strict schedules: pre-dawn briefings, hourly monitors, off-hours digests
  • Connector-only data access — Gmail, Calendar, Drive, Slack, CRM, etc.
  • No missed runs from a closed laptop — the cloud is always on
  • Managed alongside Local Routines, but flagged as cloud-hosted

Limitations: No local file access and no screen awareness. If the job needs a file on your disk or an app you have open, a Cloud Routine can't see it. It also runs without you present, so its capability surface is exactly its connectors — scope those tightly (read-only where possible), because there's no one watching the run.

Recurring · cloud

Best for: Promoting a Task you keep re-running into a managed, recurring routine.

  • Trigger with /schedule or plain language ("every Monday at 9am, ...")
  • Cron-style cadences or one-off fireAt times
  • /schedule list shows everything you have running; update/delete to manage
  • Choose local vs cloud where the cadence and capability needs make the choice clear
  • Routines are revertible — disable without deleting the prompt

Limitations: Routines accrete. It's easy to schedule five things in a week and forget what's firing. Review /schedule list periodically and disable the ones you no longer read — an unread daily briefing is just noise that costs runs.

Control surface

Best for: Knowing which routine type a job can even run on before you pick a cadence.

  • Local-only signals: reads/writes a working folder, uses Dispatch, watches an open app
  • Cloud-eligible signals: all inputs and outputs live behind connectors (MCP)
  • Must-run-on-time + cloud-eligible → Cloud Routine
  • Needs local context (any cadence) → Local Routine (or a Task if it's one-off)
  • When in doubt, start local and promote to cloud once the job is connector-only

Limitations: Connectors carry the agent's authority and run unattended in a Cloud Routine — a misbehaving or compromised connector is a real risk vector with no human watching. Prefer read-only scopes for anything a Cloud Routine touches, and add write scopes only when you've watched the read flow work as a Task first.

The decision

A Cloud Routine runs without you watching — scope it like it

The thing that makes Cloud Routines powerful — they run while your laptop is closed — is also what makes them riskier: **no human is in the loop when they fire.** A Task lets you confirm a risky action; a Cloud Routine just acts, with whatever authority its connectors carry. So the discipline is: prove the work as a **Task** first, watch the read flow, then promote it to a routine. Give Cloud Routines **read-only connector scopes** wherever the job allows, and add write access only after you've seen it behave. Powerful and unattended is exactly the combination that turns one bad connector into a quiet problem.