AI Elements Vue copies chat, workflow and artifact components into your Vue app

Chat primitives written into your components directory

AI Elements Vue is a component library for chat-style user interfaces, and its pitch is narrow: hand you the rendering layer for AI conversations so your team writes the model calls instead of the message markup. The set covers conversation containers, individual messages with avatars, code blocks, reasoning displays, tool usage, source attribution and workflow graphs.

Every entry in the catalog is presentational. Nothing there opens a connection to a model provider, and the prerequisites assume the AI SDK is already installed in your app, which tells you exactly where the library stops. Who it suits: a team already shipping Vue or Nuxt applications that needs a chat surface to look finished this month rather than next quarter. Who it does not suit: anyone wanting a managed chat backend, a streaming protocol helper or a conversation stored somewhere for them.

The delivery model matters more than the component list. Files are written into a components directory inside your repository instead of being resolved from a package at runtime, so the code you review right after installation is the code you own from that moment onward.

Two install routes and the JSON registry behind them

The first job is preparing the host project, and shadcn-vue has to exist before anything else runs:

npx shadcn-vue@latest init

After that, two documented routes reach the same files. The direct route executes the project's own binary with no arguments:

npx ai-elements-vue@latest

That command sets up shadcn-vue when it is missing, writes every component into your configured components directory, and adds the required dependencies. For a first real use, pull only what you need:

npx ai-elements-vue@latest add message conversation

Component names go after `add`, one or many. The second route skips the project CLI entirely and hands the manifest to shadcn-vue:

npx shadcn-vue@latest add https://registry.ai-elements-vue.com/message.json

Replace that address with `https://registry.ai-elements-vue.com/all.json` and the full set is written instead of one component. Note that the README's usage section stops at commands: no import statement, props table or example rendering appears for a component once installed, so your first integration is reading the generated source.

Prerequisites pin Tailwind to one mode and disagree on Node

Four prerequisites stand between a fresh Vue app and a working component: Node.js 18 or later, a Vue.js or Nuxt.js project with the AI SDK installed, an initialized shadcn-vue project, and Tailwind CSS configured. The Tailwind bullet carries a restriction that is easy to skim past. AI Elements Vue supports CSS Variables mode only, and the README does not document a conversion path, a fallback, or a compatibility matrix for any other configuration mode.

The Node number is where the docs and the repository disagree. The prerequisite list says 18 or later. The repository's own package.json declares a much stricter floor:

"engines": {
  "node": ">=22.23.0",
  "pnpm": ">=11.17.0"
}

Both numbers are real and they describe different sides, since one governs your application while the other governs the monorepo that builds these files. Even so, a gap of four major Node versions between what a consumer is told and what the maintainers' toolchain requires is worth checking against your CI image before the first add.

Seventeen chat components, two sharing one description

The catalog is grouped, and the largest group is where a chat product lives. Seventeen entries sit under Chatbot: `chain-of-thought`, `checkpoint`, `confirmation`, `context`, `conversation`, `inline-citation`, `message`, `model-selector`, `plan`, `prompt-input`, `queue`, `reasoning`, `shimmer`, `sources`, `suggestion`, `task` and `tool`. The descriptions show where the design effort went. `queue` is a message and todo queue with attachments, `prompt-input` is an advanced input with model selection, `confirmation` handles tool execution approval workflows, and `context` shows context consumption.

One row pair deserves a closer look, because a skim will miss it. `reasoning` and `chain-of-thought` carry an identical description, word for word: Display AI reasoning and thought processes. Two distinct names, one line of documentation. If your backend emits reasoning events and tool-thought events separately, nothing states which component consumes which stream, and you learn that by opening both files after the CLI writes them.

The group header row also has an empty description cell, so the catalog never explains how these pieces are meant to compose into one interface.

A VueFlow canvas widens the scope past the chat box

Three smaller groups pull the project in different directions. Workflow holds `canvas`, described as a VueFlow canvas for workflow visualizations, plus `connection`, `controls`, `edge`, `node`, `panel` and `toolbar` for the graph around it. Vibe-Coding carries `artifact`, which displays a code or document, and `web-preview`, which embeds web page previews. Documentation introduces `open-in-chat`, whose description cell is empty, and the table stops there.

That VueFlow line is a dependency decision hiding inside a component list. A chat interface that renders tool calls as graph nodes now pulls in a graph engine with its own layout, zoom and edge routing behaviour. The README names VueFlow as the basis for `canvas` but does not pin a version, list the peer dependency, or show how nodes are wired to conversation events, so compatibility is something you confirm after installation rather than before.

The unfinished Documentation group is the other detail a skim misses. `open-in-chat` appears with an empty description and no closing row, which means the visible catalog is not the whole catalog, and no total component count appears anywhere in the README.

What you own once the CLI has written files into your tree

Here is the cost side of the copy-in model. After `npx ai-elements-vue@latest add` runs, the result is files in your repository. You can edit them, which is the whole point of the approach, but then the file in your tree and the file the CLI would write next time are different files. Documentation does not describe upgrade behaviour for an installed component: the copied output carries no version stamp to diff against, no overwrite rule is stated, and no rollback path exists in the docs. The registry route shares that gap, since its manifests are JSON files addressed by path rather than versioned artifacts you can pin.

The repository does have a test entry point, `turbo run test`, wired through root scripts. Nothing tells a consumer what to run after an upgrade, or whether those tests cover the copied components at all. Verification is yours to build: pin the manifest URL you pass to `npx shadcn-vue@latest add`, keep the generated files under review, and re-run your own smoke tests after every add.

Contributor tooling ships a parallel document that consumers never receive. An `AGENTS.md` file sits at the repository root beside the lint configuration, which tells you the maintainers expect machine-readable instructions for changes made inside the repo.

Monorepo tooling decides how bumps reach your copy

Beneath the components sits a pnpm and turbo monorepo. The root package declares `[email protected]` as its package manager and gates work behind `>=22.23.0`. Scripts are thin wrappers: `turbo run build`, `turbo run test`, `turbo run dev`, plus per-app filters for the documentation site and the registry, whose workspaces are named www and registry. Every dev dependency resolves through a `catalog:` entry instead of a pinned range, so versions are decided centrally in the workspace configuration.

Hooks enforce the workflow. `prepare` runs `pnpm simple-git-hooks`, and linting runs across the root and every package:

eslint . && turbo run lint

Version bumps are scripted across the whole workspace in one command:

bumpp package.json packages/*/package.json apps/*/package.json

The root package is marked private and pins 1.5.2, the newest listed version, dated 2026-07-28, while the last push was on 2026-09-11. Two earlier numbers sit close behind it, 1.5.1 dated 2026-07-16 and 1.5.0 dated 2026-06-24, so the catalog moved three version steps inside five weeks. GitHub cannot classify the licence, listing it as Other, so the terms that govern redistribution live in the LICENSE file rather than in a standard header.

The alternative is no library at all, or the shadcn-vue CLI

The honest alternative is not another package but no package. Because AI Elements Vue is built on shadcn-vue, a team can assemble the same surface from shadcn-vue primitives and the AI SDK directly, owning every file and depending on neither the registry nor the project CLI. The trade is legible in the catalog. `conversation`, `message` and `sources` are thin enough that many teams would write them anyway, while `queue`, `prompt-input`, `tool`, `confirmation` and `plan` encode interaction decisions that cost real time to reconstruct.

Between the two documented routes there is a difference in what you depend on. Running `npx ai-elements-vue@latest` ties your upgrade cycle to that binary. Pointing `npx shadcn-vue@latest add` at a manifest URL ties it to the shadcn-vue CLI plus the continued availability of registry.ai-elements-vue.com.

One caveat for strict supply chain rules: the documented manifest URLs carry no version segment, so the same command can return different content over time. Copying files into your repository partly answers that, since what lands is reviewable as a diff, but pinning remains yours to arrange.

Editorial conclusion

Adopt AI Elements Vue if your Vue or Nuxt app needs a finished chat surface now and you already run shadcn-vue with Tailwind in CSS Variables mode, because those chat components and the VueFlow canvas are work you would otherwise write yourself. Skip it if your policy requires versioned npm dependencies, since what you review is a set of copied files with no documented upgrade path. Before the first add, confirm your Node version against the CI image, then read the files the CLI wrote and keep them under review.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. vuepont/ai-elements-vue on GitHub