taOS: a self-hosted agent platform that treats the framework as replaceable
Self-hosted AI agent OS. Your memory, chat, agents, and files stay on hardware you own, offline by default, cloud by choice. Offline AI memory (taOSmd), self-hosted multi-framework group chat, a full web desktop + app store, and auto-clustering across the consumer hardware you already have (Orange/Raspberry Pi, Mac mini, gaming PC).
At a glance
- What is it?
- taOS is a beta, AGPL-3.0 self-hosted AI agent platform that keeps memory, chat and files on your own hardware, with taOSmd as its framework-agnostic memory layer. The design bet is that the agent framework should be swappable without losing history, and the README is candid that large parts of its app, framework and model catalogs are untested.
- Who is it for?
- Adopt taOS if you want agent memory and chat to live on hardware you own and you accept beta rough edges: the README states the install script, backend, API, taOSmd and multi-framework group chat work, while some agent management, worker connections and model routing flows are still being smoothed out.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- 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 September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem taOS targets: agent state trapped inside the framework
Every agent framework tends to own the things that are expensive to recreate: the conversation history, the memory store, the tool credentials, the files the agent produced. Move from one framework to another and you usually rebuild that state by hand. taOS takes the opposite position. The README states that taOS owns the agent's memory, files, communication channels, model access and configuration, and that the framework is "just a replaceable execution engine". The claim is that switching from SmolAgents to LangChain to OpenClaw leaves the agent's history, its Telegram, Discord and Slack connections, its trained LoRA adapters, its files and its API keys intact, with no migration step.
The intended audience is people who already have spare hardware and a reason to keep data off someone else's servers. The README describes an old laptop, a Raspberry Pi, a gaming PC, or several of them at once, and says the platform runs fully offline by default with cloud models as an opt-in. That is a narrower audience than a general chatbot user. It is for someone willing to run a controller, install a systemd unit and accept that a beta product will break in specific places.
How the pieces fit: taOSmd, the framework boundary and the cluster
The mechanism that makes the framework-swap claim plausible is taOSmd, a separate repository linked from the README. It is described as a framework-agnostic AI memory system that any agent framework can read and write through an HTTP API. Because memory sits behind that API rather than inside the framework's process, the framework becomes an interchangeable consumer of state. The README lists the taOSmd stack: a temporal knowledge graph with validity windows and contradiction detection, hybrid semantic plus keyword vector search with a cross-encoder rerank and LLM-assisted query expansion (called the Librarian layer), an append-only archive, automatic fact extraction, intent-aware retrieval routing and multi-layer context assembly.
Above that sits the platform layer. The README describes a full web desktop with 43 bundled apps, 109 catalog apps, 47 MCP plugins, 17 agent frameworks, a curated local model catalog of 120 manifests spanning LLMs, vision, embeddings, audio and image generation, plus search over a HuggingFace model index. The screenshots show six agents on six different frameworks (OpenClaw, Hermes, SmolAgents, Langroid, PocketFlow, OpenAI Agents SDK) in one shared channel, which is the group-chat feature the README calls multi-framework group chat.
The hardware story is clustering: the README says taOS turns spare machines into a distributed AI compute cluster and lists Apple Silicon via MLX, NVIDIA, AMD, Rockchip NPU, Raspberry Pi and Android phones. The repository topics include vllm, kv-cache-quantization and turboquant, and the model catalog includes RK3588 NPU variants and Hailo-10H HEF variants, so the intended inference path is local. The README does not, in the supplied material, describe the scheduling or sharding algorithm behind the cluster, so how work is divided across heterogeneous nodes is not something I can state.
Installing the controller and the one verified platform
The README gives a single install command for the controller, covering Debian, Ubuntu, Fedora, Arch, Alpine and macOS:
curl -fsSL https://raw.githubusercontent.com/jaylfc/taOS/master/scripts/install-server.sh | sudo bash
Running it without sudo is documented as installing a user-mode systemd unit instead. The script is described as idempotent and safe to re-run, with environment-variable overrides for install path, branch and port. The README does not name those variables in the material supplied, so I cannot list them; the installer is said to print an environment banner for bug reports.
The verified-installs table has exactly one entry in the text provided: an Orange Pi 5 Plus 16GB on the RK3588, running Armbian on a Debian trixie base, which the README says runs the maintainer's stack daily including the RK3588 NPU memory and embedding path. Everything else is unverified by the project's own standard. That asymmetry matters: the install script supports many distributions, but only one hardware and OS combination is listed as verified end to end. If you are on anything else, you are the test case.
The catalog is the weak point, and the README says so
The most useful paragraph in the README is the warning about catalogs. With 100+ apps, 16 frameworks and a large model catalog, it states that plenty of install manifests have not been exercised on real hardware, so some apps, frameworks and models will fail to install. The maintainer asks for an issue with the name and the error, and says most manifest fixes ship same-day.
That is an honest limitation, and it is also a structural one. A catalog of 120 local model manifests plus 109 catalog apps plus 17 frameworks is a surface area no single maintainer can validate across RK3588, Hailo-10H, Apple Silicon, NVIDIA, AMD, Raspberry Pi and Android targets. The beta note is equally direct: the install script, backend, API, taOSmd and multi-framework group chat work, while some agent management, worker connections and model routing flows are still being smoothed out. Model routing being incomplete is a real constraint for anyone expecting the platform to pick the right local model automatically across a cluster.
The second limitation is the memory claim itself. The README reports 97.0% end-to-end Judge accuracy on LongMemEval-S, 500 questions across 50+ sessions, and explicitly notes that the cited comparators, MemPalace at 96.6% and agentmemory at 95.2%, publish Recall@5 retrieval scores, which is a different and weaker measurement. The README concedes the metrics are not apples-to-apples until someone re-runs end-to-end. So the number is not directly comparable to the numbers it sits next to, and the honest reading is that taOSmd's evaluation is stricter, not that it is proven better. The per-category figures (knowledge-update 100%, multi-session 98.5%, single-session-preference 90.0%) come from the maintainer's own hybrid-plus-query-expansion configuration, and I have not reproduced them.
Where taOS is the wrong tool
If you want a hosted assistant that works after a five-minute signup, taOS is the wrong shape entirely. It expects a machine you control, a systemd unit, and tolerance for beta software. The offline-by-default stance is a cost, not a free feature: you supply the electricity, the storage and the model weights.
If your workload depends on a specific catalog app or a specific model manifest, the README's own warning applies. Unverified manifests fail, and you will be filing an issue rather than shipping. If you need model routing to be finished, the beta note lists it as still being smoothed out. And if you need a stable API contract, the version string is 1.0.0-beta.52, with releases landing days apart (beta.50 on 2026-08-21, beta.51 on 2026-09-07, beta.52 on 2026-09-08), which tells you the interfaces are still moving.
How taOS differs from a plain local inference server
The closest comparison in the material is a local inference server such as vLLM on its own. vLLM is listed as a repository topic and taOS uses local inference, but the two solve different problems. A bare inference server exposes an OpenAI-compatible endpoint and stops there. It has no opinion about where the agent's memory lives, no desktop, no app catalog, no group chat across frameworks. You would assemble memory, scheduling and a UI yourself.
taOS puts a controller in front of inference and claims ownership of the state layer through taOSmd, then wraps it in a web desktop and a catalog. The trade is control for surface area. With a bare inference server you choose every component and every version. With taOS you get the memory system, the app store and the clustering for free, and you inherit the catalog risk and the beta churn described above. Neither is strictly better; they fail in different ways. The inference server fails when you need orchestration you did not build. taOS fails when a manifest in its catalog has not been run on your board.
Licence, maintenance and what to check before you install
taOS is AGPL-3.0. The practical implication, stated plainly and without legal advice: if you modify taOS and offer it to users over a network, the AGPL's source-availability condition is designed to reach that modified version. For an internal, self-hosted deployment on your own hardware the obligation is lighter, but if you plan to build a hosted service on top of taOS, read the licence text and get your own advice. The README also mentions a self-hostable binary mirror and an air-gapped install path, which matters if the machine has no outbound network.
Maintenance cost is visible in the release cadence. Three beta releases in roughly three weeks, with the most recent push on 2026-09-10, means you should expect to re-run the install script (documented as idempotent) rather than treat the controller as a set-and-forget service. The memory system lives in a separate repository, taosmd, so upgrades touch two projects.
Before installing, check three things. First, whether your board and OS appear in the verified-installs table, which currently lists only the Orange Pi 5 Plus 16GB on Armbian. Second, whether the app or model manifest you actually need is one of the exercised ones, because the README states many are not. Third, read the taosmd repository for the LongMemEval-S methodology, since the README itself flags that its end-to-end Judge number and the comparators' Recall@5 numbers are not the same measurement.
Editorial conclusion
Adopt taOS if you want agent memory and chat to live on hardware you own and you accept beta rough edges: the README states the install script, backend, API, taOSmd and multi-framework group chat work, while some agent management, worker connections and model routing flows are still being smoothed out. Do not adopt it if you need a stable catalog, since the README warns that many of the 100+ apps, 16 frameworks and model manifests have not been exercised on real hardware and some will fail to install. Before committing, verify the taOSmd LongMemEval-S claim by reading the separate taosmd repository, confirm your platform appears in the verified-installs table, and test the specific app or model manifest you depend on.
Community notes