jarvis-ai-assistant: hold a key, speak, and text lands in any Mac app

Push to talk with the Fn key held down

Jarvis is described as a voice-powered AI assistant for Mac, and the interaction model is one line: hold one key, speak, text appears.

The keyboard shortcut table lists three bindings. Fn held starts and stops recording. Fn double-tapped toggles hands-free mode. Escape cancels a recording. That is the entire input vocabulary, and it is the design decision the rest of the project hangs on. Because the trigger is a modifier key rather than a dedicated key, there is no keyboard shortcut conflict to configure and the app can be triggered from any application, which is what makes it a dictation tool rather than a chatbot window.

The output claim is that clean, punctuated text appears anywhere. The README lists the pipeline features: filler words such as um and like are removed automatically, grammar is fixed, the text can be rephrased, turned into bullet points or generated outright, and small actions already work, such as opening YouTube or setting a five minute timer.

The point of that last feature is worth pausing on. A dictation tool that only inserts text is a speech to text converter. A dictation tool that can also set a timer or open a site is an assistant, and that is the difference the project is actually selling. It also explains the Prompt Engineering section, since every behaviour is described as customizable, so you can tweak how Jarvis formats mail, cleans dictation or behaves as an assistant.

The audience is a Mac user who dictates a lot and does not want a subscription for it. The homepage is jarvis.ceo.

Two transcription paths, and the latency difference

The quick setup offers a fork. Go Local is recommended for privacy, and it means enabling a local model in Settings, then Transcription, then Enable Local Model, and choosing either Whisper with the tiny, base or small variants, or Parakeet, described as NVIDIA's 600M parameter model, which the project says runs through Sherpa-ONNX.

Go Cloud is the other path, and it means pasting free Deepgram and Gemini keys. The README notes that Deepgram requests default to mip_opt_out=true, which is the model improvement opt-out flag, and that the Gemini allowance is stated as one million tokens per day free.

The local option is the interesting one and the honest cost is documented. The performance note says running models locally depends heavily on your hardware, that enabled AI post-processing adds roughly one to three seconds of latency on typical M1 and M2 chips, that with AI post-processing disabled the transcription is instant, and that M1, M2 and M3 Max or Ultra chips are nearly instant. The recommendation for speed-critical work is the cloud path, or local Whisper with Gemini Flash, which is described as significantly faster than local LLMs on standard hardware.

So the choice is not privacy against speed in the abstract. It is a specific tradeoff with a specific number attached. If you only need clean text, local transcription with post-processing off is instant. If you want the model to rephrase, bullet point or generate, you are paying one to three seconds on ordinary Apple Silicon, and that cost is what a local LLM buys you in exchange for never sending audio off the machine.

The project claims zero tracking and zero telemetry, and states that no data is collected.

Ollama as the local language model, and the commands to set it up

The Ollama support is the part that makes the local path complete, because it replaces the cloud language model with one on your own machine. The project says Jarvis can run any LLM locally via Ollama, and describes it as fast, private and free.

The setup is three steps. Install Ollama from its site, pull a model, then enable Use Ollama under Settings, AI Models, and select the model from the dropdown, with Jarvis auto-detecting what is available. The commands for the pull step are:

    # LFM2 (optimized for speed)
    ollama pull sam860/LFM2:1.2b

    # Llama 3 (standard)
    ollama pull llama3

The two suggestions reflect the trade. LFM2 at 1.2 billion parameters is described as optimized for speed, and Llama 3 is the standard option. Given the latency figures above, a small model is the pragmatic choice for local post-processing, since a larger one pushes past the one to three second budget the README already warns about.

The roadmap also lists AWS Bedrock support as done, so there are three model paths in total, local through Ollama, cloud through Gemini, and Bedrock, with Deepgram handling cloud transcription.

The auto-detection of installed models is a small quality-of-life detail that matters more than it sounds. Without it, every model change on the Ollama side would mean a trip into the settings, and users routinely pull models on the command line.

Building it from source, and what the build actually involves

The source build is three commands:

git clone https://github.com/akshayaggarwal99/jarvis-ai-assistant.git
cd jarvis-ai-assistant
npm install && npm run build && npm run dev

The requirements are Node.js 18 or newer, macOS 10.13 or newer, and the Xcode command line tools. The macOS floor is older than you would expect, and the Xcode requirement is not optional because there is native code involved: the repository has a binding.gyp file and an include/ directory, and the build script for it is a separate step.

The scripts in package.json show the shape of the build. The build script runs build:native and then webpack, and build:native invokes node scripts/rebuild-native.js, which is the native module rebuild. The dev script runs webpack in watch mode and then starts Electron once dist/main.js exists, using concurrently and wait-on to sequence it. There is also a server script that runs the TypeScript server entry point with tsx, and a start script that is just electron ., which is how you run the built app.

The packaging scripts are the most numerous part of the list, and they are a good map of the release engineering. build:mac produces an unpacked directory, build:dmg produces a DMG for both x64 and arm64, and there are per-architecture variants plus a build:dmg:custom path that runs a shell script to create the disk image. There is a separate build:signed family that runs scripts/notarization/build-sign-notarize.sh for both architectures and a notarize script for the quick path, which is what produces the signed and notarized builds the download table points to.

The dev-app-update.yml file at the root is the electron-updater configuration, and the release notes mention auto-update as part of the 1.3.9 fixes.

The iOS build exists, the Windows build does not

The download table lists three platforms. Mac on Apple Silicon gets a DMG for M1, M2, M3 and M4. Mac on Intel gets an x64 DMG. And iOS, for iPhone and iPad, is available through TestFlight, with the ios/README.md in the repository as the entry point.

The build is signed and notarized by Apple, which the README points out as the reason you do not get the scary warnings on first launch. Given that the app requests microphone access and is distributed outside the Mac App Store, notarization is the difference between a build a user can trust and one they have to work around.

The roadmap is honest about what is not there. Windows version is unchecked. Clipboard magic and multi-step actions are unchecked. Streaming transcription, real-time words as you speak, is unchecked. Everything else on the list is checked, including proper local-only onboarding with no fake keys needed, custom voice commands and prompts, and NVIDIA Parakeet support through Sherpa-ONNX.

Two of those unchecked items are worth understanding before you commit. The Windows gap means the project is Mac-only today, which is fine for a personal tool but rules it out for a team with mixed laptops. The streaming gap means you speak a sentence and then get the text, rather than watching it appear as you talk, which is a real difference in feel for anyone used to a live caption.

The releases tell a similar story. The tagged versions are v1.3.11, described as local SenseVoice transcription, v1.3.10, the Jarvis 2.0 beta upgrade offer, and v1.3.9, auto-update and onboarding fixes, all in late May and early June of 2026.

A single maintainer, and what that means for the project

The project states its own origin plainly. Wispr Flow raised 81 million dollars to build a voice dictation app, the author got annoyed, spent three months of late nights building his own version, and open-sourced it. No funding, no team, one developer who hates subscriptions.

That framing also tells you what to expect from the codebase. The repository is a single Electron app: src/ and packages/ for source, public/ for static assets, assets/ for images, scripts/ for build and notarisation helpers, tests/ and jest.config.js for testing, webpack.config.js and tailwind.config.js for the frontend build, and a tsconfig.json alongside the TypeScript sources.

The project is MIT licensed, which is the permissive choice and means a company can take it, modify it and ship it, provided the copyright and licence notice is kept in the derived work.

The comparison table in the README is worth reading as a statement of intent rather than a fact sheet, because it compares Jarvis against a competitor described only as the 700 million dollar one, with columns for price, offline support, open source status, telemetry and who built it. The row for telemetry on the competitor is left as question marks. Rows like built by one guy at 2am against VC money are the kind of line that tells you the project's tone.

The maintenance picture is fine but young. The repository is not archived, the last push was on 2026-09-23, and the releases are all 1.3.x from mid-2026, with a Jarvis 2.0 beta referenced in the release names. A single maintainer project with a beta in its name is a project you can rely on for a personal tool and should think twice about for a production dependency.

Editorial conclusion

jarvis-ai-assistant fits a Mac user who wants push-to-talk dictation that works offline, values having the transcription and the language model run on their own hardware, and is willing to configure Whisper, Parakeet or Ollama rather than paste an API key. It is the wrong choice for anyone on Windows, since that version is still an open roadmap item, for anyone who needs shared team transcription workflows, or for a team that needs a vendor to call when a release breaks. Before installing, decide between the local transcription path and the Deepgram plus Gemini cloud path, since the README states the local route costs roughly one to three seconds of extra latency on typical M1 and M2 chips, and read the prompt customisation options before you assume the output format will match your dictation habits.

Frequently asked questions

Official sources

1. akshayaggarwal99/jarvis-ai-assistant on GitHub
2. License: MIT
3. Project website
4. README
5. Releases