Mark XXXIX-OR is a local voice assistant that watches your screen and runs commands

A voice front end that also sees the screen and types for you

Mark XXXIX-OR is the latest model in a Jarvis style series by FatihMakes, described as a real-time voice AI that can hear, see, understand and control your computer on any operating system, with Windows, macOS and Linux named as supported. The readme stresses local execution and zero subscriptions.

The capability table lists six things: real-time voice conversation in any language, system control covering app launching, file management and terminal commands, autonomous tasks with planning for multi-step goals, visual awareness through real-time screen processing and webcam vision, persistent memory of projects and preferences, and hybrid input where you can switch between typing and voice.

The one that changes the risk profile is visual awareness combined with system control. A tool that both sees the screen and can type into a terminal is a tool with the permissions of the user who runs it, and the readme is explicit that this is what it does. The permissions of the assistant are the permissions of your account.

The project is also a series. The description frames each iteration as adding features and integrations on the previous one, with Mark XXXIX-OR building on the earlier Mark models, and the readme invites you to support the journey to Mark 100. That framing explains the code layout, which is organised by role rather than as a single application.

The directory layout separates the agent, its actions and its memory

The repository top level is short enough to read in one look: main.py, ui.py, or_client.py, and the directories actions/, agent/, config/, core/ and memory/, alongside setup.py and requirements.txt.

Those names describe the data flow. The agent directory holds the reasoning loop that decides what to do, the actions directory holds the individual capabilities such as web search, the flight finder and desktop control, memory/ holds the persistent store, core/ holds shared machinery, config/ holds settings, ui.py is the interface layer and or_client.py is the OpenRouter client.

The or_client.py file is the clearest signal about the architecture. Rather than one model handling everything, the readme explains that selected action modules route their LLM calls through OpenRouter's free-tier models while Gemini Live continues to handle real-time voice and tool calling. That split has a practical effect: the conversational layer is one model and one API key, and the individual actions are a separate set of calls that can use cheaper or free models.

The claimed benefit of that routing is a higher effective request limit at no additional cost, which is the kind of constraint that shapes how the assistant is used, since every action that goes through OpenRouter consumes part of a shared free allowance.

Quick start: clone, install requirements, install Playwright, run

The quick start is five commands.

git clone https://github.com/FatihMakes/Mark-XXXIX-OR.git
cd Mark-XXXIX-OR
pip install -r requirements.txt
playwright install
python main.py

The Playwright step is separate from pip because Playwright downloads browser binaries of its own, and the screen reading and web interaction parts of the assistant need them.

The setup.py script at the root does the two installation steps for you. It installs the requirements and then the Playwright browsers.

print("Installing requirements...")
subprocess.run([sys.executable, "-m", "pip", "install", "-r", "requirements.txt"], check=True)

print("Installing Playwright browsers...")
subprocess.run([sys.executable, "-m", "playwright", "install"], check=True)

One small inconsistency is worth knowing about. The final line of setup.py prints a message telling you to run the application as MARK XXV, while the project is Mark 39. The project clearly iterates faster than its own helper script.

The readme also warns about the requirements file. Some OS specific dependencies are not bundled to keep the repository lightweight, and a missing module surfaces as a ModuleNotFoundError that you fix by installing the package yourself for your system.

The dependency list shows exactly what it drives

The requirements file is the most honest description of the project, because it lists what the assistant actually touches on your machine.

sounddevice
google-genai
google-generativeai
pillow
requests
beautifulsoup4
duckduckgo-search
pyautogui
pyperclip
opencv-python
numpy
mss

The first group is the model and speech layer, with sounddevice for microphone capture and the two google packages for the Gemini client. The second group is the web layer, with requests, beautifulsoup4 for parsing pages and duckduckgo-search for the search action.

The third group is the reason to read the list carefully. pyautogui drives the mouse and keyboard, pygetwindow enumerates and focuses windows, pyperclip reaches the clipboard, opencv-python with numpy and mss handles screen capture, and playwright drives a real browser. Together they are the mechanism behind the system control and visual awareness features: nothing here is a sandboxed API call, it is direct desktop automation.

The tail of the file is Windows specific, with comtypes, pycaw, win10toast and pywinauto. Those are the pieces that make audio control, toast notifications and UI automation work on Windows, and their presence explains the readme note about missing packages on other systems.

What changed in this iteration, and how the numbers are stated

The readme has a section on what is new in XXXIX-OR, and it is worth reading because it shows the direction of travel.

File handling is the headline addition. Direct file uploads are supported, so PDFs, source code or images can be dropped into the assistant to be analyzed, summarized or edited. The interface was overhauled to be fully resizable and responsive with transparency controls and customisable layouts.

Cross-platform work is the second item, described as major fixes for macOS and Linux compatibility, with core system actions made more consistent across the three operating systems. That is a statement about a specific platform, macOS and Linux, rather than a general claim about the project working everywhere.

Performance is the third, described as a significant boost in the tool-calling logic and response generation, resulting in a 40 percent faster interaction speed. The number is the project's own and the readme does not give the measurement conditions, so it should be read as a claim about the comparison the author made rather than a benchmark you can reproduce.

The fourth item is the OpenRouter integration already described, which is what lets selected action modules use free-tier models and raises the effective request limit without additional cost. The stated division of labour is that Gemini Live keeps handling real-time voice and tool calling.

The licence rules out the commercial use people often want

The licence section is short and it is the most consequential line in the readme. The project is licensed under Creative Commons BY-NC 4.0, and the licence line states personal and non-commercial use only.

For an individual running this on their own laptop, that is a workable arrangement. For a company that wants to ship it, host it for staff, or build on it inside a product, it is not, and the boundary is not a technical one that can be engineered around. No licence identifier appears in the project listing at all, so the file in the repository and the readme are what you have to work from.

That also changes what kind of project this is. It is not infrastructure you depend on. It is a demonstration of an approach, published by a developer who describes the work as building a real-world JARVIS-style assistant and links a setup video, an Instagram account and a YouTube channel alongside the code.

Read in that light, the version numbering and the absence of releases make sense. The readme lists no GitHub releases, the repository is not archived, and the last push was on 2026-05-10. There is no published version to pin and no changelog to consult, so anyone running this is running whatever the main branch holds on the day they clone it.

The alternative is to assemble the same stack yourself

The realistic alternative to this project is not another assistant, it is the same stack built by hand. The requirements file is effectively the shopping list for a voice assistant that sees the screen and drives the desktop: a Gemini client for the model, a microphone library, a screen capture stack, a browser automation library, an automation library for the mouse and keyboard, and a search library for the web action.

The difference in approach is what the repository adds on top of that list. Mark XXXIX-OR supplies the orchestration. The agent directory decides what to do, the actions directory packages the individual capabilities, memory holds the persistent context, and ui.py is an interface you can resize and make transparent. OpenRouter routing is configured for you, so the action modules use free-tier models while voice stays on Gemini Live.

Building that yourself is a weekend project per feature, and the readme's own framing, a series where each iteration adds integrations to the previous model, suggests the author agrees.

Two constraints on that plan are worth stating. The first is that the pieces are not free to run. You need a free Gemini API key and a free OpenRouter API key, and the free tier limits are what the routing is working around, so usage patterns have to fit inside them.

The second is the one the licence creates. Anything you assemble yourself from the same public libraries carries none of the non-commercial restriction, which is the practical reason to build rather than copy if the goal is anything commercial.

Editorial conclusion

Mark XXXIX-OR suits an individual on a desktop who wants a spoken interface to their own machine and is comfortable supplying API keys and granting an assistant control over the screen, the keyboard and the terminal. It is not usable as a commercial dependency, because the licence is Creative Commons BY-NC 4.0 and personal, non-commercial use only, and it is not a stable release, since the repository has no GitHub releases. Check first that you have free Gemini and OpenRouter keys, that your Python version is 3.11 or 3.12, and that the missing OS specific packages the readme warns about are ones you are willing to install by hand.

Frequently asked questions

Official sources

1. FatihMakes/Mark-XXXIX-OR on GitHub
2. Issues
3. README