# OpenHuman: a down-only dependency ratchet, and an app crate kept out of the workspace

> A GPL-3.0 agent harness written in Rust with one core running a desktop app, a browser UI, a terminal client, and an embeddable library, with every LLM, memory, embedding, and search engine selected by config. The measurements are published with their methodology, and the structural choices that come with them, a locked-out desktop crate and duplicated patch tables, are documented in the build files rather than the README.

**tinyhumansai/openhuman** — Your Personal AI super intelligence. A brain that builds a local-first memory of your life, a fantastic orchestrator of agent fleets and workflows, and a deep researcher.

- Repository: https://github.com/tinyhumansai/openhuman
- Website: https://tinyhumans.ai/openhuman
- Stars: 40,214 · Forks: 3,974
- Language: Rust
- License: GPL-3.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/tinyhumansai-openhuman

## Early beta sits directly above a trending claim, and the tags agree

Two lines at the top of the page sit next to each other and point in opposite directions. The first is a status line reading Early Beta, under active development, expect rough edges. The second claims that within one week of launch the project was the number one trending repository on GitHub for nine days in a row. Neither cancels the other, but the release list resolves the tension in favour of the first. Three releases landed inside five days, v0.64.3 on 2026-09-25, v0.64.4 on 2026-09-26, and v0.64.7 on 2026-09-29, and the workspace version in the build manifest matches the newest tag exactly. A jump from .4 to .7 in three days is a project in motion. The practical consequence is that a version number here does not denote a stable surface, and pinning is worth doing precisely so that a routine upgrade is a decision rather than a surprise.

## The desktop app crate is excluded from the workspace, so patch tables must be mirrored

The workspace manifest carries a comment that explains more about this project than the README does. `crates/openhuman-app` is deliberately excluded from the members list, along with `vendor`, `worktrees`, `app/src-tauri-mobile`, and `packages/tauri-plugin-ptt`. The stated reason is that the app is its own Cargo world with its own lockfile and target directory, so that root-only Cargo commands do not resolve GTK, WebKit, or Tauri. There is a second sentence with a sharper edge in it. The app must mirror the root file's patch tables rather than inherit them, and another comment explains why, that patches are workspace-root settings and Cargo ignores them in member manifests. So every version override applied at the root has to be duplicated by hand in the excluded crate, and nothing enforces that the copies stay equal. If you are debugging a dependency version that resolves correctly in the core and incorrectly in the desktop app, this exclusion is the first place to look.

## The container drops all capabilities and then adds exactly three back

The compose file is unusually explicit about its own security posture, and the comments argue for the configuration rather than just asserting it. The service sets `read_only: true`, `no-new-privileges:true`, and `cap_drop: ALL`, with a tmpfs mounted at `/tmp`. Then it adds back three capabilities, `CHOWN`, `SETUID`, and `SETGID`, and a comment explains exactly why. The entrypoint starts as root so it can repair the ownership of a volume that Docker created as root, then drops to the `openhuman` user through gosu. Both steps need capabilities that dropping everything removes, and without the setuid pair the container crash-loops before the core ever starts. The comment closes by noting that deny-by-default is preserved because those three are the entire grant. It also names the alternative, pinning `user: "10001:10001"`, which makes the entrypoint exec the binary directly and skip the heal, at the cost of no longer being able to repair a root-owned volume. That is a real trade-off, stated by the project, and which side you land on depends on who creates the volume.

## The headless image still installs audio and X11 headers for crates that are off at runtime

The container runs a headless core, and the build stage still installs a long list of audio and input development headers, including ALSA, libxdo, libxtst, libx11, and libevdev. The comment in the build file gives the reason plainly: `cpal`, `enigo`, `arboard`, and `rdev` are unconditional dependencies of the core crate, used by the voice, autocomplete, and clipboard subsystems, and they link against system libraries even when the corresponding features are disabled at runtime. So headless describes the running process, not the build, and a binary built for a server with no audio hardware still carries its build-time native requirements. There is a second default worth knowing about. The build takes a `CARGO_PROFILE` argument defaulting to `ci`, chosen because Docker builds often run on small VPS and CI builders where the `ci` profile keeps peak rustc memory lower than `release`, with the note that you should override it with `--build-arg CARGO_PROFILE=release` when maximum runtime optimization matters. The out-of-the-box container is therefore tuned for build memory, not for speed.

## Memory starts local, and a no-restart switch can move it to a metered account

The default memory story is the strongest part of the project. Memory Trees run on TinyCortex and are mirrored as an Obsidian vault on your own machine, and the README states that this default stays fully local. From there the shape changes. Settings, then Memory Engine, switches a live install with no restart to CortexDB hosted by TinyHumans, which is billed in credits and signed in with your account, or to Supermemory, Mem0, Cognee, CortexDB, or AgentMemory using your own endpoint and key. It can also copy your existing memories across, and remote engines require the `memory-remote` gate, which the shipped product includes. Read those two features together. A control that relocates a personal memory store with no restart and no rebuild is convenient, and the local-first guarantee only survives it if the copy-across option is used. Otherwise the authoritative copy is the one on your machine, and the hosted engine becomes the one you are querying without a backup you have verified.

## The 25 times denser figure is measured against one process per agent

The architecture is the source of the headline number. The core runs in-process, not as a separate daemon that the UI talks to over a socket. A fleet sweep of 50, 100, and 500 live agents in one process measured a marginal cost of 1,985, 1,866, and 1,770 KiB per additional agent, settling at 223 MiB, 356 MiB, and 1,393 MiB total. The comparison is 500 separate processes for the same workload, which costs about 48 MiB per instance, making the shared process roughly 25 times denser. Two things follow. The comparison is against a specific alternative architecture rather than against file transfer in general, so it tells you what you gain by choosing in-process over one-process-per-agent and nothing beyond that. And the 1,393 MiB figure at 500 agents is the one to plan against, since memory grows close to linearly even as the marginal cost falls. The page is also careful about its own ceiling, saying that thousands of agents on one box is the direction this is heading and not a number that has been hit.

## Contributors build against nine gates, and the product ships a wider set

Modularity is controlled by Cargo feature gates, and the gate list you build against is not the gate list users get. The contributor default is nine gates: `media`, `skills`, `flows`, `mcp`, `channels`, `http-server`, `scheduler-gate`, `file-logging`, and `modules`. The shipped desktop product turns on a wider set, enumerated in a separate file at `scripts/ci/product-features.txt`. The size spread is the point of the design: dropping everything gives a pure-slim build at 51 MiB stripped, adding back `skills` and `flows`, which is the recommended recipe for embedding, lands at about 60 MiB stripped, and turning on every gate produces a 116 MiB unstripped binary. The consequence for a contributor is that a defect reproducible on a slim build may be absent from the product build and the reverse also holds, so a local test run is evidence about your configuration and not about what ships. There is also a guard, `scripts/kernel-floor.sh`, described as keeping a down-only ratchet on the dependency count, which means the floor can shrink over time but cannot creep back up on its own.

## Conclusion

Use it if you want one Rust process to host a large fleet of agents, want every model and memory backend configurable rather than hardcoded, and are willing to track a project that labels itself early beta and shipped three releases in five days. Do not adopt it expecting a settled API surface, and think carefully before switching Memory Engine away from the local default, since a no-restart move to a hosted store billed in credits relocates the personal data the tool exists to keep. Before you build, read the nine-gate contributor feature set rather than the product's wider one, and if you self-host the container, decide up front whether you want the ownership-healing entrypoint or a pinned non-root user.

## FAQ

### What is OpenHuman AI?

OpenHuman is an open-source agent harness with a Rust core, described as lightweight, modular, and pluggable into whatever LLM, memory, or search engine you already run. One core runs four surfaces: a desktop app, a browser UI, a terminal client, and a Rust library wrapped around it.

### how to install openhuman

Download installers from the project's download page or from the GitHub Releases page. For terminal installs, including Homebrew, a Debian or Ubuntu deb package, the AUR, install scripts, and platform notes, the README directs you to INSTALL.md rather than listing the commands itself.

### Is OpenHuman free to use?

The software is open source under GPL-3.0. Some managed paths are not free, though: CortexDB hosted by TinyHumans is billed in credits and tied to your account, managed web search is included with a subscription, and the managed LLM and Voyage-backed embedding routes are alternatives to bringing your own key.

### is openhuman safe

The self-hosted compose file is hardened: read-only filesystem, no-new-privileges, all capabilities dropped with only CHOWN, SETUID, and SETGID added back for the ownership repair and privilege drop, and a token that is required for any client calling the rpc endpoint. The default memory engine stays local and is mirrored to an Obsidian vault on your machine.

### openhuman vs hermes vs openclaw

The README does not compare OpenHuman with Hermes or OpenClaw. Among the files it points to for evidence are a library benchmarking document, a harness comparison dated 2026-07-22, and a performance page, which is where a comparison would be looked for rather than in the README itself.

## Sources

- [Official documentation](https://tinyhumans.ai/openhuman)
- [Official README](https://github.com/tinyhumansai/openhuman#readme)
- [Project repository](https://github.com/tinyhumansai/openhuman)
- [Release notes](https://github.com/tinyhumansai/openhuman/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tinyhumansai-openhuman