Open SWE is an open-source software factory that gives coding tasks to an asynchronous agent, which investigates repositories, changes code, validates the results, and delivers pull requests. Engineering teams use it to automate code changes, reviews, CI follow-up, and related repository work from dashboards and connected tools.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add langchain-ai/open-swe --skill workspacesgit clone --depth 1 https://github.com/langchain-ai/open-sweWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/langchain-ai/open-swe/workspaces)<a href="https://agentmods.dev/skills/langchain-ai/open-swe/workspaces"><img src="https://agentmods.dev/badge/skills/langchain-ai/open-swe/workspaces/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/langchain-ai/open-swe/workspaces"><img src="https://agentmods.dev/badge/skills/langchain-ai/open-swe/workspaces.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00089 | $0.01381 |
| Opus 5.5 | $0.00036 | $0.00552 |
| Sonnet 5.5 | $0.00018 | $0.00276 |
| Haiku 4.5 | $0.00009 | $0.00138 |
Grade A, and why
workspaces scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 14d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Workspaces
A workspace prefers repositories and owns Slack channels, MCP connections, and
team settings, plus the sandbox image its runs boot from. Preferring a
repository routes its GitHub and Linear events here and preloads it into the
image; it does not limit access, since every workspace's sandbox can reach
every repository the GitHub App installation can. That image is two
things: a record (name, prompt, repos, sizing, optional scripts) and a
published sandbox image, <prefix>-environment-<slug>:latest. Runs
routed to a workspace boot from its image and get its prompt appended to
their system prompt. The workspace named default is what a run uses when
routing picks no other.
Only workspace admins can change a workspace's image, from an admin thread or through supported writes in a verified sole-writer shared thread. Shared writes return only acknowledgements; workspace reads and switching to another workspace's image still require a private admin surface. Anyone can read workspaces on the Workspaces page. If the asker is not an admin, tell them what would need to happen and who can do it; do not try the tools.
The one rule: build here, publish from here
You do not write a workspace's image as a script and hope. You build it in
the current thread's own sandbox with ordinary tools — execute, the file
tools — and when it works you call publish_workspace. That captures this
sandbox as the image and writes the record only after the capture
succeeded. Nothing is half-written on failure, and the image is usable the
moment the call returns.
Everything on the sandbox filesystem is captured, so provision it fully and leave no tokens, credentials, or proxy secrets on disk.
Which image to start from
The image you publish is whatever you are sitting on plus your changes, so start the admin thread on the right one:
| You want to… | Start the admin thread… | Then |
|---|---|---|
| Edit a workspace's image | in that workspace (composer → Workspace picker) | change it, publish_workspace under the same name |
| Fork one into a new workspace | in the parent | change what differs, publish_workspace under a new name |
| Build from scratch | in no workspace, or recreate_sandbox(source="base") |
provision everything, publish |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 14d ago Changed e99f790ca2d3
- 15d ago Changed · +2 lines 0bdca64c248a
- 18d ago Changed · +3 lines 5ebdbd812462
- 28d ago Changed af3635ff6f25
- 29d ago Changed · -3 tokens per session 6a74c3e6e332
- 1mo ago First seen · 74 lines · 92 tokens per session scan A e2df4ca2d27e
workspaces is a skill published in the GitHub repository langchain-ai/open-swe (11,030 stars, last pushed today), licensed MIT. It adds 89 tokens to every session and 1,381 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-16.
Other skills, from other repositories
langbot-deploy
Deploy and configure a LangBot instance — Docker / Docker Compose, Kubernetes, the config.yaml model, the Box sandbox runtime, the plugin runtime, and the global API key. Use when installing, deploying, upgrading, or configuring LangBot in production or self-hosted environments. Triggers on "deploy langbot", "langbot…
docker-management
Manage Docker containers, images, volumes, and Compose.
deployment-patterns
Deployment workflows, CI/CD pipeline patterns, Docker containerization, health checks, rollback strategies, and production readiness checklists for web applications. Use when setting up deployment infrastructure or planning releases.
pydantic-ai
Build production-ready AI agents with PydanticAI — type-safe tool use, structured outputs, dependency injection, and multi-model support.
langbot-plugin-dev
Develop, debug, and test LangBot plugins. Use when creating new LangBot plugins, fixing plugin bugs, setting up a LangBot test environment, or testing plugins via WebSocket. Covers plugin component architecture (EventListener, Command, Tool), the plugin SDK API (invokellm, getllmmodels, sendmessage, plugin storage)…
langbot-dev
Develop, build, and debug the LangBot core backend and web frontend. Use when working inside the LangBot repository — backend (Python/Quart, src/langbot/pkg), the Vite/React web UI, HTTP API controllers/services, Alembic migrations, or the MCP server. Covers the dev environment (uv, pnpm), repo layout, the API auth…