OpenMOSS runs agents like a company, and ships its dashboard from a release

The Vue source is on an orphan branch and the container fetches its own dashboard

The architecture table names Vue 3 with shadcn-vue as the frontend, then immediately explains that the current branch keeps only the built static files, with the source maintained on a separate branch. The project-structure notice is blunter: the main and dev branches are the backend mainline plus the branch that carries WebUI release artifacts, not a frontend development branch. The runtime static directory can be downloaded automatically on first start, the Vue source lives on an independent orphan branch, and the absence of a webui source directory in the checkout is described as normal rather than as a mistake.

The container agrees with that arrangement. The Dockerfile copies the app, skills, prompts, rules and the example config, and a comment states that the static frontend files are pulled from a GitHub Release when the service starts, so they need not be built into the image. The release history shows two version lines in one repository: backend tags v1.1.2 and v1.1.3, both published on 2026-04-02 within half an hour of each other with notes about WebUI download logic and Docker deployment fixes, and a separate webui-v0.0.1 tag from the day before.

Agents never talk to each other, the backend is only a task queue

The design is explicitly middleware. OpenMOSS sits between OpenClaw and the agents as a scheduling centre, every agent talks to it asynchronously over the API, and no agent communicates with another directly. Each one is a model instance running on OpenClaw carrying a role prompt and a skill, woken by cron, and the loop for a wake-up is: fetch current state, act according to role, write the result back, sleep until the next tick.

Work is organised in three levels: a task is a whole project goal, a module is a functional slice of it, and a sub-task is one executable unit. Sub-tasks move through pending, assigned, in_progress, review and done, with a rejection path from review back to rework and then to in_progress, and a patrol branch where an agent watching for trouble marks a sub-task blocked and sends it back to pending. Four roles fill those slots: planner creates tasks, splits modules and assigns sub-tasks, executor claims and delivers, reviewer scores and passes or rejects, patrol watches for stalls and raises alerts.

The zero death rate claim is the one number with nothing behind it

The feature list states that patrol monitoring pushes the agent death rate to zero percent. Nothing on the page measures it: no run length, no task count, no comparison, no definition of what counts as a death. By contrast the one concrete figure in the document is attached to a specific site. A human set a single goal for the 1M Reviews English news site, collect Chinese-language technology news, translate it and publish to WordPress, and the reported result is more than twenty articles published inside two days with no human intervention, plus a case where a new requirement, adding images, was tested by the agent team during the tenth loop of the recurring task and then applied to every later task.

So the page has one operational story and one slogan. That is not a criticism of the platform so much as a reading instruction: the case study describes what one deployment did, the feature bullet describes what the patrol agent is for. Anything a buyer needs beyond that, such as what happens when a reviewer rejects the same sub-task repeatedly, or how many wake-ups a busy day costs, is not written down here. The scenarios table makes the same split by marking the content pipeline as verified and listing autonomous coding, research assistants, data collection and operations automation as possibilities.

Every agent is a model instance on cron, so quota scales with headcount

Three notices sit above the architecture section and they are the most operationally useful text on the page. One says results depend strongly on the underlying model and that a larger context window is better, recommending GPT-5.3-Codex or GPT-5.4. One warns that multi-agent runs consume model quota multiple times over and that interface limits and rates should be controlled to avoid financial loss. One suggests configuring a dedicated desktop-class production environment for best results.

Those three together describe the cost model: a deployment is a set of model instances, each with its own wake-up schedule, each paying for its own context window, and the platform's own incentive loop pushes them to keep working. Points and a leaderboard exist, review results feed the performance score, and recurring task types are built in for continuous daily operation, so nothing in the design idles an agent by default. The 1M Reviews site publishes a public activity log at goai.love/feed and says any agent can be mentioned in the group chat for a status update, which is the intended way to watch a team that will not stop on its own.

The compose file pulls a mutable latest tag and mounts three host directories

Deployment through Docker is short. The compose file names the image ghcr.io/uluckyxh/openmoss:latest and also carries a build context pointing at the local Dockerfile, maps `${OPENMOSS_PORT:-6565}` to container port 6565, and sets the config path to /data/config/config.yaml. Three host directories are mounted: the data directory, a docker-data config directory and a docker-data static directory, which is where the dashboard build lands after the release download.

A fourth mount is present but commented out, with a note saying to uncomment it when OpenClaw and OpenMOSS run on the same machine so they can share a working directory. That single line is the whole deployment topology: co-located or not changes whether agents and the scheduler see the same files. The image is python:3.11-slim with curl added for one purpose, the health check, which polls /api/health every thirty seconds with a five second timeout and three retries. The service starts under uvicorn bound to 0.0.0.0 on port 6565, and authentication is a layer above that, in an auth module that validates an API key or an admin token.

Ten SQLite tables, and a backend that never calls a model

The persistence layer is deliberately plain: SQLite with SQLAlchemy across ten tables covering tasks, agents, reviews and points. The dependency list matches that scale, with fastapi, uvicorn, sqlalchemy, pyyaml, httpx, bcrypt and python-frontmatter, and no model client library at all. Nothing in this repository talks to a large language model. The backend schedules and records, the agents running on OpenClaw do the thinking, and the boundary between them is the API.

The layout makes the same point in directory form:

OpenMOSS/
|
|-- app/                            # 后端应用（FastAPI）
|   |-- main.py                     # 入口：路由注册、中间件、SPA 静态服务
|   |-- config.py                   # 配置加载（config.yaml）
|   |-- database.py                 # 数据库初始化（SQLAlchemy）
|   |-- auth/                       # 认证模块
|   |   +-- dependencies.py         # API Key / Admin Token 校验
|   |-- middleware/                  # 中间件
|   |   +-- request_logger.py       # 请求日志记录（驱动活动流）
|   |-- models/                     # 数据模型
|   |   |-- task.py                 # 任务
|   |   |-- module.py               # 模块
|   |   |-- sub_task.py

Two of those dependencies have an obvious job. bcrypt is there for the credentials that the API key and admin token checks depend on, and python-frontmatter is there because prompts, skills and rules are markdown files with frontmatter rather than database rows, which is why prompts/, skills/ and rules/ are copied into the image alongside the app. A request logger in the middleware layer is what drives the activity stream shown in the dashboard, and the directory listing itself stops partway down the models directory at sub_task.py.

Skills decide what the agents can do, and some of them need paid services

The project is explicit that it does not constrain what an agent can do. What you configure as prompts and skills is what the team is capable of, which is why the scenarios table is followed by a note saying each one needs the matching skill, such as web search, code execution or API calls, and that OpenMOSS handles scheduling and collaboration while the skill determines the capability.

A marker convention separates the skills that work out of the box from the ones that do not. Skills carrying the gear marker depend on particular external services, and the examples named are a WordPress site, the Gemini API and the Grok API. That marker is doing real work in a platform whose own cost warning is about quota: a team that publishes to WordPress or calls a hosted model is spending money on every cron wake-up, not once. Two other structural choices are worth noting for anyone planning a fork. Recurring tasks are a built-in type rather than an extension, and the dashboard covers task management, the activity stream, performance ranking and prompt management.

The documentation is Chinese, and an English file sits beside it in the tree

The project page that carries all of the above is written in Chinese, down to the section numbering and the role descriptions, where planner is a director, executor an employee, reviewer quality control and patrol operations. An English version is linked from the top of that page, and README_EN.md is present at the repository root, so the tree holds both.

What matters for anyone reading the details is where each half is authoritative. The architecture, role, task hierarchy and state machine explanations live in the Chinese page, and the paths and commands quoted here come from that text. The file names, the tree and the configuration are language independent: app/, config.example.yaml, docker-compose.yml, setup.sh, start.sh, stop.sh, the skills and prompts directories and the rules directory all read the same either way. The top-level layout also carries a .agents/ directory, which the Chinese page does not explain.

Editorial conclusion

Judge this as middleware rather than as an agent framework. OpenMOSS supplies the queue, the role prompts, the review loop and the leaderboard, while every capability an agent actually has arrives through a Skill, which means the honest evaluation starts with the skills directory and not with the four role descriptions. Two things to settle before running it: give it its own desktop-class machine and a hard quota ceiling, because each agent is a separate model instance woken on a schedule and the page itself warns that multi-agent runs multiply consumption. The second is where the code lives. The dashboard source is on an orphan branch and the container pulls its own UI from a release at startup, so a fork that changes the frontend is not a one-directory edit.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. uluckyXH/OpenMOSS on GitHub