Cultivation World Simulator: an LLM agent sandbox where you play the world, not a character

The problem is LLM drift, and the answer is a rule layer the model cannot override

Ask a language model to run a fantasy society and it will produce plausible prose with no memory of who owes whom a debt. Ask it to run a hundred characters at once and the failure compounds: characters act out of character, dead NPCs reappear, a mortal suddenly flies. The README states the project's position directly, saying the world is built so that AI imagination is confined inside a cultivation logic framework, and that the world's worldview and operating rules are written in to avoid AI hallucination and excessive divergence. That is the design thesis. The simulator is not trying to make the model smarter. It is trying to make the model's output checkable against spirit roots, realms, techniques, personality, sects, pills, weapons, martial tournaments, auctions and lifespan. The audience is therefore narrow and specific: people building agent systems who want a non-toy domain to test them in, plus players who want to watch rather than play. The README frames the user as the 天道, the heaven's way, observing rather than inhabiting a character, and describes the player's available actions as watching, or intervening through things like heavenly tribulation or rewriting a mind.

Every cultivator is an agent, and the world state is the shared blackboard

The architecture described in the README is a population of independent agents over a shared world model. Each cultivator is its own agent with its own personality, memory, relationships and behavioural logic, and each one observes the environment and makes decisions rather than being scripted. Sects are treated as a second kind of actor with their own will, so the simulation has two layers of agency that can cooperate or conflict. The screenshots listed in the README point at what the state model actually tracks: a character panel, traits and equipment, a thinking view, nicknames earned in the world, cave exploration, and separate categories for pills, artifacts and weapons. The thinking screenshot is the tell. The system surfaces an agent's reasoning as a first-class object, which means the decision step is inspectable rather than buried in a final action. Nothing in the supplied material specifies how memory is stored or how far back an agent can recall, so treat persistence of memory as unconfirmed. What is confirmed is the intended shape: rules hold the invariants, agents produce the variation, and the resulting plot is described as emergent, with the README stating that the developers themselves do not know what happens next and that there is no pre-written script.

Getting it running: three paths, and only one of them is for tinkering

The README offers a desktop build on the Epic Games Store, a source deployment, and Docker. For source, the stated requirements are Python 3.10 or newer, Node.js 18 or newer, and a working model service. The commands given are pip install -r requirements.txt, then cd web && npm install && cd .., then python src/server/main.py --dev. The dev flag is documented as starting both the front end and the back end, with the front end usually on http://localhost:5173, and the README notes that if it does not open automatically you should read the front-end address out of the startup log. Model configuration is not a file you edit first. The README says you pick a preset in the settings page, naming DeepSeek, MiniMax and Ollama as examples, and that the configuration is saved automatically into the user data directory. That ordering matters: a fresh source install will start and show you a world you cannot advance until a model is configured. The Docker path is git clone, cd, then docker-compose up -d --build, with the front end on http://localhost:8123. The container persists user data through CWS_DATA_DIR=/data, covering settings, keys, saves and logs, mapped by default to ./docker-data on the host so that a docker compose down followed by up keeps them. Note the README's own parenthetical on this section: it is marked as untested. For LAN or phone access the README suggests starting the back end with SERVER_HOST set to 0.0.0.0, editing system.host in the read-only static/config.yml if you want to change the default, and adding host: '0.0.0.0' to the server block in web/vite.config.ts. The same section warns that the mobile UI is not fully adapted and is for early experimentation only.

The REST API is the part worth stealing, and it is split by intent

Buried in a collapsed section of the README is the most reusable thing in the repository: a stable namespace split into read-only queries under /api/v1/query/* and controlled writes under /api/v1/command/*. The documented entry points are GET /api/v1/query/runtime/status, GET /api/v1/query/world/state, GET /api/v1/query/events, GET /api/v1/query/detail?type=avatar|region|sect&id=<target_id>, POST /api/v1/command/game/start, POST /api/v1/command/avatar/* and POST /api/v1/command/world/*. The README describes the intended minimal loop: check runtime status, call game/start if no game is running, then read world state and events. It explicitly frames this as the path for external agents, automation scripts, and a closed observe, decide, intervene, observe cycle. The query and command split is a real design decision rather than a naming convention: it tells you which calls are safe to poll and which ones mutate the world, which is exactly what you want if your own agent is going to sit on top. The README's description of this section is truncated mid-sentence in the supplied material, so the full event schema and the complete avatar and world command surface are not documented here. Budget time for reading the source or running the server to enumerate them.

What the design costs you: LLM calls per agent, and a licence you must read yourself

The obvious constraint is inference volume. The README describes every NPC as independently LLM-driven, making decisions from the current situation. It does not state how often an agent is invoked, whether decisions are batched, or whether cheap models are used for minor characters. Without that, the only honest statement is that cost scales with population multiplied by decision frequency, and that a world with many cultivators is a world with many calls. This is the main reason to run Ollama locally rather than a hosted preset: it converts a per-token bill into a hardware bill, at the price of model quality, which in turn increases the pressure on the rule layer to catch bad output. The second cost is licensing. The repository reports NOASSERTION, which means no machine-readable licence was detected. The README does not discuss licence terms. Do not infer permissions from the fact that a desktop build is distributed free on the Epic Games Store; free distribution and an open licence are different things. If you plan to fork this or ship a derivative, resolve the licence question before writing code against it. This is not legal advice, and the only reliable source is the repository's own licence file and its maintainer.

Where it fits against a general agent framework

The natural comparison is a general multi-agent framework such as AutoGen or a graph-based orchestrator like LangGraph. Those give you message passing, tool calling and control flow, and leave the domain entirely to you. Cultivation World Simulator makes the opposite trade. It ships the domain: the realm ladder, spirit roots, sects, pills, artifacts, tournaments, auctions and lifespan are already modelled, and the agent layer is wired into them. You get a populated world on first run instead of an empty graph. What you give up is generality. The rule system is the product, so bending it to a different setting means rewriting the invariants the agents are constrained by, and the README does not describe a plugin or schema mechanism for swapping the domain out. There is also a third option worth naming: a plain text-based simulation with no LLM in the loop at all. That is far cheaper and fully deterministic, and it is the right choice if you want reproducible runs. The moment your requirement is that characters react to situations the designer did not enumerate, this project's approach is the one that scales, because the rules define the boundary and the model fills the interior.

Maintenance, versions and what to check before you build on it

The release history shows three releases in roughly a month: v3.9 on 2026-07-19, v4.0.0 on 2026-08-01, and v4.0.1 the next day. A patch the day after a major version suggests active iteration rather than a frozen API, and the last push predates this review by a short interval. Practically, that means the /api/v1 namespace is the surface to depend on, since it is the only interface the README presents as stable, and that anything you build against internal modules will need attention at each minor release. Upgrading through Docker is the least disruptive path because user data lives behind CWS_DATA_DIR, so settings, keys, saves and logs survive a container rebuild; the README states this persistence explicitly. Upgrading from source means re-running pip install -r requirements.txt and npm install in web, since dependency changes are not documented per release. Two things to verify first, both cheap. Check the licence file rather than the repository metadata. Then run the Docker path once with a local Ollama preset and watch the runtime status endpoint while a small world runs, because that tells you the real call rate, and the call rate is what decides whether this is a weekend experiment or a hosting commitment.

Editorial conclusion

Adopt it if you want a working example of many LLM agents sharing one rule system, or if you want a REST surface to drive a simulation loop from your own agent. Do not adopt it if you need permissive, unambiguous licensing for a commercial derivative, or if you want a headless library: the README treats the web front end and the game loop as the product. Verify three things before committing: the actual licence text, since the repository reports NOASSERTION; whether the Docker path works, because the README itself marks it as untested; and the cost of running one LLM call per agent per decision at the population size you intend.

Official sources

1. 4thfever/cultivation-world-simulator on GitHub
2. Issues
3. README
4. Releases