elizaOS packages a runtime, product app, cloud code, and native bridges
elizaOS is much larger than an agent loop with a few tools. Its monorepo contains AgentRuntime, shared types, memory and state primitives, plugin contracts, a standalone agent server, React UI, application hosting, the Eliza product, a scaffolding CLI, cloud services, native bridges, and first-party plugins. A separate repository owns bootable Linux and Android distributions, while this one retains the application shells and device integrations.
The breadth creates a plausible path from experiment to product. A plugin can register actions, providers, evaluators, services, model handlers, routes, events, tests, and app views. Eliza itself lists chat, voice, memory, documents, messaging, calendars, browser control, camera, phone, contacts, location, scheduled work, coding agents, and wallet operations. Availability depends on platform, permission, plugin, and provider, so the feature list is a menu rather than one universal installation.
The source tree is nearly 1 GB before dependencies
Our checkout at commit 5161753 occupied 990.8 MB before installation. It contained 31,514 files and about 6,921,967 source lines. The scan found 61 CI workflow files and monorepo workspaces, with no Dockerfile or top-level tests directory. These figures put elizaOS in platform territory: a contributor should choose a package first, read its local README and agent guide, and avoid treating the repository as one application.
The README pins Node and Bun versions in package.json. Its source path is bun install followed by bun run dev; installation also prepares submodules and applies patches. Repository commands then cover Turbo builds, verification gates, unit and integration tests, end-to-end tests, and a mocked local cloud stack. Legacy archive fixtures are downloaded only through an explicit command, which avoids adding them silently to an already large checkout.
What happened when we ran it
Our install step failed after 5 seconds in a fresh unprivileged Node 22 container with 3 CPUs and 8 GB of RAM. npm returned error code EOVERRIDE: the override for @playwright/test@^1.62.1 conflicted with a direct dependency. The log points to npm's override resolution and gives no second cause. That is the complete measured outcome for installation.
The lab recorded no build or test result after the install stopped. We therefore cannot say whether commit 5161753 builds or whether any part of its suite passes in this environment. The README's intended source route uses pinned Bun and Node versions, while the visible failure came from npm. That distinction is useful for diagnosis, but it does not turn our failed run into a pass or establish that Bun would have succeeded.
Local inference offers four text tiers with hardware-dependent routing
The first-party local-inference plugin describes Eliza-1 text tiers at 2B, 4B, 9B, and 27B, plus local embeddings, speech, vision, and image-generation assets. Hardware detection routes eligible work to supported backends after assets download. Operations may run offline once those assets exist, but local execution is not forced when hardware cannot support it.
The same capability can route to a direct model provider or optional Eliza Cloud. Cloud adds accounts, authentication, hosted model routing, remote connectivity, deployment, and cross-device services. This flexibility helps product teams mix private and hosted work. It also gives operators more boundaries to document: which model handled each action, where memory lives, what leaves the device, and which cloud account or provider key pays for it.
Device and wallet plugins require narrow permission design
Eliza can expose browser and desktop automation, camera, phone, messages, contacts, and location through installed plugins and native bridges. It also lists non-custodial EVM and Solana wallet operations with approval boundaries. Those abilities can make a personal agent useful, but they move mistakes beyond a chat transcript. A bad action may send a message, expose private context, alter a browser session, or prepare a wallet operation.
Treat every plugin as a separate security decision. Install only the capabilities a product needs, request operating-system permissions at the moment of use, and keep approval boundaries outside model-generated text. The repository links a security policy and architecture documentation, which is a good starting point. Production review still has to follow the exact plugin, platform bridge, and provider configuration being shipped.
Current issue traffic shows fast change and unfinished edges
GitHub recorded the last push on August 27, 2026, with 1,240 combined issues and pull requests. Work that morning covered cloud deployment, voice handoff, authentication, browser UI, media enumeration, and personal-assistant timing. Issue #29498 reported that the media gallery silently skipped sources after the tenth matching table; pull request #29501 proposed removing that cap. That pace is active, but it also means adopters should pin revisions and follow the packages they use.
The latest release endpoint returned pr-evidence-11, published August 23 with before-and-after visuals for pull request #26518. That is an unusual artifact to present as the repository's latest release and is not a normal product version. Users should obtain version guidance from the relevant package, app download path, and branch documentation instead of assuming GitHub's latest-release API identifies a stable platform bundle.
elizaOS suits a product team better than a weekend agent script
The framework becomes attractive when a team genuinely needs shared runtime contracts across an agent server, UI, plugins, native devices, and several model routes. Building those layers separately would be expensive. The CLI and package structure give specialists places to work without inventing every boundary from scratch.
The cost is ownership. Our install failed before build or tests, the checkout approached 1 GB, and capabilities span sensitive device and wallet permissions. A team adopting elizaOS should assign maintainers to a narrow package set, reproduce the pinned Bun setup, and prove each selected plugin on its target platform. For a single workflow or service agent, LangGraph or AutoGen will usually leave less platform code to audit.