Leon 2.0 Developer Preview: A Local-First Personal Assistant Rebuilt Around Tools and Memory
Project brief: Leon is your open-source personal assistant. Leon supports both local and remote AI providers, which helps balance privacy, control, and capability.
At a glance
- What is it?
- Leon is an open-source personal assistant that now runs on a tool-based, agentic core. This review covers the 2.0 Developer Preview on the develop branch, its architecture, setup, and the trade-offs you face while the docs lag behind.
- Who is it for?
- Adopt Leon 2.0 if you are a developer comfortable with a moving codebase and want a local-first assistant that uses tools, memory, and context rather than pure model guessing. Do not adopt it if you need a stable, documented assistant for production or everyday use; the docs are not ready, and the develop branch is explicitly a preview.
- Can I use it commercially?
- Yes. MIT 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 received new commits within the last day.
- 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Leon 2.0 Is and Who It Targets
Leon is an open-source personal assistant written in TypeScript, licensed under MIT, and hosted at getleon.ai. The 2.0 Developer Preview on the develop branch is a full rebuild. The README states that Leon is no longer a classic intent-classification assistant like its 2019 release. Instead, it is built around tools, context, memory, and agentic execution. The target user is a developer or tinkerer who wants a self-hosted assistant that can run tasks end to end, use real tools, and keep data local. It is not aimed at a non-technical user who expects a finished product. The project explicitly warns that the new documentation is not ready and that the current docs site reflects the legacy architecture. If you are evaluating Leon for a serious deployment, you are looking at a moving target.
The Core Mechanism: Modes, Skills, and Tools
Leon's runtime is organized around three execution modes. The README describes smart mode, which chooses how to handle a task; controlled mode, which follows deterministic native skills and actions; and agent mode, which plans step by step. Under the hood, native skills follow the chain Skills -> Actions -> Tools -> Functions, with optional binaries at the end. This is a deliberate departure from asking a language model to guess an answer. The assistant prefers explicit tools and context. It also includes a bounded proactive pulse system and a compact self-model, which the README says helps it stay consistent without flooding its own context. The architecture splits into several components: a server for routing, memory, context, and an HTTP API; a web app; an aurora UI environment; skills divided into native and agent types; bridges for Node.js and Python; and a TCP server for Python services. The repository layout is the only reliable map right now, since the docs lag.
Installation and First Run: Commands That Work Today
Getting Leon running requires Node.js version 24.0.0 or newer, and it supports Linux, macOS, and Windows. The README recommends managing Node with Volta. The installation sequence is straightforward: clone the repository, install pnpm globally, then run pnpm install. After that, pnpm start launches the assistant, and by default it runs locally on http://localhost:5366. A setup check is available via pnpm run check. These commands are the only ones documented, and they are simple enough. The catch is that the project is on the develop branch, and the README tells you to treat the repository as the source of truth. There is no stable release for 2.0 yet, so these commands may change as the preview evolves. The recent releases listed are for bridges and the TCP server, not for the core assistant itself, which signals that the core is still in flux.
Local and Remote AI Providers: The Privacy Trade-Off
Leon supports both local and remote AI providers. The README frames this as a way to balance privacy, control, and capability. This is a practical design because it lets you run a local model for sensitive tasks and switch to a remote provider when you need more power. However, the README does not specify which providers are supported or how to configure them. That information is presumably in the missing documentation. The implication is that you will need to inspect the repository or wait for the docs to understand the configuration keys. This is a real limitation for evaluation. You cannot verify the provider setup without digging into the source code or experimenting. If you are privacy-focused, the local option is appealing, but the lack of documentation makes it hard to assess the actual privacy guarantees.
Memory and Context: Layered but Undocumented
Leon includes layered memory, which the README says stores durable preferences, day-to-day context, and recent discussion context. This is a key feature for an assistant that needs to remember user details across sessions. The architecture also includes context about the user's environment, so answers can be grounded in what is actually happening on the machine. The design sounds reasonable, but again, the details are thin. The README mentions that Leon keeps a compact self-model and a bounded proactive pulse system, which suggests a mechanism to avoid context bloat. That is a thoughtful design choice, but without documentation, you cannot know how memory is stored, how it is retrieved, or how to clear it. For a privacy-conscious user, the storage location and retention policy are critical unknowns. You would need to read the source code in core/context or the server directory to answer those questions.
The Real Limitation: Documentation and Stability
The most significant limitation is the documentation gap. The README is explicit: the new docs are not ready, and the public docs site reflects the legacy architecture. The only reliable references are core/context/LEON.md and core/context/ARCHITECTURE.md, which are generated context documents. This means that any team evaluating Leon must treat the repository as the source of truth, which is time-consuming and error-prone. The project also has a small contributor base, and the README attributes that to the transition period and to spare-time development. Progress can be uneven. If you need a stable assistant for production, this is the wrong tool. The legacy master branch is the safer alternative, but it lacks the new agentic features. The 2.0 preview is for exploration and contribution, not for deployment.
Alternatives and What They Do Differently
The obvious alternative is a self-hosted assistant like Home Assistant's Assist or a tool-based framework like LangChain. Home Assistant's Assist is a voice assistant that integrates with a smart home platform, and it uses intent recognition and local processing through the Wyoming protocol. It is more stable and documented, but it is tied to the Home Assistant ecosystem and does not offer the same general-purpose tool use or agentic planning. LangChain, on the other hand, is a framework for building agentic applications with tools and memory, but it is not a ready-made assistant; you have to build the entire application. Leon sits between these: it is a full assistant with a web app and skills, but it is also a framework because you can extend it with skills and toolkits. The key difference is that Leon is designed to be used out of the box, whereas LangChain requires assembly. If you want a stable, documented assistant, Home Assistant is the choice. If you want to build your own agent, LangChain gives you more control. Leon is for those who want a pre-built assistant that they can still modify deeply.
Maintenance and Upgrade Cost
The maintenance cost for Leon 2.0 is currently high. The project is in a major transition, and the README says the core is being rebuilt. That means APIs, configuration, and even the architecture could change between commits. The recent releases are for bridges and the TCP server, not the core, which suggests that the core is not yet stable enough for versioned releases. Upgrading from the legacy master branch to the develop branch is not a simple update; it is a migration to a different system. The MIT license is permissive, which is good for commercial use, but it does not come with any warranty or support guarantee. You will need to rely on the community, the Discord server, and the roadmap. For a production deployment, you would need to pin a specific commit and manage your own updates. This is a significant cost that the README does not hide, but it is a cost nonetheless.
Editorial conclusion
Adopt Leon 2.0 if you are a developer comfortable with a moving codebase and want a local-first assistant that uses tools, memory, and context rather than pure model guessing. Do not adopt it if you need a stable, documented assistant for production or everyday use; the docs are not ready, and the develop branch is explicitly a preview. Before integrating, verify the current state of core/context/ARCHITECTURE.md, check that your Node.js version is 24 or newer, and confirm that the skills and toolkits you need (search, productivity, system utilities, media, coding, memory, voice) exist in the repository. The legacy master branch remains the safer choice if you want the pre-agentic version.
Community notes