# Alice, a desktop assistant with three provider lists and one Go target

> Alice is a voice-first desktop assistant built with Vue and Electron over a Go backend, with short-term vector memory, permissioned shell tools, and support for several cloud and local model providers. The README is thorough about features and loose about facts, and the most checkable things in the repository are the three different lists of supported providers and a set of build scripts that all target one processor architecture.

**pmbstyle/Alice** — Alice is a voice-first desktop AI assistant application built with Vue.js, Vite, and Electron. Advanced memory system, function calling, MCP support, optional fully local use, and more.

- Repository: https://github.com/pmbstyle/Alice
- Stars: 322 · Forks: 60
- Language: TypeScript
- License: MIT
- Published: 2026-09-14 · Updated: 2026-09-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/pmbstyle-alice

## Three provider lists in one document, and they disagree

The same README names the supported model providers three times, in three different sets.

The features section lists cloud providers as OpenAI, the Codex subscription, OpenRouter, Z.ai, Minimax, and DeepSeek, plus local models through Ollama or LM Studio. The technologies section lists OpenAI, OpenRouter, API Route, DeepSeek, and Groq, with no local options at all. The settings section lists OpenAI, OpenRouter, API Route, DeepSeek, Z.ai on its coding plan, Minimax on its token plan, Ollama, and LM Studio.

So Groq appears in exactly one of the three places. Ollama and LM Studio appear in two and are absent from the technologies list. Z.ai and Minimax are qualified with subscription-plan names in the settings list and unqualified in the features list.

None of this is a claim that anything is broken; a project gaining a provider and updating two of three lists is completely ordinary. It matters because the technologies list is the one a reader consults when deciding whether the project fits, and it is the least complete of the three.

The one thing all three agree on is that the OpenAI cloud path is the preferred one and that running fully locally is described as experimental. That is stated in the features section and is worth taking at face value before you plan a local deployment.

## Every backend build script targets the same architecture

There are three scripts for compiling the Go backend, one per operating system, and all three name the same processor architecture.

The Windows script sets the operating system to windows and the architecture to amd64. The macOS script sets darwin and amd64. The Linux script sets linux and amd64. All three pass the same linker flags to strip the binary.

The consequence is that the macOS backend is an Intel build and the Linux backend is an x86-64 build, with no arm64 target anywhere in the scripts. On an Apple Silicon machine the application runs the shell natively and the backend under emulation, or not at all if the process is not translated.

That is visible in the download table too. There is one macOS artefact, a disk image, and one Linux artefact, an AppImage, with no architecture suffix on either and no universal binary offered.

The architecture is the kind of value that is easy to leave behind and hard to notice, because a working x86-64 build on an Apple Silicon machine looks like a working build. The Windows path is the least likely to expose it, since that architecture is the correct one there.

## The Windows build script only runs in a command prompt

The three cross-compilation scripts do not share a shell, and one of them is written for a different operating system than the others.

The macOS and Linux scripts set the target with an environment variable prefix on the same line as the build command, which is standard shell syntax and works in any POSIX shell.

The Windows script sets the same two variables using the command-prompt form of setting an environment variable, with the assignment and the command chained by ampersands. That syntax is specific to the Windows command interpreter, so running that script from a POSIX shell, from a continuous integration runner using one, or from a task runner that normalises to a POSIX shell will not set the variables the way it appears to.

The script is only reached if you invoke it directly. The ordinary build path goes through a Node script that dispatches on the host, so most users never touch it. The exception is a maintainer building for a platform other than their own, which is exactly the case the manual scripts exist to serve.

A cross-compilation setup that only works when invoked by hand on the right operating system is a normal shape for a desktop application. It is still worth knowing that the supported path for a cross-build is a script that only runs natively.

## Two native modules are rebuilt against Electron's ABI

The memory system is two native modules, and both have to be recompiled for the desktop runtime.

The vector search engine is a Node binding to a hierarchical navigable small-world index library. Local storage is a synchronous SQLite binding. Both are compiled native code with a C layer, and both are listed together in the rebuild script, which forces a rebuild of exactly those two and nothing else.

That script exists because of how a desktop application loads native modules. The runtime bundles its own Node and its own module ABI, and a native addon compiled against the system Node will refuse to load, usually with an error that names the module version rather than the cause. A rebuild step that names its two targets explicitly is the standard fix, and naming them explicitly rather than rebuilding everything is faster and less likely to break something unrelated.

```bash
npm run rebuild
```

The rest of the build chain follows the same shape. One script compiles the backend, one downloads the inference runtime and the pinned embedding model, and one prepares other dependencies. The full build runs the backend compilation first, then the renderer, then the packager, so a packaging step cannot succeed against a stale backend binary.

## The readme names its storage engines as features

The memory section is written in a way that is unusual for a feature list, and it is also the clearest description of how the assistant works.

Short-term context is described as thoughts, stored in a vector index. Long-term structured facts are described as memories, stored in a local relational database. Message history is compacted into context prompts by summarisation, and those summaries carry an estimate of mood so responses can be more human. Local documents can be added to the context for retrieval-augmented answers.

Naming the storage engines in the feature bullet is unusual, and it is the most useful thing in the section. Two different stores with two different purposes is a real design decision: a vector index for the loose short-term material where similarity is the right lookup, and a relational database for facts that need to be queried exactly rather than approximated.

The mood estimation in the summaries is the other thing worth flagging. It is a behavioural choice, not a capability claim, and it is the kind of feature that should be on by default only if the user knows about it.

The wake-word mode is related. With a local speech model configured, the assistant can listen continuously while only acting on a configured phrase, and the default is automatic language detection rather than a fixed one.

## The avatar animation comes from a commercial video service

One line in the technologies list undercuts the local-first framing in a way that is easy to miss.

The assistant has three animated video states: standby, speaking, and thinking. Under technologies, the animation entry names a hosted commercial generative video service rather than anything local.

So an application whose fully local mode is described as experimental still depends on a paid cloud service for the movement you see while it waits and while it answers. Nothing in the feature list mentions it, and nothing says what happens when the service is unreachable.

That said, the framing is not dishonest. The local claim is about the language model, the speech recognition, the speech synthesis, and the embeddings, and all four of those have local paths named: a local speech recognition implementation, a local multilingual synthesis engine, and a pinned multilingual embedding model served through an inference runtime. What has no local path is the animation.

The custom avatar feature is the escape hatch. You supply three video files for the three states, all required, in a folder under the user customisation directory, and refresh the list in settings. A user who does not want a cloud dependency for a three-second loop can supply their own.

## The readme points at .env.example and the file is .env-example

The development instructions name a file with a dot that the repository does not contain.

The getting-started block says to set up the environment file and points at the example file for reference. The example file in the repository root is named with a hyphen before the word example rather than a dot.

That is a one-character difference and it is exactly the kind of thing that costs a new contributor ten minutes: the file they are told to copy is not there, the file that is there is not named, and the fix is to guess.

The rest of the root is more conventional. There are two configuration files for the renderer and the build tool, a markdown lint configuration, a prettier configuration, an npm configuration file, two editor and continuous integration directories, a licence, and the usual source, backend, script, asset, documentation, and type directories.

Three things stand out among the absences. There is no contributing guide, no security policy, and no changelog, despite a versioned release history with three tagged releases in the last five months. There is also no licence file beyond the standard one and no code of conduct, for an application that asks for calendar, mail, and file system access.

The newest release is 1.5.0 from August 2026, and the last push to the branch is 1 October 2026, the same day this was checked.

## Conclusion

Alice is worth trying if you want an assistant that can act on your machine rather than only talk to you, because the permission model for shell commands is unusually granular and the local-first path is real rather than aspirational. Check four things first. Whether you are on Apple Silicon, since the backend build scripts target one architecture for all three operating systems. Whether you want the local stack, which the README marks experimental and which needs two models downloaded before first run. Which provider you plan to use, because the three provider lists in the README do not agree. And whether you are comfortable granting a desktop app calendar, mail, and download client access, since those are function calls rather than settings you can inspect in advance.

## FAQ

### What is the Alice desktop assistant built with?

Vue.js and Tailwind for the frontend, Electron as the desktop shell, Pinia for state, and a Go backend. The vector search engine is a Node binding to an HNSW library, local storage is a synchronous SQLite binding, and speech recognition, synthesis, and embeddings all have local paths as well as cloud ones.

### Which model providers does Alice support?

The README lists them three times with different sets. The features and settings sections include OpenAI, OpenRouter, DeepSeek, Z.ai, Minimax, plus local models through Ollama and LM Studio, while the technologies section lists OpenAI, OpenRouter, API Route, DeepSeek, and Groq with no local options. The OpenAI path is described as preferred and fully local use as experimental.

### How does Alice get permission to run shell commands?

Approvals are granular and come in three scopes: one-time, session-based, and permanent but revocable. A permissions tab in settings lists every approved command for review and management. File system browsing and shell execution sit behind the same approval model.

### What platforms does Alice ship builds for?

Windows, macOS, and Linux, plus a community-maintained package in the Arch Linux repository. The macOS artefact is a single disk image and the Linux one a single AppImage, with no architecture suffix on either. The backend build scripts set the same processor architecture for all three operating systems.

## Sources

- [Issues](https://github.com/pmbstyle/Alice/issues)
- [License: MIT](https://github.com/pmbstyle/Alice/blob/main/LICENSE)
- [pmbstyle/Alice on GitHub](https://github.com/pmbstyle/Alice)
- [README](https://github.com/pmbstyle/Alice/blob/main/README.md)
- [Releases](https://github.com/pmbstyle/Alice/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pmbstyle-alice