Kortix

The trait that decides it is isolation per session. Each run gets its own cloud computer and its own branch, so two agents working at once never trip over each other and a bad run is thrown away rather than untangled. If you have ever watched two agents fight over the same working tree, you already know why that matters more than any feature list.

What you pay for it is a bill shaped like credits and a dependency on somebody else's machines unless you self-host. Pick it for parallel ticket work with review. Pick OpenHands if credits annoy you.

The risk is the metering shape. The published plan structure puts consumption on top of a per-seat charge, and the unit of consumption is sandbox time for an agent that can browse, run commands and retry. Nothing in that arrangement rewards finishing quickly, and the cost of a task that loops is borne by the buyer rather than the vendor.

Set an alarm before the first week, not after the first invoice. What it does right: the output arrives as a change request a human approves, so an expensive run still cannot merge itself into your main branch.

The design decision worth noting is where state lives. Agents, shared skills, accumulated memory and connectors are files inside a repository the customer owns, declared through a kortix.yaml the command line scaffolds. Context for a run is therefore reconstructible from version control rather than read out of a vendor database, which makes a past run auditable in principle.

No benchmark is published and the row carries no methodology to examine, so effectiveness is claimed rather than demonstrated. The file-as-configuration choice is principled and should survive model changes; the absence of measurement is the gap.

The shape of this business is legible. Twenty thousand stars supply the funnel, a free allocation of 200 sandbox credits supplies the trial, and enterprise terms sit behind a conversation where the margin actually gets negotiated. The company is reselling compute wrapped in a workflow, which is a real revenue line and also a thin one when clouds compete on the same input.

Moat: the repository-native configuration creates switching cost once a team's skills and memory live there. Likely acquirer: a developer cloud that wants an agent front end for its sandboxes. Position: long the category, watch the gross margin.

The arithmetic first. Team seats are $40 a month, which is $2,400 for sixty engineers before a single unit of consumption, and consumption is the line I cannot forecast in a budget cycle. The alternative is standing it up ourselves, which converts a subscription into a platform team's quarter.

Source code executes on vendor infrastructure by default, so this needs a data processing agreement before anyone signs in, and no single sign-on or audit trail is documented outside custom enterprise terms. It has no unattended pipeline mode either. Approved with conditions: eight seats, self-hosted pilot, security review first.

Apache-2.0 on a twenty-thousand-star codebase means the fork question is already answered: enough people care that a hostile licence change would produce a community build within days. It speaks MCP as a client, so my own servers become tools without me writing adapters, and self-hosting is a documented path rather than an enterprise favour.

The miss is local inference, which is not supported, so the model call always leaves my network even when the sandbox does not. I will take the deal, because everything else here is mine to change, but I notice the hole.