ChatDev logo

ChatDev

★★★★ 4.3/5
Visit site
Category
Agents
Pricing
Free

Quick Verdict

ChatDev 2.0, branded DevAll, is a strong evaluation candidate for developers, researchers, and educators who want to design multi-agent workflows in YAML or on a visual canvas and can operate the platform themselves. It is no longer limited to ChatDev 1.0’s “virtual software company.” The main branch defines agents, tasks, conditional edges, human input, tools, and artifacts for deep research, data visualization, 3D generation, and software experiments. The classic CEO, CTO, programmer, designer, and tester pattern remains on the separate chatdev1.0 branch.

The current release decision needs a security qualification. As of July 21, 2026, the newest formal tag is v2.2.0. A filename path-traversal fix for uploads merged on June 29, 2026, after all published v2.0.0, v2.1.0, and v2.2.0 artifacts. Do not expose those artifacts to untrusted or multi-user uploads. Deploy a revision containing fix commit 4fd4da6, or a later release whose history confirms an equivalent fix. Even then, attachments, Python execution, MCP tools, remote models, and generated code create a broad privilege surface. Authentication, per-session isolation, upload policy, secret handling, and human approval remain operator responsibilities.

Best For

  • Researchers comparing multi-agent organizations, orchestration strategies, and human-in-the-loop designs.
  • Educators who want a visible workflow graph rather than an opaque chain of agent messages.
  • Developers building controlled research, data-processing, 3D, game, or software prototypes.
  • Teams able to maintain Python 3.12+, Node.js, a reverse proxy, model providers, storage, and execution sandboxes.
  • It is not suitable as an assumed turnkey SaaS, for anonymous public uploads, or for agents that receive production credentials and host access without approval gates.

Key Features

  • Visual and YAML workflows: Define agent nodes, conditions, loops, dependencies, and human input in configuration or a Vue-based canvas.
  • General-purpose examples: Repository workflows cover research, visualization, Blender tasks, games, and software rather than only a sequential software company.
  • Model and tool configuration: Connect model endpoints and local or remote MCP tools, with environment-variable placeholders for sensitive values.
  • Python execution and artifacts: Generated Python can run in a workspace, consume uploaded data, and register outputs for download.
  • Attachment lifecycle: REST and WebSocket interfaces upload, list, stream, and download files and can package a complete session.
  • Programmatic operation: Web UI, backend APIs, scripts, and Python integration support different experimentation styles.
  • Legacy research path: The 1.x branch preserves the communicative-agent software-company design for reproduction and comparison.

Use Cases

In a course, teams can visualize how role definitions and graph topology change outcomes. In a research pipeline, retrieval, analysis, drafting, and review can become separate nodes whose intermediate outputs remain inspectable. For data visualization or 3D prototypes, a scanned sample can be uploaded to a disposable workspace, transformed by generated code, and reviewed before export. Software generation is also possible, but its output belongs in a conventional review pipeline with tests, dependency scanning, and controlled release. It should never deploy directly from an agent workspace.

Treat prompts, websites, MCP responses, and uploaded documents as untrusted. Isolate users and jobs with separate sessions, containers or VMs, output directories, and temporary model credentials. Do not mount SSH keys, cloud credential directories, browser profiles, or production configuration. Restrict network egress and tool selection. Deletion, package installation, external writes, publication, and whole-session download should require explicit approval. Logs and exported archives may contain source documents, prompts, generated content, or provider responses and need their own access and retention controls.

Pricing

ChatDev is Apache-2.0 software and can be self-hosted without a license fee. Model tokens, compute, storage, scanning, monitoring, networking, and operations still cost money. ChatDev 2.0 and legacy 1.x are different operating paths, not interchangeable editions.

PathSoftware priceAppropriate useCritical check
ChatDev 1.x branchFreeReproducing the virtual-company designLegacy architecture, not DevAll functionality
DevAll v2.2.0FreeControlled reproduction onlyPredates the June 29 upload traversal fix
Patched commit or later releaseFreeNew evaluationsConfirm 4fd4da6 or equivalent is included
Production self-hostingInfrastructure dependentTeams with platform and security staffBudget models, isolation, auth, scanning, and audit

The repository’s development startup commands are not a production topology. The attachment guide says the backend has no hard upload-size cap and expects a proxy or service customization to enforce one. It also says session IDs should be protected with proxy authentication or internal JWT checks. Add object-level authorization to uploads, WebSockets, artifact listing, single downloads, and session archives; test CORS, quota, cleanup, backup, and denial-of-service behavior.

Pros

  • A configurable, general multi-agent platform rather than one fixed role-play pattern.
  • YAML, a visual canvas, APIs, and Python execution serve teaching and engineering experiments.
  • OpenBMB’s MacNet and evolving-orchestration work gives the project a clear research lineage.
  • Apache-2.0 source can be reviewed and adapted for a controlled environment.
  • Attachments, artifacts, and live events improve observability for data-oriented workflows.
  • Chinese and English project documentation make the core concepts more accessible.

Cons

  • The newest tagged artifacts predate an important path-traversal fix, so version selection requires commit-level verification.
  • Upload authentication, hard size limits, malware scanning, and multi-tenant boundaries are not supplied as a complete production baseline.
  • Python execution, generated code, and MCP tools can gain extensive filesystem and network access without external isolation.
  • Operators must maintain frontend, backend, model access, storage, proxy policy, and workspace cleanup.
  • More agents add token use, latency, nondeterminism, and debugging work; extra roles do not guarantee a better result.
  • Migration between legacy 1.x workflows and DevAll should not be assumed automatic.

Alternatives

ToolBest fitAdvantageMain tradeoff
MetaGPTSoftware-team role researchExplicit software-engineering organizationLess general visual orchestration
AutoGenPython-built conversational agentsFlexible code-first frameworkHigher barrier for non-developers
CrewAIRole, task, and crew workflowsClear Python task abstractionsTool security remains operator work
DifyOperated LLM applications and workflowsBroader app, RAG, workflow, and admin layerHeavier platform with a different goal
CozeManaged agent publishingMore productized publishing and connectorsDifferent self-hosting and control model
n8nDeterministic business automationMature triggers, connectors, and approvalsNot a multi-agent research framework

FAQ

Are ChatDev 2.0 and ChatDev 1.0 the same system?

No. DevAll is the general zero-code orchestration platform on the main branch. The virtual software company is maintained on chatdev1.0, with a different architecture and workflow format.

Is tagged version 2.2.0 safe to expose to public uploads?

It should not be used that way. The tag predates the June 29, 2026 upload filename path-traversal fix. Use code containing 4fd4da6 or a later release verified to include an equivalent change, then add normal upload defenses.

Does DevAll provide production authentication and tenant isolation by default?

Do not assume so. Its attachment guide calls for proxy authentication or internal JWT checks. Every session, artifact, WebSocket, and archive endpoint still needs object-level authorization testing.

How should uploads be handled?

Enforce size and type limits, assign safe storage names, scan for malware and sensitive data, cap disk use, set retention, and prevent session identifiers from acting as authentication. Keep patched code as the first prerequisite.

Can generated code run on the host?

It should run only in a disposable, low-privilege sandbox with no production secrets, restricted networking, resource and time limits, and a controlled output directory. Review and test it before moving anything into a real project.

Where should model and tool secrets live?

Use a runtime secret manager or controlled environment injection. Never commit them to YAML, expose them to prompt context, include them in uploads, or retain them in session archives. Prefer narrow, temporary credentials.

Bottom Line

ChatDev 2.0 turns a notable multi-agent research lineage into a configurable DevAll workspace, which is useful for education, research, and controlled prototyping. It is not a secure public platform merely because it starts locally. Pin a revision containing the post-release traversal fix, begin with non-sensitive sample workflows, and measure quality, cost, and reproducibility. Expand only after authentication, session isolation, upload scanning, generated-code sandboxing, secret management, egress controls, and high-impact action approvals have been implemented and tested.

Last updated: July 21, 2026

Related tools