An open-source cloud agent hands back a branch your team can refuse
A cloud agent is an agent that runs on a machine you did not hand it, and comes back with work
A cloud agent is an agent that runs on a machine you did not hand it, and comes back with work. Kortix is the open-source AI Operating System, and the question that decides whether any of these products is usable is the one most comparisons skip: what the work comes back as, and who is allowed to merge it.
Three products share the name
ThousandEyes sells network-monitoring agents under the same name and is not part of this discussion (ThousandEyes, checked October 2026). Cursor and Railway sell a cloud machine for a coding agent. Qoder sells a runtime your own application calls. Alloy's explainer reaches for the wide definition: "an AI workspace that runs tasks remotely with access to code, tools, and runtime context" (Alloy, checked October 2026). A definition that wide fits every product here, which is why it settles nothing.
What comes back, in each case
Cursor's product page sells one motion: hand a plan off from your local agent so it runs while you are offline, and read it back as a diff in a review pane with a Commit & Push button (cursor.com/cloud, checked October 2026). The docs describe the repository side. A cloud agent clones your repository, works on its own branch, and pushes the changes to your repo with screenshots and logs attached, opening pull requests that are ready to merge (Cursor docs, checked October 2026). Cursor runs the agent loop itself and will move tool execution to machines you manage, keeping the checkout and build cache on your hardware while file contents, terminal output, diffs and screenshots travel back to Cursor (Self-Hosted Machines, checked October 2026). Cloud agent work needs Premium or higher, Teams, Enterprise, or a legacy paid plan.
Railway hands you the machine and stops there. "Each cloud agent is a personal virtual machine in a Railway project environment," the docs say, and you drive it from a terminal with railway code --claude or connect Claude Desktop, Codex Desktop or OpenCode to it (Railway docs, checked October 2026). Closing the connection leaves the VM running. Sleeping stops compute billing and keeps the disk, the machine ships with Claude Code, Codex, Grok CLI, Railway Agent and OpenCode 2 installed, and creation is capped at 25 agents per user per day. The handoff is whatever git client you type into it.
Qoder returns a result to your code. The page promises "ONE Call. End-to-End Delivery": long-running agents with orchestration, memory, Skills and MCP, a sandbox per session, event-backed sessions that outlive a single process, and every tool call streamed over SSE (Qoder, checked October 2026). You install it as an npm, pip or Go SDK. What comes back is a value in your application, and any merge after that is code your team wrote.
Five questions that decide the purchase
- Which branch does the work land on, and whose repository is it? A branch on your own remote outlives the tool that pushed it. A diff that lives only in a vendor's review pane leaves with the subscription.
- What does the reviewer receive? A diff invites a code review. A transcript asks someone to read a conversation and trust it. A screenshot asks them to trust the screenshot.
- Who may merge, and is that rule in a file you can read? When the answer sits inside a product's settings, expect a security reviewer to ask who changed it and when.
- Where are the grants recorded? A run that had access to tools and secrets should leave that list next to the commit, somewhere a colleague can open six months later.
- What stays if you change tools? Repositories, branches and review comments usually stay. Agent definitions, memory and permission grants usually do not.
The handoff on Kortix
A Kortix project is a git repository, and the docs describe the handoff as a sequence. "A session runs one agent in its own sandbox. The sandbox clones the repo and works on a new branch. The branch name is the session_id." The agent then "commits, pushes the session branch, and opens a change request against the project's default branch" (Kortix docs, checked October 2026).
Session work reaches main through a change request. Merge is default-deny for agents. The rule lives in the manifest: kortix.yaml declares the machine image, connectors and triggers, and secret names and grants, and secret values never appear in the repo. A session can merge its own change request when its agent's kortix_permissions list includes project.gitops.merge. The starter agent ships kortix_permissions: all, so a fresh project lets an agent land its own work. A team that wants a second name on the merge replaces that entry with a list that omits project.gitops.merge.
Because the branch name is the session id, the diff and the run behind it share one identifier. A reviewer who opens a change request can find the session that produced it.
The check you can run on any repository
Whether an agent lands its own work is a fact about a repository, so read it from the repository. The first command lists every merge on the default branch with the identity that made the merge commit and the commit's subject. The second reads the author of the tip commit on the branch that merge brought in.
git log --first-parent --merges --format='%h %an <%ae> | %s'
git log -1 --format='%an <%ae>' <merge>^2Compare the two names for one merge. When they match, the work landed with no second name on it: the identity that wrote the tip also made the merge. When they differ, a second identity put the work on the trunk, which is the handoff worth reading. A bot account in the merge position is automation rather than a review, whether its name matches the work's or not.
The history has limits. Approvals, review comments and CI results live in the forge rather than the clone, so no clone shows them. Squash and rebase landings leave no merge commit, so an empty list is a finding about the history, not proof that no work landed.
Where Railway is the better pick
Railway suits a development machine you return to: a refactor, a long test run, a workspace you come back to from a desktop app. Kortix works the other way. One isolated sandbox per session. Each session has its own isolated machine and branch. A team that wants one long-lived box with a terminal and a slept meter should use Railway, because per-session sandboxes are the wrong shape for a place you keep.
Side by side
| Cloud agent | Open source | Where the work lands | Who merges |
|---|---|---|---|
| Kortix | Yes, self-hostable | Session branch, then a change request on your repo | Whoever holds project.gitops.merge; the starter grants it |
| Cursor Cloud | No; tool execution can run on your machines | Your repo, after a branch push | You, in the pane or the pull request |
| Railway Cloud Agents | No | The agent's own disk | You, in the VM or your git client |
| Qoder Cloud Agents | Not stated on the page | Vendor-managed sandbox, returned through the API | Your application's code |
When to pick which
You want one persistent development machine you drive by hand and sleep when you are done.
You want the work to arrive as a change request on your own repository, with the merge going to whoever your team grants it to.
For the argument about what an agent's work leaves behind as a record, Kortix vs OpenHands follows the same thread through a coding harness. If the constraint is running the platform yourself, the four checks that decide an install covers the install.
More from the blog
An AI agent for HR has to read the policy library your team wrote
HR agents in the big suites answer from their own product's data, while an open-source agent reads your policy library and drafts the reply.
An open-source agentic operating system is one whose permissions you can read
Most definitions of an agentic operating system stop at coordination, while an open-source one puts permission in a grant file you can read.