Local vs Remote AI Agents: Where Should Your Agent Run?

A practical comparison for engineers choosing between running AI agents on their own machine and letting a vendor run them in the cloud—across vendor lock-in, 24/7 execution, interactive modes, and browser automation.

The same brain, a different body

Two engineers run the same agent product. One keeps it in a terminal on a laptop; the other uses the vendor's cloud sandbox from a browser. The models are identical, the tool calls nearly so, yet the two setups behave differently in ways that have nothing to do with intelligence: whose disk the repo lives on, whether the agent survives a closed lid, how a human says “yes” mid-task, and which browser the agent is allowed to drive.

The confusion starts because “local” and “remote” are used for three different things at once: the model (local inference vs hosted API), the runtime (the agent process with its tools and filesystem), and the context (your repo, credentials, and browser sessions). A “local” agent almost always calls a “remote” model. What people usually mean by local vs remote agents is the runtime—and the runtime is what the rest of this article compares.

Three planes, three different owners

Plane	Local option	Remote option
Model plane	Local inference (Ollama, LM Studio, llama.cpp) or your own API keys to any hosted model	The vendor’s model, billed per token inside the product
Runtime plane	A process on your machine: reads your filesystem, your shell, your localhost services	A sandboxed VM or container in the vendor’s cloud, reachable from your editor or a chat UI
Context plane	Your repo, IDE state, terminal history, browser sessions, corporate SSO cookies	What you push or sync: cloned repos, uploaded files, MCP connections you authorize

Each plane has its own owner, and the ownership is what drives the trade-offs below. The model plane is a billing decision. The context plane is a security decision. The runtime plane—where the loop of “read, decide, act” physically spins—is the decision this article is about, because it quietly decides the other two.

A mental model

Think of the runtime as a worker who lives somewhere. A local worker lives in your office: they can read anything on your desk, but they go home when you lock the door. A remote worker lives in a building you rent: they work around the clock, but everything they read is copied into that building first, and you pay per hour. Most teams end up hiring both—for different jobs.

Vendor lock-in: what actually gets locked

Lock-in is usually discussed as a binary—open protocols vs proprietary platforms. In practice it is four separate couplings, each with a different escape route:

Model & billing lock

Remote agent products bundle the runtime with one vendor’s models and pricing. You cannot point the same product at a cheaper or open model without changing products, and every background task, retry, and tool call is metered on their invoice. A local runtime like a CLI agent is just a client: swap API keys, route through a gateway, or drop in local inference, and the workflow you built keeps working.

Context & history lock

Sessions, transcripts, checkpoints, and memory live in the vendor’s cloud. That is convenient—resume a session from any device—until you need to leave: export formats are incomplete, deletion is a support ticket, and your agent’s accumulated context about your codebase is not a file you can copy. Local runtimes store history as plain files (transcripts, .md rules, git history) that you can archive, diff, and migrate.

Tool & agent-definition lock

Your custom skills, MCP server configs, and agent definitions are the portable part—most are files. But registries, permission models, and how agents are packaged differ per vendor, so an agent you define in one product does not drop into another unchanged. Open protocols help here more than anywhere else.

Orchestration lock

The planner, the router, the background scheduler, and the approval UI are proprietary and invisible. Even with the same model available elsewhere, you cannot reproduce how the vendor’s agent breaks tasks apart, retries, or decides when to stop. This is the deepest lock-in and the hardest to test for, because it only shows up when you try to leave.

The open-protocol wave of the last two years—MCP for tools, ACP (Agent Client Protocol) between editors and agents, LSP for languages—genuinely removes two of the four locks. Your MCP servers and skills travel between clients, and an ACP agent runs in any supporting IDE, the same way an LSP server works in any editor. If that is all you need, portability is largely solved, and the vendor-neutral posture of recent products (the ACP Agent Registry is a good example, covered in our earlier article) reflects it.

What the protocols deliberately do not standardize is everything above the tool layer: the planner, the memory, the background scheduler, the permission model, and the billing. That is where remote products earn their margins and where your switching cost lives. Industry analyses of agent-ecosystem fragmentation make the same point from the market side: portability at the protocol layer coexists with consolidation at the platform layer (see Zylos' research on platform lock-in and multi-vendor strategies).

The escape-hatch test

Before you build your workflow around any agent product—local or remote—ask:

Can I run the same agent definition against another vendor’s model with one config change?
Can I export my session history, checkpoints, and rules as files I actually own?
Do my custom tools and MCP servers survive a move to another runtime unmodified?
Is the background scheduler a file I can read, or a button in a web UI?
If the vendor raises prices or deprecates the product, what do I lose beyond convenience?

24/7 execution: the laptop-closed problem

The single most common reason teams move an agent from their laptop to the cloud is mundane: at 6pm the lid closes, and the agent that was mid-refactor simply stops. Remote runtimes solve this by existing independently of your devices—the vendor keeps the sandbox alive, and the loop that started in your editor keeps running on their servers. Claude Code's routines feature is the flagship example: recurring background jobs that work a backlog, review PRs, and respond to events in the cloud while you are offline (Anthropic's announcement), and the other major agent vendors now ship some form of scheduled or event-driven execution. The mental model that fits is “managed agents are the new serverless function”: you define the job, the platform keeps it warm, and you pay for what it does.

Local does not automatically lose this axis—it just moves the problem. Your options, in increasing order of commitment:

Keep the machine awake

A docked laptop or a spare desktop that never sleeps, with the agent run from tmux or a launch daemon. Zero cloud dependency, but now you are the datacenter: power, updates, and the occasional cat walking across the keyboard.

A cheap always-on box or VPS

Run the same CLI agent on a rented or home server, driven by cron or webhooks. This is the classic self-hosted answer: the runtime is remote in the geographic sense but fully yours—your disk, your secrets, your history files.

CI as the night shift

For repo-triggered work (PR review, dependency bumps), a scheduled pipeline job running an agent is often the cleanest “24/7 without a vendor agent runtime”: your infrastructure, your logs, no new platform. See our build-your-own PR review agent for the pattern.

Unattended is un-watched

Background execution is a trust decision before it is an uptime decision. An agent that works while you sleep is an agent that holds credentials while nobody is looking: give it a short-lived token scoped to one repo, no production secrets, dry-run mode first, human approval on merges, and a visible audit trail of what it did. This applies to self-hosted boxes as much as vendor clouds—the machine you left running is just another unmonitored surface.

Interactive modes: locality follows the loop

Agents are not one interaction pattern. The right locality tracks the cadence of the loop you are actually running:

Loop	Cadence	Where it runs best	Watch out for
Interactive loop	Seconds	Local runtime wins on feel: latency and local context are instant. A remote agent works too, but every turn crosses the WAN and your approval has to travel back.	The agent is only as good as your attention: it stalls the moment you close the laptop or walk away from the chat.
Task loop	Minutes	Either locality works. The deciding factor is what the task touches: localhost services and your uncommitted work favor local; shared team context favors remote.	Approvals are the bottleneck. Plan for how the agent asks before it runs destructive commands.
Background loop	Hours to days	Remote, unless you self-host: the job must survive your laptop closing, WiFi drops, and reboots. This is the loop where cloud agents are categorically better than an agent on your desk.	Unattended means un-watched. Scope the credentials, log the runs, and keep a way to hit the kill switch.

The interactive loop is where locality shows up as feel. A local runtime reads your files, your shell history, and your running dev server without a network round trip per step, so back-and-forth prompting stays fast and you can interrupt mid-step with a keystroke. That is why most engineers keep one local agent for the desk. Remote interactive modes have their own strengths: the session is not tied to a machine—you can attach from another device, hand a cloud session to a teammate, or pick up in the morning where the sandbox left off. Some remote products even invert the topology, letting you steer a task on your own machine from elsewhere, which is genuinely useful for long builds and deploys.

The part that changes most between local and remote is the approval channel. Locally, the agent asks in your terminal and you answer in one keystroke—cheap and frequent. Remotely, every “can I run this?” has to travel through a chat UI, a notification, or a policy you configured in advance, so teams end up pre-authorizing more: scoped auto-approvals, branch protection instead of per-command consent, and dry-run passes before the real one. Neither is better; they are different risk postures. Match the approval granularity to the locality, not the other way around.

Browser automation: the CDP question

The browser is where agents touch the world beyond your editor—filling forms, checking staging, verifying a fix in a real render. Nearly all of it goes through the Chrome DevTools Protocol (CDP): the JSON-over-WebSocket interface that Chrome exposes for its own DevTools and that Playwright and Puppeteer wrap. CDP gives an agent the same powers a human has—navigate, click, type, read the DOM, intercept network—so “where the agent runs” and “which browser it is allowed to drive” become the same question. There are four workable answers, and they are not interchangeable:

Local agent, local browser

CDP over localhost

The agent attaches to your running Chrome through the Chrome DevTools Protocol (“Chrome --remote-debugging-port=9222”, or Playwright’s connectOverCDP). It sees localhost apps, your dev servers, your logged-in sessions and corporate SSO, because it is driving the browser you already trust. Cost: your machine must be on and awake, and the agent shares your real profile—give it a separate user-data-dir so it cannot touch your banking tab.

Remote agent, cloud browser

Browser-as-a-service

The agent runs in a cloud VM with its own headless browser (Browserbase, Playwright on hosted runners, and similar). Sandboxed profiles, 24/7 availability, parallel sessions, clean state between runs. Cost: your logins do not follow you—cookies, MFA, and CAPTCHAs are a permanent tax—and every page the agent visits crosses into the browser vendor’s cloud. Great for scraping, e2e suites, and public-site work; painful for anything behind your SSO.

Remote brain, your browser

Tunneled CDP

A cloud agent attaches to a CDP endpoint tunneled out of your machine, so the model runs remotely while the browser’s context—localhost apps, your cookies—stays local. This is the hybrid with the best of both and the largest blast radius: remote code is executing against a real browser holding your credentials. Treat it like granting remote desktop access: explicit consent prompt, allow-listed actions, time-bound token, and a visible kill switch.

Remote agent, whole VM

Computer use

The agent gets an entire disposable desktop—a virtual screen, browser, and OS it can click and type in (the “computer use” pattern shipping in several agent products). Isolation is excellent and sessions can be recorded end-to-end. Cost: anything internal must be reachable or provisioned inside the sandbox, and “your machine” is now a remote box you pay for by the hour.

The recurring theme is session portability: your logged-in state is the most valuable thing a browser has, and it is the hardest thing to move. Cloud browsers solve isolation by throwing away state; local browsers keep state but chain the agent to your machine; tunnels move the state problem to your risk model. Whatever topology you pick, treat the agent's browser like an employee's browser: separate profile, scoped permissions, and a recording of what happened.

An agent in a browser looks like a user in a browser

Every CDP-driven session produces the same event stream as a human visit—clicks, inputs, network calls, errors—which is exactly the data that session replay records. When your agent misbehaves at 3am in a cloud browser, logs tell you what it printed, not what it did on the page. Recording the run like a user session lets you watch the agent's steps, audit what it touched, and debug failures against the actual page state. The instrumentation that makes human sessions debuggable makes agent sessions debuggable too—we wrote about the replay side of that story in When Error Logs Lie, and about giving agents read access to session data in LogNroll's MCP server.

Security and the data plane

Strip away the features and the local-versus-remote argument is mostly about one sentence: where does the context travel? A local runtime keeps your repo, your diffs, and your secrets on a disk you control; even if the model call goes to a hosted API, only the prompt leaves—and you can filter that, or point the runtime at local inference and stop egress entirely. A remote runtime is a machine you do not control with a copy of your context on it. That is not automatically worse: a well-audited vendor sandbox with zero-retention promises, SSO, and DLP is often more secure than the average developer laptop—but it is a different boundary, and your compliance paperwork will want to know which one your code crossed.

Three rules keep the data plane sane regardless of camp:

Assume hosted models see your prompts. Local runtime or not, the model provider is in the loop unless you run local inference. Use zero-retention agreements or local models for regulated context.
Never give an agent more access than the task needs. Scoped tokens, read-only defaults, separate browser profiles, and no production secrets in the sandbox. The agent inherits whatever you mount into it.
Keep the audit trail outside the agent. Git history, replay recordings, and run logs should live in systems you own—an agent's own transcript is not an audit log if the vendor decides to expire it.

A decision framework

If a workload ticks any of these boxes, the answer writes itself:

The workload...	Local-first	Remote-first
Needs your localhost, uncommitted work, or dev-only services	Strongly local	Painful—unless tunneled
Needs to run while you sleep, or react to events for days	Only with a self-hosted box or CI	Native
Data is regulated or the repo is the crown jewels	Context never leaves your disk	Only with zero-retention + DLP guarantees
Switching vendors must stay cheap	CLI agents + open protocols	Higher switching cost by design
Small team, one person watching the loop	Fine	Fine
Cost is a fixed budget, not a surprise invoice	Predictable	Metered; watch background hours

The practical answer for most teams is not one camp but four hybrid patterns that are cheap to run side by side:

Local orchestrator, remote model

Run an open CLI agent (Claude Code, OpenCode, Gemini CLI) locally and treat the model as a pluggable backend. You get local context, local history files, and your own API keys—plus the ability to switch models or go local-inference later without changing your workflow.

Self-hosted runner for the night shift

If you want background loops without a vendor runtime, run the same local agent on an always-on machine—a CI runner, a VPS, or a spare box—driven by cron or webhooks. You keep the 24/7 execution and your data, and you trade it for a little ops.

Cloud agent, scoped credentials

When you do use a remote agent for background work, give it the least it needs: a short-lived token scoped to one repo, no production secrets, dry-run mode first, and a human gate on merges. The question is not whether to trust the vendor—it is how much of your access the agent inherits.

MCP as the remote control

Instead of giving a cloud agent a shell in your infrastructure, expose the data you want it to reason over as MCP tools. The agent stays in its sandbox and pulls only what you authorize, read-only where possible. We do exactly this for session data—see the LogNroll MCP server below.

The one-paragraph answer

Keep a local agent for the interactive work that touches your uncommitted code, your localhost, and your logged-in sessions—it is where the feel and the data control matter. Put background work that must outlive your laptop on a runtime that never sleeps, whether that is a vendor cloud with scoped credentials or a self-hosted box with cron. Treat browser automation as a trust decision per topology, not a feature. And whatever you choose, assume you will switch vendors someday: keep agents, skills, and MCP configs as files, keep history on your side, and keep the audit trail somewhere you own.

Conclusion

Local and remote agents are converging on the same capabilities—the same models, the same MCP tool ecosystem, increasingly the same protocols—so the remaining differences are operational, not magical. Locality buys you control over context, history, and interactivity; remoteness buys you uptime, managed sandboxes, and sessions that follow you. Choose per workload, mix the four hybrid patterns freely, and keep your exit routes open. The agent that runs on your laptop and the agent that runs in someone else's cloud are the same species—but they are very different employees.