OpenManus: three entry points, a second browser, and two disagreeing dependency lists

main.py, run_mcp.py and run_flow.py, and the last one is called unstable

Three scripts sit at the repository root and they are not three versions of the same thing. main.py is the agent itself, and running it drops you into a terminal where you type an idea. run_mcp.py is the MCP tool version, which matters if the tools are meant to be reached over a protocol rather than called in process. run_flow.py is the multi-agent version, and the project labels it unstable, which is the word to weigh before you build a workflow on it.

The repository layout says something about how the code is arranged. app/ holds the tools, config/ holds the configuration directory that config.toml lives in, protocol/ sits alongside, workspace/ is where an agent's output has somewhere to go, and examples/ is split into benchmarks/ and use_case/. There is also sandbox_main.py and run_mcp_server.py, which are not mentioned in the quick start, so what they are for is a question the documentation leaves open.

uv is the recommended install, and conda is the fallback with the same Python

Both routes land on Python 3.12, which setup.py enforces with python_requires of 3.12 or higher. The recommended route installs uv first:

curl -LsSf https://astral.sh/uv/install.sh | sh

then clones the repository:

git clone https://github.com/FoundationAgents/OpenManus.git
cd OpenManus

The conda route creates the environment before the clone:

conda create -n open_manus python=3.12
conda activate open_manus

and both routes finish with a dependency install. The project recommends uv for faster installation and better dependency management:

uv pip install -r requirements.txt

With uv the environment is created in one more step, and the Windows activation line is written as a comment in the same block:

uv venv --python 3.12
source .venv/bin/activate  # On Unix/macOS
# Or on Windows:
# .venv\Scripts\activate

The conda route uses pip install -r requirements.txt instead. Nothing else differs between the two.

config.toml needs an [llm] block, and the vision block is optional

There is no environment variable for the model. Configuration is a file, copied from the example that ships in the config directory:

cp config/config.example.toml config/config.toml

The global block is the one you must fill in:

# Global LLM configuration
[llm]
model = "gpt-4o"
base_url = "https://api.openai.com/v1"
api_key = "sk-..."  # Replace with your actual API key
max_tokens = 4096
temperature = 0.0

A second block, [llm.vision], takes the same four keys for a separate vision model and is described as optional, so an agent that never looks at an image can leave it alone. temperature is pinned to 0.0 in the example, which is a deliberate default for a tool that plans before it acts.

A third switch belongs to the multi-agent route. The DataAnalysis agent is integrated but off:

[runflow]
use_data_analysis_agent = true

Flipping it is not enough on its own. The project also asks you to install the relevant dependencies for the chart visualization tool, with the instructions in app/tool/chart_visualization/README.md, so the feature arrives as a flag plus a second install step.

Browser Use runs as a separate MCP server, kept out of your environment by uvx

Browser automation is not part of the OpenManus process, and the design choice is stated: uvx keeps Browser Use and its fast-moving dependencies isolated from the OpenManus environment. OpenManus starts Browser Use CLI 3.0 as its default MCP server:

uvx browser-use --cli-mcp

The agent then receives the canonical Browser Use skill and the native browser_exec and browser_screenshot tools, so from the agent's side the tools look local while the process is not. Local mode attaches to Chrome or Chromium automatically and needs no API key. Diagnostics and a Chromium install are separate commands:

uvx browser-use --doctor
uvx browser-use install

Going remote is one environment variable, set before OpenManus starts:

export BROWSER_USE_API_KEY="bu_..."

An existing browser can be attached instead with BU_CDP_URL, BU_CDP_WS or BU_NAME, and the whole default server is removed by setting OPENMANUS_DISABLE_BROWSER_USE=1. The cost of the isolation is a second stack to maintain: BrowserGym, which is a separate dependency, still needs its own Playwright browser installed with playwright install.

setup.py and requirements.txt are two different dependency lists

The repository ships a setup.py, so pip install . is a route that looks available. It is not the same environment. setup.py declares pydantic~=2.10.4, openai>=1.58.1,<1.67.0, datasets>=3.2,<3.5 and gymnasium>=1.0,<1.2. requirements.txt declares pydantic~=2.10.6, openai~=1.66.3, datasets~=3.4.1 and gymnasium~=1.1.1, and then adds packages setup.py never mentions: mcp, playwright, docker, crawl4ai, tiktoken, fastapi, duckduckgo_search, baidusearch, beautifulsoup4, boto3, requests and huggingface-hub.

That gap decides whether your run works. The MCP entry point needs the mcp package, the browser stack needs playwright, and the tool layer reaches for the search and scraping packages. Install through the package metadata and python run_mcp.py has no MCP library to import, while the documented uv and conda routes, which both use requirements.txt, do.

The version field is stale in the same file: setup.py says 0.1.0 while the newest release tag is v0.3.0. The console entry point is still declared, openmanus=main:main, so the package installs a command that points at the agent.

All three release tags share one timestamp, and main moved long after

The tags do not form a cadence you can plan against. v0.1.0, v0.2.0 and v0.3.0 were all published on 2025-04-10, seconds apart, which reads as a set published in one sitting rather than as three milestones. Since then the default branch has kept moving: the last push was on 2026-08-22, and the repository is not archived. Any code you evaluate is therefore main, and no tag describes it.

The project is candid about its own state. It calls itself a simple implementation, says the prototype was launched within three hours of starting, and asks for suggestions, contributions and feedback. The authors are named, with the core pair credited from MetaGPT alongside three more contributors, and the README exists in four languages. That candour is useful when you are reading the code, and it is also a signal about what kind of artefact this is: a readable implementation to learn from and change, not a service with a compatibility promise.

A related project exists for the training side. OpenManus-RL is a separate repository for reinforcement learning based tuning methods such as GRPO for LLM agents, developed with researchers from UIUC. If your goal is to tune the planner rather than run the agent, the code is not here.

The Docker image ends in bash, so nothing starts the agent for you

The Dockerfile at the repository root is short enough to read in full, and it explains a lot about how the project expects to be used. It starts from python:3.12-slim, installs git and curl, installs uv only if the command is missing, copies the whole tree into /app/OpenManus, and installs the requirements into the system interpreter:

RUN uv pip install --system -r requirements.txt

The final line is CMD ["bash"]. There is no entrypoint that runs main.py, no exposed port, and no volume declared, so the image is a prepared environment rather than a runnable service. If you containerise this, you supply the command, and you decide separately whether workspace/ should live in the container or on a mounted volume.

Two housekeeping files sit alongside the Dockerfile: an assets/ directory, and a .pre-commit-config.yaml that the contribution instructions expect you to use before opening a pull request.

pre-commit run --all-files

Contributions go through issues and pull requests, and the project asks for the pre-commit run first.

The pitch is access without an invite code, not a benchmarked match

The project's positioning is worth reading precisely, because it is a claim about access. It opens by saying that Manus is impressive but that OpenManus can achieve any idea without an invite code, and the repository description says the same thing in fewer words. What the project offers is the ability to run the agent yourself, with your own key, on your own machine, and to read every line of the loop that decides what the model does next.

What it does not offer is a comparison. No evaluation numbers appear in the documentation, no benchmark results are published, and examples/benchmarks/ exists as a directory without a described procedure. So a reader deciding between this and a hosted agent is not choosing on measured quality, and the honest basis for the choice is control: local files, your own model endpoint through base_url, your own browser process, and code you can edit.

There is also a distribution question the project does not settle. A Hugging Face space, a Discord link and a Feishu group exist for trying and talking about it, but the repository is the only artefact with a licence attached, and that licence is MIT.

Editorial conclusion

OpenManus fits a developer who wants to read and modify a small agent codebase in Python, has an API key for a chat model to hand, and does not mind that the browser lives in a separate process. Do not adopt it as a packaged product: the newest release tags are all from 2025-04-10, the version in setup.py still reads 0.1.0, and the multi-agent entry point is labelled unstable. Before you build on it, decide whether you install with requirements.txt or with the package metadata, because the two lists are not the same, and confirm that whichever browser route you take is one you can restart.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes