AIaW Is Deprecated: What the Client Still Does and What Nya AI Replaces

The Deprecation Notice Changes the Adoption Question

Normally a review of an AI chat client asks whether it is good enough. Here the README answers a different question before you finish the first paragraph. A warning block states that the project is deprecated and has been succeeded by Nya AI, described as a complete rewrite with a new tech stack, offering most of the same features plus new ones. Existing users are pointed to a migration guide. The last push on the default branch is dated 2026-05-18, the same day as release v1.8.12, so the repository is not abandoned in the sense of being untouched. It is closed for new direction. That distinction matters: bug fixes and small releases may still land, but the architectural work has moved elsewhere. For anyone evaluating AIaW today, the honest framing is not whether the client is elegant. It is whether the features it already ships are worth running on a codebase the author has publicly stopped developing.

What AIaW Solves for People Who Run Many Models

The client targets a specific annoyance: using OpenAI, Anthropic, Google, DeepSeek, xAI and Azure through separate web UIs, each with its own history, its own file handling and its own keyboard behaviour. AIaW puts those providers behind one conversation interface with branching for edits and regenerations, so a regenerated answer does not destroy the previous one. Workspaces separate conversations by theme, and workspaces can be grouped into nested folders. Assistants can be scoped to a workspace or defined globally. The intended user is someone who switches providers often, keeps long-running threads, and wants the same shortcuts on Windows, Linux, macOS, Android and the browser as a PWA. It is not aimed at teams needing shared audit logs or server-side policy enforcement. Everything described in the README is oriented around a single person's data on their own devices.

Local-First Storage and Optional Cloud Sync

The data model is the most consequential design choice in the project. The README states that data is stored locally first, remains accessible offline and loads instantly, with cloud synchronization available after login for cross-device use. It also mentions multi-window collaboration: several tabs in the same browser stay in sync with each other responsively. That last detail implies a reactive store shared across tabs rather than a polling refresh, which is consistent with the Vue and Quasar stack listed in the repository topics. The practical consequence is that the client works with no account at all. You can run it, chat, and never touch the sync backend. If you do log in, your conversations leave the device, and the README does not describe the encryption model for that path. Treat the sync server as part of your trust boundary, not as a transparent backup.

Plugins, MCP and Artifacts as Three Separate Extension Points

AIaW does not have one extension mechanism, it has three, and they are worth separating. The first is the plugin system, which the README describes as more than tool calling. Built-in plugins cover a calculator, document parsing, video parsing and image generation. Additional plugins come from a marketplace, and Gradio applications can be configured as plugins, with compatibility for some LobeChat plugins. The second is MCP, supporting Tools, Prompts and Resources over both STDIO and HTTP, with servers added manually or installed as MCP-type plugins from the marketplace. The badge in the README advertises resources, prompts and tools together, which is a fuller MCP surface than clients that only implement tool calls. The third is Artifacts: any part of an assistant response can be converted into one, edited by the user, versioned, syntax highlighted, opened several at a time, and gated by read/write permissions the user grants the assistant. Three overlapping surfaces is a lot of configuration to reason about, and the README does not explain how a plugin and an MCP server that expose the same tool would be resolved.

Running It: pnpm, Quasar and the Build Targets

The README gives a short self-hosting path. Install dependencies with pnpm i. Start development mode with quasar dev, which the README notes includes hot-code reloading and error reporting. Lint with pnpm lint. For production, quasar build produces an SPA, and quasar build -m pwa produces a PWA. A separate self-hosting guide is linked at docs.aiaw.app/self-host, and Docker appears in the repository topics, though the README excerpt does not include a Dockerfile or compose command, so check the docs before assuming a container path exists. The stack is Quasar over Vue in TypeScript, which means the build output is static assets you can serve from any web server. There is no config key list in the README itself. Provider credentials, MCP server entries and plugin settings are configured through the app UI according to the feature descriptions, not through a documented file. If you need infrastructure-as-code for your chat client settings, that is a gap you will feel.

Where the Client Is the Wrong Tool

Two limitations are visible without running anything. First, the deprecation itself. Starting a new self-hosted deployment means adopting a codebase whose author has redirected effort to a rewrite with a different tech stack. Feature parity between the two is described as most features plus new ones, which is not the same as identical behaviour, so any workflow you build on AIaW's specifics may not transfer cleanly. Second, the plugin and MCP surface assumes you are comfortable granting a chat client access to local processes over STDIO. That is powerful and it is also the part of the system with the least described isolation. The README does not state whether plugins run sandboxed or with full client privileges. If your threat model includes untrusted marketplace plugins, that silence is a reason to stay on built-in plugins only. Neither point is a defect in the code. They are boundaries of what the documentation supports.

Web Search, Dynamic Prompts and the Small Details

Several features are easy to overlook and are the ones that decide daily usability. Web search is built on SearXNG and described as ready to use out of the box, with concurrent search and concurrent crawling, plus URL-based content fetching. Dynamic prompts use template syntax so prompt variables can be defined once and reused, with repetitive parts extracted into workspace variables. The attachment handling is more opinionated than most: text files such as code or CSV attach without occupying display space, and pressing Ctrl + V outside the input box pastes a large block as an attachment instead of flooding the message. Code pasted from VSCode is automatically wrapped in fenced blocks with a language tag. Quoting content from earlier messages into a new input, and selecting multiple lines to copy the original Markdown, round out an interface clearly built by someone who uses it all day. These are the features that make migration decisions hard, because a rewrite rarely reproduces every small behaviour at once.

Alternatives and Maintenance Cost

The comparison the project itself makes is Nya AI, the successor, described as a complete rewrite on a new tech stack. That is not a competitor so much as a fork in the road: staying on AIaW means frozen architecture plus whatever maintenance you perform yourself, while moving to Nya AI means re-verifying that your plugins, MCP servers and prompt variables behave the same way. Outside the project, the README references New API, an OpenAI-compatible model gateway, but that solves a different problem: routing and distributing model access rather than providing a chat interface, so it complements AIaW instead of replacing it. On cost, the licence is BSD-3-Clause, which permits modification and redistribution provided the copyright notice and licence text are retained; that makes a private fork legally straightforward, but it does not obligate anyone to maintain your fork. The real maintenance cost is the migration: reading docs.aiaw.app/migration, testing each MCP server and plugin against the successor, and confirming that locally stored conversations export or import correctly. Do that before the old client stops receiving fixes, not after.

Editorial conclusion

Adopt AIaW only if you are already running it and need time to move, or if you specifically want the BSD-3-Clause codebase to fork and maintain yourself. Do not start a new deployment on it: the README states the project is deprecated and succeeded by Nya AI, and the migration guide lives at docs.aiaw.app/migration. Anyone self-hosting should first read that migration page, then decide whether the fork path or the Nya AI path fits, because the upstream repository will not receive the rewrites the successor already has.

Official sources

1. License: BSD-3-Clause
2. NitroRCr/AIaW on GitHub
3. Project website
4. README
5. Releases