oh-my-openagent is installed as omo-ai, published as oh-my-opencode, and its memory is a git repo of markdown

The package is omo-ai, and the package named omo belongs to someone else

The command is one line, and the install writes a native binary rather than a JavaScript bundle:

curl -fsSL https://get.omo.dev/install.sh | bash
omo

What that script does is spelled out: it installs the native omo binary for your OS and CPU into ~/.local/bin, checks it against the release checksums, and falls back to GitHub Releases when the mirror is unreachable. On Windows in PowerShell the equivalent is irm https://get.omo.dev/install.ps1 | iex, and passing -s -- beta, or a version such as -s -- 5.1.1, after bash picks another channel.

The package manager route installs the same thing under a name that does not match the repository:

bun add -g omo-ai

The npm equivalent is npm i -g omo-ai. The project is explicit that the package is omo-ai and that the unrelated omo package on npm is someone else's, which is the single most useful warning on the page: the command you type afterwards is omo, so an install typo lands you on a stranger's package with a familiar command name.

omo setup, omo update and omo doctor are three different jobs

Coming from the OpenCode edition or LazyCodex, you run omo setup once. It carries your provider keys, custom providers, MCP servers, skills and model picks across, and omo doctor then shows two things: which task categories your providers can run, and what the old install left behind. The full walkthrough is in docs/guide/migrating-from-opencode.md.

Updating is a separate path. Run the install line again for a binary install, or, if you came from a package manager, omo update. Removing it splits the same way:

rm ~/.local/bin/omo
bun remove -g omo-ai

The npm form is npm uninstall -g omo-ai. Both install methods write the same command, so the practical hazard is having one of each: the binary in ~/.local/bin and the package in a global node_modules directory, with one shadowing the other on your PATH. Nothing in the project detects that for you, and omo doctor reports what a previous install left behind rather than telling you which omo your shell resolves first.

Config is .omo/omo.jsonc, and the closest file wins

Settings live in ~/.omo/omo.jsonc, and a project can add its own .omo/omo.jsonc. The rule is that the closest file wins, and every key is documented in the configuration reference at docs/reference/configuration.md.

That rule is the whole configuration story, and it has a consequence worth being careful about. The file says which one wins but not whether winning means replacing the settings or merging them key by key, so when a project ships its own .omo/omo.jsonc and you also have one in your home directory, the effective value of a key is something you check rather than something you can reason out. The practical exposure is that opening a repository can change how your agent behaves, with no change to your own configuration, and the failure looks like the agent ignoring a setting you know you set.

The repository tree shows the reach. Alongside .omo/ there are .claude/, .codex/, .cursor/, .opencode/ and .agents/, so the project ships configuration for five agent tools, not just its own. A file committed for one of those tools can be read by another, which is worth knowing before you add a key.

The published manifest is oh-my-opencode, with five bin aliases

The identity of this project is spread across four names, and the one in the registry manifest is not the one in the URL. The package.json is named oh-my-opencode at version 5.1.4, with main at ./dist/index.js and type module, while the repository is code-yeongyu/oh-my-openagent and the npm package is omo-ai.

It also publishes five command names, all pointing at the same script:

"bin": {
  "oh-my-opencode": "bin/oh-my-opencode.js",
  "oh-my-openagent": "bin/oh-my-opencode.js",
  "omo-agent-toolkit": "bin/oh-my-opencode.js",
  "lazycodex": "bin/oh-my-opencode.js",
  "lazycodex-ai": "bin/oh-my-opencode.js"
}

The practical effect is on discovery rather than on running it. A dependency audit that looks for oh-my-openagent in the registry finds nothing, an internal allowlist written from the repository name does not match the installed package name, and the manifest declares 34 workspace packages, so what npm installs as one package is a monorepo of focused cores: lsp-core, mcp-client-core, memory-core, isolation-core, telemetry-core, team-core, claude-code-compat-core and the rest.

On licensing the two sources disagree in a way worth resolving yourself. GitHub's license field for the repository reads NOASSERTION, the root carries LICENSE.md, and the Cargo workspace declares license = "MIT" for the desktop crates. This is not legal advice; it is a note that a scanner reading the API field will tell you there is no licence while a reader of the repository finds one.

mass ulw turns one prompt into a graph of agents

The harness runs on senpi, the project's fork of pi, and its main verb is a keyword. Add ultrawork, or ulw, to a prompt and the agent reads the codebase before touching a line, plans, proves each step before moving on, checks the result on the real surface, and stops when it is done. Type mass ulw and the whole job becomes a graph of agents, with each part running on the model that fits it, in parallel, and checked before anything is called done.

The stated design goal is that token spend buys speed, so easy parts go to cheap models. The rest of the machinery follows from that: independent tool calls run together in one small program, so twenty reads are one round trip; malformed tool arguments are repaired before they run; waiting on a build or a deploy is a subscription rather than polling; long work keeps a record of what was checked, so a restarted session picks up where it stopped; and config, skills and prompts reload live.

The gap to weigh is cost control. The documentation describes automatic routing between a frontier model and cheap ones, with /login covering Claude, ChatGPT, Kimi and GLM subscriptions and a system prompt tuned for each, but it does not document a budget, a spend cap or a way to see which model handled which part of a graph run. A graph that fans out across dozens of agents is the case where you would want that number.

Computer use is nine Rust crates, one backend per window system

The only feature with a native layer is computer use, and the docs list it as experimental with its own guide at docs/guide/computer-use.md. Its implementation is a Cargo workspace of nine crates, and the crate names are the interesting part:

members = [
    "crates/senpi-desktop-core",
    "crates/senpi-desktop-safety",
    "crates/senpi-desktop-session",
    "crates/senpi-desktop-backend-fake",
    "crates/senpi-desktop-backend-atspi",
    "crates/senpi-desktop-backend-macos",
    "crates/senpi-desktop-backend-x11",
    "crates/senpi-desktop-backend-wayland",
    "crates/senpi-desktop-backend-win32",
]

One backend per desktop, plus a fake backend that exists for tests and a safety crate alongside the core. Every dependency is pinned with an exact version, image at 0.25.10, xcap at 0.9.6, x11rb at 0.13.2, atspi at 0.30.0 with tokio and zbus, zbus at 5.19.0, windows-sys at 0.61.2, and a comment above them says the pins are copied from another workspace's resolutions. Exact pins across nine platform crates mean a dependency bump is a manual edit in the manifest rather than something a lockfile resolves, and the workspace version is 0.0.0, so the desktop stack is versioned independently of the 5.1.4 package you install.

Kibitzer keeps your memory in a git repository of markdown

The memory system is called Kibitzer, and its design is one sentence: memory lives in a git repository of markdown files. A small, cheap model sits beside the expensive main agent, reads what you have done before, and nudges the main agent before it repeats a mistake.

That choice has good and bad sides, and the good side is concrete. A git repository of markdown is diffable, reviewable and branchable, so you can see what the agent believes about you and correct it in the open instead of wondering why it keeps doing the same thing.

The bad side is that the documentation does not say where that repository lives, whether it is pushed anywhere, or how to keep credentials and customer names out of it. Markdown in git is also not a privacy boundary, and a cheap model reading it is a cheap model reading it on every run. The skill system works the same way in spirit, loading only the skills a task needs, browser use included, so the surface area of what the agent reads is bounded by the task and by what you installed, which is a design you have to audit rather than inherit.

Editorial conclusion

Adopt it if you want a batteries-included harness with a graph mode, model routing and a persistent markdown memory, and you are willing to live with a command that is called omo while the package is called omo-ai and the manifest is called oh-my-opencode. Do not install the package named omo on npm, which belongs to someone else, and do not treat computer use as a settled feature while the docs mark it experimental. Before your first run, read the configuration reference at docs/reference/configuration.md rather than guessing at the jsonc keys, and check which .omo/omo.jsonc is closest to your working directory, because the project file can override the one in your home directory.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes