MOMO CODE: a Claude Code fork with a self-evolution loop and a Genesis physics sandbox

What MOMO CODE is, and the specific gap it targets

MOMO CODE is a command-line coding agent written in TypeScript. The README states it is built on opencode and adds what it calls a dual-speed self-evolution system based on a paper it cites as Pioneer Agent. That framing tells you the intended audience: developers who already use a terminal agent and want the agent to accumulate something between sessions, rather than starting each conversation from the same static system prompt. The README describes two loops at different time scales. The fast loop, /evolve, is described as second-level prompt injection through a KEP protocol, where tactics distilled from successful runs are selected with Thompson sampling. The slow loop, /fine-tune, is described as hour-level weight improvement using Monte Carlo Graph Search plus LoRA. Most CLI agents stop at the first loop or skip both. MOMO CODE's pitch is that the agent changes its own behaviour over time. If that is not a feature you want, the rest of the project (provider coverage, a Claude Code migration path, voice input) is available in several other tools, and the self-evolution machinery is just extra surface area.

Two loops, two very different costs

The fast loop writes to disk. On first run the README says momo creates ~/.momo/ containing momo.jsonc, a sessions/ directory, and an experience/ directory with tactics.json and ledger.jsonl. Tactics are the unit of learning: /evolve runs the loop with default settings, and the README's own example for the command is truncated mid-line, so the full flag set for /evolve is not something I can state from this material. What is clear from the file layout is that learning is persisted as JSON plus an append-only ledger, which means you can inspect and, in principle, edit what the agent has learned. The slow loop is a different category of operation. /fine-tune is described as hour-level training with MCGS and LoRA, which implies GPU time and a training run, not a config change. The README does not state hardware requirements, dataset construction, or where the resulting adapter is stored. That omission matters: a weight-update loop with no documented hardware floor is the kind of feature that either works on your machine or does not, and you will not know until you try. Treat /evolve as the loop you will actually use and /fine-tune as an experiment to schedule deliberately.

Installation: a curl script, a source build, and no npm package yet

There are two documented install paths. The recommended one is a shell script: curl -fsSL https://momozi.cc/install | bash. According to the README, the installer clones the repo into ~/.momo/lib/momo-code, runs npm install and npm run build (the README estimates 30 to 60 seconds), writes a wrapper at ~/.momo/bin/momo, and appends that directory to PATH in your ~/.zshrc or ~/.bashrc. You then open a new terminal and check with momo --version, which the README says prints 1.0.0. The manual path clones the repository and builds from packages/opencode: git clone https://github.com/momozi1996/momo-code.git, then cd momo-code/packages/opencode, npm install, npm run build, and node bin/momo --version. Note the directory name: the build target is packages/opencode, which is consistent with the fork claim. Prerequisites are macOS or Linux, with Windows only through WSL, plus Node.js 20.0.0 or later, git and curl. Piping a remote script into bash is a real decision, not a formality. The script clones and builds from GitHub, so the trust boundary is the momozi.cc host serving the script plus the repository contents. If that bothers you, the manual clone path is documented and gives you the same binary.

Configuration surface: env vars, tiers, and inheriting .claude/

Authentication is environment-based. The README shows MOMO_API_KEY as a generic key that works with any provider, and provider-specific variables MOMO_ANTHROPIC_API_KEY and MOMO_OPENAI_API_KEY. A custom provider can be plugged in through MOMO_CUSTOM_* variables, and the README states the chat command uses only the OpenAI-compatible protocol. Provider coverage is listed as 25 or more, naming Deepseek, Zhipu (GLM), Moonshot (Kimi), Claude, GPT-4, Gemini, Doubao, OpenRouter, Groq and Mistral. Model selection happens through tiers rather than model IDs if you want zero-config behaviour: ultra for complex tasks and large context, standard for daily work, lite for quick low-latency tasks. The CLI accepts --model or -m for a model ID or tier, --provider or -p for the provider name, plus --help and --version. One-shot use is momo "prompt"; interactive use is bare momo. The migration story is the part most likely to decide adoption. The README claims Claude Code interop that inherits .claude/ configuration, MCP servers and prompts. That is a concrete claim about file compatibility, and it is the first thing I would test with an existing .claude/ directory before rewriting any workflow around this tool.

The /sim sandbox and the long-running work commands

Beyond code editing, the README lists a set of commands for work that outlives a single session. /agent is described as RLM-style recursive subagents: plan, parallel child processes, synthesis, with depth and budget rails. /graph turns long-horizon tasks into a resumable DAG of subagents, LLM-planned, executed in parallel, with retries and /sim world-agent nodes. /goal, /heartbeat and /daemon combine into persistent goals injected into every session, timed tasks, and a daemon loop the README describes as multi-hour autonomy. The most unusual item is /sim: LLM-driven control of a persistent Genesis physics world, where the agent writes Python into a long-lived namespace and loads skills-as-code from ~/.momo/sim/skills/. That is a robotics and simulation workflow bolted onto a coding agent, and it is the clearest signal that this project is a personal research vehicle rather than a product with a narrow job. It also means the dependency surface is wider than a typical CLI agent: a physics engine, a Python namespace, a skills directory, and whatever /sim needs to start a Genesis world. The README does not document that setup here. Budget rails on /agent and retries on /graph are the right primitives for autonomous loops, but they are also the parts where a bug costs you tokens rather than seconds.

Where it is the wrong tool, and what to use instead

The clearest limitation is distribution. There is no npm package in v1.0; the README says one is coming in v1.1. Every install is a clone plus a local build, and every upgrade means pulling and rebuilding rather than bumping a version. That also means the project has no documented release cadence beyond a single v1.0.0 tag dated 2026-06-16 in the material supplied. The licence is the second problem. The repository carries a NOASSERTION identifier, which is GitHub's marker for a licence file it could not classify. The README has a License section in its table of contents but the supplied text does not include the terms. For a tool that reads your source code and writes to your working tree, and that you might want to run inside a company, an unclassified licence is a blocker to resolve before anything else. Third, platform support is macOS and Linux, with Windows only via WSL. If you want a coding agent that installs from a package registry, upgrades cleanly, and has unambiguous licensing, Claude Code or Aider are the honest comparisons, and the difference is architectural: those tools keep the model's behaviour fixed between sessions and put adaptation in your prompts and config files, whereas MOMO CODE moves adaptation into tactics.json and, optionally, into LoRA weights. If you do not want an agent that changes its own prompt injection based on past runs, the fixed-behaviour model is easier to reason about and easier to audit.

Maintenance cost and the licence question

Running MOMO CODE costs you three things. First, build time and rebuild time: the installer runs npm install and npm run build, so upgrades are source operations, not package operations. Second, state you now own. The ~/.momo/ tree holds momo.jsonc, sessions/, and the experience/ directory with tactics.json and ledger.jsonl. That directory accumulates learned tactics, and nothing in the supplied material describes a pruning, versioning or rollback policy for it. If a distilled tactic degrades output, the README's /refine description is the relevant safety valve: it reviews session trajectories and proposes small, evidence-based improvements to tactics or prompt patches that only take effect after human approval. That approval gate is a good design choice and worth relying on rather than letting /evolve run unattended. Third, uninstall is manual: rm -rf ~/.momo plus a sed line against your shell rc, with separate commands documented for zsh and bash. On licensing, the supplied material gives a NOASSERTION identifier and a License section in the table of contents but no terms, so I cannot tell you what you are permitted to do with the code. That is a factual gap, not a legal opinion. Check the LICENSE file in the repository and the momozi.cc site before using this at work.

Editorial conclusion

Adopt MOMO CODE if you already run a terminal-based coding agent, you are comfortable with a curl-to-bash installer that clones into ~/.momo/lib/momo-code, and you specifically want the /evolve and /sim experiments. Do not adopt it as your team's primary agent if you need a published npm package (the README says npm arrives in v1.1), a clear licence, or Windows support outside WSL. Verify three things first: the licence text behind the NOASSERTION identifier, whether /fine-tune actually runs on your hardware, and whether the /sim Genesis world installs cleanly on your machine. Until the licence is resolved, treat it as a personal-workstation tool, not something to vendor into a product.

Official sources

1. Issues
2. momozi1996/momo-code on GitHub
3. Project website
4. README
5. Releases