# Open SWE: LangChain's Open Source Coding Agent, Reviewed

> Open SWE is a Python coding agent built on Deep Agents and LangGraph, with five graph entrypoints, pluggable sandboxes and GitHub, Slack and Linear surfaces. Here is what it does, how to run it, and where it stops.

**langchain-ai/open-swe** — An Open-Source Asynchronous Coding Agent

- Repository: https://github.com/langchain-ai/open-swe
- Website: https://www.langchain.com/blog/open-swe-an-open-source-framework-for-internal-coding-agents
- Stars: 10,775 · Forks: 1,292
- Language: Python
- License: MIT
- Published: 2026-09-09 · Updated: 2026-09-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/langchain-ai-open-swe

## What Open SWE solves, and for whom

Most coding agents stop at a diff. Open SWE is aimed at the part after that: committing, pushing, opening or updating a pull request, then staying with it through review and CI. The README frames the project as a software factory and describes a loop that starts from issues, conversations, pull requests or schedules, moves through planning and investigation, implements in an isolated sandbox, validates and delivers a pull request, and then feeds review and CI feedback back into the next round.

The audience is therefore not an individual who wants autocomplete. It is a platform or developer-productivity team that already runs internal infrastructure and wants an agent bound to its own repositories, tools and policies. The README states the project is deployable in your infrastructure and designed to be adapted to your team's repositories, tools, policies and workflows. That sentence is the whole positioning: this is a framework plus a product surface, not a hosted service you sign up for.

## Deep Agents is the harness, LangGraph is the runtime

The architecture is a composition rather than a monolith. Deep Agents supplies the planning, file operations, shell access, skills, state and subagent primitives. Open SWE adds the software-engineering tools, prompts, middleware, integrations, authorization and product surfaces. LangGraph supplies durable execution and thread state. The stated benefit of that split is inheritance: improvements in the underlying LangChain agent stack flow through.

On top of LangGraph, Open SWE ships five graph entrypoints, and the Dockerfile names them explicitly in the LANGSERVE_GRAPHS environment variable: agent, reviewer, analyzer, chat and scheduler. The Agent graph plans, implements, validates and delivers changes. Reviewer performs read-only pull request reviews. Analyzer learns repository-specific review style. Chat answers questions about a pull request without changing code. Scheduler dispatches recurring tasks and CI monitoring work. That separation matters operationally: a read-only review does not need a sandbox, while a coding thread does, and the README says read-only PR chat does not need a sandbox at all.

Sandboxes are the containment layer. Cloud tasks run in isolated Linux sandboxes with tooling supplied by the configured environment or snapshot. A sandbox persists with its thread, and the README is explicit about failure behaviour: an unreachable coding sandbox is not silently replaced, because doing so would risk discarding uncommitted work. That is a deliberate trade of availability for safety, and it is the kind of decision that shows up in production as a stalled thread rather than a lost branch.

## Installing Open SWE and running the agent graph locally

The Python package is named open-swe-agent and pyproject.toml sets requires-python to >=3.14, so a Python 3.14 interpreter is a hard prerequisite rather than a preference. The repository uses uv for Python dependency management, and the Makefile exposes a dev target that starts the local LangGraph server on port 2024 with ten jobs per worker.

```bash
uv run langgraph dev --no-browser --port 2024 --n-jobs-per-worker 10
```

Running that from the repository root should start the LangGraph development server, which then serves the graphs registered in langgraph.json. The Dockerfile shows the same entrypoints being registered for a container build through LANGSERVE_GRAPHS, mapping each name to a traced object under agent.graphs.

```bash
make dev-ui
```

The dev-ui target runs the Vite dashboard and the backend side by side under make -j2, with DASHBOARD_DEV_SERVER_URL set to http://localhost:3000, so the dashboard hot-reloads at http://localhost:2024 without a production build. Note what the Makefile says about that setup: langgraph dev has no auth. If you expose the port for GitHub or Slack webhooks, the repository provides a tunnel target that applies an ngrok traffic policy file, examples/ngrok/webhooks-only.yml, restricting public traffic to /webhooks/*. The Makefile warns that any other tunnel is acceptable only if it enforces the same allowlist. That is a real constraint, not boilerplate.

The Dockerfile builds from langchain/langgraph-api:0.13.3-py3.14, installs the project with uv pip install --system, and exposes port 8000. It also sets a checkpointer TTL of 43200 seconds with a sweep interval of 60 minutes, which tells you the project expects long-lived threads that are eventually cleaned up.

## The desktop surface is experimental, and the README says so

Open SWE Desktop appears in the repository as a desktop/ directory with its own langgraph.desktop.json and a nightly release channel: the most recent releases listed are desktop-v0.2.7-nightly builds dated 2026-09-09. The README labels the desktop surface experimental and states that packaged releases currently target macOS, while source builds also support Windows and Linux. Desktop tasks can run directly against an allowlisted local project.

If your goal is an agent that edits code on a developer's laptop, this is the weakest part of the project to build on today. Nightly versioning means the desktop build is not on a stable release cadence, and the supported packaged platform is a single one. The cloud path, by contrast, is where the sandbox isolation, the five graphs and the GitHub delivery loop live. Treat the desktop build as a preview of the same agent rather than the primary product.

## Sandbox providers, models and the cost of pluggability

LangSmith is the default sandbox and tracing provider. The project also supports Modal, Daytona, Runloop, E2B and local execution, with a pluggable interface for additional providers, and the dependency list carries a matching integration package for each cloud option. Model choice is similarly open: the dependencies include langchain-anthropic, langchain-openai, langchain-fireworks and langchain-google-genai, and the README says you can choose the models and reasoning effort available to agents and reviewers.

That breadth has a maintenance cost, and pyproject.toml documents it. There is an override-dependencies block whose comment explains that the externally maintained langchain-e2b integration still declares deepagents<0.7.0 while the project pins deepagents==0.7.13, and that its e2b dependency caps wcmatch<11.0 while deepagents requires wcmatch>=11.0. The override exists until that integration publishes compatible metadata. Separately, the dependency list pins fireworks-ai explicitly because langchain-fireworks 1.4.2 pins a pre-release. These are the seams you inherit when a framework composes many vendor integrations, and they are the first place a dependency upgrade will bite.

## Open SWE vs Claude Code and opencode

The comparison people search for is Open SWE against Claude Code or opencode, and the difference is structural rather than a feature checklist. Those tools are primarily interactive coding assistants driven from a terminal or editor session. Open SWE is a service: the README describes starting work from a dashboard, GitHub, Slack or Linear, or on a schedule, and delivering a pull request. The unit of work is a thread with a persistent sandbox, not a chat window.

That also explains the review side. Open SWE runs read-only pull request reviews on demand or automatically, learns repository-specific review preferences from historical feedback, and can monitor opted-in pull requests with /baby-sit, diagnose CI failures and rerun only evidence-backed flaky jobs. An interactive assistant has no equivalent of an analyzer graph whose job is to learn a repository's review style from past feedback. The trade is control surface for setup cost: you get scheduling, authorization boundaries and organization allowlists, and in exchange you run a LangGraph deployment, a dashboard and a sandbox provider. If you want a tool a single developer starts in a terminal, Open SWE is heavier than the problem you have.

## Licence, upgrade cadence and what that means for forks

The project is MIT licensed, and pyproject.toml declares license = { text = "MIT" } alongside the LICENSE file at the repository root. MIT is permissive, so the practical question is not whether you may modify Open SWE but whether your changes survive upstream. The README claims you can extend the curated toolset without forking Deep Agents, and that sandbox providers, middleware, skills, triggers and delivery policies are swappable. If that holds for your use case, extension lives in configuration and provider interfaces rather than in a divergent fork.

The upgrade picture is less settled. The README carries a note that Open SWE is under active development and that APIs, setup and product surfaces may continue to evolve. The dependency pins are exact in several places, including deepagents==0.7.13, langchain-e2b==0.0.6, alembic==1.20.0 and sqlalchemy==2.0.52, and the override block exists precisely because one integration's metadata lags the rest. Expect to spend upgrade effort on the Python dependency graph, not on the agent prompts. The last push to the repository was on 2026-09-09, and the nightly desktop releases were published the same day.

## Conclusion

Open SWE fits teams already invested in the LangChain stack who want an agent that opens pull requests, reviews them and watches CI, and who can supply their own sandbox provider and model credentials. It is the wrong tool for anyone who wants a single binary that edits files on their laptop: the desktop surface is labelled experimental and packaged releases currently target macOS only. Before adopting it, verify three things in your own environment: that you can run Python 3.14, that the five entrypoints in LANGSERVE_GRAPHS start under langgraph dev, and that your chosen sandbox provider is reachable from the worker. The last push was on 2026-09-09, and the README states the project is under active development with APIs and setup subject to change.

## FAQ

### What is Open SWE?

Open SWE is an open source coding agent from LangChain, described in its README as a software factory built on Deep Agents. It takes a code-change task from a dashboard, GitHub, Slack or Linear, or on a schedule, works in an isolated sandbox and delivers a pull request. It also performs read-only pull request reviews and monitors CI.

### How does Open SWE compare with Claude Code?

The architectural difference is that Open SWE is a service rather than an interactive session: work starts from a dashboard, GitHub, Slack, Linear or a schedule, and each cloud coding thread is bound to its own persistent sandbox. It additionally runs read-only pull request reviews, learns repository review style through an analyzer graph, and monitors CI. Claude Code is not discussed in the Open SWE material, so the comparison stops at that structural level.

### What are alternatives to Open SWE?

The README positions Open SWE against interactive coding assistants such as Claude Code and opencode, which are driven from a terminal or editor session rather than from a service with threads and sandboxes. It also composes Deep Agents and LangGraph, so teams that only need the underlying agent primitives could build on those directly instead of adopting the full product surface.

## Sources

- [langchain-ai/open-swe on GitHub](https://github.com/langchain-ai/open-swe)
- [License: MIT](https://github.com/langchain-ai/open-swe/blob/main/LICENSE)
- [Project website](https://www.langchain.com/blog/open-swe-an-open-source-framework-for-internal-coding-agents)
- [README](https://github.com/langchain-ai/open-swe/blob/main/README.md)
- [Releases](https://github.com/langchain-ai/open-swe/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/langchain-ai-open-swe