A general assistant is the obvious thing to want from local AI and the hardest thing to get right. Most assistants assume a cloud account: your voice, your calendar, your half-finished thoughts all travel to someone else’s server so the assistant can answer. OpenJarvis takes the other path. It is built local-first, which means the model that listens and reasons runs on your own machine, and your words do not leave the building unless you choose to send them.
This Playbook is the studio’s working setup notes for OpenJarvis. We are publishing it as we test, so wherever a concrete command or result belongs, you will see a bracketed marker like [CONFIRM]. Those are the spots we are still pinning down on real hardware. The shape of the setup is here; the exact numbers land when we have run them ourselves.
What OpenJarvis is, in plain terms
An assistant is a loop: it takes an input, decides what to do, optionally uses a tool, and reports back. “Local-first” means each of those steps can run on your machine. The model that interprets your request is a local model. The decision loop runs locally. Any tools it calls are ones you have wired up on purpose. The cloud is opt-in, not the default.
That is the whole pitch, and it is a real one. The trade is the usual local-AI trade: you give up the very top end of cloud model quality and you gain privacy, no monthly bill, and an assistant that keeps working on a plane or during an outage.
[CONFIRM: OpenJarvis homepage and repository URL]
[CONFIRM: what OpenJarvis is actually built on – is it a standalone app, a framework, or a wrapper around a local engine like Ollama]
Before you start
The honest prerequisites for any local-first assistant look like the rest of a local stack:
- One machine with at least 16GB of RAM. An assistant that listens and reasons wants headroom, so more is better. Apple Silicon is a comfortable fit because the model and the work share one memory pool.
- A local model engine already running, so the assistant has a model to talk to. If you have followed our local-stack Playbook you already have one serving on
http://localhost:11434.
[CONFIRM: exact RAM and disk requirements for OpenJarvis specifically]
[CONFIRM: whether OpenJarvis bundles its own model runtime or expects an existing one like Ollama]
[CONFIRM: supported platforms – macOS, Windows, Linux]
Step 1: Install OpenJarvis
The install path depends on how the project ships. We will fill in the exact command once we have run it cleanly on a studio machine.
[CONFIRM: exact install command for OpenJarvis]
[CONFIRM: whether install is a desktop app download, a package manager command, or a clone-and-run from the repo]
Step 2: Point it at a local model
A local-first assistant is only as private as its model. The setup that keeps everything on your machine is to point OpenJarvis at a model served locally rather than at a cloud API key.
- Make sure your local engine is running and a model is pulled. Confirm with
ollama listif you are using Ollama. - In OpenJarvis, open the model or provider settings.
- Choose the local provider and confirm the address matches where your engine listens (Ollama defaults to
http://localhost:11434). - Select the model you want the assistant to use.
[CONFIRM: exact location of the model/provider setting in OpenJarvis]
[CONFIRM: which models OpenJarvis supports, and which the studio recommends for the assistant role]
Step 3: Configure what it can do
An assistant that only chats is a chat app. The value is in the tools it can reach: reading a file, checking a calendar, running a command you approve. This is also where local-first matters most, because every tool you grant is a door, and you want to know exactly which doors are open.
[CONFIRM: how tools/skills/integrations are configured in OpenJarvis]
[CONFIRM: which integrations ship by default, and whether each action asks for permission before it runs]
Our standing rule for any agent applies here: turn on the smallest set of tools that does the job, and prefer ones that ask before they act.
Prove it works
The test that proves “local-first” is the same one we use across the stack: turn the Wi-Fi off and see if it still answers.
- Disconnect from the network.
- Give OpenJarvis a plain request that needs the model but no internet, for example summarizing a local file or answering a general question.
- Confirm it responds, and watch that nothing tries to reach out.
[CONFIRM: a specific first request that exercises OpenJarvis end to end]
[CONFIRM: observed behavior offline – does it answer fully, or do some features need a connection]
If it answers with the network off, the model and the loop are genuinely running on your machine.
Trade-offs and gotchas
- The model is the ceiling. A local-first assistant is only as sharp as the local model behind it. For everyday requests a good local model is enough; the hardest reasoning is still where big cloud models lead. You can route one task to a cloud model when it is worth it, then come back.
- Local-first is not always local-only. Some assistant features (web search, certain integrations) reach out by design. Know which ones, so “local-first” stays an accurate description of your setup and not a slogan.
- Tools are doors. Every integration you enable widens what the assistant can touch. Grant the few you need.
[CONFIRM: specific gotchas the studio hits during real setup – first-run quirks, model-loading delays, permission prompts]
[CONFIRM: how OpenJarvis compares to other local assistant options, and where it fits among agent frameworks]
Where to go next
Once the assistant answers reliably against a local model, the natural next moves are the same ones that make any local tool more useful: give it access to your own notes through a documents tool on the same model endpoint, and wire in the one or two integrations you actually reach for daily. Each addition reuses the model you already have.
We will update this Playbook with the confirmed commands, supported models, and offline results as soon as we have run OpenJarvis end to end in the studio. For now, treat it as the map: a local-first assistant is a model on your machine, a decision loop on your machine, and a short list of tools you opened on purpose. Curious about these things. You should be too.
Harness your curiosity.
— Stridenote · № 010