Claude Co-work Now Runs in the Cloud: What Changed and How to Use It
Claude Co-work moved to the cloud so tasks run even when your laptop is closed. Here's what changed, how scheduled tasks work, and what still needs desktop.
What Claude Co-work Actually Is (and Why the Cloud Shift Matters)
If you’ve been using Claude for autonomous tasks — having it research topics, draft documents, or run multi-step workflows while you focus on other things — you may have noticed a significant change recently. Claude Co-work, Anthropic’s feature for longer-horizon, background task execution, moved a substantial portion of its processing to cloud infrastructure rather than relying on your local desktop client.
This isn’t a minor performance tweak. The shift fundamentally changes what Claude can do between when you assign a task and when you come back to check on it. For anyone using Claude in a serious workflow context, understanding what moved to the cloud, what stayed local, and how scheduled tasks now work is worth a few minutes.
This article breaks down exactly what changed, walks through how to use the updated scheduled task system, and clarifies what capabilities still need your machine running locally.
The Core Problem Cloud Execution Solves
Before the cloud shift, running background tasks through Claude had a frustrating dependency: your computer had to stay on and your Claude desktop app had to remain open.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
This created real friction. A task you kicked off before lunch could silently fail if your laptop went to sleep, your internet dropped, or you closed the lid to take a meeting in a different room. You’d come back expecting finished work and find a stalled process or an error state that gave you no clear indication of when it failed or why.
The fundamental issue is that local execution ties task completion to machine uptime. That’s fine for tasks that take 30 seconds. It’s a problem for tasks that take 30 minutes — or tasks you want to run at 3 AM while you’re asleep.
Moving execution to the cloud decouples task completion from your device state. The task runs on Anthropic’s infrastructure. Your laptop can be off, traveling with you on a plane, or sitting closed in your bag. The work still happens.
That decoupling is what makes a scheduled task something you can build a process on. Anthropic has been explicit that its direction for agentic AI is systems that handle longer-horizon work with minimal supervision, and a task that requires someone to keep a desktop client awake doesn’t clear that bar. It also makes shared workflows realistic: when execution doesn’t depend on one person’s machine, a team can actually rely on the output.
What Actually Moved to the Cloud
Not everything about Claude Co-work runs server-side. Understanding the split helps you know what you can realistically schedule and what still has constraints.
Cloud-Executed Capabilities
These now run entirely on Anthropic’s infrastructure and don’t require your desktop to be active:
- Web research and browsing — Claude can search, read pages, and synthesize information without your machine in the loop
- Document drafting and editing — Writing tasks, summarization, reformatting content — these are pure language tasks that run fine server-side
- Connected web services — Anything reachable over a public API runs server-side: Gmail and Google Workspace, Slack, Notion, Salesforce, HubSpot, cloud storage, and any SaaS tool you’ve connected through OAuth
- Scheduled recurring tasks — This is the biggest practical change for regular users (more on this below)
- Multi-step reasoning chains — Long chains of thought and planning steps that don’t require local file access
Cloud execution also takes the runtime off your hands. You’re no longer responsible for keeping an app version current, a machine awake, and a connection alive. Anthropic runs the environment, retries steps that fail transiently, and records the result whether or not anyone is watching.
What Still Needs Desktop
Some capabilities remain tied to local execution because they require access to your machine’s actual environment:
- Computer use on your screen — When Claude needs to click, type, or navigate your actual desktop UI, it needs to see your screen. That’s still local
- Local file system access — Reading or writing to files on your hard drive requires the desktop app to be running
- Applications that aren’t web-accessible — If Claude is automating a locally-installed app that has no API, that stays on-device
- On-premises databases and internal APIs — Anything sitting behind a corporate firewall or VPN isn’t reachable from Anthropic’s cloud without a tunnel or a local component to broker the connection
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
The practical upshot: anything that would require a remote worker to be sitting at your physical desk stays local. Anything that a remote worker could do from their own computer — web research, writing, emailing, integrations — now runs in the cloud.
Worth saying plainly: this split isn’t a Claude limitation. Every cloud automation platform hits the same wall, because a server in someone else’s data center has no route to your laptop’s file system or your company’s private network.
How Scheduled Tasks Work Now
Scheduled tasks are the feature that benefits most from cloud execution, and the setup is simpler than it might sound.
Setting Up a Scheduled Task
Within Claude.ai (or the Claude desktop app when connected to cloud execution), you can assign a recurring task using natural language or a structured schedule. The basic flow:
-
Describe the task — Tell Claude what you want done. Be specific about inputs, outputs, and what “done” looks like. “Every Monday morning, pull the top five stories from [source], summarize them in bullet points, and draft them into an email I can send to my team” is the right level of detail.
-
Set the schedule — You can specify timing in plain language (“every weekday at 8 AM”) or set it precisely: specific times, recurring intervals, day-of-week patterns. Claude parses this into a real schedule on the backend, and because execution no longer waits for a desktop client to wake up, start times are more consistent than they were locally.
-
Define where output goes — This is important. Cloud-executed tasks need somewhere to put results. Common destinations include email drafts, connected document tools, or a notification you’ll see when you open the app. Specify this explicitly.
-
Confirm and save — Once the task is saved, it runs independently. You don’t need to do anything to trigger it.
Checking on Running Tasks
One of the practical improvements with the cloud shift is visibility into task status. You can now check whether a scheduled task ran, what it produced, and whether it hit any errors — even from a different device than the one you used to set it up.
This was nearly impossible with local execution, because the task state lived on your machine.
Modifying or Canceling Scheduled Tasks
If a task needs to change — different timing, different output format, different scope — you can edit it directly. Claude will apply changes on the next execution cycle. If you cancel a task that’s mid-run, the cloud infrastructure handles the cleanup rather than leaving your local system in a partial state.
How to Migrate an Existing Co-work Setup
If you already had tasks running under the old local model, they don’t all move over the same way. A short audit up front prevents most of the failures.
Step 1: List What You’re Actually Running
For every scheduled task, write down four things: what triggers it, what data sources it reads, what actions it takes, and where the output lands. Most people are surprised by how many tasks they have and how many quietly depend on something local.
Step 2: Sort by What Each Task Connects To
One coffee. One working app.
You bring the idea. Remy manages the project.
Cloud-ready — the task only touches web APIs, SaaS tools, and cloud storage. It can move with no redesign.
Local-dependent — the task reads or writes files on your drive, queries an internal database, or drives a desktop application. It needs a hybrid approach.
Step 3: Move the Cloud-Ready Tasks First
Reconfigure them for cloud execution, confirm the schedule matches what you had (including the time zone), then run one cycle with your desktop app closed. That last step is the actual test. A task that has only ever run with the app open hasn’t proven anything yet.
Step 4: Redesign the Local-Dependent Ones
Three options, roughly in order of how much they buy you:
- Lift the data to the cloud. If a task picks files out of a local folder, sync that folder to Google Drive, Dropbox, or S3 and point the task at the cloud copy. Usually the cleanest fix, and it removes the local dependency permanently.
- Split the task. Keep the file access or internal-system step local and move everything else — reasoning, drafting, external API calls — to the cloud, then chain the two halves together.
- Keep a local client running for that step. Least appealing, but sometimes unavoidable for on-premises systems and desktop apps with no API. You’re back to depending on machine uptime for that portion of the work, so scope it as narrowly as you can.
Step 5: Don’t Cut Over Until the Cloud Version Proves Itself
For anything critical, run the old and new versions in parallel for a few cycles and compare outputs before you disable the local task. Scheduled work fails quietly, and the first sign of a silent failure is usually a missing output somebody notices days later.
Practical Use Cases That Work Well Now
The cloud shift opens up patterns that were too unreliable to count on before.
Morning Briefings
Set up a task that runs at 6 AM every weekday. Claude pulls from your specified sources, summarizes what matters for your context, and has a briefing waiting in your inbox or a document when you wake up. Your laptop doesn’t need to be on at 6 AM.
Recurring Research Tasks
If you track competitors, monitor industry news, or need regular market snapshots, these work well as scheduled cloud tasks. Define what you’re tracking, how you want it structured, and where it goes. Claude handles the execution on schedule.
Automated Draft Preparation
For teams with regular reporting cycles — weekly updates, monthly summaries, quarterly reviews — Claude can pull structured data from connected tools, draft the document, and have it ready for human review before the meeting. The draft doesn’t appear because someone remembered to run a prompt. It appears because it was scheduled to.
Async Research While You Sleep
This was technically possible before but unreliable. Now you can legitimately close your laptop, go to sleep, and wake up to completed research on a complex topic. As long as the task is cloud-executable (no local files needed), it runs.
Common Setup Mistakes to Avoid
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
A few patterns consistently cause scheduled tasks to fail or produce poor results.
Being vague about outputs. “Summarize the news” gives Claude no clear destination or format. “Summarize the top five headlines from [specific source], format as bullet points with a one-sentence context note for each, and add them as a draft to my email” is specific enough to execute reliably.
Assuming local files are accessible. If your task references “the spreadsheet on my desktop,” that’s a local file. Cloud execution can’t reach it. Either connect your files through a cloud storage integration or restructure the task to work with web-accessible data. The same applies to internal databases and desktop applications — audit what a task connects to, not just what the prompt says, because a cloud task pointed at a local resource tends to return an incomplete result rather than a loud error.
Not testing before scheduling. Run the task manually first. If it works once, it’ll work on a schedule. If it fails manually, debug it before setting up recurrence.
Not reconfiguring the schedule after moving. Cloud scheduling isn’t necessarily the same system your local tasks used. Set time zones, intervals, and trigger types explicitly instead of assuming they carried over intact.
Skipping failure notifications. With local execution you often noticed a failure because you happened to be sitting right there. Cloud tasks fail out of sight by design. Turn on failure alerts and result logging before you depend on a task for anything that matters.
Moving sensitive local data to the cloud without checking. If data lives on-premises for compliance reasons, cloud execution changes where it gets processed. That’s a policy question, not a technical one, and it’s cheaper to resolve before the migration than after.
Scheduling too frequently without checking results. It’s easy to set up ten scheduled tasks and then not look at the outputs for a week. Cloud execution means the tasks run — but someone still needs to close the loop and actually use what Claude produces.
Where MindStudio Fits for More Complex Scheduled Automation
Claude Co-work’s cloud shift handles a lot — but it’s built around Claude’s own task management system. If you’re building workflows that need to span multiple tools, trigger based on external events, or connect to business systems in more structured ways, that’s where a platform like MindStudio becomes relevant.
MindStudio lets you build autonomous background agents that run on a schedule without any desktop dependency — because they’re cloud-native from the start. You connect them to tools like HubSpot, Slack, Google Workspace, Airtable, and hundreds of others, then define what should happen and when.
The difference from Claude’s built-in scheduling is depth of integration and workflow control. In MindStudio, you can chain multiple AI steps together, add conditional logic (“if the research finds X, do Y; otherwise do Z”), and pipe outputs directly into business tools rather than email drafts. You can also use Claude as the model inside a MindStudio workflow if you want — it’s one of 200+ models available on the platform.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
For teams that need scheduled AI work to connect cleanly with existing operations rather than sitting in a chat interface, MindStudio’s background agents are worth looking at. You can try it free at mindstudio.ai.
Frequently Asked Questions
Does Claude Co-work in the cloud cost extra?
Cloud task execution is tied to your existing Claude subscription tier. Anthropic has not introduced a separate line item specifically for cloud versus local execution — you’re billed based on your plan and usage volume, not where the compute runs. That said, if you’re running frequent scheduled tasks that consume significant context, it will draw against your usage limits faster. Check your plan details if you’re running high-frequency schedules.
Can I use Claude Co-work cloud tasks on a team plan?
Yes. Team and enterprise plans support cloud task execution, and in many cases they offer better limits for scheduled tasks than individual plans. Team setups also allow shared task definitions — meaning one person can configure a recurring workflow and others on the team can see or use its outputs.
How do I know whether an existing Co-work task is cloud-compatible?
Walk the task step by step and look at what each step touches. If every one of them talks to a web service with a public API — Gmail, Slack, Notion, a cloud storage folder — the task is almost certainly cloud-compatible. If any step reads a local drive, queries an internal server, or clicks through a desktop application, that step still needs something running locally.
Can I keep running tasks locally if I prefer to?
Yes. The model is hybrid rather than all-or-nothing: cloud execution for tasks that can use it, local execution for tasks that genuinely need machine access. Keeping a task local when it could run in the cloud mostly means keeping the old failure mode — if your machine sleeps, the task doesn’t run.
What happens if a scheduled cloud task fails?
With cloud execution, Claude captures the failure state and logs it. You’ll typically get a notification (depending on your settings) and can review what went wrong. The task doesn’t silently disappear the way local tasks sometimes did when a machine went offline. You can retry or edit the task definition and run it again.
Is my data safe running tasks in the cloud versus locally?
Anthropic’s cloud infrastructure is subject to the same privacy and security policies as the rest of Claude.ai. For enterprise customers, data handling agreements apply. If you had concerns about local execution because you worried about what Claude was doing on-device, cloud execution is actually more transparent — there’s a clearer audit trail. If you had concerns about data leaving your machine at all, cloud execution means your task inputs and outputs are processed on Anthropic’s servers rather than locally.
What AI models are used for cloud-executed tasks?
Cloud tasks default to the same Claude model your account is configured to use. If you’re on a plan with access to Claude 3.5 Sonnet or Claude 3 Opus, those capabilities apply to your scheduled tasks. Anthropic hasn’t segmented cloud task execution to a different or lesser model.
Can I trigger cloud tasks via webhook or API instead of a schedule?
This is currently more of a developer-facing capability through Anthropic’s API rather than a native Claude.ai UI feature. If you want event-driven task execution (trigger when something happens, not just on a clock), you’re better served building that through the API directly or using an automation platform that supports webhook-triggered AI workflows. This is one area where the native scheduling UI has clear limits.
Key Takeaways
- Claude Co-work’s cloud shift means scheduled tasks now run whether or not your laptop is on or the desktop app is open
- Web research, document drafting, API integrations, and recurring schedules now run server-side
- Computer use on your actual screen, local file access, and anything behind a corporate firewall still require a local component
- The biggest practical improvement is reliable scheduled task execution with status visibility across devices
- Migrating an existing setup is an audit exercise: list your tasks, sort them by what they connect to, move the cloud-ready ones first, and prove each one runs with the desktop app closed before you cut over
- Setting up effective cloud tasks requires being specific about outputs and destinations — vague prompts don’t execute reliably at scale
- Cloud tasks fail out of sight, so turn on failure notifications before you depend on one, or a broken schedule can go unnoticed for days
- For workflows that need to span multiple business tools or include conditional logic, a dedicated automation platform like MindStudio extends what’s possible beyond Claude’s native scheduling
