There is a repository on GitHub whose README opens with a claim big enough to make you wince: "Your Personal AI super intelligence." One line later it walks itself back. "OpenHuman is not AGI. But it is a meaningful architectural step closer, with better memory, better orchestration, and better tooling." That act of self-limitation is rarer than it should be, and it is the reason this project deserves a careful read rather than a reflex eye-roll.
The repository is tinyhumansai/openhuman. Measured against the GitHub API on 2026-09-01: 39,264 stars / 3,855 forks, written in Rust, licensed GPL-3.0, created 2026-02-18, last pushed today (2026-09-01), 382 open issues, not archived. It was created by @senamakel. Documentation lives at tinyhumans.gitbook.io/openhuman, the community runs on Discord, Reddit and X, and the README ships a Simplified Chinese translation at docs/README.zh-CN.md.
Two calibration notes before we go further. First, the weekly trending snapshot dated 2026-08-30 places it at rank 20 with 39k stars and 1,298 stars gained that week. That figure is stale; everywhere below, the authoritative number is the API-measured 39,264. Second, the README line claiming OpenHuman "became the number one trending repository on GitHub for nine days in a row" within one week of launch is self-reported, unverified by any third party, and internally odd on its own terms -- nine days does not fit inside one week. Discount it accordingly.
This article is built from first-hand README material plus API measurements, with facts current as of 2026-09-01. It is not a vendor puff piece: three full sections below are about things that should give you pause, and one of them is about the license.
What it actually is: three layers, not three checkboxes
The official description puts three things side by side: a brain that builds a local-first memory of your life, an orchestrator of agent fleets and workflows, and a deep researcher. These are not three feature toggles. They are three interdependent architectural layers -- memory supplies context to orchestration, orchestration supplies execution to research, and what research produces flows back into memory.
Most AI assistants on the market today do one of these three. A chat box does conversation. A coding agent does code. An automation tool does pipelines. OpenHuman's ambition is to close the loop across all three, with all data staying on your own machine.
The brain: memory as a scored Markdown tree
The first layer is memory, and the design deliberately diverges from mainstream RAG. Data is compressed into a scored Markdown tree stored in a local SQLite database and mirrored as an Obsidian vault.
Two details matter here. The first is "scored". Memory is not a flat append-only log; it is organised into a tree structure with importance scores attached, which means retrieval can prune by score and spend a finite context window on the nodes that actually matter. The second is "Markdown tree plus Obsidian mirror". Your memory is not entombed in a vector store that only a program can read. It is plain text you can open in Obsidian, hand-edit, and grep.
Where does the data come from? The project claims 100+ OAuth integrations, 5,000+ MCP servers and 90,000+ Skills. All three figures are self-reported and unverified by any third party -- read them as marketing-scale numbers rather than measured inventory. Ingestion runs through auto-fetch, pulling locally every 20 minutes and feeding the memory layer. That "pull, do not wait to be fed" posture is the deepest structural difference between OpenHuman and plugin-mediated designs.
On top of memory sit Goals and Todos: long-term goals, per-thread goals, and a shared board for each session. The agent therefore knows not only what you have said, but what you are currently chasing.
Finally there is TokenJuice, which compresses tool output before it reaches the model. "Up to 80%" is a self-reported ceiling, not a measured average -- do not build a cost model on it. The direction is right, though: once memory grows past a certain size, a compression layer stops being an optimisation and becomes a precondition for the thing working at all.
The orchestrator: graphs, agent fleets, encrypted handoffs
Orchestration is the second layer and the one with the most signal in it.
Graphs, not loops. This is the single most important sentence in the architecture description. Most agents run on a loop: the model decides the next step, calls a tool, reads the result, decides again, and so on until it stops. A loop is neither interruptible nor resumable -- crash the process and everything is gone, and there is no clean way to inject a human comment mid-flight. OpenHuman runs each turn on checkpointed graphs from the open-source tinyagents project: every step has a checkpoint, so a run can pause for a human, survive a restart, and resume mid-run. Put those three together and long-running task delegation becomes genuinely deliverable rather than aspirational.
Sub-agent fleets. Specialist agents nest three levels deep. An agent that gets stuck collapses into a root-cause report and hands it upward, converting a runaway retry risk into bounded human attention.
Agent-to-agent, encrypted. Separate OpenHuman instances can orchestrate each other over end-to-end encrypted Signal-protocol sessions combined with x402 payments. The README puts it bluntly: "No server ever sees plaintext." Encryption is at Signal-protocol strength and settlement rides on x402, which means cross-instance collaboration gets both communication confidentiality and a payment rail.
A split brain, always on. A fast reflex agent triages inbound traffic while a deep reasoning core delegates complex work to worker fleets, with a subconscious layer guiding both. This is the classic fast/slow split: a cheap fast lane absorbs high-volume trivial requests, and expensive core reasoning engages only when it has to.
Workflows build on the open-source tinyflows project: the agent proposes an automation, you review it on a visual canvas, and then you save it. Workflows are durable, trigger-driven (schedules, webhooks, channel events), and survive restarts -- and critically, all side effects are gated behind approval. That last property is non-negotiable. A system that writes its own workflows without an approval gate has effectively been handed a key it can cut for itself. Every run is also replayable and displays real per-call costs.
On that governance thread, this site's agent credential and permission governance comparison breaks down how different projects handle credential storage, approval gates and least privilege. OpenHuman's combination of approval-first side effects plus OS-keyring secrets fits neatly into that framework.
The deep researcher and doer: search, routing, and seventeen doors
The third layer is execution and reach.
Search is powered by Exa, built in and included with the subscription, so no API key of your own is required. Alongside it sit a scraper, a coder toolset, a real browser, and native voice via in-process Whisper.
Model routing picks an LLM based on the workload. The phrasing is the tell: the subscription is a default, not a lock-in. You can point the system at your own provider key or at a local Ollama instance, and the three modes can be mixed. "Subscription as default rather than lock-in" is one of the most reliable single-sentence tests for whether an AI product respects the user's assets.
For generation, Seedream and SeedEdit produce images, Seedance and Veo produce video. On reach, it supports 17 messaging channels -- Telegram, Discord, Slack, WhatsApp, Signal, iMessage and others -- plus native email via IMAP IDLE and SMTP.
Onboarding: from "wait for it to learn you" to "one sync and you are done"
This is the part OpenHuman most wants to talk about, and it is where the differentiation is sharpest.
The README acknowledges inspiration from Karpathy's LLM Knowledgebase and names two competitors directly: "Hermes learns by watching you work; OpenClaw waits for plugins to ferry context in." It then notes that both approaches take days to weeks before they are useful.
OpenHuman takes a third route. Connect your accounts, auto-fetch pulls locally every 20 minutes, and Memory Trees compress everything into a Karpathy-style Obsidian wiki, so that a single sync yields complete compressed context. Instead of a cold start in which the model slowly observes you, it converts the digital traces you have already produced into a searchable archive. The practical consequence is that cold start shrinks from "days to weeks" to "one sync".
There is also an interoperability path: set memory.backend = "agentmemory" in config.toml to share one persistent store with Claude Code, Cursor, Codex and OpenCode.
Privacy: where Privacy Mode is actually enforced
On privacy, the useful distinction is between a promise and an architectural guarantee.
Four baseline items: on-device encrypted data, an approval gate, OS-keyring secrets (credentials in the operating system keyring rather than a plaintext config file), and opt-in sandboxing. The keyring detail is one that surprisingly few projects get right; the cost is low and it removes the most common class of credential leak.
The real story is Privacy Mode. One toggle and inference does not leave the machine, and the README stresses that this is enforced in the Rust core. That distinction carries weight: a toggle-style privacy promise depends on every call site in every code path behaving itself, whereas enforcement in the core means the outbound path is cut at the bottom of the stack. One caveat, though -- an architectural guarantee is not the same thing as a verified one, and this site has not run packet-level checks. If it matters to you, capture traffic at your own gateway and confirm it yourself.
Pitfall one: Early Beta and 382 open issues
Now the cold water.
The README badge says Early Beta, with the line "Under active development. Expect rough edges." Read that next to 382 open issues and the picture is unambiguous: an unusually broad feature surface with early-stage polish.
Breadth is itself the risk. Seventeen messaging channels, meeting participation, image and video generation, agent fleets, workflows -- each one is an integration surface that has to be maintained forever. The more integration surface you carry, the higher the breakage rate when upstream APIs move. Verdict: run a personal pilot. Do not put this under a production SLA yet.
Pitfall two: the GPL-3.0 problem, the hardest constraint in this piece
This is the section worth remembering.
The API-measured license.spdx_id is GPL-3.0 (the README badge says GNU). That stands in sharp contrast to its two closest comparators: OpenClaw is MIT, and Hermes is MIT. GPL-3.0 is a strong copyleft license. If you incorporate OpenHuman's code into your own product and distribute it, the derivative work generally has to be released under GPL-3.0 as well.
The boundary needs to be stated precisely. Merely running the software does not trigger copyleft; what triggers it is modifying and then distributing. Personal use, internal corporate use, and server-side (SaaS) use where you never distribute a binary generally fall outside its range. Conversely, if you intend to modify the code, package it into your own client product and ship that to customers, you are almost certainly creating a derivative work.
The above is a general summary of licensing norms, not legal advice, and it does not constitute a legal conclusion. Defer to the LICENSE file in the repository and to your own counsel. If your scenario involves distribution, do not skip that step.
Pitfall three: the comparison table is out of date, and three self-reported numbers
The README carries a four-way comparison table across Claude Cowork, OpenClaw, Hermes Agent and OpenHuman, with rows for Open-source, Simple to start, Cost, Memory, Integrations, Auto-fetch, Orchestration, Workflows, Meetings, Messaging channels and Local-only mode.
The table is useful, and it is out of date in exactly the dimensions that matter most.
It marks OpenClaw as Memory: Plugin-reliant, Orchestration: Single loop and Auto-fetch: None. The Open-source row lists OpenClaw as MIT, Hermes as MIT, OpenHuman as GNU, and Claude Cowork as Proprietary. The problem is this: OpenClaw 2.0 shipped on 2026-08-30/31 and just introduced Shared Cloud Sessions (multi-machine, multi-person collaboration and takeover) and Active Memory (background memory consolidation). In other words, the table describes the pre-2.0 OpenClaw. The two verdicts it hands down -- on memory and on orchestration -- are precisely the two things that release set out to fix.
So do not read that table as a statement of current reality. For what OpenClaw 2.0 actually changed, see this site's companion pieces, the OpenClaw 2.0 release writeup and the 2.0 upgrade and migration SOP. OpenHuman bet on local-first compressed memory and graph-based orchestration, while OpenClaw 2.0 bet on shared cloud sessions and background active memory — the two roads diverge head-on on whose memory it is and where it is computed.
Three more numbers need their provenance marked: 90,000+ Skills, 5,000+ MCP servers and 80% token compression, plus that trending claim from earlier. Every one of them is self-reported and unverified by any third party as far as this site can tell; treat all of them as "claimed by the vendor". Integration counts are especially prone to inflation, since the number of entries in a registry and the number of maintained, actually-usable entries routinely differ by an order of magnitude.
Who should use it, and who should not
Use it if you want a local memory archive you can read, edit and grep instead of yet another vector black box; if your tasks need long-horizon delegation with recovery after interruption and a human in the approval loop; if you care about inference never leaving your machine and are willing to pay the configuration cost for an architectural guarantee; or if you already run Claude Code, Cursor, Codex or OpenCode and want them sharing one persistent store.
Skip it if you need an MIT license or plan to fold the code into a closed-source product you distribute -- GPL-3.0 is a wall; if you need a production SLA, which Early Beta plus 382 open issues cannot support; if you have no appetite for local ops work, in which case a hosted product will make you happier; or if all you wanted was a coding co-pilot, in which case this is far too much machine.
One-line verdict: what OpenHuman sells is "memory is yours, orchestration is controllable, inference stays home". What it costs you is Early Beta maturity and a GPL-3.0 obligation. Run both halves of that arithmetic yourself.
Installing it
Two routes. Download an installer from https://tinyhumans.ai/openhuman or from GitHub Releases, or follow INSTALL.md in a terminal, where the README lists Homebrew, a Debian/Ubuntu .deb, AUR and an install script.
A sensible order: get it running on a non-primary machine first, connect one or two read-only accounts, and inspect what auto-fetch and the Memory Tree actually produce before widening permissions.
References
- tinyhumansai/openhuman GitHub repository (39,264 stars / 3,855 forks, Rust, GPL-3.0, created 2026-02-18, last push 2026-09-01, 382 open issues): https://github.com/tinyhumansai/openhuman
- OpenHuman documentation: https://tinyhumans.gitbook.io/openhuman/
- Simplified Chinese README: https://github.com/tinyhumansai/openhuman/blob/main/docs/README.zh-CN.md
- Download page and Releases: https://tinyhumans.ai/openhuman
- Related on this site: OpenClaw 2.0 release writeup | agent credential and permission governance comparison | 2.0 upgrade and migration SOP | OpenClaw resource | Hermes Agent resource
FAQ
Q1: What is the catch with OpenHuman's license? A1: The API reports GPL-3.0 (the README badge says GNU), which is strong copyleft. Running it does not trigger copyleft; modifying and distributing does. Fold the code into a closed-source product and ship it, and the derivative work generally has to be GPL-3.0 as well. Personal use, internal corporate use, and server-side use without binary distribution generally fall outside its range. This is a general summary of licensing norms, not legal advice -- defer to the LICENSE text and to your own counsel.
Q2: Can I trust the four-way comparison table in the README? A2: It is usable but out of date. It labels OpenClaw as plugin-reliant for memory and single-loop for orchestration, yet OpenClaw 2.0 shipped on 2026-08-30/31 with Shared Cloud Sessions and Active Memory, which target exactly those two weaknesses. The table describes the pre-2.0 OpenClaw and should not be read as a snapshot of today. The companion release writeup and migration SOP carry the current picture.
Q3: Are the 90,000+ Skills, 5,000+ MCP servers and 80% token compression figures credible? A3: All are self-reported and unverified by any third party, so treat them as vendor claims. Integration counts inflate especially easily, because registry entries and maintained, actually-usable entries routinely differ by an order of magnitude. The 80% figure is a stated ceiling rather than a measured average, so do not use it as a baseline for cost modelling; capture your own per-call token data instead.
Q4: It says Early Beta. Can I put it in production? A4: Not yet. The README badge says Early Beta with "Expect rough edges", 382 open issues remain unresolved, and the project was created on 2026-02-18 and is still under active development. The feature surface is unusually wide (17 messaging channels, meeting participation, image and video, agent fleets, workflows), and the wider the integration surface, the higher the breakage rate when upstream APIs move. Personal pilots, yes. Production SLAs, no.
Q5: Will it conflict with the Claude Code, Cursor or Codex setup I already use?
A5: No, and it can share memory with them. Set memory.backend = "agentmemory" in config.toml to proxy the Memory backend to the open-source agentmemory project, giving Claude Code, Cursor, Codex and OpenCode one persistent store. The two are complements rather than substitutes: OpenHuman owns cross-session persistent memory and long-horizon orchestration, while your coding agent owns what happens inside the editor.