WorldX: one prompt, four model roles, and an alpha simulation you run yourself
One sentence creates an AI-driven world — generate maps, characters, and watch stories emerge on their own. 一句话生成一个AI自主驱动的世界.
At a glance
- What is it?
- WorldX turns a single sentence into a playable pixel world with LLM-driven characters. The README documents four separately configured model roles, a Node 22.13+ SQLite dependency, and an Alpha status. Here is what that means before you clone it.
- Who is it for?
- Adopt WorldX if you want to read or extend the agent loop and you already hold keys for a reasoning model, an image model, a vision model and a cheap chat model, since the README treats all four as separately configured roles. Do not adopt it if you need a stable product, a hosted endpoint, or a single-key setup, because the repository labels itself Alpha and the runtime depends on node:sqlite.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap WorldX aims at: a sentence in, a populated world out
Most generative agent demos hand you a fixed town and let you watch. WorldX inverts that. The README's central claim is that one sentence, in its example "北宋汴京的夜市街，有算命的、当铺掌柜、小偷、捕快，还有一个穿越来的现代人", is enough to produce the map, the cast, and the rules that govern them. The project describes itself as Alpha and the repository carries no releases yet, so treat the claim as a design target rather than a finished capability. The audience is narrow and specific: developers who want to inspect how a world specification is decomposed into agents, memory and map data, and who are willing to supply four model configurations to find out. It is not aimed at someone who wants a hosted sandbox to paste a prompt into.
Four model roles instead of one: the architecture the README exposes
The README divides the work across four environment-variable prefixes, and this split is the most informative part of the documentation. ORCHESTRATOR_ designs world structure, characters and rules, and the README recommends a stronger reasoning model. IMAGE_GEN_ produces map art and character portraits. VISION_ reviews map quality and locates regions and elements, which implies a multimodal model. SIMULATION_ drives runtime character behavior, and here the README explicitly says any model works and a cheap one is fine. Each role takes a base URL, an API key and a model identifier, formatted as {ROLE}_BASE_URL, {ROLE}_API_KEY and {ROLE}_MODEL. Three of the four speak the OpenAI-compatible chat/completions protocol; the image role is the exception, accepting either openai-compatible or google-native through IMAGE_GEN_PROVIDER. That separation is a real architectural decision, not a configuration convenience. Generation happens once and can afford an expensive model; simulation runs continuously and cannot. The vision role sits between them as a quality gate on generated maps, which suggests the project does not trust raw image output to match the requested layout.
Node 22.13+ and node:sqlite: why the version window is narrow
The prerequisites section is unusually precise, and the precision is worth reading closely. WorldX uses Node's built-in SQLite module, node:sqlite, which means npm install compiles no native modules. The README states the usable range as >=22.13 <23 || >=23.4, and explains why: between 22.5 and 22.12, and between 23.0 and 23.3, node:sqlite still sat behind the --experimental-sqlite flag. Anyone on Node 20 or on an early 23.x release will hit a failure that has nothing to do with WorldX itself. Node 24 LTS is the recommendation. This is a genuine constraint rather than a formality, and it is the kind of detail that separates a project whose author actually ran it from one that copied a badge.
Getting it running: two paths, two levels of API commitment
The README offers a fast path and a full path. The fast path clones the repository, copies .env.example to .env, fills only the SIMULATION_ lines, runs npm install and npm run dev, then opens http://localhost:3200 and picks one of two bundled pre-generated worlds. The full path fills all four model groups and opens http://localhost:3200/create to generate from a sentence. There is also a CLI route: npm run create -- "赛博朋克风格的深夜拉面馆，黑客和仿生人在这里交换情报". The README documents platform examples for OpenRouter (one key covering every role) and Google AI Studio (which has a free tier), plus a mixed arrangement where generation runs on AI Studio and simulation runs on DeepSeek's deepseek-chat because high-frequency calls are cheaper there. It also warns about proxy issues, though the supplied excerpt cuts off mid-sentence, so the full guidance is not available here.
The image model is the weak link, and the README says so
The most candid passage in the documentation concerns image generation. The README recommends nano banana 2, given as gemini-3.1-flash-image, and states that gpt-image-2 still falls short on instruction following, that it tends to cause various problems in this project and affect the final result, even though its art style looks noticeably better than nb2. That is an admission that the pipeline depends on layout compliance from the image model, and that a model producing prettier pictures can still break the world. For anyone planning to swap in a different image backend, this is the first thing to test. The vision role exists to catch some of this, but the README does not describe what happens when the review fails or how many retries occur, and that gap is worth knowing about before you build on top of it.
What the README does not tell you
Several things a prospective adopter would want are absent. There is no description of how world state is persisted beyond the fact that SQLite is involved, no schema, no note on how memory is stored or retrieved for characters, and no discussion of token cost per simulated day. The features list mentions multi-day evolution across day and night cycles, a timeline system where one world can spawn multiple timelines, and a god mode for broadcasting events, editing character personas and memories, and holding out-of-character conversations. How any of that is implemented is not documented in the material available. The README also notes the project is in Alpha, core usable, continuously being optimized. There are no releases, so there is no version to pin and no changelog to read. Anyone evaluating this for anything beyond experimentation is evaluating a moving main branch.
Where a different approach makes more sense
If your goal is to study emergent multi-agent behavior rather than to generate worlds, a framework such as the Stanford generative agents line of work gives you a small fixed environment with published memory-stream and reflection mechanics, and you spend your time on the agent loop instead of on map generation and image review. WorldX's bet is the opposite: it spends two of its four model roles on producing and checking visual assets, which buys variety in setting at the cost of an extra failure surface. The distinction matters practically. In a fixed-environment framework, a bad day of simulation is a prompt problem. In WorldX, a bad day can also be a map that did not match the sentence, which the vision role was supposed to catch. If you want to iterate on agent cognition, the fixed environment is less machinery between you and the question. If you want to see a requested setting rendered and inhabited, WorldX is doing work those frameworks do not attempt.
Licence, maintenance and the cost of staying current
WorldX is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, and it also means no warranty is offered. This is not legal advice; read the LICENSE file in the repository for the operative terms. On maintenance, the repository was last pushed on 2026-09-01, is not archived, and carries no releases, so there is no upgrade path defined by version numbers. Updating means pulling main. The runtime cost is not licence-bound but provider-bound: three text roles plus an image role, each with its own key and its own per-call pricing, and the simulation role fires continuously while a world runs. The README's own advice to use a cheap model for SIMULATION_ is a cost statement. Budget for the orchestrator and vision calls being infrequent and expensive, and the simulation calls being frequent and cheap, then measure the second one before running a world for many simulated days.
Editorial conclusion
Adopt WorldX if you want to read or extend the agent loop and you already hold keys for a reasoning model, an image model, a vision model and a cheap chat model, since the README treats all four as separately configured roles. Do not adopt it if you need a stable product, a hosted endpoint, or a single-key setup, because the repository labels itself Alpha and the runtime depends on node:sqlite. Verify first that your Node build falls in the documented range (>=22.13 <23 or >=23.4), that your image model follows layout instructions, and that your provider exposes an OpenAI-compatible chat/completions route for the three text roles.
Community notes