AWorld declares no dependencies, and ships its command line separately

The base package installs with nothing attached to it

The project manifest declares an empty dependency list, and everything else is an extra. That is the single most consequential packaging fact in the repository.

A bare install gives you the kernel and nothing to run it with: no HTTP client, no model client, no configuration loader. The model stack lives in an extra named for language models, and it is substantial. It carries the OpenAI client with a wide range, HTTP with the SOCKS extra pulled in explicitly, pydantic, YAML, a logging library, numpy, a tokenizer library, requests, a tracing-and-instrumentation library, an introspection helper, packaging metadata helpers, FastAPI, and both halves of the OpenTelemetry API and SDK.

Two smaller extras exist. One for skills that adds nothing but YAML, and one for development with the test runner, the build frontend, and the build backend itself.

The SOCKS extra on the HTTP client is worth noting on its own. It means a proxied endpoint is a supported configuration rather than something you patch in later, which matters for a framework whose harness layer is where network policy usually gets enforced.

So the install question is not whether the dependencies are small. It is that none of them arrive unless you ask, by name.

Two command names, two distributions

The manifest registers one console script, mapping a command named aworld to the package's CLI main function.

The installation instructions in the README then install a second distribution. After the editable install of the root, the sequence continues into a directory named aworld-cli and installs that as editable too:

conda create -n aworld_env python=3.11 -y && conda activate aworld_env

pip install -e . && cd aworld-cli && pip install -e .

and every subsequent example invokes the second command:

aworld-cli --config

So there are two packages, two entry points and two names, and the one the documentation tells you to use is not the one the manifest declares. That is workable and it is also the kind of detail that breaks a Dockerfile or a CI step written by someone who read the manifest rather than the README.

Configuration follows the same split in spirit rather than in code. The configuration command is run from your working directory, and the alternative is to create an environment file in that directory with your model and API settings. So the configuration belongs to the project you are working on, not to the installation, which is the right default for a harness that runs inside someone else's repository.

The wheel ships two token vocabularies

The build configuration does something unusual: instead of including a package directory wholesale, it enumerates individual files, and two of those files are tokenizer vocabularies.

"aworld/config/qwen.tiktoken",

sits in the list next to a second one named for another tokenizer family, and both are data files rather than code. A wheel that bundles two vocabularies is a wheel that can count tokens for two different model families without downloading anything at first use, which is exactly what a harness that reports usage and manages context needs.

The same configuration sets the version source to a file inside the package rather than to a tag, and it turns off version control introspection for the build, which means a wheel can be built from a directory with no Git metadata at all. For a repository that also carries a second, older build script, that matters: the two builds have different ideas of where the version comes from.

Everything else in the include list is spelled out module by module, down to individual files in the agent, context, checkpoint, command line and configuration directories. That is a deliberate choice for a package that wants a reproducible file list, and it is also a file that has to be updated by hand whenever a module is added.

Two build systems and two pytest configurations

The repository root contains a modern project manifest built with one build backend and, beside it, a setup script written for a different one.

The manifest builds with a recent build frontend and the modern backend, taking its version from a file inside the package. The setup script at the root is a setuptools build that imports the version from a separate version generation module, generates a version information class with properties for the build date, the build version and the build user, and installs a custom source distribution command that runs that generator. The build date comes from the system clock and the build user from the name of the account running the build, and every subprocess it invokes has a sixty second timeout.

So a build produces a generated file recording when it happened and who made it, which is useful provenance, through a path that duplicates the manifest's own version handling.

The test configuration is duplicated too, with a current test configuration file and one explicitly marked legacy. There is also a root conftest, which suggests the tests are run from the repository root rather than per package.

None of this is broken, and all of it is the shape of a project that has changed build systems without cleaning up after itself. For a dependency you install from a wheel it is invisible; for anyone reading the repository to understand what they are running, it is the first thing they will notice.

One evaluation harness has its own container definition

Most directories in the root are plural or hyphenated and self-explanatory. Two are not.

There is a container file and a compose file, both named for one specific evaluation rather than for the project, alongside a web launch script and directories for internal code, training and shared environment files. That pairing suggests the harness for one named benchmark is deployed and pinned separately from the framework itself, which is a defensible way to keep a difficult evaluation reproducible.

The examples directory is where the project's range shows. It holds a quick start, browser use, a core session example, a directory for multi-agent work, one for skill agents, one for subagent integration, one for video generation, and one for web use. Alongside those are directories named after public benchmarks, including two agent evaluation suites, an olympiad mathematics suite, a desktop and computer-use suite, and a web arena. There is also an acceptance example for command line hooks, a sandbox example, a phone-use example, and one named for a scheduled-task experience demo.

A dated document also sits in the repository root, an internal technology insights note whose name carries a date. Whatever its purpose, a dated analysis file at the top level of a project is the kind of artifact that dates the snapshot it was written in.

Some of the listed capabilities come from an external skill hub

The capability table lists what each entry produces, the expertise it needs, and a recipe to follow, and the second column is where the supply chain lives.

Two rows point at skills inside this repository: a user interface evaluation skill and an agent browser skill, both referenced by path in the project's own skills directory. The video rows are mixed. The subtitles and audio insertion skill and the embedded video skill are local, referenced by path. The Remotion skill that creates the videos is not: it is referenced at an address on an external skill hub site.

So one of the headline demonstrations depends on a skill hosted elsewhere, which means reproducing it means trusting a third party to keep serving the same artifact. That is a normal trade for a community skill ecosystem and an unusual one to see inside a project's own capability table.

Two more things about the table. The action column has no text in it, since those cells held video, and two of the video rows are commented out in the source, which is why the visible list jumps from the general video rows to the trigonometry one.

The recipe paths are also worth reading twice, because the documentation directory in those links contains a space in its name, which is the kind of path that breaks a shell command and works fine in a browser.

The thesis is about the wall of context, and the versioning is quiet

The framing in the README is worth restating because it explains the architecture. General purpose AI hits a wall of context: the specific data, workflows and intuition that define a particular world. An agent's power is described as living not in the model but in the harness, the framework that orchestrates its tools, memory, context and execution. The thesis follows that a harness alone is not enough, and that scaling happens when experts encode their knowledge, described as building the gate in that wall.

That is why the project is organised around skills and recipes rather than around a model wrapper: the knowledge is the deliverable, and the harness is the recipe it is encoded in.

The release history is quiet by comparison. Three tags are visible, 0.3.0 in November 2025, 0.3.1 in February 2026 and 0.3.2 in May 2026, and the last push to the default branch was 2026-10-01. So the default branch has moved roughly four months past the newest release without a tag, which for a framework at version 0.3 means the version number understates how much has changed on main. The repository is not archived, and it carries over a thousand stars with 54 open issues.

Editorial conclusion

AWorld is worth trying if you want to encode domain knowledge as skills rather than prompts and let a CLI orchestrate the rest, and the recipe-per-capability structure is a usable way to see how that works. Three things to check before you commit. The install shape, because a bare editable install gives you a package with no HTTP client and no model client, so decide which extras you actually want rather than discovering it at the first call. The packaging, because there are two build systems, two pytest configurations and two command names in one repository, which is fine for experimentation and a maintenance question for a dependency you intend to pin. And where a capability comes from, because the showcased video results lean on a skill hosted on an external hub rather than on code in this repository, so the reproducibility of a demo and the auditability of its supply chain are different questions.

Frequently asked questions

Official sources

1. inclusionAI/AWorld on GitHub
2. License: MIT
3. Project website
4. README
5. Releases