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.

Install

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.

What is OpenHuman?

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.

Lightweight and fast

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.

Modular

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 a wider set 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: tinydocs, tinyvoice, tinyjuice, tinyruntime, tinywallet, tinymcp, tinychannels, and tinyconnectors, each with a small *-bus contract crate that defines its interface and wire types. See docs/library-minimal-recipe.md for the measured trade-offs of each gate.

Pluggable engines

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: managed search included with a subscription, or your own key for Parallel, Brave, Querit, Exa, Tavily, or a self-hosted SearXNG instance.

Engine details: engines.

Jev decides fast

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: with 215 core tools 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.

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

Workflows are saved, typed automati