Model or dataset
zeraix/zeraix avatar
zeraix/zeraix

Zeraix: an Electron desktop that puts local GGUF models at the centre of a file-and-agent workspace

Open-source local AI workspace — advancing on-device inference.

428 stars13 forksTypeScriptApache-2.0

At a glance

What is it?
Zeraix is an Apache-2.0 desktop app for macOS and Windows that runs local models, edits project files, and delegates multi-step tasks to sub-agents. It is a workspace first and an inference engine second, which shapes both what it does well and where it stops.
Who is it for?
Adopt Zeraix if you want a single desktop surface for local models, project files and approval-gated agents on Apple Silicon or Windows 10/11 x64, and you accept that the general local inference path currently goes through llama.cpp-based runtimes rather than the Imparo engine. Do not adopt it if you need the tuned inference stack the README highlights: that code lives in the separate Imparo repository, and the README states the desktop uses llama.cpp-based runtimes instead.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem Zeraix is aimed at: a workspace around the model, not a model server

Most local inference tooling stops at a server process and an HTTP endpoint. You get tokens, and then you build your own file handling, your own approval flow, your own way of seeing what an agent did. Zeraix inverts that. The README describes it as "an open-source AI desktop for working with models, files, tools, and agents, with local inference at its core," and the repository layout backs the claim: alongside src/ and electron/ there are native/, runtime/, sandbox/, skills-lock.json and a registry directory. This is an application, not a library.

The target user is someone who already has a machine with 16 GB of memory or more and wants a model working against a real project directory. The README recommends 16 GB and notes that some smaller models support 8 GB systems, with larger models and longer contexts requiring more. The local core is explicitly account-free: no Zeraix account, subscription, or API key is needed for local models. Cloud models and remote services are opt-in connections rather than the default path.

How the pieces fit: Electron shell, Next.js UI, a Rust agent runtime and a sandbox

The desktop is an Electron application. package.json sets "main": "electron/main.mjs", and the dev script runs Next.js and Electron together, waiting on tcp:3000 before launching the shell. So the interface is a Next.js app served locally and wrapped by Electron, not a pure native UI.

The file and tool operations do not live in the JavaScript layer. The README states that built-in file operations "now share the Rust Agent Runtime's execution and permission layer." The repository has a native/ directory, a runtime/ directory, and a build script named build:runtime that runs scripts/build-rust-runtime.mjs. A separate script, ensure-runtime.mjs, is invoked before Electron starts in development, and a comment in package.json explains why it is inline rather than a pre-script: pnpm does not run pre/post scripts by default, and "the sidecar is not optional: without it the app has no file tools." That is the clearest architectural statement in the README. The Rust sidecar is the file tool layer.

Permission handling is a first-class setting rather than an afterthought. The README lists four approval modes: Default, Full trust, Manual approval, and Plan mode. Plan mode investigates and proposes changes; Default reviews protected actions as a task progresses. An optional QEMU sandbox, under sandbox/, provides an isolated environment for supported commands, and its resources are downloaded when needed rather than bundled. The README also tells you to check whether commands will run on the host or in the sandbox, which implies the answer is not uniform across commands.

Installing Zeraix and running a first local model

There is no package manager install. Zeraix ships as a desktop installer from GitHub Releases, and the README's Quick Start table points at the stable channel. Note the version mismatch in the README itself: the download table lists v2.1.0 while the text says "2.0 is the current stable release," and the repository's own releases list v2.2.0 as the newest tag. Check the releases page rather than trusting the table.

On macOS you need macOS 13 or later on Apple Silicon. On Windows you need Windows 10 or 11 x64. The README also warns that if your operating system shows a security warning, verify the installer came from the official repository before continuing.

After installing, the first-run flow is inside the app rather than the terminal:

bash
# No CLI install step is documented.
# Download the installer from the releases page:
# macOS: Zeraix-intl-2.1.0.dmg
# Windows: Zeraix-intl-2.1.0.exe

Once the app is open, the README's four steps are: open Model Library and let Zeraix detect your hardware; choose a recommended model and review its memory and disk requirements; download the model and required runtime, then start it; select the running model in chat and send your first message. Initial setup downloads model and runtime assets, and sandbox resources are downloaded when needed, so the first run needs network access even though local inference and local tools work offline afterwards.

For a first real task, choose a working directory and pick an approval mode from the chat composer. The README gives this example prompt:

text
Read this project, explain how it works, and suggest a focused improvement.

Plan mode is the safer first choice here, because it investigates and proposes changes rather than applying them. If you want to build from source instead, the repository is a pnpm workspace pinned to pnpm@10.29.2, with dev, build, typecheck and test scripts; the test suite runs through node --test over test/**/*.test.mjs.

What the model library actually runs, and where the tuned inference lives

The curated catalogue in the README is short and specific: Qwen3.6-35B-A3B with MoE, vision and MTP; Qwen Bonsai 27B as a compact dense model with vision and optional DSpark speculative decoding; Gemma 4 26B-A4B with MoE, vision and MTP; Gemma 4 12B with vision/audio and MTP; Gemma 4 E4B as a smaller-memory profile with vision/audio and MTP; and LFM2.5-2.6B as a lightweight text model with tool calling. Availability depends on the runtime and platform, and the README says usable context length depends on available memory and configuration. Beyond the curated list, Zeraix accepts community GGUF imports with repository search, quantization selection and memory estimates, plus custom OpenAI-compatible endpoints.

Here is the part that deserves attention. The README states that "the desktop currently uses llama.cpp-based runtimes for general local inference," and that Zeraix's tuned Apple Silicon paths, model-specific memory planning, mapped weights, MoE pooling, speculative decoding and persistent KV reuse, are described in MODEL_SYSTEMS.md as historical configurations and reported results. The model-systems work itself continues in Imparo, a separate repository. So the desktop you install is not the tuned engine the opening line points at. That separation is honest, but a reader scanning the topic list (metal, moe, llm-inference) could easily assume otherwise. The README also cautions that the optimization results are specific to their tested Apple Silicon configurations and that Apple Silicon results do not establish Windows behaviour.

Where Zeraix is the wrong tool

If you need a headless inference server that other services call over HTTP, this is the wrong shape. Zeraix is a desktop application with an Electron main process; the README documents no server deployment path, no container image, and no daemon mode. The runtime/ and native/ directories contain build scripts for the sidecar, not a documented standalone server.

Platform is a second boundary. The README lists macOS 13+ on Apple Silicon and Windows 10/11 x64. Linux is not mentioned in the download table or the platform badge. If your team develops on Linux, the installer does not exist for you.

Memory is the third. The 16 GB recommendation is a floor for comfortable work, not a ceiling you can ignore: the curated models include a 35B MoE and several 26B to 27B models, and the README ties context length to available memory. Running a large model with a long context on an 8 GB machine is not a configuration the README presents as viable.

Finally, the offline claim has edges. The README says local inference and local tools can work offline after setup, but web search, remote MCP servers, generation services and cloud models each need their own network connection. Offline is a property of the local path, not of the app as a whole.

How Zeraix differs from a plain llama.cpp setup or an IDE assistant

The closest comparison is running llama.cpp yourself with a chat front end. The difference is everything above the token stream. Zeraix bundles file read, search and edit operations, diff inspection, terminal commands and browser tools into the same conversation, and routes them through the Rust Agent Runtime's execution and permission layer with four approval modes. A raw llama.cpp server gives you an endpoint and leaves permission design to you. The trade-off is control: with llama.cpp you choose the exact build, flags and quantization; with Zeraix you take the runtimes the app ships and the catalogue it curates, though community GGUF imports and custom OpenAI-compatible endpoints soften that.

The second comparison is an editor-integrated assistant. Those tend to be scoped to the open file or the current repository window, with a single approval model. Zeraix instead offers scheduled recurring workflows with run history and notifications, sub-agents you can inspect and stop individually, a media library for uploaded and generated assets, and bundled Skills for Word documents, PDFs, presentations and spreadsheets. That is a broader surface, and broader surfaces carry more places for a permission setting to be wrong. The README's own advice, to review permissions and file changes and check whether commands run on the host or in the sandbox, is the correct posture.

Maintenance, licence and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-16, the same day as the v2.2.0 release tag. Release cadence in the README and release list is tight: v2.0.0 on 2026-09-09, v2.1.0 on 2026-09-11, v2.2.0 on 2026-09-16. That pace means the main branch may contain changes newer than the available installers, a caveat the README states directly. If you build from source you are tracking a fast-moving tree; if you use installers you are one or more releases behind main.

Upgrade cost has a concrete component: model and runtime assets are downloaded during initial setup, and sandbox resources are downloaded when needed. Changing the curated model or runtime can mean another download, and the README ties usable context to memory configuration, so an upgrade that changes the recommended profile can change what your machine can run.

Licensing is Apache-2.0, per the LICENSE file and the package.json license field. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries notice and attribution obligations: the repository includes a NOTICE file, and Apache-2.0 requires that NOTICE contents be preserved in distributions. That matters if you fork the desktop and ship it. This is not legal advice; read the licence text and the NOTICE file, and get counsel if you plan to redistribute.

Editorial conclusion

Adopt Zeraix if you want a single desktop surface for local models, project files and approval-gated agents on Apple Silicon or Windows 10/11 x64, and you accept that the general local inference path currently goes through llama.cpp-based runtimes rather than the Imparo engine. Do not adopt it if you need the tuned inference stack the README highlights: that code lives in the separate Imparo repository, and the README states the desktop uses llama.cpp-based runtimes instead. Before committing, verify three things on your own machine: that your chip and memory profile appears in the Model Library recommendations, that the curated models you want are listed as available for your runtime and platform, and that the approval mode you intend to work in matches how you want commands to run on the host versus in the QEMU sandbox.

Frequently asked questions

What is Zeraix?

Zeraix is an open-source AI desktop application for working with models, files, tools and agents, with local inference at its core. It runs supported GGUF models on your own hardware and lets you use files, terminal commands and browser tools from the same conversation.

Which platforms does Zeraix support?

The README lists macOS 13 or later on Apple Silicon and Windows 10/11 x64. Linux is not listed in the download table or the platform badge.

Does Zeraix need an account or API key to run local models?

No. The README states the local core requires no Zeraix account, subscription or API key. Cloud models, web search, remote MCP servers and generation services are optional connections that need their own network access.

Official sources

  1. License: Apache-2.0
  2. Project website
  3. README
  4. Releases
  5. zeraix/zeraix on GitHub
Community notes

Community notes