PandoraAI: a Vue chat client that keeps your conversations in local storage

What PandoraAI actually is, and who ends up using it

PandoraAI is a web chat client, not a model provider. The README describes it as "a web chat client powered by node-chatgpt-api", and that phrasing sets the boundary of the project: it renders conversations, manages presets, and talks to an API server over HTTP. The models themselves come from elsewhere.

That makes the target user fairly narrow. You are the person who already has, or is willing to run, a node-chatgpt-api server, and you want a browser interface in front of it. The README lists what that server exposes: gpt-3.5-turbo, text-davinci-003, ChatGPT, and Bing. PandoraAI is the layer that lets you switch between those without rewriting your own front end.

The second group is people who care where the transcript lives. The README states that everything is stored in local storage, so the client works without an account and can be exported or imported across devices. If your reason for self-hosting is avoiding an account on someone else's service, that design choice is the point of the project.

It is not for someone who wants to sign up and start chatting. There is no hosted instance described in the README, and no bundled key management. You supply the backend.

How the Nuxt 3 client talks to node-chatgpt-api

The architecture is a single Nuxt 3 application, which the README describes as built on the Vue 3 framework. The repository layout confirms the shape: app.vue at the top level, a components/ directory, a stores/ directory, and nuxt.config.js. State management comes from Pinia, which appears in package.json as both pinia and @pinia/nuxt.

The data flow is short. The browser loads the Nuxt app, the app reads its configuration from an environment variable named API_BASE_URL, and requests go out to that server. Streaming responses are handled by @microsoft/fetch-event-source, which is listed in dependencies and is the library you would reach for when consuming server-sent events. Markdown in replies is rendered with marked, and the output is passed through isomorphic-dompurify before display, which matters because model output is untrusted text.

Presets and conversation history do not travel to a database in this project. The README says everything is stored in local storage, and it also says PandoraAI works with other API server implementations as long as the endpoints are compatible. That compatibility clause is the real integration contract: the client is coupled to an endpoint shape, not to a specific binary.

One consequence worth stating plainly. Because the client is a thin renderer, a change in the API server's response format breaks the UI, and PandoraAI cannot paper over it. The README does not document a version negotiation mechanism.

Installing PandoraAI and getting a first reply

The README gives a two-part setup: run the API server from node-chatgpt-api, then run this client against it. Start with the client's dependencies. The README lists yarn, npm, and pnpm as acceptable, and the package.json scripts confirm the commands.

npm install

Next, configure the server address. The repository ships .env.example with a single variable, and the README's step three says to copy the file and fill in API_BASE_URL with the URL of your API server. The README does not give the copy command itself, so the example file is quoted below as it appears in the repository.

API_BASE_URL=http://localhost:3000

Then start the development server. The README says it starts on http://localhost:3000, which is the same port the example env file uses, so if you leave both at the default you will have a collision between the Nuxt dev server and the API server. Change one of them.

npm run dev

For a production build the README gives two more scripts. `npm run build` builds the application, and `npm run preview` serves the production build locally for a check before you deploy it. The README defers deployment specifics to the Nuxt documentation.

The README also records a known failure mode: if you see an empty white page after pulling the latest changes, run `nuxi upgrade --force` first and then `npm run dev`. That is a real instruction from the project, not a general troubleshooting tip.

The Dockerfile runs the dev server, not a production build

The repository includes a Dockerfile, and reading it changes how you would use it. It is based on node:16-alpine, copies the working directory into /app, copies .env in, runs npm install, exposes ports 3000 and 24678, and finishes with `CMD ["npm", "run", "dev"]`.

That last line is the important one. The container starts the Nuxt development server. It does not run `npm run build` and it does not run `npm run preview`. For local experimentation that is convenient, because you get hot reloading inside the container. For anything you intend to expose to other people, it is the wrong command: a dev server is not the artifact the README's production section describes.

Two smaller details follow from the same file. The image pins Node 16, while package.json declares Nuxt ^3.5.2 and overrides vue to latest, a combination that leaves the exact Vue version to resolution time rather than to the manifest. And the Dockerfile copies .env into the image, which means the API_BASE_URL value is baked into the build rather than injected at run time. If your API server address differs per environment, you are rebuilding the image to change it.

The README does not document an alternative Dockerfile or a production container recipe.

Where PandoraAI is the wrong choice

The clearest limitation is the one the README states as a feature: everything is stored in local storage. Conversation history lives in the browser, on one device, until the user exports it. There is no server-side account, no sync, and no central record. If your requirement is that a team can see each other's chats, or that history survives a cleared browser profile, this client does not do it. The export and import feature is a manual workaround, not a backup system.

The second limitation is the dependency. PandoraAI is only as capable as the API server behind it. The README lists gpt-3.5-turbo, text-davinci-003, ChatGPT, and Bing as what node-chatgpt-api supports, and it says other server implementations work if their endpoints are compatible. If your provider's API does not match that endpoint shape, the client has nothing to talk to. There is no adapter layer described in the README.

The third is operational. The Dockerfile runs the dev server, the env file is copied into the image, and the README's own troubleshooting note about a white page points at dependency drift between the client and its Nuxt toolchain. None of that is fatal, but it means you should expect to spend time on build configuration rather than on features.

Finally, there are no releases retrieved for this repository, so there is no versioned artifact to pin. The last push was on 2026-05-29. That is the state of the tree you would be cloning.

How it compares with a general-purpose chat UI

The obvious alternative is a browser extension or a desktop chat front end that talks directly to a provider's API. The difference is where the backend lives. Those tools typically embed a provider SDK and expect you to paste a key; PandoraAI expects a URL. It never holds credentials itself, because the README's setup step is about pointing at a server, not authenticating to a model vendor. If you already run node-chatgpt-api for other reasons, that separation is free. If you do not, it is an extra service to operate.

The second alternative is writing your own Vue front end against the same API. That is a real option, and the README implicitly invites it by noting that any compatible endpoint works. What you would be rebuilding is the preset system: the README describes creating multiple presets per client and choosing between clients or custom presets from a dropdown. Presets are the feature that makes the client more than a text box, and they are stored in local storage alongside the conversations.

The third comparison is against a hosted chat product. Hosted products give you an account, sync, and someone else's uptime. PandoraAI gives you the opposite trade: no account, local data, and you own the operational work. Neither is better in the abstract. The README's local-storage design is a deliberate answer to a specific preference, and it should be read that way.

Maintenance, upgrades, and what the MIT licence leaves to you

The repository is not archived, and the last push was on 2026-05-29. The README lists no release process and no changelog, and no releases were retrieved, so upgrades mean tracking the main branch rather than bumping a pinned version. The README's contributing section asks for pull requests with a detailed description, which is the only contribution process it documents.

Upgrade cost concentrates in the toolchain. package.json pins Nuxt ^3.5.2 and overrides vue to latest, so a fresh install can resolve a Vue version the code was not written against. The README's own remedy for a white page after pulling changes, `nuxi upgrade --force` followed by `npm run dev`, is effectively an upgrade instruction. Budget for it.

On licensing: the project is MIT, and the README states that plainly. MIT is permissive, but this is a client that depends on node-chatgpt-api and on whatever model endpoints you point it at. Those dependencies carry their own terms, and the README does not discuss them. Nothing here is legal advice; if you are deploying this inside an organisation, the licence of the backend and the terms of the model provider are the questions to take to whoever handles that, not the MIT header on this repository.

Editorial conclusion

Adopt PandoraAI if you already run node-chatgpt-api or a compatible endpoint and want a browser UI that stores conversations locally rather than on a vendor account. Skip it if you expect a hosted service, a managed login, or a client that ships its own model access; the README points you at a separate API server for that. Before committing, confirm that API_BASE_URL in your .env reaches a live server, that the endpoints your chosen client needs are implemented there, and that you are comfortable with conversation history living in browser local storage that users can export and import themselves.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. waylaidwanderer/PandoraAI on GitHub