Which Claude do you actually need? A tour of Anthropic's product range

Anthropic ships Claude in four flavours now, and the differences matter more than the marketing pages suggest. The Web app is the cloud workbench. The Desktop app is the local-files workbench. Mobile is the pocket version. And Claude Code, the CLI, is the one that actually moves files around on your machine and runs on a schedule while you're asleep.

The short version: if you're chatting, use the Web. If you want Claude to do things in your repo, use the CLI.

Core differences

• Web (claude.ai) — Runs entirely in the cloud. Best for long conversations, research, and remote connectors (Google Drive, Slack, GitHub). You upload or paste anything you want it to see. Projects, Artifacts, and Skills all live here.
• Desktop app — A native wrapper around the same Web experience with a few extras: local filesystem access via MCP, a tidier multi-window layout, and global hotkeys. Think "Web, but it can see one folder on your Mac."
• Mobile (iOS / Android) — The on-the-go version. Voice input, camera capture, and device-specific connectors (iMessage on iOS, share-sheet integrations). Same conversation history syncs from Web.
• Claude Code (CLI) — A terminal-based agent that lives inside your project directory. It reads, edits, and writes files; runs shell commands; opens PRs; and chains tools together autonomously. This is the one developers reach for daily.

Where Claude Code pulls ahead

The CLI isn't just "Claude in a terminal." It's a different product shape:

• Agentic by default. It plans, executes, and verifies multi-step tasks across your codebase — not one prompt, one response.
• Tool ecosystem. Hooks fire on events (commits, tool calls, session start). Slash commands and Skills let you bundle reusable workflows. MCP servers connect it to anything from Notion to Shopify to your own internal APIs.
• Subagents. Spin up specialised agents (explorers, planners, reviewers) in parallel so the main thread doesn't drown in context.
• IDE integrations. First-class support in VS Code and JetBrains; also runs as a desktop app and a web app at claude.ai/code.
• Background tasks & scheduling. This is the part most people miss. Claude Code can:
  • Run long jobs in the background while you keep working.
  • Schedule its own wake-ups (ScheduleWakeup) to come back and check on a CI run, a deploy, or a queue.
  • Run autonomous loops on a cron schedule — wake up every morning, check for new tickets, triage them, and report back. No human in the loop until you want one.
  • Use Remote Triggers to fire on external events (webhooks, GitHub actions, anything that can POST).

That last bullet is the real unlock. The Web app responds when you talk to it. The CLI can run on its own clock.

Feature breakdown

Feature	Web (claude.ai)	Desktop app	Mobile	Claude Code (CLI)
Local file read/write	Manual upload	Limited (via MCP)	No	Yes — native
Run shell commands	No	No	No	Yes
MCP servers	Yes	Yes	Limited	Yes — full
Subagents	No	No	No	Yes
Hooks & slash commands	Skills only	Skills only	Skills only	Yes — full
Background tasks	No	No	No	Yes
Scheduled / cron triggers	No	No	No	Yes
Remote triggers (webhooks)	No	No	No	Yes
Voice / camera input	No	No	Yes	No
Cross-device sync	Yes	Yes	Yes	Per-project
IDE integration	No	No	No	VS Code, JetBrains

How to pick

• Brainstorming, writing, research, one-off Q&A → Web.
• You want a native window and occasional access to a local folder → Desktop.
• You're away from your laptop → Mobile.
• You want Claude to ship code, run on cron, or work in the background → Claude Code.

Most days the answer is "both": Web for the thinking, CLI for the doing.

A note on subscriptions

Pro, Max, Team, and Enterprise plans all share usage across surfaces. The CLI counts against the same budget as the Web app, so you don't pay twice — you just pick the right surface for the job.

FAQ

Do Projects work across all of them, and does the context sync?

Projects — Anthropic's way of bundling custom instructions, uploaded files, and a persistent knowledge base — live in your Anthropic account, so they sync automatically across Web, Desktop, and Mobile. Start a Project on the web, open the Desktop app, and it's right there. Same on your phone.

Claude Code is the odd one out. It doesn't use Projects in the same way. Instead, project context lives in the repo itself:

• CLAUDE.md files (root, subdirectory, or user-global) act like Project instructions.
• Skills, MCP server configs, and hooks live in .claude/ directories.
• Memory files persist user preferences and learned context across sessions.

So Web/Desktop/Mobile share one cloud-side Project. The CLI has its own project model that's local-first and version-controllable — which is usually what you want for a codebase, but means there's no automatic bridge between "my Project on claude.ai" and "my repo on disk." If you want the same instructions in both, you currently have to maintain them in two places.

Can I connect a chat Project to a Claude Code session (especially on mobile)?

No — and this trips a lot of people up. Projects and Claude Code sessions are separate context systems, even though both surface inside the Claude app.

On mobile (and at claude.ai/code on the web), Claude Code runs in a cloud sandbox. To start a session, you point it at a git repository — GitHub, GitLab, or similar. The sandbox clones the repo, and Claude works inside it. There's no field to attach a chat Project, and the custom instructions or uploaded files from your Project don't carry over.

The mental model:

• Chat Projects = a bucket of instructions + knowledge files for conversations.
• Claude Code sessions = a sandbox + a git repo for doing work on code.

If you want Claude Code to follow project-specific instructions, commit a CLAUDE.md file to the repo. That's the equivalent of Project custom instructions, and it works identically on mobile, desktop, web, and the terminal CLI — because they're all reading the same file from the repo.

So if you were trying to get your mobile Claude Code session to pick up a Project you'd built in chat, the answer is: copy those instructions into a CLAUDE.md at the repo root, commit it, and re-open the session. From then on, every Claude Code surface will have that context.

How long do Claude Code cloud sessions last? Can I come back to them?

Yes — with a caveat. There are two layers here, and they have different lifetimes:

The conversation persists indefinitely. When you start a Claude Code session on the web or mobile, the chat history is saved to your account. Close the browser, close the app, come back next week — the session is still in your list at claude.ai/code, and you can pick up the thread.

The sandbox environment is reclaimed after inactivity. The actual cloud VM that's running Claude, with your repo cloned in and dependencies installed, gets torn down after a period of idle time. Anthropic doesn't publish an exact number, just "a period of inactivity." When that happens, you'll see something like Could not resume session ... its environment has expired. Creating a fresh session instead. if you try to reconnect from the terminal, or the session is flagged as expired in the web list.

Reopening just re-provisions a fresh environment. Critically, the docs are clear that your conversation history is restored when you reopen — you're not starting from scratch, you're just getting a new sandbox under the same conversation. The setup script reruns, dependencies reinstall, and Claude picks up where you left off.

A couple of related lifetimes worth knowing:

• Setup script cache: ~7 days. Even if you're actively using a session, the environment's setup script gets re-run roughly weekly to refresh the cache.
• --teleport / Remote Control tokens are short-lived. If you're moving a cloud session into your local terminal and get a Remote Control session expired error, just /login again.

Practical habits:

• The durable artifact is git. Commit and push often — uncommitted edits in a reclaimed sandbox are gone.
• Don't rely on /tmp or installed-but-not-scripted state surviving long gaps. Put it in your setup script.
• You can monitor running sessions from the Claude mobile app, which is handy for long jobs you've kicked off from your laptop.

The terminal CLI on your own machine doesn't have any of these concerns — it's your filesystem, your processes, your call.

What about Claude Cowork? Isn't that a bridge between Projects and local files?

Close, but not quite. Cowork is the third tab in the Claude Desktop app, alongside Chat and Code. Anthropic positions it as "agentic AI for knowledge work" — longer, autonomous tasks that operate on your local files, folders, and applications and return a finished deliverable. Think "research this, summarise it into a deck, save it to my Documents folder" rather than a back-and-forth chat.

So yes, Cowork does have access to local files (that's the whole point), and yes, it does have Projects. But there's a twist worth knowing:

Cowork Projects are not the same as chat Projects. As of the March 2026 desktop release, Cowork got its own Projects feature — and they're desktop-only, stored locally on your machine, with no cloud sync. Files, conversation history, and project settings all live on your PC. Only the prompt context goes to the cloud at inference time.

That means there are now three separate Projects systems in the Claude ecosystem:

Surface	Projects?	Where stored	Syncs?
Chat (Web / Desktop Chat / Mobile)	Yes — chat Projects	Cloud	Yes, across all three
Cowork (Desktop only)	Yes — Cowork Projects	Local disk	No
Claude Code (CLI / web / mobile)	CLAUDE.md + .claude/	Repo	Via git

So Cowork isn't a bridge between cloud chat Projects and local files — it's its own thing. The bridge it does provide is between Claude's agentic capabilities and your local working environment: it can read your files, open your apps, and run scheduled recurring tasks against a local Project that has its own memory and instructions.

A few specifics worth knowing:

• Memory is on by default in Cowork Projects. Claude remembers context from tasks you've run in a project and applies it to future ones in the same project.
• Scheduled tasks can be configured per-project — recurring jobs that run inside a Cowork Project on a schedule.
• Desktop only. No Linux build; on mobile and web, you don't get the Cowork tab at all.

If you were hoping to take a Project you'd built in chat (say, a Project with a knowledge base of company docs and custom instructions) and have Cowork operate on your local files using that same context — the answer is no, you'd need to rebuild the instructions and files inside a fresh Cowork Project. Two separate systems that happen to share the word "Project."

How does scheduling work? What are "routines"?

This is genuinely confusing because there are now three different scheduling systems, each tied to a different surface. Here's the map:

1. Cowork Scheduled Tasks (Desktop Cowork)

Set up recurring tasks inside a Cowork Project — for example, "every Monday at 9am, summarise last week's emails." The catch: these run on your machine. If your Mac is asleep or the Claude Desktop app is closed when the task is scheduled to fire, Cowork skips it and runs it later when you wake the machine or reopen the app. Fine for daily-driver workflows, not great for anything that has to fire reliably.

2. Claude Code session-scoped scheduling (local CLI)

Inside a Claude Code session on your laptop, the agent can schedule its own wake-ups — pausing and resuming itself to check on long-running work (CI jobs, deploys, queues). This is session-scoped: it only runs while that terminal session is alive. Useful for "wait until the build finishes, then keep going," not for "every Monday."

3. Claude Code Routines (cloud) — the new one

Announced 14 April 2026 and the most powerful of the three. A routine is a saved Claude Code configuration — a prompt, one or more repositories, a set of connectors, and one or more triggers — that runs as a full Claude Code cloud session on Anthropic's infrastructure. Your laptop can be closed, off, or at the bottom of a lake; the routine still fires.

Three trigger types:

• Scheduled — hourly, nightly, weekly, or a one-off at a future time.
• API — POST to a per-routine endpoint with a bearer token. Wire it up to anything that can send a webhook.
• GitHub — fire on repo events (PR opened, release tagged, etc.).

You can create routines from claude.ai/code/routines, from the Desktop app, or conversationally from the CLI via /schedule. (Heads up: if you were previously using /schedule in the CLI for local scheduled tasks, the same command now creates cloud routines instead.)

Routines run with no permission prompts during a run — they're meant to be autonomous. They can run shell commands, use any Skills committed to the cloned repo, and call any connectors you've attached.

Plan limits (as of mid-2026):

Plan	Routines per day
Pro	5
Max	15
Team / Enterprise	25

Which one should you use?

• One-off "check back on this in 10 minutes" while you're working → CLI session scheduling.
• Recurring desktop knowledge-work ("summarise my inbox at 9am") → Cowork Scheduled Tasks.
• Anything that needs to run reliably whether or not you're at your machine — daily triage, nightly maintenance, webhook-triggered automations, GitHub event responders → Cloud Routines. This is the one most people actually want.

The mental shift with Routines is that Claude Code stops being a tool you open and becomes a tool you deploy. You configure once, attach triggers, and it runs on its own clock — closer to a Vercel cron job with a brain attached than to a chat session.

I'm out and about and I need to work on my iOS app. The cloud sandbox can't run Xcode and screenshots are painful. What do I do?

Right — Claude Code's cloud sandbox is a Linux container. It doesn't have Xcode, can't run an iOS Simulator, and can't capture SwiftUI previews. For genuine iOS work you need a Mac in the loop. The trick is: it doesn't have to be the Mac in your hand.

The setup most people land on is Remote Control. Before you walk out the door, on your home Mac:

claude remote-control --name "iOS App"

That leaves a Claude Code process running locally, registered with Anthropic, polling for work. Then from your phone — the Claude iOS app, Code tab — you'll see the session online (green dot, computer icon). Tap in and you're driving the session that's actually running on your Mac. Xcode is available, the iOS Simulator is available, your MCP servers are available, your local filesystem is available. The phone is just a window into the session.

Why this is the right shape for iOS work specifically:

• Xcode builds run locally. xcodebuild works because it's running on your real Mac.
• Simulator screenshots actually work. Claude can boot the Simulator and capture screenshots from it — and as of Xcode 26.3 (Feb 2026), Claude Code is a native, first-class citizen inside Xcode itself, including the ability to capture SwiftUI previews and iterate on them visually.
• Push notifications close the loop. Enable Push when Claude decides in /config and your phone will ping you when a long build finishes or Claude hits a question.
• Nothing moves to the cloud. The session executes on your Mac. Your code, signing certs, and provisioning profiles never leave the box.

One important caveat: permission prompts

You'll hear (rightly) that Remote Control and Dispatch sessions can be annoying because every tool call wants approval, and from a phone that gets old fast. A few things to know going in:

• --dangerously-skip-permissions does not apply to Remote Control sessions. Even if you start the host process with that flag, the mobile client still pops a permission prompt for every file edit and bash command. (Tracked in Anthropic issue #29214.)
• On iOS, prompts truncate to ~100 characters of the proposed command with no way to expand them — so you may be approving xcodebuild -workspace … blind. (Issue #37235.)
• Various rendering and round-trip bugs come and go: prompts that don't appear on mobile, approvals from the phone that don't release the host. Worth checking the latest version before relying on this for serious work.

Mitigations that actually help:

1. Pre-allow trusted tools in settings.json. The permissions.allow list is evaluated for Remote Control sessions too. Add the verbs you trust ahead of time — for an iOS project, things like Bash(xcodebuild *), Bash(xcrun simctl *), Edit, Read, Bash(swift *). Keep Bash(git push *) and Bash(rm *) gated. Done well, this cuts prompts from "constant" to "a handful per session."
2. Push Routines do the unattended work. If a task is well-defined enough to script (nightly lint, weekly dependency bumps), it belongs as a Cloud Routine — Routines run with no permission prompts. The catch is they're Linux, so the iOS-build parts of your workflow can't move there. But your repo's non-iOS scripts can.
3. Turn on push notifications. Doesn't reduce prompts, but at least your phone buzzes when one is waiting instead of you having to keep the app foregrounded.

Other options worth knowing:

• Dispatch — lighter than Remote Control: from the Claude mobile app, message a task and your Desktop app spawns a session to handle it. Good for "kick off this thing, tell me when it's done." Same permission caveats apply.
• Channels — wire Telegram, Discord, or iMessage into a running session so messages from those apps become prompts. Handy if you'd rather not open the Claude app, but again, doesn't dodge the approval flow.

Practical recipe:

1. Install Claude Code v2.1.110+ on your Mac. Confirm with claude --version.
2. In your project's settings.json, build out a permissions.allow list for the safe verbs you use constantly. This is the single biggest quality-of-life change.
3. Run claude remote-control --name "iOS App" before leaving the house. Scan the QR code (press spacebar in the terminal) to open it on your phone.
4. Turn on push: /config → enable Push when Claude decides.
5. Leave the Mac awake. (Caffeinate it if you have to — if the network drops for more than ~10 minutes, the Remote Control session times out and you'd have to restart it next time you're back.)

The honest TL;DR: you can't take Xcode with you, but you can take a remote control for it. Plan on tuning your allowlist or you'll be tap-tap-tapping through prompts at the café.

Can I trigger Claude with an HTTP POST from my own scripts or services?

Yes, and the way it works is different depending on whether you're targeting a cloud Routine or a local CLI session.

Cloud Routines have first-class API triggers. When you create a Routine, Anthropic gives you a per-routine HTTPS endpoint and a bearer token. A POST to that endpoint kicks off a fresh cloud session — no local infrastructure, nothing running on your machine. This is the easy answer if your task can run on Anthropic's Linux cloud (anything web, API, or non-Mac-specific).

The local CLI doesn't listen on HTTP — there's no inbound API for a claude process running in your terminal. But there's a direct equivalent called Channels. A Channel is a framework-agnostic adapter that forwards external events into a running local Claude Code session. The shipping integrations are Telegram, Discord, and iMessage, but the more important point is that you can build your own channel that turns an arbitrary HTTP POST into a prompt fed to your local session. That's the CLI's answer to "how do I trigger this from outside."

Mapping the surfaces:

Surface	External POST trigger?	How
Cloud Routines	Yes, first-class	Per-routine endpoint + bearer token
Local CLI session	Yes, but you wire it up	Channel plugin (built-in for Telegram/Discord/iMessage; custom for arbitrary webhooks)
Mobile / Remote Control	No direct POST	Drive interactively from phone

Why this matters in practice. If you're tempted to chain "GitHub Action triggers Cloud Routine triggers my local machine" — that's not a direct path. The Routine runs in Anthropic's cloud; it can't hand off mid-flight to your laptop. The two real options for getting external events to a local session are:

1. External trigger → your local machine directly (e.g. a self-hosted CI runner that invokes the CLI headlessly)
2. External trigger → POSTs to a custom Channel endpoint on your machine → the channel injects the prompt into a long-running Claude Code session

Option 2 is conceptually cleaner if you want a single always-on session that handles many kinds of incoming work (issues, webhooks, your own automations), instead of spinning up a fresh runner per event. But it's more bespoke — you write the channel, you manage the long-running session, you handle restarts.

Most teams use cloud Routines for genuinely cloud-shaped work, direct CI invocations for repo work, and reserve channels for "react to messages while I'm away" patterns. The primitives are all there; the choice is mostly about what infrastructure you already have.