← Back to all projects

eliza

TypeScript agents from character files and plugins, inside a product stack that now outweighs the framework

OfficialMIT
Stars
19.2k
Forks
5.7k
Open issues
1.3k
Last commit
28 Aug 2026

What is eliza?

You write a character file — a name, a system prompt, a few bio lines and the list of plugins to load — and the runtime turns it into an agent that stores each message, composes context from the providers the turn actually routes to, lets the model pick an action, and files what it learned through evaluators that run after the reply. First-party plugins ship in the same repository for the chat platforms people already use, MCP servers, browser and desktop control, calendar and inbox assistants, non-custodial EVM and Solana wallets, and an on-device model path that answers with the network off. Two things to weigh before adopting it: the repository is a whole product stack — desktop and mobile apps, a hosted cloud, native device bridges — so you take on far more than an agent library, and the stable release on npm is still the older 1.x line while the stack described here ships only under beta and alpha tags.

What can you do with eliza?

  • Write the agent as a character file — Character holds name, a system prompt, bio and topics as lists of strings, messageExamples as groups of example exchanges, and style, whose all voice is the shared one that both chat and post build on. plugins names the packages to load, and knowledge points at documents the agent can look things up in.
  • Learn which providers the runtime actually asks — AgentRuntime stores the message, composes state, lets the model choose among registered actions, runs their handlers, then hands the turn to evaluators once the reply is out. Composition is selective: providers marked private or dynamic are skipped outright, and the rest run only when their declared contexts match the ones the turn was routed to — declare nothing and you get general, which drops out of narrow planner turns. alwaysInResponseState is the opt-in for a signal that should always be there.
  • Add capability as a plugin object — A Plugin exports any mix of actions (a validate check plus a handler returning success or failure), providers (a get returning text and structured data), evaluators, long-running services, model handlers, HTTP routes, app views and event listeners. The 2.x beta CLI scaffolds one with elizaos create my-plugin --template plugin; on the 1.x release that npm still installs by default the same flag is --type plugin.
  • Put the agent where people already talk — Connectors for Discord, Telegram, Slack, WhatsApp, Signal, Matrix, WeChat, X, Instagram and iMessage ship in the repository, alongside plugin-mcp, which reads servers from settings.mcp.servers and exposes their tools through a single MCP action, and assistant plugins for calendar, contacts, inbox, notes, todos and reminders. Of the hundred-plus plugin directories, roughly thirty are native device bridges that only do anything inside the Eliza app.
  • Run the models on the machine itself — plugin-local-inference serves text generation, embeddings, transcription, Kokoro speech synthesis, image generation and image description on-device, needing no network once the model files land in ~/.eliza/models. Routing is set per capability from the dashboard, so transcription can stay local while reasoning goes to a hosted provider.
  • Let it drive a browser or the desktop — plugin-browser adds a BROWSER action — open, navigate, click, type, fill, press, scroll, hover, drag, snapshot, screenshot — driving an embedded browser view, a paired Chrome or Safari extension, or a Playwright endpoint. plugin-computeruse takes the machine itself: screen capture, mouse and keyboard, window management, clipboard and OCR, with an approval inbox in front of it. Both are off until you enable them, and desktop input needs cliclick on macOS or xdotool on Linux.

Before you choose eliza

  • As of August 2026 the stable npm tag for elizaos and @elizaos/core still resolves to the 1.x line last published in January, while the 2.x stack described here ships only under the beta and alpha tags.
  • In August 2026 the founder said the ELIZAOS token was dead and the foundation winding down after a class-action settlement transferred the remaining treasury, while pledging that open-source development continues.

Star history

17 Aug to 28 Aug · +118

19.1k19.2k

Frequently asked questions

Is eliza free for commercial use?

eliza is released under the MIT licence — OSI-approved open source, which permits commercial use.

How can eliza be deployed?

eliza is available as Self-hosted / Runs locally / Managed cloud.

Documentation

Reproduced from the elizaOS/eliza README, published under MIT. Read the original ↗

elizaOS is an open-source TypeScript framework and product stack for autonomous AI agents. This monorepo contains the core runtime, the Eliza app, the CLI, cloud services, native bridges, and first-party plugins. The bootable Linux and Android distributions live in the separate elizaOS/os repository.

Choose a starting point

GoalStart here
Use ElizaOpen the web app, visit Eliza downloads, or use a published GitHub release
Run this repositoryFollow Run Eliza from source
Build an agent or pluginInstall the elizaos CLI and read the developer docs
ContributeRead CONTRIBUTING.md and the repository guide in AGENTS.md
Run a whole device as elizaOSUse the installers and target guides in elizaOS/os

Run Eliza from source

The repository pins Bun and Node versions in package.json. Install those versions, then:

git clone --filter=blob:none https://github.com/elizaos/eliza.git
cd eliza
bun install
bun run dev

bun install also prepares submodules and patches. The legacy archive artifact bundle is never pulled implicitly; fetch it deliberately with bun run fetch:archive-artifacts if you need those fixtures.

Common repository commands:

bun run build       # build the workspace with Turbo
bun run verify      # package parity, dependency, type, lint, and audit gates
bun run test        # repository unit/integration test lane
bun run test:e2e    # end-to-end lane
bun run cloud:mock  # local Eliza Cloud stack with mocks

See AGENTS.md for package scoping, shared development servers, and the evidence required before a change is considered complete.

What is in the stack?

Eliza

Eliza is the user-facing agent app for web, desktop, and mobile targets. Its capabilities are supplied by the runtime and installed plugins, including:

  • chat, voice, memory, knowledge, and document workflows;
  • messaging and workspace connectors;
  • calendar, reminders, inbox, goals, health, and other personal-assistant domains;
  • browser and desktop automation;
  • camera, phone, messages, contacts, location, and other native device bridges;
  • non-custodial EVM and Solana wallet operations with approval boundaries; and
  • scheduled workflows, coding-agent orchestration, and installable app views.

Availability depends on the operating system, installed plugins, granted permissions, and configured model or service providers. Package-level READMEs document the exact support and setup for each capability.

The framework

The framework is model-agnostic and extended through plugins:

  • @elizaos/core defines AgentRuntime, the canonical types, the message loop, memory and state primitives, and plugin contracts.
  • @elizaos/agent assembles a standalone agent and HTTP backend around the core runtime.
  • @elizaos/app-core provides shared application hosting, API, and platform orchestration for Eliza app targets.
  • @elizaos/ui contains the shared React UI used by app surfaces.
  • elizaos is the project and plugin scaffolding, upgrade, and deployment CLI.

A plugin exports a Plugin object. Plugins can register actions, providers, evaluators, services, model handlers, routes, events, tests, and app views. See the plugin component guide and the first-party implementations under plugins/.

Local inference

@elizaos/plugin-local-inference provides the Eliza-1 on-device path. The current Eliza-1 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 the required assets are downloaded, eligible operations can run without a network connection.

Local inference is not forced on hardware that cannot support it. Eliza can route each model capability to local, direct-provider, or Eliza Cloud backends.

Eliza Cloud

Eliza Cloud is optional. It provides account and authentication services, hosted model routing, application and agent deployment, remote connectivity, and cross-device product services. The local runtime and direct model-provider configuration remain first-class paths.

elizaOS distributions

The standalone elizaOS/os repository owns bootable Linux and AOSP distributions, installers, release manifests, and OS toolchains. This monorepo retains the Eliza application shells and native runtime bridges used by desktop, iOS, Android, and device integrations.

Build with elizaos

The beta CLI published from this branch uses the unscoped elizaos package:

bun add --global elizaos@beta
elizaos create my-project --template project
elizaos create plugin-example --template plugin

Projects are deployable workspaces; plugins are reusable capability packages. The packaged templates and their scaffold contracts live in packages/elizaos/templates/.

To embed the runtime directly without the CLI or application host, import @elizaos/core. The scenario runner provides executable integration coverage against a real runtime and, when configured, live models.

Repository map

packages/        runtime, hosts, UI, CLI, docs, cloud, native code, and tooling
plugins/         first-party model, connector, domain, app, and device plugins
scripts/         repository-wide checks, test orchestration, and release tools
patches/         dependency patches applied during installation

Every maintained package or plugin should explain its public surface, scripts, configuration, and local constraints in its own README.md and paired CLAUDE.md / AGENTS.md. Read the nearest package guide before making changes.