# ChatDev 2.0 ships as DevAll, pinned to Python 3.12

> ChatDev 2.0 rebranded its package to DevAll and moved from a virtual software company to a zero-code orchestration platform you configure rather than code. The interesting details are all in the packaging: a Python 3.12 only bound, two dependency lists that do not match, and a 1.0 command line that now lives on a branch rather than on main.

**OpenBMB/ChatDev** — ChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration

- Repository: https://github.com/OpenBMB/ChatDev
- Website: https://arxiv.org/abs/2307.07924
- Stars: 34,407 · Forks: 4,307
- Language: Python
- License: Apache-2.0
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/openbmb-chatdev

## The package is DevAll 0.1.0, the repository is ChatDev, the tags say 2.2.0

Start with the mismatch, because it is the first thing that bites. The repository is ChatDev and the releases are tagged v2.0.0, v2.1.0 and v2.2.0, dated 7 January, 22 January and 23 March 2026. The packaging metadata tells a different story: the project name in pyproject.toml is DevAll, the version is 0.1.0, the description reads "Workflow orchestration runtime for DevAll", and the author field is the DevAll Team. So a tag of v2.2.0 and a reported package version of 0.1.0 can both be true of the same commit, and neither number tells you which release you are running. The [tool.uv] table settles how the project is meant to be used: package = false, so it is not built and published as an importable library, it is run in place. The lock file is uv.lock and the dependency set is duplicated into requirements.txt. Treat 0.1.0 as a label on the runtime, not as a release number, and record the tag yourself if you need to name a version.

## Python 3.12 and nothing else, with SWIG warnings muted to cope

The interpreter bound is narrow, and it is written as a range with both ends closed:

```toml
requires-python = ">=3.12,<3.13"
```

That upper bound means 3.13 is out, and so is anything below 3.12, so a machine with either a newer or an older interpreter cannot install this project. The reason is visible in the dependency list, which pulls in native pieces such as faiss-cpu, cartopy, pygame, numpy and pandas. The friction is acknowledged rather than hidden: the pytest configuration carries a filterwarnings entry that ignores the Swig deprecation warnings coming out of faiss-cpu on Python 3.12, with a comment explaining that it is an upstream SWIG issue and that a fix is being awaited in SWIG 4.4. That is a small but honest signal about what you are adopting, because a project that has to silence a deprecation class from a binary extension is a project whose install story is tied to the exact interpreter version and to wheel availability. Budget for a version manager and for the possibility of building from source on a platform without a matching wheel.

## click is capped at 8.3, with the reason left in the file

One dependency in the list carries an upper bound and a comment that explains it:

```toml
    "click>=8.1.8,<8.3", # pin until click restores postponed annotations
```

So click is held below 8.3 because a later release dropped postponed annotations, and the project has decided to wait rather than adapt. Read that as a maintenance liability you may have to take over: when the fix ships on the click side, this line stops being a safety measure and starts being a blocker, because the cap will keep a correct click release out of your environment and the workaround will have to be removed and tested by you. The same file shows the same style of control elsewhere, with fastapi==0.124.0 and pydantic==2.12.5 pinned to exact versions. A zero-code front end and a web backend both sit on those pins, so a reproducible install is the point and a fresh dependency is not free. Anyone taking this into production should expect to own the pinning, because the bounds in the file were chosen for the developers of this project rather than for your release cycle.

## requirements.txt and pyproject.toml do not list the same dependencies

There are two dependency lists in the repository and they are not identical. pyproject.toml ends its list with mem0ai>=1.0.9, a memory library. requirements.txt stops one line earlier, at xhtml2pdf>=0.2.17, with no mem0ai in it. Everything else lines up, including the click range, the exact fastapi and pydantic versions, and the matplotlib, networkx, cartopy, pandas, openpyxl, numpy, seaborn, google-genai, chardet, pygame, filelock and markdown entries. That gap is easy to miss because the two files look interchangeable from a distance, and a contributor who installs with requirements.txt gets a runtime that the packaging metadata says should have a memory subsystem. The second list is also the one without the explanatory comments, since the comment about click and its upper bound lives only in pyproject.toml. If you are pinning a deployment, pick one file, say which one in your own build documentation, and diff it against pyproject.toml on every upstream merge. Otherwise a routine dependency update can quietly change what is installed.

## Two containers, two ports, and the backend gets your whole checkout

The compose file describes a backend and a frontend that are not built the same way. The backend builds from the repository root with target runtime, mounts the entire checkout at /app, and publishes a fixed port:

```yaml
    ports:
      - "6400:6400"
```

The frontend builds from the ./frontend directory with target dev, mounts ./frontend and an anonymous volume over /app/node_modules, and takes its port from an environment variable with a default:

```yaml
    ports:
      - "${FRONTEND_PORT:-5173}:5173"
```

Both read the same pair of env files, .env and .env.docker, which means credentials for model access are supplied at that level rather than in a config file inside the image, and both are set to restart unless-stopped. The asymmetry is the tell: a runtime target for the service you would expose, and a dev target with a watched mount and a live-reload port for the one you would not. The backend volume is the broader of the two, so the container sees the whole tree including your local environment file. The repository also carries a .dockerignore, a Dockerfile, a Makefile and a server_main.py, so there is more than one way in and they are not documented as equivalents.

## The 1.0 command line quoted in the project's own news is not on main

ChatDev 2.0 was released on 7 January 2026 and the classic v1.x line was moved to the chatdev1.0 branch for maintenance. That split matters because the commands this project still quotes in its news section belong to the old line. The human agent interaction mode is invoked as:

```bash
python3 run.py --task [description_of_your_idea] --config "Human"
```

The Art mode uses the same shape with --config "Art", and the incremental development feature was introduced with:

```bash
--config "incremental" --path "[source_code_directory_path]"
```

The Git mode from September 2023 is switched on by setting "git_management" to "True" in ChatChainConfig.json. None of that is the shape of the current default branch, whose top level carries server_main.py, server/, frontend/, workflow/, yaml_template/, yaml_instance/, schema_registry/, .agents/, functions/, runtime/, utils/, tools/, mcp_example/, entity/, check/ and docs/, and no ChatChainConfig.json. So a tutorial, a blog post or an answer built on run.py and a chain config file is describing a branch that is no longer what you get when you clone. Check the branch before you follow anyone's setup instructions.

## The published research lives on branches, not in the zero-code platform

Three techniques this group has published are reachable only through branches other than main, which means the thing you install by default does not contain them. The MacNet work from June 2024 uses directed acyclic graphs for task-oriented collaboration, supports cooperation across topologies and among more than a thousand agents without exceeding context limits, and was described as a more advanced version of ChatDev's chain-shaped topology; it lives in the macnet branch. The puppeteer paradigm from May 2025, published as Multi-Agent Collaboration via Evolving Orchestration and accepted to NeurIPS 2025, adds a learnable central orchestrator optimized with reinforcement learning that activates and sequences agents; its implementation is in the puppeteer branch. The MacNet paper also pointed beyond software development to logical reasoning, data analysis and story generation, which overlaps with what the 2.0 platform now advertises. Meanwhile an older item, Iterative Experience Refinement from May 2024, says the technique will soon be incorporated, and the sibling Experiential Co-Learning module was integrated in January 2024. Read that gap carefully: announced techniques and shipped ones are not the same list, and branch names are where the difference lives.

## Conclusion

ChatDev 2.0 makes sense when you want to assemble agents, workflows and tasks out of configuration rather than Python, and you are willing to work inside a 3.12 only environment and a project that ships as an application rather than a library. It is the wrong choice if you need something to import and call, if your machines run 3.13, or if what you actually want is the MacNet or puppeteer research, since both sit on separate branches. Before you commit, read pyproject.toml for the Python bound and the pinned dependencies, diff it against requirements.txt, and confirm which branch you are installing.

## FAQ

### What does ChatDev do?

ChatDev 2.0, called DevAll, is a zero-code multi-agent platform where you define agents, workflows and tasks through configuration instead of writing code, and run scenarios such as data visualization, 3D generation and deep research. The earlier 1.0 line was a virtual software company whose CEO, CTO and Programmer agents worked through seminars covering design, coding, testing and documentation.

### what is chatdev

It began as a multi-agent system for software development and is now positioned as a multi-agent orchestration platform. Version 2.0 was released on 7 January 2026, the 1.x line moved to the chatdev1.0 branch, and tags v2.1.0 and v2.2.0 followed in January and March 2026. The last push to main was on 24 July 2026 and the repository is not archived.

### how to install chatdev

The repository is an application, not a published package: pyproject.toml sets requires-python to >=3.12,<3.13 and the uv table sets package = false, with a lock file at uv.lock. It ships a Makefile, a Dockerfile, a compose.yml running a backend on port 6400 and a frontend on 5173, and both .env.example and .env.docker for environment settings.

### is chatdev free

The open source repository is Apache-2.0, stated in the project metadata and backed by a LICENSE file at the top level. A hosted SaaS version was launched in November 2023 at chatdev.modelbest.cn, which is a separate offering from the repository you can clone.

### chatdev alternative

The alternatives this project names are its own other lines rather than competing frameworks. The chatdev1.0 branch keeps the virtual software company, the macnet branch carries directed acyclic graph collaboration, and the puppeteer branch carries the NeurIPS 2025 orchestration work. No comparison against other agent frameworks is published in the repository.

## Sources

- [Official documentation](https://arxiv.org/abs/2307.07924)
- [Official README](https://github.com/OpenBMB/ChatDev#readme)
- [Project repository](https://github.com/OpenBMB/ChatDev)
- [Release notes](https://github.com/OpenBMB/ChatDev/releases)

---

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