1,313 packages support an unusually broad desktop agent
Our pnpm install pulled 1,313 packages and occupied 897 MB, which fits the size of OpenHuman's promise. This is a desktop assistant, local memory system, visual workflow builder, research tool, messaging bridge, and agent coordinator. The Rust and TypeScript monorepo contains 5,117 files and about 1,332,302 lines of source. That breadth may appeal to someone who wants one personal AI application. It also means every connected account, model route, browser action, and stored memory adds another behavior to understand.
The most distinctive feature is the memory design. OpenHuman says it stores compressed, scored Markdown trees in local SQLite and mirrors them to an Obsidian vault that the user can inspect and edit. Connected sources can refresh on a 20-minute loop. This is more tangible than a hidden remote chat history, but it makes data ingestion a central trust decision. An inbox, calendar, document store, or chat account can reveal far more than an isolated prompt, even when the resulting index stays on the machine.
What happened when we ran it
In our 3 CPU, 8 GB sandbox, pnpm installation succeeded in 54 seconds. It added 1,313 packages and used 897 MB. The build completed successfully in 55 seconds. The measured checkout had 19 CI workflow files, a Dockerfile, a Compose file, a tests directory, and monorepo workspaces. Those are solid build signals for a large source tree, though they do not establish whether the desktop app can connect an account or complete an agent workflow.
The tests did not finish within our 900-second cap. The tail shows several UI files passing, including 6 tests for LoadingState, 6 for UserTurnBody, 3 for FeedbackVoteControl, and 4 for AgentEditorToolsPicker. Repeated mock servers reported listening on 127.0.0.1:5005. The log then reached OrchestrationRedirect.test.tsx and ended without a final summary. We cannot state a passed, failed, or total test count, and the tail does not identify why the run remained active.
Local memory still needs a threat model
OpenHuman documents encrypted on-device data, OS keyring storage, approval gates, optional sandboxing, and a Privacy Mode intended to prevent inference from leaving the machine. Those are relevant controls for an assistant that can ingest mail and documents. Privacy Mode can route work to a local Ollama model, while normal use may involve the project's subscription, user-supplied provider keys, managed search, or OAuth integrations. Users should map each feature to its network destination instead of treating the word local as a complete answer.
An open config permission report gives one concrete reason for review. On August 20, 2026, pre-production logs showed config.toml created with mode 644, briefly readable by other local users, before startup changed it to 600. The issue says the file may hold API keys and connection identifiers. The automatic correction narrows exposure but does not fix creation. On a shared machine, that is enough reason to wait for the write path to be corrected.
Visual workflows trade typing for operational scope
OpenHuman can propose a workflow as a graph, show it on a canvas, and save it after review. Saved workflows can react to schedules, webhooks, or channel events, with approvals around side effects. That is a friendlier model than copying an agent-generated script into cron. The underlying promise is still automation, so a visible graph needs the same care around retries, duplicate actions, revoked credentials, and partial failure as code. A canvas makes the plan inspectable; it does not make the action harmless.
The orchestrator adds checkpointed agent graphs, worker fleets, run journals, and communication with other agents. Messaging support covers 17 channels according to the README, and the integration catalog claims more than 100 OAuth sources plus MCP and skill directories. Those figures describe advertised reach, not our lab verification. Our 900-second run never produced a final test summary, and we did not connect any external account. Trial one workflow with one low-risk integration before enabling recurring sync across a personal stack.
Source contribution requires two full toolchains
The packaged installer is the sensible first look, while contributors face a specific build list: Node 24 or newer, pnpm 10.10.0, Rust 1.93.0, CMake, Ninja, ripgrep, desktop prerequisites, and recursive git submodules. Web-only UI work can avoid some desktop compilation, but the complete app crosses JavaScript, Rust, and platform-native boundaries. Our 55-second build succeeded in the prepared lab image; a fresh workstation still needs the README's platform packages and submodule setup.
GPL-3.0 also shapes reuse. Individuals can inspect, modify, and run the code, while a company distributing a modified application needs to review the license obligations with its counsel. The latest v0.63.12 release, published August 7, contained only a version bump and release housekeeping. GitHub showed 37,755 stars, 302 open issues and pull requests combined, and a last push on August 25, so development is active even though the latest tag says little about feature stability.
Early beta is the correct buying label
The README itself calls OpenHuman early beta and tells users to expect rough edges. That is more useful than its claims about personal superintelligence. A 1,332,302-line application with a successful build can still have unfinished integration, permission, and shutdown behavior, as the 900-second test cap and open config issue demonstrate. New users should create a separate OS profile, connect disposable or low-value accounts, inspect the Obsidian and SQLite output, and verify exactly which requests leave the machine.
OpenHuman is worth testing if the combination of editable local memory and visual agent workflows matches how you want to work. OpenClaw is a better fit for an agent centered on existing chats, Hermes for terminal control, and AnythingLLM for a narrower document assistant. Do not hand OpenHuman your primary digital life on day one. Give it 1 bounded source and 1 reversible workflow, then expand only after the stored data, approvals, and network behavior match the documentation.