On this page
Should your AI agent work on your laptop, or on someone else's server? A year ago that was not a real question. Now it is one you answer every time you start a task.
There are two models. A cloud agent runs in a remote sandbox: it clones your repository, works there, and opens a pull request. A local agent runs on your computer, with your shell, your files and your running services.
Both are useful. Here is how they compare on the points most developers care about, and where each one comes out ahead.
In short:
- "Local" means the agent runs on your machine. Your prompts and the code it reads still go to the model provider.
- Local agents win when a task needs your real environment, your secrets or fast feedback.
- Cloud agents win when work must go on while you are away, when you want many agents at once, or when you want a throwaway sandbox.
- Plenty of developers use both.
What "local" means, exactly
A local CLI agent such as Claude Code, Codex CLI or OpenCode runs as a process on your computer. It still sends your prompts, and the code it reads, to a model provider. So "local" does not mean "the model is on your machine."
What stays local:
- The working copy of your code
- Your
.envfiles, keys and tokens - Your shell, your toolchain and your running services
- The terminal output of each command
What leaves your machine: the prompt and the context the agent sends to its model.
Local and cloud agents side by side
| Factor | Local agent | Cloud agent |
|---|---|---|
| Where code runs | Your computer | A remote sandbox |
| Access to local services (database, queue, containers) | Yes, the same ones you use | Only what the sandbox sets up |
| Secrets | Stay in your files; you control what the agent reads | Must be copied to the provider's environment |
| Compute cost | Your hardware | Provider compute, often billed or limited by plan |
| Feedback loop | Your machine, your test suite, your browser | Wait for the sandbox, then review a pull request |
| Works with your laptop closed | No | Yes |
| Scale to many agents | Limited by your CPU and memory | Limited by plan and budget |
| Start a task from a phone | No | Often yes |
| Isolation if the agent makes a mistake | Low: it runs with your permissions | High: a throwaway sandbox |
Where local agents win
Your real environment is already running
Most apps need more than source code. Think of a database with seed data, a queue worker, a cache, a container runtime, or a VPN to a staging API. A local agent uses the environment you already have up. It can run the full test suite, read the real logs and check the page in your browser.
A cloud sandbox has to rebuild all of that. For a small library, no problem. For an app with several services, the setup can take more work than the task itself.
Secrets stay where they are
A local agent reads .env from your disk, and you decide which files it may read. A cloud agent needs those secrets in the provider's environment configuration before it can run integration tests. Some teams have a policy that forbids that.
No second compute bill
You pay the model provider for tokens either way. With a local agent, builds and tests run on your own hardware.
Feedback you can see as it happens
You watch each command as the agent runs it. You can stop it, correct it, or take over in the same terminal. No waiting for a pull request.
Where cloud agents win
It is only fair to give the other side its due. Cloud agents are the better tool here:
- Work continues while you are away. A cloud agent keeps going with your laptop closed. A local agent stops when the computer sleeps.
- Scale. Ten cloud agents do not slow your machine. Ten local agents fight over your CPU and memory.
- Isolation. A cloud sandbox limits the damage of a bad command. A local agent with
--dangerously-skip-permissionsruns with your full permissions. - No local setup. A new laptop, a tablet or a phone can start a task.
- Team visibility. The output is a pull request that everyone can review.
A practical setup for local agents
If local agents suit your work, the pain is usually organization, not capability. Too many terminal tabs. Sessions lost after a restart. Context you copy by hand. DevWorkspace Pro handles these:
| Problem | What DevWorkspace Pro does |
|---|---|
| Many agents, many projects | Start claude, codex or opencode in any project with ⌘+J. Each session has a tab in the headless terminal, and the status bar shows what runs. |
| Lost sessions after a restart | Unfinished sessions show a Resume button with the same folder, conversation and arguments. See Session Resume. |
| Copying context | Send to AI on a GitHub issue, a failed Actions run or a log entry. See AI Sessions. |
| The computer sleeps during a long run | Keep Awake keeps the computer on for a set time. |
| Open items from the agent | The Focus Pad MCP server runs on 127.0.0.1 only, so the agent can add tasks to your checklist. |
Saved session records and terminal snapshots stay on your computer, in the app data folder. DevWorkspace Pro does not save your prompts.
Working offline
Your editor, files, Git history and local services all work without a network. A CLI agent that uses a hosted model needs a connection to reach it. If you often work offline, check whether your agent supports a model that runs on your computer.
One part of DevWorkspace Pro runs fully on your machine: Voice-to-Text. After the one-time model download, it sends no audio or transcripts to external servers.
How to choose for each task
Three questions settle most cases:
- Does it need local services or secrets? If yes, go local.
- Must it run while you are away? If yes, go cloud, or keep the computer awake.
- How much damage can a wrong command do? If the answer worries you, use a sandbox, or run the local agent without permission-skip flags.
You do not have to pick one for good. Many developers send small, isolated tasks to cloud agents and keep work in the full app on local agents.
FAQ
Frequently asked questions
Does a local agent keep my code away from the AI provider?
No. A local CLI agent such as Claude Code or Codex still sends prompts and the files it reads to its model provider. Local means the agent, the shell, the files and the secrets stay on your machine, not in a remote sandbox.
Do local agents work offline?
Your tools, files and local services work offline. The agent needs network access to its model provider, unless the tool is configured for a model that runs on your computer.
When is a cloud agent the better choice?
When you want work to continue with your laptop closed, when you want many agents without local CPU and memory, when the task needs no local services, or when you start tasks from a phone or browser.
Can I use both?
Yes. Many teams send small, isolated tasks to a cloud agent and keep tasks that need local databases, services or secrets on a local agent.