# Cloud agent vs local agent: the open-source difference is the machine > A local agent edits the checkout in front of you; a cloud agent boots its own machine and hands back a branch. Kortix, the open-source AI Operating System, is the cloud side of that split, managed or self-hosted. URL: https://cloudagentsguide.com/cloud-agent-vs-local-agent ## Running an agent on your machine or on a machine you rent Where the machine is, what the agent can see, and what reaches you at the end. | | Kortix (recommended) | OpenCode on your laptop | Cursor Cloud | Railway Cloud Agents | | --- | --- | --- | --- | --- | | Where it runs | Isolated Platinum sandbox per session, control plane in your VPC. | In the terminal you already have open. | Isolated VMs in Cursor's cloud. | A personal VM in a Railway project. | | What it can see | Your repo at /workspace, on the session branch. | The working tree, uncommitted edits included. | The pushed repo, team secrets, its own environment. | Files on its disk, credentials carried from your machine. | | What you get back | A change request on a branch of your repo. | Edits in place, for you to commit. | Merge-ready pull requests with screenshots and logs. | Files on the VM disk, pushed with its GitHub CLI. | | Open source | Yes | Yes | No, closed vendor service | No, closed platform service | | Self-host | Yes, your VPC or on-prem; self-host is free. | It already runs there. | Tool execution on machines you manage. | No, Railway hosts the machine. | ## Two things move when the agent leaves your desk A local agent runs in the terminal you already have open and writes to the checkout in front of you. It reads the working tree, your uncommitted edits, your branch, your shell environment. OpenCode is the plain case: install the binary, run it inside a project, and it edits files in place, with `/undo` to walk a change back ([OpenCode docs](https://opencode.ai/docs/)). A cloud agent runs on a machine that boots for the task. Cursor describes its cloud agents as running in isolated VMs "instead of on your local machine", cloning the repository from your Git host ([Cursor docs](https://cursor.com/docs/cloud-agent)). Railway gives each agent "a personal virtual machine in a Railway project environment" ([Railway docs](https://docs.railway.com/cloud-agents)). Both work from what was pushed. Neither sees the half-finished branch on your disk. Where the machine runs decides more of this than model quality, and so does the second question the vendor pages skip: what happens to the change after you stop looking at it. ## Where the local agent wins Three situations have a local answer and no good cloud one. The first is work that depends on state nobody pushed. A dirty tree, a local database, a service behind your VPN, a device plugged into your desk. A cloud machine starts from a clone. Railway's docs say that launching from a local repository "selects context and eligible configuration to carry; it does not upload your repository files". If the repository has never left your machine, only a local agent can see it. The second is a loop you are watching. One file, thirty seconds, an error you read as it appears. Booting a virtual machine to save a keystroke costs more attention than it saves. The third is a credential that stays at the desk. A token for a production database, a signing key, a customer's staging box. No amount of isolation at the other end makes sending it somewhere else the safer option. ## Where the cloud agent wins Parallel work changes the arithmetic. Two tasks at once on a laptop means two agents sharing one battery, one cursor and one working tree, with a manual merge at the end. Kortix starts a session on an isolated cloud computer and cuts a branch for it. That machine is "an isolated Linux machine that clones your repo, cuts a branch named after the session, and runs OpenCode" ([Agent Computer](https://kortix.com/agent-computer)). One isolated sandbox per session. Each session has its own isolated machine and branch. The second is persistence. Close the laptop and the machine keeps going, because nothing on it is precious except what the agent commits. Open the session tomorrow and the work is where you left it. The third is review. The branch lives in your repository, not in a vendor dashboard. The change comes back as a diff a teammate can read, a preview URL they can open, and a change request a person merges. Every port in the sandbox gets its own preview address, so a reviewer clicks into the running app instead of rebuilding it ([sandbox docs](https://kortix.com/docs/work/runtime)). Session work reaches `main` through a change request. Merge is default-deny for agents. ## What self-hosting moves, and what it does not The split is plain in the docs: the control plane runs on Kortix Cloud, in the customer's VPC or on-prem, while each session runs on an isolated Platinum sandbox. Kortix states the limit without softening it: "Sessions run on Platinum sandboxes, not on the server." Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. Reachability explains why. A sandbox calls back to the instance's public API, and in local mode no session starts, because "the sandbox cannot reach the API" ([self-hosting docs](https://kortix.com/docs/host)). What self-hosting does move is everything you would want to keep: the database, the files, the agent definitions in git, and the API your people sign in to. ## Moving the same agent between the two What travels is the repository. Agents, skills, memory, connectors and triggers arrive with the clone "because all of them are files in that repo" ([Agent Computer](https://kortix.com/agent-computer)). The persona is a markdown file under `agents/`. The grants beside it in `kortix.yaml`, covering connectors, secrets, permissions and the sandbox template, only mean something where Kortix enforces them: a local OpenCode session reads the same persona and skill files and will not enforce the same grant list. In practice the move is dull. Keep the agent files in git and run a local session while the work is exploratory and tied to your desk. Then push the branch and start a Kortix session from the same commit, once the work has to run in parallel or outlive the afternoon. Review the change wherever the diff already sits. ## The machine a session boots on `the machine a session boots on` ``` A sandbox is the isolated cloud computer a session runs on. Each session gets its own sandbox, with the project repository cloned at /workspace on the session’s branch. The session branch is named after the session_id. By default, work reaches the base branch through a change request. Kortix gives each port two addresses. ``` Source: https://kortix.com/docs/work/runtime One session, one sandbox, one branch, and a preview address for every port it opens. ## Questions this choice raises How the two differ, when you need the cloud, and whether it can run on your own box. ### What are the key differences between a cloud agent and a local agent? Where the machine is and where the change lands. A cloud agent boots its own machine and returns a branch; a local agent edits your working tree in place, with your uncommitted state in view. ### Do I need a cloud agent? Not always. A local agent covers a single change you are watching. A cloud agent earns its place when work has to run in parallel, outlive your laptop, or arrive as a change a teammate reviews. ### Can a cloud agent run locally? Partly. The Kortix control plane runs in your VPC or on-prem, while sessions still boot on Platinum sandboxes. A local OpenCode session, run beside your files, is the fully local option. ## Run the agent on its own machine, and keep the repo. One session, one branch, one change request a person reviews. [Try Kortix](https://kortix.com) · [Read the sandbox docs](https://kortix.com/docs/work/runtime) One isolated sandbox per session | Self-host is free | Open source. Read it, fork it, audit it.