OpenJarvis: a local-first stack for personal AI agents

The problem OpenJarvis targets: personal agents that still call someone else's server

Most personal AI agents route their intelligence through cloud APIs. The README states the consequence plainly: your personal AI continues to depend on someone else's server. OpenJarvis is the project's answer to that, a framework for local-first personal AI. The audience is developers who want to build on-device agents, and researchers who care about what those agents cost in energy and dollars rather than only in accuracy.

The README frames the case with the project's own Intelligence Per Watt research: local language models already handle 88.7% of single-turn chat and reasoning queries, and intelligence efficiency improved 5.3x from 2023 to 2025. Those two numbers are the argument for local-first. They are also single-turn numbers, which matters, because the agents that ship with OpenJarvis are not all single-turn. The morning digest, the continuous monitor, and the multi-hop researcher are exactly the workloads where a local model has the least headroom, and the README does not break the 88.7% figure down by agent type. Treat the statistic as a motivation for the stack, not as a promise about every preset.

The stated goal is to be both a research platform and a production foundation, in the spirit of PyTorch. That ambition is visible in the repository layout: there is a rust/ directory for the native extension, a desktop/ directory for the GUI, deploy/, frontend/, configs/, and a tests/ tree, alongside src/. It is not a single script with a model call inside it.

How the stack is put together: primitives, agents, skills, and a Rust extension

The pyproject.toml describes the package as a modular AI assistant backend with composable intelligence primitives. Three ideas run through it: 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 from local trace data.

Agents are the unit you configure. The README lists eight built-in agents across three execution modes. On-demand agents include deep_research, orchestrator, native_react, native_openhands, and simple. Scheduled agents include morning_digest. Continuous agents include monitor_operative and operative. The modes matter more than the names: a scheduled agent wakes on a cron-like trigger, a continuous agent holds state across a long horizon and compresses and retrieves memory, and an on-demand agent runs once per request.

Skills sit beside agents and are the mechanism for teaching tool use. The README says every skill is a tool, that agents discover them from a catalog and invoke them on demand, and that skills follow the agentskills.io open standard. You can import them from Hermes Agent (roughly 150 skills) or OpenClaw (roughly 13,700 community skills) or any GitHub repo. That import path is the most interesting design decision in the project: rather than writing its own skill format and asking the ecosystem to adopt it, OpenJarvis reads an existing specification and pulls in catalogs that were built elsewhere.

The Rust extension is the part worth watching during a first run. The Makefile builds it with maturin against rust/crates/openjarvis-python/Cargo.toml, and the README says the extension and larger models continue downloading in the background after the installer finishes. That is why jarvis doctor exists: it reports status rather than pretending the install is complete the moment the shell prompt returns.

Installing OpenJarvis and running a first preset

The README gives one command per platform, and each installer handles uv, the Python venv, Ollama, and a starter model. The stated time is about three minutes on broadband. On macOS, Linux, or WSL2:

curl -fsSL https://open-jarvis.github.io/OpenJarvis/install.sh | bash

On native Windows, the PowerShell equivalent:

irm https://open-jarvis.github.io/OpenJarvis/install.ps1 | iex

If you prefer a GUI, the README points at .exe, .dmg, .deb, .rpm, and .AppImage files on the latest release page instead. After the installer, the README says to run jarvis to start chatting, and jarvis doctor to see the status of the background downloads. Expect the first session to be slower than later ones, because the Rust extension and the larger models may still be arriving.

To move past the default chat-simple preset, pick a starter config with jarvis init. The morning digest is the most concrete example in the README:

jarvis init --preset morning-digest-mac
jarvis connect gdrive          # one OAuth covers Gmail / Calendar / Tasks
jarvis digest --fresh          # generate and play your first briefing

Note the platform suffix on the preset name: morning-digest-mac, morning-digest-linux, and morning-digest-minimal are three separate presets, so a Linux user copying a macOS command will get an error rather than a silent fallback. The README also warns that you should prefix jarvis commands with uv run, or activate the virtual environment first with source .venv/bin/activate.

Skills install from public sources, and the README shows the pattern:

jarvis skill install hermes:arxiv
jarvis skill sync hermes --category research
jarvis ask "Use the code-explainer skill to explain this Python code: for i in range(5): print(i*2)"

The colon in hermes:arxiv names the source and the skill. There are also two optimization commands, jarvis optimize skills --policy dspy and jarvis bench skills --max-samples 5 --seeds 42, which the README presents as the way to improve skills from your own trace history and then measure whether the change helped. That pairing is the clearest expression of the learning loop the project describes.

Constraints you will hit: Python range, alpha status, and unsupported platforms

The pyproject.toml caps Python at >=3.10,<3.14, and the comment above it explains why: numpy 2.2.x, pinned transitively through datasets and pandas, ships no cp314 Windows wheel, so under Python 3.14 uv would compile numpy from source with Meson and fail on Windows machines without a C toolchain. The classifiers list 3.10 through 3.13. If your environment is on 3.14, the project will not install cleanly on Windows, and that is a deliberate cap rather than an oversight.

The development status classifier is 3 - Alpha. The README describes the framework as aiming to be a production foundation, and both of those things can be true at once, but they set different expectations for what you should build on top of it. An alpha project can change a config key between releases; the CHANGELOG.md at the repository root is where to look before you upgrade.

The README also does not document rollback. There is no stated procedure for undoing a preset switch, reverting a skill optimization, or removing the Ollama models the installer pulled. If you experiment on a machine you care about, plan for that yourself before you start, because the documentation is silent on it.

Native Windows is supported through install.ps1 and a scheduled-task service, and the README points at platform-specific notes for WSL2 setup and desktop prerequisites rather than inlining them. That is a sign the platform differences are real and not cosmetic. The morning-digest preset names alone tell you the project expects you to match a preset to your operating system.

OpenJarvis against Hermes Agent and OpenClaw: importers, not rivals

The obvious comparison is with the two projects OpenJarvis pulls skills from. OpenClaw is described in the README as a source of roughly 13,700 community skills, and Hermes Agent as a source of roughly 150. Both are reachable through jarvis skill install and jarvis skill sync. So the difference in approach is not that OpenJarvis does something the others cannot. It is that OpenJarvis treats those catalogs as upstream content and puts its own weight on the agent runtime: the eight built-in agents, the three execution modes, the energy and cost-aware evaluation, and the trace-driven optimization loop.

That is a real architectural choice with a real cost. If your skills already live in OpenClaw, adopting OpenJarvis does not mean abandoning them, which lowers the switching cost. But it also means the skill catalog is not a differentiator, and the quality of any given skill is set by the project that authored it, not by OpenJarvis. The README says skills follow the agentskills.io open standard, which is what makes the import work at all.

A second comparison point is the desktop application. OpenJarvis ships .exe, .dmg, .deb, .rpm, and .AppImage builds under desktop/, with desktop-v1.0.2 as the most recent release. If you want a local agent with a GUI rather than a Python library you wire into your own code, that is the path, and it is a different product surface from the CLI presets. The README lists the desktop prerequisites separately, so check those before downloading a package.

Where OpenJarvis is the wrong tool: if your workload is genuinely multi-turn and heavy, the 88.7% single-turn figure does not apply, and a cloud engine may be the honest choice. The README itself frames the goal as calling the cloud only when truly necessary, which concedes that some calls are necessary.

Licence and upgrade cost

OpenJarvis is Apache-2.0, declared in both pyproject.toml and the LICENSE file at the repository root, and the classifier is OSI Approved :: Apache Software License. That is a permissive licence with an explicit patent grant, which matters if you are embedding the framework in a product. It is not legal advice; read the LICENSE text yourself, particularly if you redistribute a modified build.

The dependency list is where upgrade cost lives. It includes openai, datasets, ddgs, httpx, python-telegram-bot, croniter, tomlkit, nvidia-ml-py, and posthog, plus optional extras for MLX on macOS, vLLM, and cloud inference. The numpy pin described in the pyproject.toml comment shows how a transitive dependency can force a source build and break an install, so the Python version cap is not the only thing that can bite you on an upgrade.

On maintenance: the repository is not archived, and the last push was on 2026-05-25. The most recent releases, desktop-v1.0.2 and desktop-edge, carry the same date, with v1.0.0 on 2026-05-16. That is the cadence to plan around. The Makefile mirrors the CI workflow so that make test matches what CI runs, which is a useful signal for anyone sending a patch: the command is uv run pytest tests/ -n auto -q --tb=short -m "not live and not cloud and not hub", and it depends on the Rust build target, so a contributor without a working Rust toolchain cannot run the suite.

Editorial conclusion

Adopt OpenJarvis if you want an agent that runs on your own machine and you are comfortable with an alpha-stage Python project: install it, run jarvis doctor, and check that the Rust extension finished downloading before you judge latency. Do not adopt it if you need a stable API surface, a documented rollback path, or a support contract, because the repository does not offer any of those and the last push was on 2026-05-25. Verify first that your Python version falls inside the range the pyproject.toml declares, that the preset you want matches your platform, and that your machine has room for the models the installer pulls.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes