The repository is an agent product stack, not one agent library
elizaOS puts its runtime, standalone host, shared UI, cloud services, native bridges, app shells, and first-party plugins in one TypeScript monorepo. The runtime supplies memory, state, authorization, model handlers, actions, providers, evaluators, routes, and events. On top of that, the Eliza app targets web, desktop, and mobile. That breadth makes sense for a team building an agent as a product rather than adding one model call to an existing service.
The scale changes the adoption decision. Our commit 45bf7ae checkout contained 32,320 files, roughly 6,892,764 lines of source, and used 647.6 MB before a successful dependency install. The current README maps separate areas for the runtime, app hosting, UI, cloud code, operating-system tooling, native code, and plugins. A developer cannot judge this repository from the root quick start alone. Each maintained package is supposed to carry its own README and AGENTS.md.
Local, direct-provider, and cloud routes are all first-class choices
The framework is model-agnostic, so an agent can call a provider directly, use Eliza Cloud, or use the local-inference plugin. The README describes local text models in 2B, 4B, 9B, and 27B tiers, plus embeddings, speech, vision, and image assets. Hardware detection chooses supported backends, and eligible work can run offline after the required assets download. That is useful flexibility, but it also leaves the buyer responsible for deciding which path is supportable on each target device.
Eliza Cloud adds hosted routing, authentication, deployment, remote connectivity, and cross-device services. It is optional according to the README. Direct providers still need their own credentials, and live benchmark runs require provider credentials and may incur charges. Wallet plugins also cover EVM and Solana operations with approval boundaries. Any team enabling those paths should review permissions and secrets per plugin, not assume one root configuration describes every capability.
What happened when we ran it
Our sandbox run did not reach a working installation. We cloned commit 45bf7ae into an unprivileged container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. The npm install exited with code 1 after 1 second. Its final lines reported EOVERRIDE and said the override for @playwright/test@^1.63.0 conflicted with a direct dependency. That is all the log establishes, so we are not assigning a deeper cause.
The repository scan found 71 CI workflow files, a workspace monorepo, no root Dockerfile, and no root tests directory. Those facts do not say that elizaOS lacks tests. The current README gives bun run test, bun run test:e2e, and package-scoped commands, while the workflows show substantial automation. They do say our npm route was the wrong proof of readiness: it failed before build or test results could tell us anything useful about commit 45bf7ae.
The documented Bun path does more than fetch packages
The source instructions pin Bun and Node versions in package.json, then call for bun install and bun run dev. Installation prepares submodules and dependency patches, provisions supported host prerequisites, and builds or verifies a staged desktop inference library. A GGUF embedding model downloads later during local-inference warmup. In other words, the quick command crosses JavaScript packages, native artifacts, host setup, and model assets. Reproducing it in CI takes more planning than copying two shell lines.
That distinction matters because our measured npm failure is concrete, while a Bun result would be speculation. Teams evaluating the project should pin the documented runtimes, run the Bun workflow on their actual operating system, then scope verification to the packages they intend to ship. Device builders have another branch of work under packages/os, which owns Linux and AOSP tooling, installers, manifests, and target guides.
Third-party plugin listings are closed even though plugins remain central
Plugins are the main extension surface, but repository contribution policy has narrowed. The README says the project no longer accepts third-party plugins or registry items, including new listings and listing updates. Existing teams can still write plugins against the contract. They should not choose elizaOS on the assumption that the main repository will distribute or endorse a new integration.
GitHub showed 19,543 stars, 74 combined open issues and pull requests, and a push on October 6, 2026. Open reports from that day covered timezone boundaries, inbox pagination, message ordering, and stale account context. That issue activity and the same-day push indicate active work. The latest-release endpoint was less useful for version judgment: it returned pr-evidence-11, published August 23, with a name about revised structured metadata visuals rather than a normal product release.
Choose elizaOS only when its breadth removes work you already have
The strongest case is a team that needs an agent runtime plus maintained app surfaces, local and hosted model routes, plugins, and device bridges. Building those layers independently can cost more than learning this monorepo. The weak case is a service that only needs durable tool calls or a small agent graph. LangGraph, CrewAI, or AutoGen asks you to build more of the product, but each keeps the initial boundary narrower.
Our 647.6 MB checkout and immediate npm failure set the right expectation: evaluation starts with environment work, package selection, and a clean Bun run. elizaOS may repay that effort when the app and platform pieces match your roadmap. If you only need orchestration, the extra surfaces become code you must understand without receiving much value from them.