tinyhumansai/openhuman

OpenHuman 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 | 🇵🇰 اردو 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 Trees on TinyCortex, mirrored as an Obsidian vault on your machine, is the default and stays fully local. Settings > Memory Engine switches a live install, with no restart, to CortexDB hosted by TinyHumans (billed in credits, signed in with your account), or to Supermemory, Mem0, Cognee, CortexDB or AgentMemory with your own endpoint and key, and can copy your existing memories across. Remote engines need the memory-remote gate, which the shipped product includes. 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 automation graphs, built on the open-source tinyflows engine. The catalog has 22 node kinds (agent calls, HTTP requests, code, conditions, loops, sub-workflows, approvals, and more), and a graph can trigger on a schedule, an app event, or manually, and can resume 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. Desktop, browser, and terminal 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 ). A Rust library openhuman-embed is the typed facade for embedding the core directly in another Rust process: one Runtime per process, then any number of independent Agent s on it, each with its own provider, access tier, working directory, MCP servers, skills, prompt, and sandbox. This is the exact code from crates/openhuman-embed/README.md : use openhuman_embed :: { Access , AgentSpec , McpServer , Provider , Runtime , Workspace } ; let runtime = Runtime :: builder ( ) . 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 .