OmO v5.1.5 turns one prompt into a worker graph
OmO v5.1.5 is a standalone agent built on the project's Senpi fork of Pi. The ultrawork keyword asks it to inspect, plan, execute, and verify a long job. mass ulw goes further by dividing the work into a graph of agents and routing each part to a suitable model. Memory lives in a Git repository of Markdown files, so a later session can recover decisions instead of starting cold.
That convenience sits on a very large codebase. Our measured checkout at commit 47678d0 had 18,051 files, about 1,958,295 lines of source, and occupied 336.1 MB before dependencies. TypeScript dominates, while Rust supplies desktop components and other packages cover prompts, skills, model routing, MCP, telemetry, memory, OpenCode, Codex, and the native runtime. This is closer to an agent operating system than a prompt bundle.
A 476-package source install is different from the binary quick start
The README's preferred path downloads a native binary to ~/.local/bin and verifies it against release checksums. npm and Bun can install the omo-ai package instead. Running useful tasks then requires at least one supported provider login or API credential. The built-in login flow covers services named in the README, while ~/.omo/omo.jsonc controls models, agents, memory, browser behavior, MCP servers, and task limits.
Our repository path was much heavier than that two-command introduction. The 476-package installation used 2,178 MB, and the checkout exposes monorepo workspaces for several harnesses. We counted 21 CI workflow files and found a tests directory, but no Dockerfile. Teams building from source should pin the commit and Bun environment. Teams using the binary should pin a release and keep its checksum verification in the installation path.
What happened when we ran it
Our sandbox installed commit 47678d0 in 148 seconds and built it in 58 seconds. The install brought in 476 packages and left 2,178 MB on disk. We used an unprivileged container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. Both installation and build completed successfully.
The test command did not finish before our 900-second cap. That is a timeout, not a failed assertion and not a pass. The final output still showed successful DAG journal and file-store tests, including subscriber recovery, checkpoint replay, refresh behavior, retention cleanup, and event-log pagination. The run never printed a complete suite count, so reporting one would be fiction.
The last visible retention-cost case passed in 5,136.88 ms, while a checkpoint-recovery case passed in 2,428.79 ms. Those lines show that tests were making progress near the cutoff. They do not identify which remaining files were slow or how much longer completion needed. A team adopting OmO should run the complete command on its own CI machine and retain the final summary before treating the repository as green.
Five default workers can become unlimited workers
OmO's configuration reference sets default task concurrency to 5 and allows separate provider and model limits. A value of 0 means unlimited concurrency. The OpenCode-side task configuration also permits as many as 4,000 tool calls per subagent by default. These controls are useful for throughput, but a model cannot be the sole authority over how much money or wall time it may consume.
Open issue 7497 shows why limits outside the session matter. The reporter's long-running thread held about 535,486 conversation tokens, but system instructions, tool definitions, and attachments pushed the provider request to roughly 1,166,728 tokens against a 1,000,000-token limit. Switching model families revived that thread. This is a user report rather than our measurement, yet it captures a failure mode created by a large, persistent tool surface.
Telemetry records token counts and cost unless disabled
OmO v5.1.5 sends anonymous telemetry by default. The documented fields include application version, operating system, CPU details, provider and built-in model identifiers, prompt-size buckets, token counts, cost, delegated-task activity, feature use, and crashes. The policy says prompts, replies, code, diffs, paths, commands, logs, account names, keys, and screenshots are excluded.
You can disable all telemetry with config or DO_NOT_TRACK=1. Computer use is a separate concern: its tool is registered by default on macOS, Linux, and Windows, but it does not touch the desktop until activated. The feature is marked experimental and can capture screens, inspect accessibility trees, and send mouse or keyboard input. Disable it in configuration if that capability should never appear in a session.
Sustainable Use License 1.0 blocks paid redistribution
The Sustainable Use License 1.0 permits personal work, non-commercial use, and a company's internal business use. Distribution must be free and non-commercial. That is materially narrower than the MIT license used by OpenCode or the Apache-2.0 license used by Cline. A company can use OmO internally, but bundling it into a paid product or managed service needs legal review and possibly separate permission.
GitHub showed 69,680 stars and 1,090 combined issues and pull requests on September 30, 2026. The repository was pushed that day, and v5.1.5 also shipped that day with fixes for standalone binaries, memory recall, and an omitted parser dependency. This is active maintenance at high speed. Open issue 9241, also opened September 30, says the legacy plugin fails under OpenCode 2.0.x, which is another reason to prefer the current standalone path.
OmO earns a trial when one difficult job really benefits from several model specialties and durable memory. Our 900-second timeout says its own full validation cycle is long, and its license says redistribution choices are narrow. Run it in a disposable checkout first, set hard provider budgets, keep concurrency finite, and require a human to approve any production-facing result.