AlphaAvatar: two plugins marked Planned that already exist
A real-time interactive Omni Avatar built on LiveKit, which allows you to seamlessly integrate with any open source Avatar components (real-time model, visual, voice, memory, search, etc.).
At a glance
- What is it?
- AlphaAvatar is an Apache-2.0 self-hostable assistant framework built around a plugin runtime, a LiveKit adapter and eight architecture layers. Its own plugin tables are more revealing than the marketing: two Foundation plugins are labelled Planned while the page admits the functionality exists, the Perception table stops mid-row, and two top-level packages sit outside the workspace definition.
- Who is it for?
- AlphaAvatar is worth a look for anyone building a long-lived assistant rather than a request and response one, because the architecture commits to things most frameworks leave out: ordered perception events with lineage, semantic addressing, turn taking across modalities, and a storage layer that keeps vectors and traces next to identity. That ambition is also why the tables matter.
- 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 received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 5, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Two Foundation plugins are marked Planned, and the text admits why
The Foundation layer holds three plugins, and only one is real. Voice is marked Available and provides voice activity detection, speech recognition and speech synthesis, sharing reusable voice components with the Router. Provider is marked Planned and is written in the future tense, that it will provide shared model access and task execution and unify structured responses and streaming output through the Foundation layer. Context is marked Planned and will make context construction and composition independently pluggable.
The sentence under the table settles the ambiguity in one line: the Provider and Context functionality already exists, their standalone Foundation plugins are planned, and Voice is currently the only service attached to `FoundationRuntime`.
So the table's two green-looking rows are placeholders for packaging work, not missing features. Anyone reading only the statuses would conclude the framework has no shared model access layer, which is the opposite of what the prose says.
The status legend above the table deserves reading for the same reason. Available means implemented in this source tree, not necessarily enabled by default or API-stable, and planned entries are not yet available as standalone plugins. A status of Available is therefore a statement about the code, not about whether a plugin will be running when you install it.
The Perception table stops partway through the Persona row
The next layer, Perception, is where the page stops. Router is Available and coordinates multimodal routing, addressing, turn taking and interruption, combining speech, transcripts and attention evidence for realtime decisions. Memory is Available, storing durable memories from conversations, tools and environment observations and retrieving what is relevant for continuity.
The third row begins and ends mid-sentence. Persona is marked Available with a description that reads that it builds user profiles and recognizes speakers and faces, and then breaks on an unclosed line break with nothing after it.
That is the last of the plugin tables. The third layer, tools for external tasks, is described in one sentence as adding external capabilities, but no table for it appears, so the plugins the introduction names for MCP, RAG, DeepResearch and the virtual character have no visible status at all.
The introduction also lists Reflection, for self-improvement and long-term behavioural adaptation, and Behavior, for response style, workflow policy and proactive assistance. Neither appears in either visible table, so whether they are plugins, config, or still an idea cannot be read from the page.
avatar-rtc and avatar-cli are in the tree and not in the workspace
The repository is a uv workspace, and its member list is explicit:
[tool.uv.workspace]
members = [
"avatar-core",
"avatar-agents",
"avatar-channels/*",
"avatar-plugins/foundation/*",
"avatar-plugins/perception/*",
"avatar-plugins/tools/*",
]
exclude = []The top-level directories, however, include `avatar-rtc/` and `avatar-cli/` as well, and neither path is covered by any of those globs. `exclude` is present and empty, so nothing is being excused deliberately.
That matters more than a stray directory would suggest, because the RTC adapter is the layer the architecture says connects LiveKit and other realtime backends. A package outside the workspace is not resolved by `uv sync --all-packages`, and the tooling only sets sources for twelve workspace distributions:
alpha-avatar-core = { workspace = true }
alpha-avatar-agents = { workspace = true }
alpha-avatar-channels-whatsapp = { workspace = true }
alpha-avatar-plugins-character = { workspace = true }
alpha-avatar-plugins-deepresearch = { workspace = true }
alpha-avatar-plugins-mcp = { workspace = true }There is no `alpha-avatar-rtc` entry among them. Directories are named `avatar-*` while distributions are named `alpha-avatar-*`, and the LiveKit adapter has neither.
The release Makefile still defaults to version 0.1.0
Releases are driven by a Makefile whose header is a usage block:
# make release VERSION=0.6.1 TYPE=prod PREVIOUS_TAG=v0.6.0
# make release VERSION=0.6.1 TYPE=testThe variables behind it are the interesting part. `VERSION ?= 0.1.0` and `TYPE ?= test`, so a bare `make release` tags 0.1.0 as a test build. Tags are derived twice: `TAG := v$(VERSION)` and `TEST_TAG := test-v$(VERSION)`, which means test releases land on a separate tag namespace from production ones. Production releases require a notes file that already exists and is committed, `docs/releases/vX.Y.Z.md`, and the GitHub Release itself is opt-in, with `GH_RELEASE ?= 0` while generated pull request notes are on by default.
The file also sets `.RECIPEPREFIX := >`, replacing tabs with a greater-than sign to avoid the tab errors that Make inflicts on YAML-shaped text, and hands the real work to `scripts/release.sh`.
Meanwhile the published tags are in a different line entirely: v0.6.7, v0.6.6 and v0.6.5, with the last push to `main` on 2026-10-01. A default of 0.1.0 in a repository at 0.6.7 is harmless if `VERSION` is always passed and misleading if it is not.
A Makefile.bak sits beside the Makefile, and jiwer sits in the dev group
The root of the repository contains both a `Makefile` and a `Makefile.bak`, alongside `DEPLOY.md`, `ROADMAP.md`, `.env.template`, a `.pre-commit-config.yaml` and a `.gitmodules`. The backup file is committed, which means at least one release script has been overwritten rather than revised.
The development environment is defined through uv rather than a hand-written virtualenv. The setup target creates `.venv` and runs `uv sync --all-packages`, and a `uv.lock` sits at the root. That is the install path the repository actually documents; the visible portion of the project page carries no install command of its own.
The dependency groups are more revealing than the tool choice. The dev group contains pre-commit, mypy, pytest, ruff, pytest-asyncio, python-dotenv, and then two packages with a specific purpose: `jiwer`, which computes word error rate, and `scipy`. Word error rate is how speech recognition is measured, and the Voice plugin is the only component attached to the Foundation runtime, so the test dependencies line up with the one plugin that is actually shipped. `tiktoken` in the same group points the other way, at token counting for context work.
Tooling is strict in a way worth noting: mypy runs in strict mode, and ruff targets Python 3.11 with a line length of 100 and pycodestyle, pyflakes, isort, bugbear, comprehensions and pyupgrade selected.
Eight layers, and the substance is in the middle two
The runtime is described as eight layers. Channels carry voice, text, camera, screen, files and messaging platforms. The RTC adapter connects LiveKit and other realtime backends, so LiveKit is the default rather than the only option. Assistant outputs deliver voice, text, avatar responses, tool actions and status updates, and storage holds identity, memory, vectors, traces, artifacts and media.
The two middle layers are where the design decisions live. Core Perception normalises typed multimodal observations, tracks source and segment lineage, orders perception events, and keeps annotations, timelines and historical snapshots. Agent and Runtime manages sessions, context, semantic addressing, conversation focus, multimodal turn taking, shared inference access and runtime lifecycle.
Those two lists are where the interesting vocabulary lives, and none of it is explained further on the page. What a lineage is, what turns an observation into an ordered event, how conversation focus is resolved between a camera frame and a spoken interrupt, and what shared inference access means in practice, are all left to the documentation site.
The provider layer underneath connects models, embeddings, routing, tracing and structured output, which is the same capability the Foundation table describes as a planned Provider plugin. Two descriptions of one layer, in two places, with two different statuses.
Six use cases, and no plugin is named for any of them
The page states six things the framework is designed for: tracking personal metrics such as health, fitness, sleep and study progress; organising notes and retrieving them through RAG; scheduling tasks and notifying proactively; planning multi-step work and calling tools automatically; understanding preferences across conversations and modalities; and bridging to email, databases, APIs and messaging.
None of the six names a plugin. The visible plugin tables cover Voice, Provider, Context, Router, Memory and Persona, and of those only Voice is attached to the Foundation runtime. RAG and DeepResearch appear in the introduction's list of tools and in the workspace source mapping, but their table is past the point where the page stops.
The framing sentence at the end of the table is that AlphaAvatar is not just a chatbot but a foundation for building stateful, proactive, multimodal and self-evolving personal AI assistants. Self-evolving is the claim with the least visible support, since the Reflection capability that would carry it appears nowhere in either visible table.
The hosting picture is separate from the code. There is a hosted service at the project site, a demo, documentation at a docs subdomain, a Discord channel, GitHub Discussions, and a roadmap file at the root.
Editorial conclusion
AlphaAvatar is worth a look for anyone building a long-lived assistant rather than a request and response one, because the architecture commits to things most frameworks leave out: ordered perception events with lineage, semantic addressing, turn taking across modalities, and a storage layer that keeps vectors and traces next to identity. That ambition is also why the tables matter. Provider and Context are listed as planned while admitting the capability exists elsewhere, the plugin status legend warns that available does not mean enabled or API-stable, and the perception list is not finished. Before adopting it, read the Foundation and Perception tables as a status board rather than a feature list, check which of the two Realtime packages is inside the uv workspace, and pin a release, since the release Makefile defaults to version 0.1.0 while the published tags are in the 0.6 line.
Frequently asked questions
What is AlphaAvatar and what is it built on?
AlphaAvatar is a self-hostable personal assistant framework written in Python under the Apache-2.0 license, organised as a uv workspace of avatar-core, avatar-agents, channels and plugins. Its realtime layer goes through an RTC adapter that connects LiveKit and other backends, and it ships a built-in virtual character for voice and avatar interaction.
Which AlphaAvatar plugins are available today?
Voice, which provides voice activity detection, speech recognition and speech synthesis, is the only service attached to FoundationRuntime. Router and Memory and Persona are listed as available in the Perception layer. Provider and Context are marked planned, with the page noting that their functionality already exists and only the standalone plugins are outstanding.
How do I set up a development environment for AlphaAvatar?
The release Makefile documents a setup target that creates a virtual environment with uv venv .venv and then runs uv sync --all-packages, with a uv.lock at the repository root. Tooling is strict, with mypy in strict mode and ruff targeting Python 3.11.
How does AlphaAvatar release new versions?
Through a Makefile wrapper around scripts/release.sh, where VERSION defaults to 0.1.0 and TYPE defaults to test. Production tags take the form v<version> and test tags take the form test-v<version>, production releases require a committed notes file under docs/releases, and creating a GitHub Release is opt-in through GH_RELEASE.
Does AlphaAvatar need any external service to run?
The page presents the framework as fully self-hostable, and the runtime layers cover models, embeddings, routing, tracing, storage for identity, memory, vectors and traces, and assistant outputs, with no external service named as a requirement. The optional integrations are described as degrading gracefully until their variable is set.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/alphaavatar-alphaavatar)