Pasting a Google Client ID / Secret never completed OAuth: Drive (and its Google siblings) accepted the credentials, showed no error, opened no browser, and never appeared in Data Sources. Root cause is three coupled defects, all reproduced at the unit level against main with a FastAPI TestClient (no Google creds, network-free): (A/B) POST /connect routed a `client_id:client_secret` pair into the connector's handle_callback, which spawned a daemon thread that popped a browser and ran its own localhost:8789 callback server. That thread fails silently in the bundled desktop context (`except Exception: pass`), so the connector never gained an access_token; /connect returned status "pending" and the UI's 20x2s poll timed out with no error. Fix: in POST /connect, an OAuth `client_id:client_secret` pair now persists the client credentials to every Google credential file and returns an `oauth_required` directive pointing at the in-process server flow, instead of the silent background thread. The Google connectors' handle_callback no longer spawns the browser thread for the pair case — it only persists the creds; the server's /oauth/start -> /oauth/callback owns the consent round-trip. (C) The would-be-correct server flow was itself broken: under `from __future__ import annotations` plus a `Request` import local to the router factory, FastAPI could not resolve the stringized `request: Request` annotation. /oauth/start returned HTTP 422 (request mis-bound as a query param) and /oauth/callback injected None -> AttributeError on `request.base_url`. Fix: import `Request` at module scope and make the callback's `request` a required injected dependency. A malformed/blank client pair now raises HTTP 400 with the provider setup URL instead of a perpetual silent "pending" (REVIEW.md silent-failure discipline). Frontend: DataSourcesPage now opens the server OAuth window when /connect returns `oauth_required`, then polls until connected; connect errors surface the backend detail; the Drive setup steps document the "Web application" OAuth client + server-callback redirect URI the in-process flow requires. Tests (run on the main venv, hermetic — no ~/.openjarvis pollution): - test_oauth_flow.py: the three handle_callback tests now assert NO browser is opened and only client creds are persisted (was: assert background flow ran). - test_connectors_router_oauth.py (new): reproduces + fixes all three defects via TestClient with mocked token exchange; parametrized over gdrive/gcalendar/ gcontacts/gmail/google_tasks to prove the shared OAuth path is fixed for every sibling and that a single consent writes the access_token to all six Google credential files and flips is_connected() to True. Full tests/connectors suite: 355 passed. Relationship to PR #510: #510 rewrites all of these files (account-scoped retrieval) but still carries all three defects. This fix is intentionally scoped to the OAuth path and does not modify oauth.py, to minimize collision. A maintainer can either merge this and rebase #510 on top, or port these changes into #510. See PR body for details. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Why OpenJarvis?
Personal AI agents are exploding in popularity, but nearly all of them still route intelligence through cloud APIs. Your "personal" AI continues to depend on someone else's server. At the same time, our Intelligence Per Watt research showed that local language models already handle 88.7% of single-turn chat and reasoning queries, with intelligence efficiency improving 5.3× from 2023 to 2025. The models and hardware are increasingly ready. What has been missing is the software stack to make local-first personal AI practical.
OpenJarvis is that stack. It is a framework for local-first personal AI, built around three core ideas: shared primitives for building on-device agents; evaluations that treat energy, FLOPs, latency, and dollar cost as first-class constraints alongside accuracy; and a learning loop that improves models using local trace data. The goal is simple: make it possible to build personal AI agents that run locally by default, calling the cloud only when truly necessary. OpenJarvis aims to be both a research platform and a production foundation for local AI, in the spirit of PyTorch.
Installation
Pick your platform and run one command. Each installer handles uv, the Python venv, Ollama, and a starter model — about 3 minutes on broadband.
| Platform | One-liner |
|---|---|
| macOS · Linux · WSL2 | curl -fsSL https://open-jarvis.github.io/OpenJarvis/install.sh | bash |
| Native Windows | irm https://open-jarvis.github.io/OpenJarvis/install.ps1 | iex |
| Desktop GUI | Download .exe / .dmg / .deb / .rpm / .AppImage from the latest release |
Then jarvis to start. The Rust extension and larger models continue downloading in the background; jarvis doctor shows status.
Platform-specific notes (WSL2 setup, native-Windows scheduled-task service, desktop prerequisites, manual / contributor install): see the installation docs.
Quick Start
jarvis # start chatting (default: chat-simple)
jarvis init --preset <name> # switch to a starter config
Prefix
jarvis ...withuv run, orsource .venv/bin/activatefirst.
| Preset | What it does |
|---|---|
morning-digest-mac / morning-digest-linux / morning-digest-minimal |
Spoken daily briefing from email, calendar, health, news |
deep-research |
Multi-hop research across indexed docs with citations |
code-assistant |
Agent with code execution, file I/O, and shell access |
scheduled-monitor |
Stateful agent on a schedule with memory |
chat-simple |
Lightweight conversation, no tools |
Example:
jarvis init --preset morning-digest-mac
jarvis connect gdrive # one OAuth covers Gmail / Calendar / Tasks
jarvis digest --fresh # generate and play your first briefing
Per-preset deep dives: morning digest · deep research · code assistant · scheduled monitor · chat simple · or the full quickstart guide.
Skills
Skills teach agents how to better use tools and improve their reasoning. Every skill is a tool — agents discover them from a catalog and invoke them on demand.
# Install skills from public sources
jarvis skill install hermes:arxiv
jarvis skill sync hermes --category research
# Use skills with any agent
jarvis ask "Use the code-explainer skill to explain this Python code: for i in range(5): print(i*2)"
# Optimize skills from your trace history
jarvis optimize skills --policy dspy
# Benchmark the impact
jarvis bench skills --max-samples 5 --seeds 42
Import from Hermes Agent (~150 skills), OpenClaw (~13,700 community skills), or any GitHub repo. Skills follow the agentskills.io open standard.
See the Skills User Guide and Skills Tutorial for details.
Built-in Agents
OpenJarvis ships with eight built-in agents across three execution modes (on-demand, scheduled, continuous):
| Agent | Type | What it does |
|---|---|---|
morning_digest |
Scheduled | Daily briefing from email, calendar, health, news — with TTS audio |
deep_research |
On-demand | Multi-hop research with citations across web and local docs |
monitor_operative |
Continuous | Long-horizon monitoring with memory, compression, and retrieval |
orchestrator |
On-demand | Multi-turn reasoning with automatic tool selection |
native_react |
On-demand | ReAct (Thought-Action-Observation) loop agent |
operative |
Continuous | Persistent autonomous agent with state management |
native_openhands |
On-demand | CodeAct — generates and executes Python code |
simple |
On-demand | Single-turn chat, no tools |
See the User Guide and Tutorials for detailed setup instructions.
Full documentation — including Docker deployment, cloud engines, development setup, and tutorials — at open-jarvis.github.io/OpenJarvis.
Community
- GitHub: github.com/open-jarvis/OpenJarvis
- Discord: discord.gg/CMVBmDQ5Fj
- X / Twitter: @OpenJarvisAI
- Docs: open-jarvis.github.io/OpenJarvis
Contributing
We welcome contributions! See the Contributing Guide for incentives, contribution types, and the PR process.
Quick start for contributors:
git clone https://github.com/open-jarvis/OpenJarvis.git
cd OpenJarvis
uv sync --extra dev
uv run pre-commit install
uv run pytest tests/ -v
Browse the Roadmap for areas where help is needed. Comment "take" on any issue to get auto-assigned.
About
OpenJarvis is part of Intelligence Per Watt, a research initiative studying the intelligence efficiency of AI systems. The project is developed at Hazy Research and the Scaling Intelligence Lab at Stanford SAIL.
Sponsors
Laude Institute • Stanford Marlowe • Google Cloud Platform • Lambda Labs • Ollama • IBM Research • Stanford HAI
Citation
@misc{saadfalcon2026openjarvispersonalaipersonal,
title={OpenJarvis: Personal AI, On Personal Devices},
author={Jon Saad-Falcon and Avanika Narayan and Robby Manihani and Tanvir Bhathal and Herumb Shandilya and Hakki Orhun Akengin and Gabriel Bo and Andrew Park and Matthew Hart and Caia Costello and Chuan Li and Christopher Ré and Azalia Mirhoseini},
year={2026},
eprint={2605.17172},
archivePrefix={arXiv},
primaryClass={cs.LG},
url={https://arxiv.org/abs/2605.17172},
}

