livekit/agents-js: a Node.js port of the LiveKit Agents framework
Build realtime multimodal AI agents with Node.js
At a glance
- What is it?
- The repository ships a TypeScript framework for realtime voice and multimodal agents, with a plugin table covering STT, LLM, TTS, VAD, turn detection and avatars. The core judgement: the plugin list is the product, and it is narrower than the Python original it is ported from.
- Who is it for?
- Adopt it if your voice agent is a Node.js service and your model vendors appear in the supported plugin table. Do not adopt it if you need a provider that only exists on the Python side, or if you want to run inference inside the agent process rather than calling hosted APIs.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: voice agents are a pipeline, not a prompt
A voice agent is not one model call. It is a capture path, a speech-to-text step, a turn boundary decision, a language model, a text-to-speech step, and a playback path, all running against a live audio session that cannot be paused while a request completes. The README frames the framework as a way to build "realtime, programmable participants that run on servers", which is a description of that pipeline rather than of any single component.
The audience is Node.js teams. The repository is explicitly "a Node.js distribution of the LiveKit Agents framework, originally written in Python". That sentence is the most important one in the README, because it tells you both what you get and what you are signing up for: the same conceptual model as the Python project, in TypeScript, with whatever plugin coverage the port has reached.
If your product already runs a Node backend and your agent needs to join a LiveKit room alongside human participants, the alternative is running a second Python process and coordinating two runtimes. This repository exists to remove that second process.
AgentSession, entrypoint and Worker: the three objects that define the runtime
The README's core concepts section names four things. An Agent is "an LLM-based application with defined instructions". An AgentSession is "a container for agents that manages interactions with end users". An entrypoint is "the starting point for an interactive session, similar to a request handler in a web server". A Worker is "the main process that coordinates job scheduling and launches agents for user sessions".
The entrypoint comparison is the clearest architectural hint in the material. A web server holds a process open and dispatches requests; the Worker does the same for sessions, and the entrypoint is the per-session handler. The sample code imports JobContext, JobProcess and WorkerOptions alongside cli and defineAgent, which matches that shape: a job is the unit of work the Worker schedules, and the context is what the handler receives.
What the README does not spell out is where audio actually flows. The features list mentions WebRTC clients and Data APIs, and the framework is built on LiveKit server, described as "one of the most widely used WebRTC media servers". The reasonable reading is that media terminates in the LiveKit server and the agent process consumes it, but the README does not describe the transport in detail, so treat the exact media path as something to confirm in the docs rather than infer from the repository description.
Turn detection is the design decision worth arguing about
The features list includes "Semantic turn detection: Uses a transformer model to detect when a user is done with their turn, helps to reduce interruptions." There is a dedicated plugin for this, @livekit/agents-plugin-livekit, marked EOU (end of utterance), and a separate @livekit/agents-plugin-silero marked VAD.
Those are two different mechanisms and the README keeps them separate. VAD is voice activity detection: is there speech energy right now. EOU is a model judging whether the speaker has finished a thought. A silence threshold alone fails on the speaker who pauses mid-sentence to find a word; a semantic model can wait through that pause. The trade-off is latency and cost, since you are running a transformer to decide when to stop listening, and it can be wrong in the other direction by holding a turn open too long.
The starter app description mentions "multilingual turn detection", which suggests the model is not English-only, though the README does not state which languages are covered. If your users code-switch mid-sentence, that is a question for the documentation, not something the repository description answers.
Installing the core package and choosing plugins
The installation section is short and specific. It asks you to install pnpm globally first:
npm install -g pnpm
Then install the core library:
pnpm install @livekit/agents
The README then states plainly that "Currently, only the following plugins are supported", followed by a table. That word, currently, is doing real work. The plugin set is the practical boundary of the project, and it is a curated list rather than an open registry.
Reading the table by capability: LLM, TTS and STT together are available from @livekit/agents-plugin-openai and @livekit/agents-plugin-mistralai. LLM and TTS come from @livekit/agents-plugin-google and @livekit/agents-plugin-xai. STT and TTS come from @livekit/agents-plugin-deepgram, @livekit/agents-plugin-cartesia and @livekit/agents-plugin-inworld. TTS alone is available from elevenlabs, neuphonic, resemble, rime, fishaudio and hume. VAD is silero. EOU is the livekit plugin. @livekit/agents-plugin-phonic is listed as Realtime. Six plugins are listed as Avatar: anam, bey, lemonslice, liveavatar, did and protoface.
The sample code shows the wiring pattern. It imports llm and voice from the core package, imports the silero plugin as a namespace, and defines a tool with llm.tool, passing a description, a zod schema for parameters, and an execute function that receives the parsed arguments and a context object. Tool definitions are typed through zod rather than through a JSON schema literal, which is the kind of choice that matters more in a TypeScript codebase than in a Python one.
The sample in the README is truncated mid-string, so the full agent construction is not visible here. The docs site is the place to look for the complete example.
MCP support and RPC are the interoperability story
Two features in the list are about talking to things outside the agent. The first is "MCP support: Native support for MCP. Integrate tools provided by MCP servers with one line of code." The second is "Exchange data with clients: Use RPCs and other Data APIs to seamlessly exchange data with clients."
The MCP claim is worth taking literally: one line of code to attach a tool server. That is a different integration model from writing an llm.tool wrapper per function, as the sample does for the weather lookup. If your tool surface is large or already exposed over MCP, the one-line path is the reason to care. If your tools are a handful of internal functions, the zod-typed llm.tool approach keeps everything in one type system.
The RPC and Data API path is what makes the agent a participant rather than a chatbot behind a socket. The README links to LiveKit's client-side RPC and data documentation, which implies the client SDKs on the other side are the same ones used for any LiveKit room. That is a genuine advantage of building on this stack rather than on a standalone voice SDK: the agent joins the same room as your users and can exchange structured messages with them.
Note that the word "seamlessly" in that feature bullet is the README's phrasing, not a claim this review can verify.
Where this is the wrong tool
The clearest limitation is the one stated in the README: the plugin table is the supported set, and it is described as current rather than complete. The Python original has a larger ecosystem by virtue of being the original. If your stack is built around a provider that appears on the Python side and not in this table, the port does not help you, and you are back to running Python alongside Node or writing your own plugin.
A second constraint is the shape of the dependencies. The plugins listed are overwhelmingly hosted API providers: OpenAI, Google, Deepgram, ElevenLabs, Cartesia, Mistral, xAI, and so on. The only local model in the table is silero for VAD. If your requirement is that no audio or transcript leaves your infrastructure, the README does not offer a path to a self-hosted LLM or TTS plugin. The framework itself is open source and the README notes you can run "the entire stack on your own servers, including LiveKit server", but self-hosting the media server is not the same as self-hosting the models.
Third, the README carries a tip that "We just released livekit-agents 1.5.0" with a link to a migration guide. A framework that publishes a migration guide for a minor version is telling you something about API stability. The recent releases listed are at 1.8.0, so the 1.5 migration is not the latest change. Plan for upgrade work between minor versions rather than assuming the surface is frozen.
The Python framework is the real alternative, and the difference is not just language
The obvious alternative is the Python LiveKit Agents framework, which the README names directly as the original. Choosing between them is not a language preference question, because the two distributions do not have the same plugin coverage. The Node version's table is explicitly the supported set for this repository. If a provider you need is missing here, the Python version is the comparison to make, not a different framework.
The other alternative class is the standalone realtime API plugins, such as @livekit/agents-plugin-phonic, listed with the feature Realtime. A realtime API collapses STT, LLM and TTS into a single speech-to-speech connection, which removes the pipeline assembly work but also removes your ability to swap one stage. The framework's stated purpose is the opposite: "Flexible integrations: A comprehensive ecosystem to mix and match the right STT, LLM, TTS, and Realtime API to suit your use case." Both modes are present in the same repository, which is unusual and useful. You can start with a realtime plugin and move to a composed pipeline later without leaving the framework.
A third option is assembling the pipeline yourself over raw WebRTC and direct vendor SDKs. You would own turn detection, interruption handling and session state. The README does not quantify what the framework saves you there, and this review cannot either, but the AgentSession abstraction and the EOU plugin are the two pieces that are genuinely fiddly to build from scratch.
Licence, maintenance and what to check before you commit
The repository is Apache-2.0, and the README source carries SPDX headers naming LiveKit, Inc. as the copyright holder. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices. It does not impose copyleft obligations on your application code. This is a description of the licence text, not legal advice; if you are redistributing the framework or modifying it, read the licence and your own counsel's guidance.
The maintenance signal in the supplied material is the release cadence: 1.8.0 for @livekit/agents, @livekit/agents-plugin-xai and @livekit/agents-plugin-trugen, all dated 2026-09-05, with the last push to main on 2026-09-10. Plugins are versioned in lockstep with the core package, at least in that release. The cost of that cadence is upgrade work: the README itself points to a migration guide for 1.5, and the framework is now at 1.8. Pin your versions and read the release notes before bumping.
One detail worth noting: @livekit/agents-plugin-trugen appears in the recent releases but is not in the supported plugin table in the README. The table may lag the published packages, or the plugin may be documented elsewhere. Check npm for the package before assuming it is unsupported, and check the table before assuming a package exists.
The starter app, livekit-examples/agent-starter-node, is described as including "a ready-made assistant, multilingual turn detection, background noise cancellation, metrics/logging, and a production-ready Dockerfile". For a team evaluating this, reading the starter's Dockerfile and its session setup is a faster way to learn the operational shape than reading the core README, which is mostly a feature list and an install line.
Editorial conclusion
Adopt it if your voice agent is a Node.js service and your model vendors appear in the supported plugin table. Do not adopt it if you need a provider that only exists on the Python side, or if you want to run inference inside the agent process rather than calling hosted APIs. Verify first that the specific plugins you need are published at the version you install, and read the v1.5 migration guide before pinning anything.
Community notes