chatgpt-vue3-light-mvp: a single-turn Vue 3 chat template for wiring up an LLM API

What chatgpt-vue3-light-mvp is for, and who it is not for

The repository describes itself as a prototype template for a Chat Bot web front end that you can redevelop. The problem it addresses is narrow and concrete: you want a working chat page with streaming output and rich text rendering, and you do not want to spend a week assembling the streaming, parsing and rendering layers before you can see anything on screen. The README frames the project as an MVP and states that it supports only single-turn conversation mode, where each question gets an independent response and no context is retained. That constraint is deliberate, and it is the first thing to weigh.

Single-turn means the client does not send prior messages back to the model. For a question-answering box, a document lookup, a demo, or an internal tool where every prompt stands alone, that is enough and it removes a whole class of state bugs. For anything resembling an assistant that remembers what you said two messages ago, this template is the wrong starting point, and the README says so directly: multi-turn is described as a possible future feature with no concrete plan, and readers who need it are told to extend the project themselves.

The audience is front-end developers who already know Vue 3 and TypeScript. The prerequisites list Vue 3.x, Node >= 22.12.x, pnpm 10.x, and the VS Code ESLint extension at v3.0.5 or later in pre-release. If your team is on npm or yarn, or on an older Node line, you will be adjusting the toolchain before you write a line of product code.

The streaming pipeline: fetch, TextDecoderStream, TransformStream, reader

The architecture note in the repository distills the core into a chain: fetch(Response.body), then TextDecoderStream, then TransformStream, then a reader. That is the mechanism behind the typewriter effect. Bytes arrive from the model endpoint, get decoded into text, get reshaped by a transform stage, and are pulled by a reader in the UI. The README also describes decoupling network read speed from UI display speed using a buffer that emits frame by frame. That separation matters: without it, a fast stream produces a burst of DOM updates and the typing effect either stutters or disappears.

Model differences are handled by a mapping table rather than by branching inside components. The skill's reference list names model-adapters.md as the place where DeepSeek, Spark, Moonshot, SiliconFlow, Ollama and the mock stream are isolated, and mentions that the adapter layer has to cope with SSE, JSON and plain text framing. This is the part of the codebase most likely to need your attention, because providers do not agree on envelope format, and a new provider means a new entry rather than a rewrite.

The rendering side is a pipeline of its own. markdown-it handles Markdown, highlight.js handles code blocks, KaTeX handles math through @vscode/markdown-it-katex, and Mermaid handles diagrams. The README notes that katex is pinned to 0.16.x for compatibility with @vscode/markdown-it-katex, and that the build uses the KaTeX ESM entry explicitly under Vite 8 to avoid CommonJS pre-bundling interfering with formula parsing. It also states that the renderer understands the <think> tag, which is how reasoning-model output is separated from the final answer. If you swap in a model that emits a different reasoning marker, that parsing is yours to change.

Installing chatgpt-vue3-light-mvp and getting a first response

The README gives a short install path. Dependencies are installed with pnpm, and the dev server runs on port 2048. The dev script is defined as vite --host, so the server is reachable from other machines on your network, not just localhost.

pnpm i
pnpm dev

After the server starts, the README says to open http://localhost:2048. With no API keys configured, the default model is the mock data model, identified as standard in the supported-model table and marked as the development default. That is the fastest way to confirm the rendering pipeline works before you spend anything on API calls.

To talk to a real provider, copy the environment template and fill in keys. The template file is .env.template and the command is cp.

cp .env.template .env

The README lists four keys and their expected formats. Spark needs the key and secret joined with a colon.

VITE_SPARK_KEY=你的_星火_API_Key
VITE_SILICONFLOW_KEY=你的_SiliconFlow_API_Key
VITE_MOONSHOT_KEY=你的_Moonshot_API_Key
VITE_DEEPSEEK_KEY=你的_DeepSeek_API_Key

The table maps model identifiers to keys: deepseek-v3 and deepseek-deep both need VITE_DEEPSEEK_KEY, spark needs VITE_SPARK_KEY, siliconflow needs VITE_SILICONFLOW_KEY, and moonshot needs VITE_MOONSHOT_KEY. Ollama, identified as ollama3, needs no key but requires a locally running Ollama service. Note the VITE_ prefix: these values are embedded in the client bundle, which is the central security fact about this template.

The proxy is a development convenience, not a production boundary

The README is explicit that the project is pure front end and that all backend services come from external or local services. Cross-origin problems in development are handled with Vite's server.proxy. The repository's vite.config.ts defines a proxy entry for /spark pointing at https://spark-api-open.xf-yun.com with changeOrigin and ws enabled.

That is fine on a developer machine. It is not a production story. Any key written into a .env file with the VITE_ prefix is compiled into the JavaScript that ships to the browser, so a deployed build exposes it to anyone who opens devtools. The README does not document a server-side key exchange, and the migration checklist in the skill covers keys and proxies as review items rather than as implemented features. If you deploy this template as-is with a real key, you are publishing that key.

The practical path is to put a small server, or a serverless function, in front of the model provider, keep the credential there, and point the client at your own endpoint. The existing proxy configuration is a reasonable shape to copy for that, but the proxy itself runs in the Vite dev server and does not exist in a static build. The repository's own gh-pages build script sets VITE_ROUTER_MODE=hash, which tells you the author expects this to be deployed as static files.

Where the template stops: no context, no persistence, no rollback

The single-turn constraint is the largest limitation and it is stated in the README rather than hidden. Everything downstream inherits it. There is no message history to persist, no conversation store to migrate, and no token budget to manage, which is precisely why the template stays small. The moment you add multi-turn, you take on context assembly, truncation policy, cost control, and a storage decision, and none of that is in the repository.

The README does not document rollback, retry or resumption behaviour for a stream that fails midway, and it does not describe what happens to a partial response when the connection drops. The skill's migration checklist lists stop-generation, scrolling, empty state and completion state as items to review when moving the design elsewhere, which suggests these are areas to inspect in your own build rather than guarantees you inherit.

Rendering is another boundary. Mermaid and KaTeX both parse model output, and model output is untrusted text. dompurify is in the dependency list, which indicates sanitization is part of the stack, but the README does not describe the sanitization policy or which renderers run before or after it. If you accept input from users who can influence the prompt, verify that path yourself instead of assuming it.

Finally, the version numbers in package.json are aggressive: Vite 8, Vue 3.5, Pinia 3, ESLint 10, axios 1.18.0, and a katex pin held at 0.16.x for a plugin dependency. The pin is a deliberate trade-off, and it means a future KaTeX major is not available to you until @vscode/markdown-it-katex moves.

Compared with assembling the same stack yourself

The obvious alternative is not another chat template but a component library plus your own glue. Naive UI is already the UI layer here, and it ships chat-adjacent primitives; starting from Naive UI directly means you write the SSE reader, the buffer, the adapter table and the Markdown pipeline yourself. You get full control over context handling and key custody from day one, and you avoid inheriting someone else's version pins. You also spend the first week on plumbing instead of on your product.

The second alternative is a full-stack chat application framework, where the server owns the model calls and the client is thin. That inverts the trade-off: you get server-side key storage and multi-turn memory as built-in concerns, but you take on a backend runtime, a database, and a deployment target that a static host cannot satisfy. This template's gh-pages build script is the clearest statement of its position: it is designed to be a pile of static files.

The honest comparison is about what you are buying. You are buying a working streaming and rendering pipeline with a documented adapter boundary, at the cost of a front-end-only security model and a single-turn conversation model. If those two costs are acceptable, the template saves real time. If either is a hard requirement, the template is a detour.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-07-31, which is under two months before today's date. Releases are versioned and recent: v3.0.0 on 2026-04-21, v3.1.0 on 2026-06-22, and v3.2.0 on 2026-07-31. The cadence suggests the author is still working on it, but the README does not publish a support policy, a deprecation schedule, or a compatibility matrix beyond the prerequisites list. Treat upgrades as something you evaluate per release rather than something the project guarantees.

The licence is MIT, declared in package.json and in the LICENSE file. MIT permits commercial use and modification with the copyright notice retained. That is a permissive starting point, and it is worth noting that the template is built to be redeveloped, so forking and shipping is the intended use. This is not legal advice; if your organisation has a policy on third-party dependencies, the transitive set matters as much as the top-level licence, and the dependency list is long.

The upgrade cost concentrates in two places. First, the version pins: KaTeX at 0.16.x tied to @vscode/markdown-it-katex, and a toolchain on Vite 8, ESLint 10 and Pinia 3. Second, the adapter table, which is where provider API changes land. The distillation skill exists partly to make the second cost cheaper, by documenting the module boundaries in .agents/skills/chatbot-mvp-distillation/SKILL.md and its references. It is not a runtime feature and not an npm package, so it does not reduce your dependency surface at all.

Editorial conclusion

Adopt it if you need a browser-only chat surface that streams from a hosted model API and you are willing to own the proxy and key handling yourself. Do not adopt it if you need multi-turn memory, server-side key custody, or a component library you can upgrade without reading release notes. Before writing any code, run pnpm i and pnpm dev, confirm the standard mock model renders Markdown and a Mermaid block at http://localhost:2048, then read .agents/skills/chatbot-mvp-distillation/SKILL.md to see which parts the author considers portable and which are specific to this repository.

Frequently asked questions

Official sources

1. License: MIT
2. pdsuwwz/chatgpt-vue3-light-mvp on GitHub
3. Project website
4. README
5. Releases