elizaOS: A TypeScript Runtime and App Stack for Autonomous Agents

What elizaOS Actually Solves

elizaOS is not just an agent framework. The README describes it as an open-source TypeScript framework and product stack for autonomous AI agents. The core problem it addresses is the gap between running a single agent and running a full application surface around that agent. It provides a runtime, a user-facing app called Eliza, a CLI, cloud services, native bridges, and first-party plugins in one monorepo. The intended user is a developer who wants to build an agent or a plugin, or someone who wants to run the Eliza app on web, desktop, or mobile. It is not for someone who wants a bootable OS image, because those live in the separate elizaOS/os repository. The scope is deliberately broad, which is both a strength and a source of complexity.

The Monorepo Architecture and Its Boundaries

The repository is organized into packages and plugins. The core is @elizaos/core, which defines AgentRuntime, canonical types, the message loop, memory and state primitives, and plugin contracts. On top of that, @elizaos/agent assembles a standalone agent and HTTP backend. @elizaos/app-core provides shared application hosting and platform orchestration, and @elizaos/ui holds the shared React UI. The elizaos package is the CLI for scaffolding, upgrade, and deployment. This separation means you can embed the runtime directly by importing @elizaos/core without using the CLI or the app host. The README makes that explicit. The monorepo also contains patches/ for dependency patches applied during installation, and scripts/ for repository-wide checks. The key boundary is that bootable Linux and Android distributions are not here; they are owned by elizaOS/os. That split matters when you evaluate what you are actually getting from this repository.

How the Plugin System Works

A plugin exports a Plugin object. That object can register actions, providers, evaluators, services, model handlers, routes, events, tests, and app views. This is the central extension mechanism. The README points to a plugin component guide for details, but the visible contract is clear: plugins are not just for model calls, they can add routes and app views, which is unusual for an agent framework. First-party implementations live under plugins/. The framework is model-agnostic, meaning you can route each model capability to local, direct-provider, or Eliza Cloud backends. That routing is per capability, not per agent, which gives fine-grained control. The plugin system is the reason the project calls itself an operating system rather than just an agent library, because plugins can extend the application surface itself.

Running elizaOS from Source: Commands and Constraints

The README pins Bun and Node versions in package.json. You must install those versions first. The clone command uses git clone --filter=blob:none to avoid pulling large blobs. Then bun install prepares submodules and patches. The README warns that the legacy archive artifact bundle is never pulled implicitly; you must run bun run fetch:archive-artifacts deliberately if you need those fixtures. Development starts with bun run dev. Build uses Turbo via bun run build. Verification is a single command: bun run verify, which runs package parity, dependency, type, lint, and audit gates. Tests are split into bun run test and bun run test:e2e. For local cloud development, bun run cloud:mock spins up a mocked Eliza Cloud stack. The CLI is installed globally as elizaos@beta, and you create projects with elizaos create my-project --template project and plugins with elizaos create plugin-example --template plugin. The templates live in packages/elizaos/templates/. This is a concrete path, but the beta status of the CLI is a caveat.

Local Inference and the Device Path

The local inference plugin, @elizaos/plugin-local-inference, provides an on-device path called Eliza-1. The current registry contains 2B, 4B, 9B, and 27B text tiers based on Gemma 4, plus local embeddings, speech, vision, and image-generation assets. Hardware detection and model routing select supported backends. After required assets are downloaded, eligible operations can run without a network connection. The README is careful to say that local inference is not forced on hardware that cannot support it. You can route each capability to local, direct-provider, or Eliza Cloud backends. This is a real differentiator for privacy or offline scenarios, but it depends on downloading large assets, and the actual supported hardware list is not detailed in the README. You would need to read the plugin's package README for exact constraints.

The Eliza App and Native Bridges

Eliza is the user-facing agent app for web, desktop, and mobile. Its capabilities come from the runtime and installed plugins. The README lists chat, voice, memory, knowledge, document workflows, messaging and workspace connectors, calendar, reminders, inbox, goals, health, browser and desktop automation, camera, phone, messages, contacts, location, and non-custodial EVM and Solana wallet operations with approval boundaries. That is a wide surface, but availability depends on the operating system, installed plugins, granted permissions, and configured providers. The README explicitly says package-level READMEs document exact support. This means you cannot assume a feature works on every target. The native bridges for desktop, iOS, Android, and device integrations are retained in this monorepo, but the bootable OS distributions are not. If you want to run a whole device as elizaOS, you must go to the separate os repository.

Limitations and Cases Where It Is the Wrong Tool

The most obvious limitation is that this repository is not a complete OS. The bootable Linux and Android distributions are in a separate repository, so anyone expecting a turnkey device image from this monorepo will be disappointed. Second, the CLI is beta, which means the scaffold contract may change. Third, the README mentions that local inference requires downloading required assets, and hardware detection selects supported backends, but it does not specify which hardware is supported. That ambiguity is a real gap. Fourth, the repository has a heavy verification culture, with AGENTS.md requiring evidence before a change is considered complete. That is good for quality but adds friction for casual contributors. If you need a simple, single-file agent script, this stack is overkill. If you need a stable, non-beta CLI for production scaffolding, the beta status is a warning. The right tool depends on whether you want the full application stack or just a runtime.

Alternatives and How They Differ

A direct alternative is LangChain, which also provides a framework for building agents with models, tools, and memory. The difference is in scope and extension model. LangChain is a library that you embed in your own application; it does not ship a user-facing app, a CLI, or native device bridges. elizaOS, in contrast, provides the entire stack, including the Eliza app and a plugin system that can register routes and app views. Another alternative is the AutoGen framework from Microsoft, which focuses on multi-agent conversations and orchestration. AutoGen does not provide a bootable OS or a mobile app shell. The key difference is that elizaOS aims to be an application platform, not just an agent library. If you only need agent logic, LangChain or AutoGen may be simpler. If you want a full product surface, elizaOS is more aligned.

Maintenance, Upgrades, and License Implications

The repository is under the MIT license, which is permissive and allows commercial use, modification, and distribution without copyleft obligations. That is a favorable license for integration into proprietary products. The maintenance cost is visible in the repository structure: every maintained package or plugin should have its own README.md and paired CLAUDE.md or AGENTS.md. The README says to read the nearest package guide before making changes. The verification gates (bun run verify) enforce package parity, dependency, type, lint, and audit checks. That means upgrades are not trivial; you must pass those gates. The repository pins Bun and Node versions, so upgrading those runtimes requires deliberate action. The recent releases are tagged as pr-evidence-* and [internal] CI evidence assets, which suggests a heavy CI and evidence process. This is good for stability but adds overhead for external contributors. The patches/ directory indicates that dependency patches are applied during installation, so you need to be aware that some dependencies are not used as-is.

Editorial conclusion

Adopt elizaOS if you are a TypeScript developer building agents or plugins and want a model-agnostic runtime with a plugin system and a local inference path. Do not adopt it if you need a turnkey bootable OS, because those distributions live in a separate repository and are not part of this monorepo. Before committing, verify the pinned Bun and Node versions in package.json, check whether the beta CLI (elizaos@beta) matches your workflow, and confirm that the specific plugin you need is maintained. The repository's own verify command (bun run verify) gates package parity, dependency, type, lint, and audit checks, so run it before relying on any contribution.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes