OpenHands separates agent control from execution

OpenHands brings coding agents, files, terminals and execution environments into a common workflow. Its current Agent Canvas interface is a control centre for work happening elsewhere: on a local machine, in a container, on a managed backend or in an organisation’s deployment. Understanding that separation is the key to evaluating the product. The interface can make work convenient, but the chosen backend determines where code runs and what it can reach.

01 / ProductA platform with distinct execution responsibilities

The company overview positions OpenHands as infrastructure for building and running AI coding agents. Its documentation now distinguishes Agent Canvas, the Software Agent SDK, Agent Server, cloud services and enterprise offerings. The introduction also identifies the previous Local GUI as deprecated. An old tutorial can therefore describe a different architecture from the one a new user should evaluate.

Agent Canvas is the browser client. Agent Server runs conversations and tools, while a workspace or sandbox supplies the execution environment. The architecture guide makes clear that the interface itself is not the sandbox. Installing a browser application does not create a security boundary around every command it can request.

The practical benefit is flexibility. A developer can use a familiar control surface while choosing where the agent operates. The corresponding responsibility is to understand that choice. A remote backend may have a different filesystem, credentials and network access from the laptop displaying the conversation. Those differences affect both whether a task succeeds and what its side effects can be.

02 / AudienceFor teams choosing more than a coding assistant

OpenHands suits a team that wants to treat agent work as a repeatable development process. Examples include investigating issues in a prepared environment, implementing a contained change and handing the diff back to a reviewer. The team needs enough engineering ownership to maintain dependencies, model credentials and the rules governing the workspace.

A local experiment is a reasonable starting point for an individual developer. An organisation sharing an installation has additional requirements: distinct identities, access policy and a clear owner for backend operation. A shared browser surface with a shared identity is materially different from an enterprise deployment with individual access controls. The free local route should be evaluated on its own terms.

The Daytona blueprint is useful when the primary need is an execution environment for agent code. The Cognition blueprint addresses a more packaged software-agent proposition. OpenHands sits between those questions: it offers an agent ecosystem and control surface, while leaving several choices about infrastructure and model access explicit. That is attractive when flexibility solves a real constraint; it can be unnecessary complexity for a simple one-off task.

03 / WorkflowA proposed issue-to-patch workflow

Begin with a proposed task to fix a reproducible parsing error in a service. Prepare a repository checkout with its dependency lockfile and the command that demonstrates the problem. Choose an execution backend before asking the agent to work. For a first evaluation, mount only the required project into a container and omit credentials that are unrelated to the repair.

The Canvas overview describes local, Docker, VM and managed-cloud paths. Use that distinction deliberately. A local host process has the access of its execution environment; a container narrows file access through its mounts but still needs appropriate network and secret configuration. Moving to a remote backend changes where the work occurs, rather than magically changing its permissions.

The setup guide separates the agent choice, backend and model connection. Configure those as three explicit decisions. An OpenHands agent profile uses its configured model access, while an ACP-connected third-party agent has its own authentication and model settings. Check that the selected combination supports the intended backend before relying on it.

Ask the agent to diagnose the failure, make the smallest necessary patch and run the relevant checks. Review the file changes and command output through Canvas, then inspect the resulting branch in the usual development tools. Keep acceptance and merging as explicit decisions. This example describes a sensible trial design; it is not evidence that OpenHands repaired a tested service.

If the team repeats the workflow, encode stable project instructions as skills. Record the test command, architecture constraints and expected output. Instructions can reduce repeated explanation, but they need review when the repository changes. A stale instruction about a migration or deployment process can be more damaging than a missing instruction.

04 / PricingPrice the deployment route that is actually offered

The fresh pricing page presents Teams as self-hosted, with multi-user identity, RBAC, SSO/SAML and budgeting controls. It lists a thirty-day trial and caps Teams at 5,000 sessions per month. Enterprise usage is advertised as uncapped, which does not remove infrastructure or model costs. The current table is different from older search extracts describing a free Individual cloud plan, so a budget should use the live offer and confirm the specific deployment being purchased.

Cloud execution remains described in the documentation introduction, but that does not establish a universally applicable cloud tariff from the current Teams table. Request a clear commercial explanation if managed execution is central to the decision. Do not transfer a self-hosted price or a historical daily-conversation limit to a different service.

The basic budget has three components: platform entitlement, the infrastructure that runs tools and the model consumption generated by the work. A slow dependency installation can consume infrastructure time without producing much model activity; an extended reasoning exchange can consume model tokens while barely exercising the workspace. Keeping these costs separate makes a pilot easier to interpret.

05 / DistinctionsThe control surface can survive changes underneath it

OpenHands’ useful distinction is the separation of interface, agent execution and environment. That allows a team to consider changes in one layer without assuming it must replace all of them. It also gives an engineering team more precise questions to ask when something goes wrong: was the model unable to plan, was the tool missing or was the backend unable to access a required dependency?

The architecture documentation describes backend ownership of conversation and configuration state, and workspace ownership of produced files. This distinction matters during a move between backends. Seeing the same browser interface does not mean that histories, secrets and working files are automatically shared across those environments.

The ecosystem also has separate public repositories and licences. The introduction explicitly advises checking the repository being used rather than assuming a single licence covers everything. That is a practical maintenance point for teams embedding the SDK or operating infrastructure: keep the component versions and licensing scope visible in the deployment record.

06 / QuestionsValidate the environment before delegating more work

The first uncertainty is the execution boundary. Test which files and network destinations the chosen backend can access before assigning a repository-wide task. Do this with harmless fixtures and non-production credentials. It should be possible to explain where a command runs without relying on the browser’s apparent location.

The second uncertainty is whether the chosen agent and model combination handles the team’s actual work. A successful small patch does not prove reliable multi-repository changes. Expand the trial through representative tasks and inspect failures, including missing dependencies, misunderstood requirements and repeated edits. The aim is to identify the scope that remains easy to review.

The third issue is version drift. The current documentation distinguishes the active Canvas architecture from legacy components, and offers a desktop preview separately. A production plan should name the supported release and components in use. Treat preview interfaces as previews, and confirm migration and support terms before making them part of a required workflow.

07 / DecisionMatch the control model to your operating capacity

OpenHands deserves a trial when the team values choice over execution location and agent configuration. The strongest initial result is a reviewable patch produced in an environment whose access is understood. If the team cannot operate that environment consistently, a more managed route may be the better starting point.