Leon: An Intents-First, Offline-Capable Open-Source Personal Assistant Rewriting Its Core in TypeScript

Positioning: an open-source assistant that lives on your own server

Leon is an MIT-licensed, open-source personal assistant. Its tagline is "Your open-source personal assistant." It is not another cloud chatbot. It is a long-running program that you host on your own server. You can talk to it and it can talk back. You can text it and it can text you. Most important, it can run fully offline to protect your privacy. In the middle of the large language model boom, this stance runs against the tide. That is exactly why it deserves a careful read.

The author lists five reasons for the project. First, developers want to build many small tools that help in daily life. Instead of one dedicated project per idea, Leon offers a single Skills structure to hold them all. Second, a generic structure lets anyone write a skill and share it, so there is only one core. Third, Leon uses AI concepts, which is fun. Fourth, privacy matters, and Leon can be configured for offline conversation with no third-party service. Fifth, open source is great.

Core architecture: several cooperating nodes

According to the README, the repository holds several nodes of Leon: the server, the skills, the web app, the hotword node, the TCP server, and the Python bridge. The TCP server handles inter-process communication between Leon and third-party nodes such as spaCy. This split into a main process plus a few specialised helpers is practical. Most natural language processing tooling lives in Python. The server and the web client suit TypeScript better. A local TCP link joins the two worlds, and each side keeps its strengths.

The latest release, 1.0.0-beta.8, is titled "Binaries and TypeScript rewrite" on the project blog. That says two things. The core is being rewritten in TypeScript, and the project now ships prebuilt binaries to lower the barrier to installation. The README also mentions an upcoming JavaScript bridge that will sit beside the current Python bridge. Skill authors will then be able to write skills in the language they know best.

How it works: intents-first NLU

Leon's natural language understanding (NLU) is "intents first". It uses its own trained model and does not rely on a large language model. The flow is roughly this. The user's utterance, typed or transcribed from speech, is classified into an intent. Named entities are extracted at the same time. The request is then routed to the matching skill, and the skill produces the answer. The benefits of this design are clear: small models, fast inference, predictable results, and full offline operation on edge hardware. The cost is just as clear. Leon can only handle intents that someone defined in advance, and its generalisation is far weaker than that of an LLM.

The author sees this trade-off plainly. The README lists four ways an LLM could help in the future. One is intent fallback: when an utterance matches no intent, an LLM supplies a result. Two is a new named entity recognition engine that extracts fruits, numbers, cities, durations, persons and similar items more reliably. Three is skill features: skills could get summarisation, translation and sentiment analysis out of the box. Four is skill building: an LLM could paraphrase sample utterances, translate answers, and convert code between the Python bridge and the future JavaScript bridge. The author's bet is that downsizing techniques such as quantization will let Leon put an LLM at its core someday and still run on the edge.

Performance and cost: the README publishes no benchmarks

We should be direct here. The README publishes no benchmark data. It gives no latency figures, no accuracy figures and no resource comparisons. This article will not invent numbers.

We can only reason about the trade-offs from the architecture. A small intents-first model is very cheap to run, with almost no metered inference cost. The price is coverage: how much Leon can do depends on how many skills the community writes, and on how many sample utterances each intent needs. If a quantized local LLM arrives later, memory use and first-response latency become the main new costs. That is why the author keeps stressing that it must run on the edge.

Ecosystem and adoption impact

For developers, the value of Leon is the Skills abstraction. Every small idea becomes a skill and reuses the same voice, text, NLU and deployment machinery.

For privacy-minded individuals and small teams, self-hosting and offline operation are hard requirements, and Leon is one of the few complete open-source answers. The author also says that once the skills platform is online, syncing progress and publishing new skills will be easier. Plans include better organisation of the Discord server, regular calls, and building skills together.

Limits and challenges

First, the project's situation is not easy. The author says the new core is built only after work and on weekends, for personal reasons. To avoid conflicts with many breaking changes, outside contributions are blocked for now. No new documentation or tests will be written until the official release of the new core.

Second, intents-first NLU has limited coverage and needs an LLM fallback, which is still only planned. Third, money is a real constraint. The author hopes to work on Leon full time one day and has ideas for monetisation, while promising that the core will always stay open source. Sponsorship is accepted today.

Future evolution

Expect these steps: the official release of the new core, the launch of the skills platform, the arrival of the JavaScript bridge and LLM fallback, and more community work such as Discord and regular calls. Two questions matter most. Will contributions reopen after the new core ships?

And can LLM integration stay truly offline-capable? Until then, Leon is best seen as a long-term project with a clear idea that is still rebuilding its foundation. The idea is worth learning from. Before any production use, check the latest branch and release notes.