Lobe Vidol: a chat client that puts a VRM avatar in the message stream

The avatar is not a decoration beside the chat

Most chat front ends are a column of text. Lobe Vidol puts a 3D character in the conversation itself, and the product description for it is a platform for making virtual idols accessible. The distinguishing feature is the video chat mode, reached from a video button in the message box, where the character responds face to face with the user and can perform rather than merely reply.

The character is a 3D model that you configure rather than a fixed asset. A character editor lets you create a virtual idol, set touch responses, and upload VRM models to the site, and by clicking different body parts of the character it responds in different ways. Those touch responses are editable, so the interaction is authored per character instead of being a single canned animation set.

The staging is configurable too. You can set the background, and you can add a background image to give the dialogue more context, since the visual setting is treated as part of the scene rather than as chrome. The system then layers motion on top of that scene. A built-in library of Mixamo character motions and poses lets a character strike a pose or perform an action mid conversation, and stage loading with built-in stage options lets the same character dance in different stage styles.

Text chat mode remains the baseline, with streamed responses and configurable character dialogue scenarios. The video mode is the addition, and the way the two are joined is the point: the same conversation drives both, so the model output and the avatar performance are one session rather than two features.

MMD files and pmx stages are the interoperability story

Where the project goes beyond a web avatar is in its support for the MMD ecosystem. The documentation credits mmd-parser for the ability to dance with idols using vmd files, and the stage feature is described in terms of pmx stages. Those two file formats are the working format for the MMD community, and supporting them means a large body of existing motion and stage assets can be used without conversion.

That is a concrete interoperability decision with an asset pipeline attached. A team that already has vmd motion data or a pmx stage does not have to rebuild its library to use this front end. The README also lists a character and dance marketplace as a feature, which suggests the distribution path for both models and motion is expected to run through the platform rather than through manual file handling alone.

The VRM upload path and the vmd path sit side by side in the same editor, which is an unusual combination. VRM covers the character, and MMD covers the performance. The result is a system that can accept a model uploaded by a user and motion authored in a different toolchain, and stage the two together. That combination is what makes the project more than a chat skin.

The documentation does not describe the parsing limits, the file size ceilings or the frame rate behaviour of the dance files, and it does not list the marketplace's terms. If a production deployment depends on specific motion assets, those are questions to put to the maintainers rather than assumptions to make.

Model providers are a layer, not a single endpoint

The third feature area is provider support, and the project's reasoning is stated in the documentation: a single provider cannot serve a community with different needs, so the client is built to work across several. The provider list begins with AWS Bedrock, integrated to serve models such as Claude and LLama2, and continues with Google AI including Gemini Pro, and the repository topics and package keywords list OpenAI alongside the chatgpt and vercel-ai references.

Architecturally, this is the piece that separates the project from a single-vendor demo. When several providers sit behind one interface, the rest of the application, the chat stream, the video mode, the TTS and STT path, has to be written against an abstraction rather than against one API shape. That work is visible in the dependency choices, with the vercel-ai keyword in the package metadata pointing at a provider neutral streaming layer for the same ecosystem.

The trade is that provider features do not line up. A model that streams tokens will not necessarily support the same function calling, tool use or system prompt conventions as another, and a chat product built on top of a video avatar is sensitive to response latency in a way that a plain text client is not, because a slow reply breaks the illusion of a person speaking back to you. Anyone deploying this needs to check which provider combinations are actually tested, and the documentation does not publish a compatibility matrix.

Voice is part of the same feature area, with TTS and STT voice conversations listed alongside the provider support.

The script surface tells you how the project is actually built

The repository is a TypeScript Next.js application, and package.json names the package @lobehub/vidol at version 0.30.0. The script entries are the clearest description of the toolchain:

"dev": "next dev"
"build": "next build"
"start": "next start"
"test": "vitest"
"type-check": "tsc --noEmit"
"lint:ts": "eslint \"{src,tests}/**/*.{js,jsx,ts,tsx}\" --fix"

That tells you the development loop is the Next.js dev server, the tests run on Vitest, and types are checked separately with the compiler in no-emit mode. There is a vitest.config.ts at the root and a tests/ directory alongside a __mocks__/ directory, so the test setup is part of the repository rather than something a contributor has to invent.

The surrounding tooling is thorough. There is a circular dependency check through dpdm in the lint:circular script, Markdown and MDX linting, stylelint, husky with a prepare hook, commitlint with .commitlintrc.js, a changelog config, Renovate for dependency updates, and semantic-release as the release script. The i18n story is first class, with a locales/ directory, an .i18nrc.js config, a lobe-i18n command and a dedicated workflow script, and there is a Simplified Chinese README alongside the English one.

Deployment is Vercel shaped. vercel.json and next.config.mjs are at the root, the README says no installation or registration is required and asks you to visit the website for a quick experience, and the feature list includes progressive web app support. A .bunfig.toml is also present at the root, which points at a Bun based toolchain alongside the npm scripts above.

Beta, private package, no releases

The project tells you its own status in a note near the top: it is currently in early development and open for beta testing, and the documentation invites contributions and issue submissions. That framing matters more than any feature list, because it tells you what kind of software you are adopting.

Two facts reinforce it. The package is marked private in package.json, so @lobehub/vidol is not published to a registry and there is no artefact to install. And the repository has no GitHub releases, with the version tracked in package.json instead and semantic-release configured to handle it. The absence of a release list means there is no published changelog to read in the repository, though a CHANGELOG.md file is present at the root.

The last push was on 2026-10-15 and the repository is not archived, so the code is being worked on. The version number is the honest measure of maturity here: 0.30.0 is a pre-1.0 line where interfaces can still move.

For evaluation, the practical effect is that you should treat the hosted site as the product to judge and the repository as the thing to read. The live deployment is the only place the whole feature set exists as a coherent experience, and the documentation does not describe a self-hosting procedure beyond the scripts in package.json.

The licence is stated twice and the two statements differ

The repository metadata reports the project as Apache-2.0, and the README carries a licence badge. The package.json declares something different, with a license field reading MIT, and the LICENSE file at the root is the third piece of evidence.

That inconsistency is not a footnote. A project published under Apache-2.0 carries an explicit patent grant and specific redistribution conditions, while MIT is a short permissive notice, and a fork inherits whichever set actually applies to the code you copied. The difference in obligations between the two is exactly the kind of thing that legal review exists to settle, and this article is not legal advice.

The practical instruction is to open the LICENSE file and read which text it contains rather than trusting any metadata field, and then to reconcile it with the package.json declaration before you redistribute anything. If the intent was Apache-2.0 and the file says MIT, that is a bug worth reporting to the maintainers, and reporting it is cheap while a fork is still internal.

One more licensing-adjacent point deserves attention in the other direction. The application renders third party 3D models, Mixamo motions, MMD stage files and vmd dances, and it ships a marketplace for characters and dances. The licence of the software does not grant rights to the assets in that marketplace, and a self-hosted deployment that pulls from it needs its own answer about asset rights and user uploaded models. The documentation does not give one.

Hosted beta or your own deployment, and what each costs you

There are two realistic ways to use this project, and they differ in more than hosting.

The first is the hosted service, which is what the README steers people toward: no installation and no registration, just a website, and a progressive web app so it can be added to a home screen. The price of that convenience is that you are a user of a beta platform whose roadmap you do not control, whose data handling you have to accept on the operator's terms, and whose model provider configuration is the operator's choice rather than yours.

The second is to fork and run it yourself. The repository is a Next.js application with a standard dev, build and start script, a vercel.json for deployment, so the deployment path is conventional. What you gain is control over providers, over which voices are used, over how conversation data is stored, and over the pace of your own changes. What you take on is the whole surface of a pre-1.0 application, including the asset rights question above and the i18n and lint tooling that assumes a maintained upstream.

The comparison that actually decides the choice is not the feature list, since both routes run the same code. It is whether the avatar in front of your users is a demo of someone else's product or a component of your own. If the answer is the latter, the second route is the only one that works, and the licence question has to be settled before anyone else does.

Editorial conclusion

Use Lobe Vidol if you want to try a virtual idol front end for a language model conversation, or if you want to fork a Next.js application that already combines a chat stream, TTS and STT, 3D avatar rendering and a plugin style model provider layer. Do not adopt it as a production dependency, because the project is described as in early development and open for beta testing, and because the package is marked private, so there is no published artefact to install. Before you build on it, read the licence files, since the repository metadata reports Apache-2.0 while the package.json declares MIT, check the scripts in package.json for the run and test commands, and confirm the provider endpoints you need are actually listed in the documentation before you plan around them.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. lobehub/lobe-vidol on GitHub
4. Project website
5. README