* fix(onboarding): guard complete_onboarding against premature flag flip (#591) - Remove premature `chat_onboarding_completed = true` flip from `set_onboarding_completed` in config/ops.rs. The flag is now exclusively owned by the welcome agent via `complete_onboarding`. - Strip auto-finalize side-effect from `check_status` action. It is now pure read-only and returns `onboarding_status`, `exchange_count`, and `ready_to_complete` in the snapshot instead of `finalize_action`. - Add engagement guard to `complete` action: rejects with a descriptive error unless exchange_count >= 3 OR ≥1 Composio integration connected. Auth check also enforced before any write. - Add process-global `WELCOME_EXCHANGE_COUNT` (AtomicU32) with `increment_welcome_exchange_count()` / `get_welcome_exchange_count()`. Dispatch layer calls `increment_welcome_exchange_count()` each time a user message routes to the welcome agent. - Update `welcome_proactive.rs` snapshot call to new signature and prompt copy to reflect `onboarding_status: "pending"` / no pre-flip. - Add 7 pure-logic unit tests for `engagement_criteria_met`, plus tests for the new exchange counter and updated snapshot shape. Fixes #591 * style: cargo fmt for complete_onboarding.rs * feat(onboarding): inject CONNECTION_STATE block into welcome-agent turns (#593) Add `build_connection_state_block()` to dispatch.rs: fetches current Composio integration status (with a 3s timeout for graceful degradation) and formats it as a `[CONNECTION_STATE]...[/CONNECTION_STATE]` block. After `resolve_target_agent` selects the welcome agent, the block is appended to the last user message in history so the agent always has up-to-date connection state without spending a tool call. This captures OAuth completions that happened mid-conversation (user clicked auth link in chat, authenticated in browser, came back). Scoped strictly to welcome-agent turns (chat_onboarding_completed=false). Orchestrator turns are unaffected. Fixes #593 Part of #599 * style: cargo fmt for dispatch.rs * feat(welcome): parallel template messages with LLM inference for faster perceived welcome (#592) Show two template messages immediately while the LLM runs in the background, cutting the perceived wait from ~15s to ~0s: - Template 1 (t≈0ms): time-of-day greeting that names any connected channels, built from the status snapshot without extra I/O - Template 2 (t=4s): "Getting everything ready for you..." loading indicator, published via tokio::join! alongside the LLM future - LLM response: published when inference completes, opened directly with personalised setup content (no duplicate greeting) `run_proactive_welcome` now fires three `ProactiveMessageRequested` events rather than one. The two template helpers (`time_of_day_greeting`, `build_template_greeting`) are pure functions covered by 6 new unit tests. `prompt.md` gains a proactive-invocation section explaining that greeting templates are pre-delivered and the agent must skip them. * feat(welcome): add composio_authorize tool and inline auth link guidance (#594) Wire `composio_authorize` into the welcome agent's tool allowlist and teach the prompt how to offer OAuth links directly in chat: - agent.toml: add "composio_authorize" to the named tools list so the welcome agent can call it during multi-turn conversations - prompt.md: new "Offering inline auth links" section covering the consent-first flow (offer → user agrees → call tool → markdown link → confirm success via [CONNECTION_STATE] block on next turn) - prompt.md: toolkit slug reference table for the common services - prompt.md: auth link rules (no speculative calls, no bare URLs, one service at a time, await CONNECTION_STATE before confirming) - prompt.md: two new "What NOT to do" bullets for composio_authorize misuse patterns * feat(welcome): conversational onboarding prompt for issue #595 - Rewrite prompt.md: multi-turn flow, Gmail-first, no silent first turn - Align with check_status/complete and ready_to_complete semantics - Update proactive injection copy to match new tool wording Made-with: Cursor * feat(onboarding): add completion readiness reason Made-with: Cursor * docs(ux): add onboarding and welcome audit for #563 Made-with: Cursor * docs(welcome): clarify OAuth link behavior in onboarding prompt Updated the onboarding prompt to explicitly state that clicking the Gmail connection link opens the user's default browser for authentication. Added guidance to return to the chat after completing the authorization process. * fix(onboarding): resolve CI test and proactive greeting review Made-with: Cursor
OpenHuman
The age of super intelligence is here. OpenHuman is your Personal AI super intelligence. Private, Simple and extremely powerful.
Discord • Reddit • X/Twitter • Docs
"The Tet. What a brilliant machine" — Morgan Freeman as he reminisces about alien superintelligence in the movie Oblivion
Early Beta — Under active development. Expect rough edges.
To install or get started, either download from the website over at tinyhumans.ai/openhuman or run
# For MacOS/Linux
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash
# For Windows
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex
What is OpenHuman?
OpenHuman is an open-source agentic assistant that is designed to integrate with you in your daily life. Here's what makes OpenHuman special:
-
Simple, UI-first — A clean desktop experience and short onboarding paths so you can go from install to a working agent in a few clicks, without a config-first setup. You don't need a terminal to run OpenHuman.
-
One subscription, many providers — You only need one account to get access to many agentic APIs (AI Models, Search, Webhooks/Tunnels and other 3rd party APIs etc..), simplifying the experience to get a powerful agent going.
-
Rich Skills — Plug into Gmail, Slack, Notion, and the rest of your stack via rich, feature-backed skills. Connections are typically one click through setup wizards instead of wiring APIs by hand. Workflow data is kept on device, encrypted locally, and treated as yours: encryption and sensitive context stay on your machine. Webhooks give instant feedback into the agent when external systems or skills emit events, so the loop stays tight without constant polling.
-
Local knowledge base — Built from your data and your activity. How you work across tools, sessions, and connected services—so the agent gets rich, workflow-aware context, not a one-off chat transcript. Everything is stored on your machine and compounding over time without becoming a cloud dossier. Channels, skills and ongoing conversations feed the same loop so day-to-day context does not reset every session.
-
Local AI model — The Rust core exposes local AI paths (and the desktop bundle can ship local/bundled runners where applicable) for the workloads above—vision snippets, speech helpers, summarization, tooling—so sensitive steps can stay off the cloud when you choose.
-
Deep desktop integrations — OpenHuman is a native desktop assistant, not a web-only chat: memory-aware keyboard autocomplete, voice (STT listening and TTS replies), screen intelligence that understands what is on screen and feeds your local context, plus windowing and OS-level permissions—so the agent meets you on the machine, not trapped in a browser tab.
Architecture: docs/ARCHITECTURE.md. Contributor orientation: CONTRIBUTING.md.
OpenHuman vs other agents
High-level comparison (products evolve—verify against each vendor). OpenHuman is built to minimize vendor sprawl, keep workflow knowledge on-device, and ship deep desktop features—not only chat.
| Claude Code/Cowork | OpenClaw | Hermes Agent | OpenHuman | |
|---|---|---|---|---|
| Open-source: Is the codebase open to review? | 🚫 Proprietary client | ✅ MIT License | ✅ MIT License | ✅ GNU License |
| Simple: Is it simple to get started? | ✅ Simple Desktop App + CLI | ⚠️ Terminal first and often complex | ⚠️ Terminal first and often complex | ✅ Simple, Clean UI/UX. Get started within minutes |
| Cost: How expensive is to run? | ⚠️ Subscription + add-on tool/API costs | ⚠️ Tied to models & hosting you choose | ⚠️ Tied to models & hosting you choose | ✅ Cost optimized with the option to run many things locally for free |
| Memory & Knowledge Base (KB): Does the agent know you and your world? | ✅ Built-in memory; mostly chat/session scoped | ⚠️ Has a local memory but often needs plugins for richer behavior | ✅ Self-learning / task loops (typical) | 🚀 Local KB + Self-learning from your activity & data (GMail, Notion etc... via skills) & prompts |
| API spagetti: How complex is it to hook mulitple features together? | 🚫 Claude bill + often extra keys for MCP/tools | 🚫 BYOK / multi-vendor common | 🚫 Multiple providers common | ✅ One account get access to many bundled platform APIs |
| Extensibility: Can you add rich features into it? | ✅ MCP (different model than sandboxed skills) | ✅ Plugin Architecture (SKILL.md) | ✅ Plugin Architecture (SKILL.md) | 🚀 Rich Skills with ability to have realtime updates, local DB & more |
| Desktop integrations: Can it integrate into your desktop completely? | ⚠️ Desktop app & access to folders | ⚠️ Often lighter native surface | ⚠️ Often lighter native surface | ✅ STT, TTS, screen intelligence, memory-aware autocomplete and a whole lot more |
Contributors Hall of Fame
Show some love and end up in the hall of fame
