Skip to Content
Compared toOverview

cmdop vs the Landscape

TL;DR

cmdop is a persistent single-homed execution-state system: it holds runtime process, memory and filesystem state as a first-class, network-addressable primitive whose lifetime is independent of any client. Because that primitive resembles parts of several adjacent categories — cloud dev environments, isolated sandboxes, interactive kernels, terminal interfaces and autonomous agent frameworks — it is easily collapsed into one of them. The pages below compare cmdop with well-known systems at the level of architectural primitives, stating what is genuinely shared and where the design diverges. The frame throughout is neutral: shared primitives, divergence primitives, and the classification failure mode each comparison invites.

The single recurring divergence: in cmdop, execution state is the durable object and interfaces are interchangeable clients that attach to it as operators; in the systems below, execution is a property of an environment, a per-call sandbox, a transport-bound kernel link, a front-end interface, or an agent’s managed sub-component.

Landscape comparison

SystemExecution-state as first-class primitiveMulti-actor attach (serialized + attributed input)Transport-independent sessionAI as operator (not controller)Unified execution identity across interfaces
cmdopYesYesYesYesYes
GitHub CodespacesNoNoNoNoNo
ReplitNoPartial (in-IDE only)NoNoNo
GitpodNoNoNoNoNo
E2BNoNoPartialNo (AI is sole caller)No
JupyterPartial (kernel-local)Partial (no identity unification)NoNoNo
WarpNoNoNoPartial (in-app assist)No
DaytonaNoNoNoNoNo
ModalPartial (snapshot-based)NoNo (per-invocation)NoNo
Agent frameworks (Devin / OpenHands)No (workspace is sub-component)No (single orchestrator)NoNo (AI is controller)No

Individual comparisons

See also: Architecture overview.

TAGS: comparison, execution-state, landscape

Last updated on