elizaOS
An open-source TypeScript system for building, running, and extending autonomous AI agents.
The workflows use read-only default permissions, environment-scoped credentials, commit-pinned Actions, exact SHA/branch/deployment identity checks, and explicit production approval boundaries. Telegram edge activation requires manual dispatch, an exact source revision, served-state proof, and rollback when success is unproven. The security materials also show private reporting, non-readable provider secrets, encrypted and shredded plans, sanitized credential observability, and secret-leak audits, providing strong evidence for least privilege, sensitive-data handling, external-effect control, and rollback. Deductions: confirmation is demonstrated mainly for selected high-risk workflows and asserted wallet approval boundaries rather than a uniform policy for every agent action; data flow is described architecturally and in localized tests rather than through a complete plugin/cloud/provider inventory; dependency gates exist but no audit result for this revision or comprehensive supply-chain policy is supplied; attribution names contributors and team channels, but the publisher remains unverified as stipulated.
The README, manifest, workflow documentation, and route tests are mutually consistent about execution paths, capability routing, error semantics, and validation entry points. Tests explicitly cover genuine not-found cases, missing credentials, invalid providers, unavailable capabilities, health state, and refusal to fabricate success; workflows likewise emit precise actionable failures. This supports full scores for consistency and failure messages. Node and Bun are pinned and many dependencies are fixed or constrained, with dependency and publication-graph gates, but the large stack still relies on external models, CLIs, cloud services, and plugins, and no offline dependency mirror or availability report for this revision is shown.
The evidence clearly separates end users, agent/plugin developers, contributors, and whole-device users while covering web, desktop, mobile, cloud, self-hosted, and local-inference scenarios. Capability boundaries are explicit: availability depends on OS, plugins, permissions, hardware, and providers, while the account API exposes runtime eligibility and reasons for unavailability. Manual, branch, path, label, and environment triggers are narrowly scoped, with exact target validation for consequential deployment operations. Pinned tool versions, a Windows guide, local/cloud/direct-provider routing, and a light installation option provide thorough environment-fit evidence.
The top-level README supplies a starting-point table, repository map, component ownership, common commands, and contribution and security entry points; information architecture and installation guidance are thorough. The complete MIT text matches the metadata. Examples cover source startup, CLI scaffolding, and test commands, but the supplied evidence has no FAQ or complete end-user walkthrough. Limitations are disclosed but dispersed among availability caveats, security scope, and references to a separate OS repository rather than consolidated. The root version and latest/beta support policy are explicit, yet no changelog or migration history is supplied; beta and alpha surfaces plus a large multi-package naming scheme limit the evidence for naming stability. Maintenance channels, contribution flow, SLAs, and release responsibilities are clear, but registry provenance is unverified and named maintainer governance or succession is not documented.
The product combines a runtime, agent host, UI, CLI, cloud services, local inference, native bridges, and a plugin system into outputs that can be used directly or embedded. Clear startup, build, and deployment paths support strong usability, while capability routing and the breadth beyond a basic chat wrapper demonstrate substantial marginal value. Local execution and a light install can reduce some costs. However, the large monorepo, model assets, hardware needs, external providers, cloud deployment, and extensive validation matrix imply meaningful resource and operational costs, and the evidence supplies no quantitative performance, footprint, or pricing comparison.
Core claims trace to named packages, scripts, workflows, tests, and policy files. README claims about operation, validation, security, and capability boundaries are corroborated by package.json, workflow documentation, and route tests. Test descriptions and assertions distinguish intended behavior, unavailable states, and failures, while cautious phrases such as “depends on,” “optional,” and “when configured” keep conditional capabilities separate from established facts. This static review does not prove that tests pass or deployments are healthy, but that affects confidence rather than these source-based verifiability criteria.
- This is a static review with no execution of code, tests, or dependency audits; the presence of scripts and tests does not prove they pass at this revision.
- The system can connect to model providers, cloud services, messaging platforms, browsers, device APIs, and wallets; review each plugin's permissions, data destinations, retention, and human-approval behavior before deployment.
- Installation runs a substantial postinstall chain and synchronizes runtime artifacts; inspect the lockfile, patches, and install scripts in an isolated environment before running it.
- Security support covers only the current latest and beta minor releases, and third-party plugins are out of scope; older versions and external plugins require separate risk management.
- Strong protections are shown for selected high-risk workflows, but they should not be assumed to apply uniformly to every agent action.
What does this agent do, and when should you use it?
elizaOS is a model-agnostic, open-source TypeScript framework and product stack for autonomous AI agents. The monorepo combines the core runtime, the user-facing Eliza application, project and plugin tooling, cloud services, native bridges, a shared React UI, and first-party plugins. Its @elizaos/core package defines AgentRuntime, the message loop, memory and state primitives, and plugin contracts, while @elizaos/agent packages the runtime as a standalone agent with an HTTP backend. Eliza targets web, desktop, and mobile, with plugin-dependent capabilities spanning conversation, voice, knowledge, documents, messaging, personal-assistant workflows, automation, and wallet operations. Model requests can be routed to on-device inference, directly configured providers, or optional Eliza Cloud services; bootable Linux and Android distributions are maintained separately in elizaOS/os. It is a fit for teams seeking an embeddable runtime, broad plugin surface, and multiple delivery paths, provided they can manage the platform, permission, hardware, and provider dependencies of the capabilities they select.
AgentRuntime receives messages through the core message loop, combines them with memory and state primitives, and invokes plugin components registered as actions, providers, evaluators, services, model handlers, routes, events, or app views. @elizaos/agent wraps that runtime in a standalone agent and HTTP backend; @elizaos/app-core supplies application hosting, APIs, and platform orchestration, and @elizaos/ui supplies shared React interfaces. Through installed plugins, the Eliza application can run chat, voice, memory, knowledge, and document workflows; connect messaging and workspace services; manage calendars, reminders, inboxes, goals, and health domains; and perform browser or desktop automation. With permission, native bridges expose capabilities such as camera, phone, messages, contacts, and location, while wallet integrations perform non-custodial EVM and Solana operations behind approval boundaries. @elizaos/plugin-local-inference detects hardware and routes models so eligible text, embedding, speech, vision, or image-generation work can run offline after assets are downloaded; other requests can use direct providers or Eliza Cloud.
- A TypeScript team can embed AgentRuntime from @elizaos/core when it needs its own application around a defined message loop, memory, state, and model integration layer.
- A plugin author can use the elizaos CLI to scaffold a reusable capability package that registers actions, services, routes, events, tests, or application views.
- A product team targeting web, desktop, and mobile can share orchestration and interface code through @elizaos/app-core and @elizaos/ui.
- A team limiting ongoing network dependence can download Eliza-1 assets and use @elizaos/plugin-local-inference for eligible operations on supported hardware.
- A personal-assistant developer can combine plugins for chat, documents, calendars, reminders, inboxes, messaging connectors, and native device functions.
- An organization that wants both managed and self-controlled paths can choose a local runtime, direct model-provider configuration, or Eliza Cloud authentication, routing, and deployment services.
What are this agent's strengths and limitations?
- The runtime is explicitly model-agnostic and can route different capabilities among local inference, direct providers, and Eliza Cloud.
- Its plugin contract spans actions, providers, evaluators, services, model handlers, routes, events, tests, and app views, giving extensions several well-defined integration points.
- The monorepo includes a runtime, HTTP agent backend, shared application host, React UI, CLI, cloud services, and native bridges rather than only a chatbot interface.
- The local-inference path includes hardware detection and model routing, with eligible operations able to run without a network after assets are downloaded.
- Documented build, verification, unit and integration, end-to-end, and mocked-cloud commands provide concrete development and validation lanes.
- The monorepo has a broad footprint, and bun install prepares submodules, patches, and runtime artifacts; the large artifact bundle can add setup, storage, and download overhead.
- Capability availability varies by operating system, installed plugins, granted permissions, hardware, and configured model or service provider, so the full feature list is not uniformly available.
- Local inference is not forced onto unsupported hardware, and the 2B through 27B model tiers introduce device qualification and resource-planning work.
- Bootable Linux and Android distributions reside in the separate elizaOS/os repository, adding a second repository for whole-device deployments.
- The documented CLI is published from the beta branch as elizaos@beta, creating potential interface or scaffold migration risk.
- Wallet, camera, contact, and location features require approval boundaries or operating-system permissions and therefore need deliberate authorization and security design.
How do you install or deploy this agent?
Install the Bun and Node.js versions pinned by the repository's package.json, and ensure Git is available. Then run:
git clone --filter=blob:none https://github.com/elizaOS/eliza.git
cd eliza
bun install
bun run devbun install prepares submodules, patches, and runtime artifacts. For a smaller development setup that omits the large artifact bundle, use bun run install:light instead. The source does not specify universal credential names; network-backed models or services require the configuration and credentials of the selected direct provider or Eliza Cloud. For CLI-only setup, run bun add --global elizaos@beta.
How do you use this agent?
Create a deployable project with:
elizaos create my-project --template projectCreate a reusable plugin with:
elizaos create plugin-example --template pluginTo embed the runtime without the CLI or application host, import @elizaos/core into a TypeScript project. Repository developers can use bun run build for the Turbo workspace build, bun run verify for package parity, dependency, type, lint, and audit gates, bun run test for unit and integration coverage, and bun run test:e2e for the end-to-end lane. Run bun run cloud:mock when a local mocked Eliza Cloud stack is needed. The exact first model or service configuration depends on whether the deployment uses local inference, a direct provider, or Eliza Cloud; the supplied material does not define one universal configuration command.
How does this agent compare with similar options?
Compared with the optional Eliza Cloud path, the local runtime and direct-provider configuration remain first-class options: Eliza Cloud adds accounts, authentication, hosted model routing, application and agent deployment, remote connectivity, and cross-device services, while the other paths preserve more direct runtime and provider control. For whole-device delivery, this monorepo retains Eliza application shells and native runtime bridges, whereas the separate elizaOS/os repository owns bootable Linux and AOSP distributions, installers, release manifests, and OS toolchains.