Alice (pmbstyle) review: a voice-first Electron assistant with local memory and MCP tools

What Alice actually is, and who it is built for

Alice is not a chat window with a microphone button bolted on. The README frames it as a companion that lives on the desktop, and the feature list backs that framing: voice activity detection, interruptible speech, animated avatar states, a memory store, and computer-use tools that touch the local file system and shell.

The target user is a single person running the app on their own machine. That is visible in the packaging. The repository ships Windows, macOS and Linux installers, plus a community AUR package for Arch. There is no server mode, no multi-user account model, and the package.json marks the project as private. This is a personal desktop tool, not infrastructure you deploy for a team.

The second audience is the tinkerer. Custom tools are defined in JSON and backed by local scripts, custom avatars are folders of video loops, and the settings interface exposes model choice, temperature, top_p, history length and prompt tuning. If you want an assistant you can reshape without forking the code, that surface exists.

How the pieces fit: Vue renderer, Go backend, Hnswlib memory

The stack splits cleanly. The frontend is Vue.js with TailwindCSS and Pinia for state. Electron is the desktop shell. The build script runs a Go backend first, then Vite, then electron-builder, and the Go binaries are compiled per platform with GOOS and GOARCH set explicitly and -ldflags="-s -w" to strip symbols. The backend is not optional: npm run build calls build:go before anything else.

Memory is the part worth understanding before you install. Alice separates short-term context from long-term facts. Thoughts are stored in an Hnswlib vector database, which is an approximate nearest neighbour index, not a relational store. Memories are structured long-term facts kept in a local database via better-sqlite3. Message history gets compacted into context prompts by a summarization step. Local embeddings come from multilingual-e5-small, an ONNX model with 384 dimensions.

That split has consequences. Hnswlib-node and better-sqlite3 are both native modules, which is why the repository carries a rebuild script targeting exactly those two packages. Any Electron version bump can invalidate the compiled binaries, and the fix is npx electron-rebuild with the module list, not a plain npm install.

Installing Alice from a release binary

The README points at the releases page rather than a package manager. The latest release listed is v1.5.0, published on 2026-08-05, with three platform artifacts: Alice-AI-App-Windows-1.5.0-Setup.exe, Alice-AI-App-Mac-1.5.0-Installer.dmg, and Alice-AI-App-Linux-1.5.0.AppImage. Arch users have a separate community build, the alice-ai-app-bin AUR package. Download the artifact for your platform and run it.

After first launch, the README directs you to docs/setupInstructions.md to configure API keys and environment. The repository root contains a .env-example file, and the README's development section says to set up your .env file based on it. The exact keys are not reproduced in the README body, so read that file directly rather than guessing variable names.

If you would rather build from source, the README gives the first three steps. Node 22 or newer is required by the engines field in package.json.

Building from source and running the dev server

The README's development section starts with cloning the repository, installing dependencies, and creating the .env file. The scripts in package.json continue from there. The dev server URL is fixed at http://127.0.0.1:3344/ in the debug env block, so that is the address to open once Vite is running.

Two setup scripts exist for the heavier local assets: setup:dependencies and setup:embeddings. The embeddings script corresponds to the ONNX embedding model, and the dependencies script handles the native module situation. The test command sets ROLLUP_SKIP_NODEJS_REQUIRE=1 before invoking vitest, which is a workaround for bundling native modules under test, not a general test configuration.

git clone https://github.com/pmbstyle/Alice.git
npm install
npm run setup:embeddings
npm run dev

For a distributable build, npm run build chains the Go compile, the Vite build, and electron-builder. If native modules fail after an Electron upgrade, npm run rebuild reinstalls better-sqlite3 and hnswlib-node against the current Electron ABI.

npm run build
npm run rebuild

Custom tools and MCP: the extension path

Alice supports two extension mechanisms, and they are aimed at different levels of effort. Custom tools are JSON definitions backed by local scripts, and the README gives a four-step flow: open Settings, Customization, Custom tools; upload or drop the script, which writes to custom-tool-scripts/; click Add Tool, fill in metadata and paste the JSON schema, which updates custom-tools.json; then toggle the tool on or off in the list. Only enabled and valid entries are offered to the model, which is a useful guardrail: a malformed schema silently removes the tool rather than producing a runtime error in front of the user.

MCP server support is listed as a function-calling capability rather than a separate subsystem. The README does not document the MCP configuration format in the text available here, so treat the settings interface as the source of truth for server entries.

The built-in tool list is broad and includes web search with Searxng support, Google Calendar and Gmail, torrent search and download through Jackett and qBittorrent, clipboard management, a task scheduler for reminders and command execution, and image generation. Each of those is a separate credential or local service to configure, which is the real cost of the feature list.

The permission model is the part to scrutinise

Alice can list folders, run shell commands such as ls, mv and mkdir, and open applications and URLs. The README is explicit that this happens with user-approved permissions and describes three approval scopes: one-time, session-based, and permanent, with permanent approvals revocable from a Permissions tab in settings.

That design is reasonable, and the review surface is the right one. The limitation is that approval is per command, and an assistant that can compose shell commands will propose commands you did not anticipate. A permanent approval granted for one workflow applies to whatever the model generates next within that command shape. The README does not describe a sandbox, a working-directory restriction, or a dry-run mode. If you would not hand a terminal to an LLM with a list of pre-approved verbs, this is the wrong tool for you, and no amount of settings UI changes that.

The wake word feature has a related cost. With the local STT model you can set a wake word so Alice always listens but only processes requests after the phrase. Always-on microphone capture is the trade-off, and the README does not describe an audio retention policy for the listening buffer.

Local mode, cloud mode, and what the README admits

The provider list spans OpenAI, OpenRouter, DeepSeek, Z.ai, Minimax, Ollama and LM Studio, and the same flexibility applies to speech-to-text, text-to-speech and embeddings. Local STT and TTS use whisper.cpp and Piper. Cloud transcription options named in the README include gpt-4o-transcribe and whisper-large-v3, with google-tts-voice for speech output.

The honest part is the framing. The README says the OpenAI cloud API is preferred and provides the best user experience, and describes fully local operation as experimental. That is a meaningful admission for anyone planning an offline setup: local mode is a supported configuration, not the configuration the project optimises for. Expect the local path to need more setup and to behave less predictably than the cloud path.

A smaller inconsistency worth noting: the README credits Groq in the technologies list and the repository topics include groq-api, while the provider selection list in the settings section does not name Groq. The README does not resolve whether Groq is a first-class provider or an OpenAI-compatible endpoint configured manually.

Alternatives and the difference in approach

The closest comparison in this space is Open WebUI, which is a self-hosted web interface for local and remote models. The difference is architectural rather than cosmetic. Open WebUI runs as a server you reach through a browser, which makes it easy to share across machines and to run on a home server. Alice is an Electron application with a per-platform Go backend and native modules compiled against a specific Electron ABI. You get desktop integration that a browser tab cannot offer: global hotkeys, clipboard access, screenshot interpretation, shell execution, and an always-listening wake word. You give up the ability to run it headless or to point three devices at one instance.

Against a plain Ollama plus a chat client, Alice's differentiator is the memory layer. Ollama gives you model serving; it does not give you a Hnswlib thought index, a summarization step that compacts history, or a separate structured store for long-term facts. If you only want to talk to a local model, the extra machinery is overhead. If you want the assistant to remember things across sessions without you pasting context, that machinery is the product.

Maintenance, upgrade cost and licence

The repository is not archived, and the last push was on 2026-09-01, which is recent. Releases have arrived at a steady cadence: v1.4.3 on 2026-05-18, v1.4.4 on 2026-06-05, and v1.5.0 on 2026-08-05. That is roughly a release every six to eight weeks across the visible window.

The upgrade cost is not in the app, it is in the native layer. better-sqlite3 and hnswlib-node are compiled against the Electron ABI, and the repository ships a dedicated rebuild script because of it. Electron is pinned at 43.2.0 in devDependencies, and moving that pin means rebuilding both modules. The Go backend is compiled per platform with explicit GOOS and GOARCH values, and the build script only produces amd64 binaries in the commands shown, so arm64 builds are not covered by the documented scripts.

The project is MIT licensed. That permits commercial use and modification, and it requires the licence and copyright notice to be preserved. The bundled models are separate: multilingual-e5-small, whisper.cpp and Piper come from their own upstream projects with their own terms, and the README does not restate them. Check those licences independently if you plan to redistribute a build. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt Alice if you want a voice-driven desktop assistant that can keep local memory and call tools, and if you are comfortable reviewing every shell command it proposes. Skip it if you need a headless server deployment, a stable plugin contract, or a documented upgrade and rollback path; the repository does not provide one. Before installing, read docs/setupInstructions.md and check which local models your hardware can actually run, because the fully local mode is labelled experimental and the OpenAI cloud API is described as the preferred path.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pmbstyle/Alice on GitHub
4. README
5. Releases