OpenJarvis installs uv, Ollama and a model before jarvis starts

One install command sets up uv, a venv, Ollama and a starter model

The install is one command, and it does more than put files on disk. Each installer handles uv, the Python venv, Ollama, and a starter model, which the docs put at about 3 minutes on broadband. On macOS, Linux, and WSL2 it is a curl pipe:

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

Native Windows gets a different script entirely:

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

A third path skips the scripts: download .exe, .dmg, .deb, .rpm, or .AppImage from the latest release. What none of these finish immediately is the runtime. The Rust extension and larger models keep downloading in the background after jarvis first starts, so a command that answers on minute one does not mean a ready system. jarvis doctor exists to report that status, and it is the first thing to run when a model call stalls. Success and readiness look different early on, and only one of them is visible from the prompt.

The GUI needs Node.js 22 from a source checkout, and the docs split there

The graphical path has stricter prerequisites than the chat path, and the two routes are documented separately. jarvis gui starts the local API server and the frontend, then opens the chat interface in your default browser, and it requires Node.js 22+. That requirement belongs to the source checkout. If you installed a packaged desktop build instead, you took the .exe, .dmg, .deb, .rpm, or .AppImage from the latest release.

The README leaves desktop prerequisites to the installation docs. The plain chat route avoids the question entirely:

jarvis                          # start chatting (default: chat-simple)
jarvis gui                      # start the graphical browser interface
jarvis init --preset <name> --force  # replace config with a starter preset

Python 3.14 is excluded because numpy has no Windows wheel there

The Python ceiling is a wheel problem, not a style choice. The project metadata requires Python >=3.10,<3.14, and a comment in pyproject.toml gives the reason: numpy 2.2.x is pinned transitively through datasets and pandas, it ships no cp314 Windows wheel, and under Python 3.14 uv would build numpy from source with Meson and fail on Windows boxes without a C toolchain. The range was capped to the versions that have prebuilt wheels, which is why the classifiers stop at 3.13.

The cost lands on you in a specific way: on Python 3.14 the package refuses to install at all, and the constraint is not owned by this project but inherited from two other dependencies. On a machine pinned to one interpreter version, this is the first thing to check, before anything about models, skills, or agents.

make test builds the Rust extension first and skips three tagged suites

Local tests are deliberately narrower than the project's real surface. The Makefile says it mirrors the CI workflow so make test matches CI locally, and the test target depends on build:

build:
	uv run maturin develop --manifest-path rust/crates/openjarvis-python/Cargo.toml

test: build
	uv run pytest tests/ -n auto -q --tb=short -m "not live and not cloud and not hub"

Two things follow from those lines. Running the suite requires the Rust extension to be compiled first through maturin, so a green run on a machine without a Rust toolchain is not reachable rather than merely slow. And the marker expression deselects every test tagged live, cloud, or hub, so what passes by default is the offline portion. The documentation points at Docker deployment and cloud engines as separate topics, which is consistent with cloud-dependent behaviour sitting outside the default run.

That is a sensible split for a fast loop and a thin safety net before you ship. What you cannot learn from make test is how anything behaves when it touches a real service, which is exactly where an agent framework tends to break.

Three of eight agents run on a schedule or continuously, and they need accounts

Eight agents come with three execution modes, and the split matters more than the count. Five are on-demand: deep_research, orchestrator, native_react, native_openhands, and simple. One is scheduled, morning_digest, and two are continuous, monitor_operative and operative. The scheduled and continuous agents are the ones that need something outside the chat session, and the morning digest flow shows the shape of it, drawing on email, calendar, health, and news and adding TTS audio. Three presets cover it, named morning-digest-mac, morning-digest-linux, and morning-digest-minimal:

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

One OAuth grant covers Gmail, Calendar, and Tasks instead of three, which is the friendliest detail in that flow. The two continuous agents differ from each other, since monitor_operative is built for long-horizon work with memory, compression, and retrieval, while operative is the persistent autonomous loop with state management, and croniter is a core dependency because the scheduled agent needs a real schedule. What the preset cannot do is run before you connect anything, and --force is what replaces your existing config, so running it costs you the configuration you already had. Read that flag before typing it.

Skills are catalog tools, so sync pulls categories and bench runs five samples

Skills are tools discovered from a catalog and invoked on demand, which means the model decides whether one fires. Installation is by source name:

# 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

Most of that catalog is not written by this project: roughly 150 skills from Hermes Agent, about 13,700 community skills from OpenClaw, or anything in a GitHub repo, with the format following the agentskills.io standard. install takes one entry while sync takes a source and a category, so a category sync brings code you did not select into reach of every agent in the session. The project cannot vouch for what a community skill contains, and a skill that reads your filesystem or runs a shell command does so because the agent decided to call it, not because you opened it. Two commands state their own limits. optimize works from your trace history, so an empty history gives it nothing to improve from, and bench at --max-samples 5 measures five samples, which is a smoke test rather than a comparison.

posthog and nvidia-ml-py ship as core dependencies, not extras

Energy and cost are treated as measurements here, and that shows up in the dependency list. posthog, an analytics client, and nvidia-ml-py sit in the core dependencies, so usage analytics and GPU metrics arrive with a plain install rather than behind an extra, while inference paths such as inference-mlx are extras of their own. The evaluation framing counts energy, FLOPs, latency, and dollar cost next to accuracy.

The supporting claim comes from the Intelligence Per Watt work: local models already handle 88.7% of single-turn chat and reasoning queries, with efficiency improving 5.3 times from 2023 to 2025. Read the scope of that number before planning around it. Single-turn chat and reasoning queries are not the workload of the agents this project ships. The code-assistant preset gets code execution, file I/O, and shell access, the continuous agents carry state and memory, and deep_research does multi-hop retrieval with citations. A metric covering one turn has not measured the loops, so treat 88.7% as evidence about local models rather than a verdict on this agent stack.

Editorial conclusion

OpenJarvis suits people who want agent workflows running on their own hardware and can accept a Rust extension in the loop. Pass on it if you are locked to Python 3.14, if you want the jarvis gui browser interface without Node.js 22+, or if you cannot accept a large community skill catalog reaching your agents. Before installing, read the platform page for the system you are on, and treat the 88.7% local capability figure as a single-turn result rather than a statement about the agents the project ships.

Frequently asked questions

Official sources

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