An open-source agent harness with a Rust core: lightweight, modular, and pluggable into whatever LLM, memory, or search engine you already run.

Discussions • Discord • Reddit • X/Twitter • Docs • Follow @senamakel (Creator)

🇺🇸 English | 🇸🇦 العربية | 🇨🇳 简体中文 | 🇯🇵 日本語 | 🇰🇷 한국어 | 🇩🇪 Deutsch | 🇹🇷 Türkçe | 🇵🇰 اردو

Early Beta: Under active development. Expect rough edges.

Within one week of launch, OpenHuman became the number one trending repository on GitHub for nine days in a row.

Download installers from tinyhumans.ai/openhuman or from the GitHub Releases page.

For terminal installs (Homebrew, Debian/Ubuntu .deb, AUR, install scripts, and platform notes), see INSTALL.md.

OpenHuman is a Rust core with a desktop app, a browser UI, a terminal client, and a Rust library wrapped around it. The same core runs all four. Every section below links to the deeper writeup in the docs.

The core runs in-process, not as a separate daemon 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 same workload run as 500 separate processes instead of 500 agents in one costs about 48 MiB per instance, so sharing one process is roughly 25 times denser. Thousands of agents on one box is the direction this is heading, not a number we've hit yet.

A cold agent turn takes 102 ms; the full nine-phase bootstrap (config load, registry init, agent build, memory construction, first turn) takes 476 ms. A slim build settles at about 42 MiB RSS, of which roughly 15.2 MiB is private heap and the rest is paged-in executable text and allocator overhead. Token compression (tinyjuice) also cuts what actually reaches the model, so a large context costs less than its raw size suggests.

Full methodology and numbers: docs/library-benchmarking.md, docs/harness-comparison-2026-07-22.md, and performance. Task-level results against other harnesses live in their own repository, tinyhumansai/openhuman-benchmarks, published at tinyhumansai.github.io/openhuman-benchmarks.

Cargo feature gates control what compiles in. The contributor default is nine gates (media, skills, flows, mcp, channels, http-server, scheduler-gate, file-logging, modules); the shipped desktop product turns on sixteen, listed in scripts/ci/product-features.txt. Dropping everything gets a pure-slim build at 51 MiB stripped; adding back skills and flows, the recommended recipe for embedding, lands at about 60 MiB stripped; turning on every gate produces a 116 MiB unstripped binary. scripts/kernel-floor.sh keeps a down-only ratchet on the dependency count so the floor doesn't creep back up.

Past compile time, capability comes from loadable native modules. The compiled registry (crates/openhuman-core/src/modules/registry/) pins fourteen of them: tinycomputer, tinysearch, tinydocs, tinywallet, tinyjuice, tinyvoice, tinyruntime and its Node and Python providers, tinymcp, tinyconnectors, tinybox, tinychannels and tinyhosts. Each has a small *-bus contract crate that defines its interface and wire types, and each is pinned to a published release by SHA-256 across eleven platform builds. Loading is lazy, so a user who never asks for a document never pays for the download, the dlopen or the resident cost of the document writer. See docs/library-minimal-recipe.md for the measured trade-offs of each gate.

Every engine OpenHuman calls out to is chosen by config, not hardcoded:

• LLM: the managed TinyHumans route, Ollama, LM Studio, MLX, any local OpenAI-compatible server, Claude Code or the Claude Agent SDK, and 26 bring-your-own-key providers including OpenRouter, OpenAI, Anthropic, Google, Groq, Mistral, DeepSeek, Together, and Fireworks. See local models and BYOK.
• Embeddings: the managed Voyage-backed route, or your own Voyage, OpenAI, Cohere, Ollama, or OpenAI-compatible endpoint.
• Memory: Memory v2 is Recall, Fetch and Store over a pluggable engine: TinyHumans (hosted CortexDB, signed in with your account) or your own CortexDB (endpoint and key). It keeps a shared brain of documents (folders, files, links, GitHub, RSS, connected apps), each agent's conversations and shared learnings, recalls what matters before every turn, and answers questions with citations. With neither engine, memory is off. Everything is switched under Connections > Memory.
• Web search: ten providers behind three capability roles (search, answer, page contents). Exa and Gemini have a managed route included with a subscription; Brave, Querit, Tavily, Seltz, Parallel, TinyFish and Gemini Deep Research are bring-your-own-key; SearXNG needs no key but needs your own instance URL.

Engine details: engines.

Not every decision needs the model to generate text. Jev is a small decision model, run through the TinyHumans System One proxy, that takes a question and a fixed set of options and returns a calibrated probability for each: pick one of these (Choice), score this (Score), or yes/no (Noul). It never writes prose.

The clearest use is tool search. Measured on 2026-09-22, with the 215 tools one orchestrator session registers plus 1,000 Composio actions on the table and 160 test requests, plain BM25 retrieval got the right tool in its top pick 22.5% of the time and made 26 needless tool calls out of 31 tool-less requests. Retrieving the top 20 candidates by embedding and letting Jev choose among them got the right tool 62.0% of the time (66.7% in its top 3) and made 1 needless call, at a p50 of 1.5 seconds against BM25's 28 milliseconds. Letting Jev pick the Composio app family first and then the action within it pushes Composio-only accuracy to 80.3% top-1. It falls back to BM25 automatically when no TinyHumans credential is present. The static catalogue is smaller than that corpus: 198 tool names, machine-checked on every test run against app/src/features/conversations/tools/__fixtures__/coreToolNames.json. An orchestrator session adds the synthesized delegation tools and the signed-in connector dispatchers on top of it.

Jev also drives step-by-step decisions inside the browser tool, where a consequential action (a purchase, a send, a delete) returns NeedsConfirmation instead of executing.

Workflows are saved, typed automation graphs, built on the open-source tinyflows engine. The engine's catalog has 22 node kinds (agent calls, HTTP requests, code, conditions, loops, sub-workflows, approvals, and more) and the canvas palette offers fifteen of them. A graph triggers on a schedule, an app event, or manually, and resumes mid-run after a pause.

The agent proposes the workflow; you review it on a canvas and save it.

The difference from n8n or Zapier: you describe what you want, the agent drafts the graph, and you review and save it rather than wiring nodes by hand.

The same core ships three ways: a Tauri v2 and Wry desktop app for Windows, macOS, and Linux; the identical SPA running in any browser (pnpm dev:app:web); and a ratatui-based terminal client (crates/openhuman-tui).

openhuman-embed is the typed facade for embedding the core directly in another Rust process: one Runtime per process, then any number of independent Agents on it, each with its own provider, access tier, working directory, MCP servers, skills, prompt, and sandbox. A host that wants hosted TinyHumans inference builds the runtime through openhuman-tinyhumans, which installs the backend transport during startup; the plain embed builder suits a host bringing its own providers. This is the exact code from crates/openhuman-embed/README.md:

use openhuman_tinyhumans::{
    embed::{Access, AgentSpec, McpServer, Provider, Workspace},
    RuntimeBuilder,
};

let runtime = RuntimeBuilder::new()
    .workspace(Workspace::dir("/var/lib/my-product/openhuman"))
    .api_key("th_live_…")                     // the only credential in library mode
    .build()
    .await?;

let reviewer = runtime.agent(
    AgentSpec::new("reviewer")
        .system_prompt("You review pull requests and never edit files.")
        .access(Access::readonly())
        .skills_dir("./skills/review")        // copied into this agent's own skills root
        .action_dir("/srv/checkouts/pr-42"),
)?;

let fixer = runtime.agent(
    AgentSpec::new("fixer")
        .provider(Provider::openai_compatible("https://api.example/v1", "sk-…").model("gpt-5"))
        .access(Access::full())
        .mcp(McpServer::stdio("github", "gh-mcp", ["stdio"]))
        .action_dir("/srv/checkouts/pr-42"),
)?;

let review = reviewer.run("Summarise the risks in this change.").await?;
let fix = fixer
    .turn(format!("Address these findings:\n{}", review.reply))
    .send()
    .await?;
println!("{}", fix.reply);

// Continue a conversation with the same agent.
let again = fixer.turn("Now run the tests.").session(&fix.session_id).send().await?;
println!("{}", again.reply);

Details, feature-flag pass-through, and the minimal-footprint recipe: embedding.

A single TinyHumans API key covers managed LLM inference (including access to the OpenRouter model catalogue), web search, embeddings, media generation, integrations, voice, and the Jev ranker. Pass it once, in code (.api_key("th_...")) or as OPENHUMAN_BACKEND_API_KEY for a headless host, and every one of those services is live. Details: the TinyHumans API key.

The badge at the top says early beta, and the checklist for taking it off is a public issue: #6047. Memory end-to-end and reply persistence are checked off. What is left is clean-install sign-in (#6020) and a Windows native-module permission case (#6008); the release-pipeline and Windows path-length blockers have since been closed, though the checklist still shows them open. Beyond that, the work tracked in the open is an agent-to-agent protocol (#3463), pluggable memory adapters alongside the two engines that ship today (#5390), external agent runtimes over a shared ACP transport (#4731), and a managed local model runtime (#6130). None of that is a commitment; it is where the issues are.

OpenHuman is licensed under GPL-3.0.

High-level comparison (products evolve, so verify against each vendor). OpenHuman is built to minimize vendor sprawl, keep workflow knowledge on-device, and give the agent a persistent memory of your data, not only chat.

New contributor? Start with CONTRIBUTING.md for the fork/PR workflow and local validation commands, or use the copy-paste AI-agent prompt in CONTRIBUTING-BEGINNERS.md. The short path is:

1. Install Git, Node.js 24+, pnpm 10.10.0, Rust 1.96.1 (rustfmt + clippy), CMake, Ninja, ripgrep, and the platform desktop build prerequisites.
2. Fork and clone the repo, then run git submodule update --init --recursive before pnpm install so the vendored Rust dependencies under vendor/ (tinyagents, tinyflows, tinychannels, tinymemory, tinycomputer, ...) resolve.
3. Use pnpm dev for web-only UI work, pnpm --filter openhuman-app dev:app (macOS) or pnpm dev:app:win (Windows) for the desktop shell, and focused checks such as pnpm typecheck, pnpm format:check, and cargo check -p openhuman --lib before opening a PR.

The Rust workspace under crates/ has six members:

crates/openhuman-app is the Tauri desktop shell and is excluded from the root workspace, so it builds as a separate Cargo world. See Building the Rust core and AGENTS.md for the full layout.

Deeper docs: Architecture · Getting Set Up · Cloud Deploy.

Star the repo to follow the project and help others find it.

Show some love and end up in the hall of fame. Contributors get free merch and special access to our Discord.