AI as Workspace (AIaW): a local-first AI chat client that is now deprecated in favour of Nya AI

What AIaW solves, and the deprecation notice you cannot ignore

AI as Workspace, abbreviated AIaW, is an AI chat client rather than a model or a proxy. The README calls it "An elegant AI client" and lists the platforms it targets: Windows, Linux, Mac OS, Android and Web as a PWA. It speaks to OpenAI, Anthropic, Google, DeepSeek, xAI, Azure and other providers, which means the project's job is to hold your conversations, prompts, files and tool configuration in one place while the model behind them changes.

The audience is people who chat with LLMs daily and want their own client instead of a vendor's web page. The README leans on that framing: multiple workspaces to separate conversations by theme, folders that nest, assistants that can be global or scoped to one workspace, and a plugin system. Data is stored locally first, so the app is usable offline and loads from local storage; cloud synchronization is available after login for cross-device use. That combination, local-first plus optional sync, is the reason someone would choose this over a hosted chat UI.

There is a hard caveat at the top of the README. The project is marked deprecated and succeeded by Nya AI, described as a complete rewrite on a new tech stack that provides most of the same features plus new ones. Existing users are pointed at a migration page in the docs. The repository is not archived and the last push to master was on 2026-05-18, but a deprecation notice in the README outweighs that: treat AIaW as a project in maintenance-by-migration, not as one to start fresh on.

Architecture: a Quasar front end, a Python backend, and local-first storage

The repository layout shows a Quasar and Vue application. package.json names the project aiaw, sets type to module, and its scripts run quasar dev, quasar build, eslint and vitepress for the docs. Dependencies include the Vercel AI SDK packages for each provider (@ai-sdk/openai, @ai-sdk/anthropic, @ai-sdk/google, @ai-sdk/deepseek, @ai-sdk/xai, @ai-sdk/azure and others), the Model Context Protocol SDK, Capacitor for Android and iOS shells, and @lobehub/chat-plugin-sdk for plugin compatibility.

That dependency list is the clearest statement of the data flow. The front end holds the conversation state and calls provider APIs through the AI SDK; MCP servers are reached over STDIO or HTTP through @modelcontextprotocol/sdk; plugins are loaded through the LobeChat plugin SDK, and Gradio applications can be configured as plugins through @gradio/client. Storage is local first, with cloud sync as an opt-in layer after login.

The Dockerfile reveals a second process that the README does not describe. The build stage installs pnpm, runs the PWA build, and the runtime stage copies src-backend into a python:3.12.7-slim image, installs requirements.txt and starts uvicorn on port 9010. So the self-hosted deployment is not just static files: there is a Python service in front of the built PWA. The README does not document that backend's API surface or its environment variables, and the .env.docker file that the Dockerfile copies into .env.local is not reproduced in the README. If you self-host, read src-backend and .env.docker before you trust the container.

Installing AIaW from source and running a first conversation

The README gives the development path directly. Install dependencies with pnpm, then start the dev server. The repository uses pnpm-lock.yaml, so pnpm is the expected package manager rather than npm.

pnpm i
quasar dev

After quasar dev, the app runs in development mode with hot-code reloading. The README describes this as the development entry point with error reporting. You should see the client open with an empty workspace list, since data is stored locally and there is nothing to load yet.

For a production build, the README lists two targets. The plain SPA build and the PWA build differ only by flag:

# SPA
quasar build

# PWA
quasar build -m pwa

The PWA build is what the Dockerfile uses, so it is the one that matches the self-hosted container. Linting is a separate script, pnpm lint, which runs eslint over .js, .ts and .vue files.

If you would rather not build from source, the README points to a hosted web version at aiaw.app and to the releases page for downloads, and there is a separate self-hosting guide in the docs. For a first real use, the practical step is to configure a provider and an API key in the client, then create a workspace and an assistant. The README does not walk through that configuration screen, so expect to find it by exploring the settings UI.

Where AIaW gets in your way

The deprecation is the first limitation and it is not a small one. The README states the project has been succeeded by Nya AI and directs existing users to a migration guide. A new user evaluating AIaW today is evaluating a codebase whose own maintainer has moved on, with the last push on 2026-05-18. Bug reports and feature requests have nowhere obvious to land.

Self-hosting is under-documented relative to the surface area. The Dockerfile exposes port 9010 and runs uvicorn against src-backend, but the README does not describe what that backend does, which endpoints it serves, or which environment variables it reads. The .env.docker file exists in the repository root and is copied to .env.local during the image build, yet its keys are not documented anywhere in the README. Anyone deploying this container is reading source to find out what it needs.

The feature set also assumes a certain kind of user. MCP servers, Gradio-as-plugin configuration, prompt variables with template syntax and Artifacts with per-assistant read and write permissions are all real capabilities, but each one is a configuration surface. If you want a chat box that talks to one model, this is more machinery than you need, and the plugin marketplace and Artifacts panels will sit unused.

Finally, the test script in package.json is `echo "No test specified" && exit 0`. There is no test suite to run before an upgrade. That shifts the verification burden onto you and makes the migration path to Nya AI the safer route for anyone who has not already invested in AIaW's data format.

AIaW against LobeChat: two different bets on where your data lives

The most direct comparison is LobeChat, and the repository itself makes the link: AIaW depends on @lobehub/chat-plugin-sdk and the README says its plugin system is compatible with some LobeChat plugins. The two projects overlap on plugin tooling, so the plugin ecosystem is not a clean differentiator.

The difference is in the storage and client model. AIaW is built as a client application you install or self-host, with Capacitor shells for Android and iOS, a Tauri directory in the repository root, and a PWA build for the browser. Data is local first, and cloud sync is an optional layer you opt into by logging in. LobeChat's plugin compatibility means a plugin written for one can often run in the other, but the deployment shape is not interchangeable: AIaW gives you a desktop and mobile binary plus a container, and its conversation data lives on your device by default.

That matters for the decision. If you want a browser-first chat interface that you reach from anywhere without installing anything, AIaW's local-first model is extra weight. If you want your conversation history on your own machine, with sync as a choice rather than a requirement, AIaW's design is the point. The trade-off is operational: local-first means you own backup and migration, and with the project deprecated, migration now means moving to Nya AI rather than waiting for an in-place upgrade.

Maintenance, licensing and the cost of staying

The repository is not archived, but the README's deprecation notice and the last push on 2026-05-18 define the maintenance picture. Releases continued through that date: v1.8.12 on 2026-05-18, v1.8.11 on 2026-04-23, and v1.8.10 on 2026-04-15, whose release title reads "v1.8.10 | Migrating to Nya AI". The migration tooling arrived in the release stream before the final push, which suggests the maintainer's intent was to move users rather than to keep developing AIaW.

The licence is BSD-3-Clause. That is a permissive licence, so forking, modifying and redistributing the code is allowed under its terms, and there is no copyleft obligation that would force you to publish your changes. It says nothing about the hosted service at aiaw.app or about Nya AI, which is a separate repository with its own licence that the README does not state. If you fork AIaW to keep it alive, the BSD-3-Clause text in the LICENSE file is what governs the code you are copying; if you depend on the hosted sync service, that is a different arrangement and the README does not describe its terms. This is a description of what the licence permits, not legal advice.

The upgrade cost is the real number. Because package.json ships no test suite, an upgrade means manual verification of conversations, plugins, MCP servers and Artifacts. The cheaper path, per the README, is the migration guide to Nya AI, which the project presents as providing most of the same features with a consistent experience.

Editorial conclusion

Adopt AIaW only if you already run it or need to understand its data layout before moving to Nya AI; for new deployments, start with the successor instead. Before committing to the self-hosted route, verify the src-backend directory contents and the .env.docker file, since the README documents neither the backend API nor the environment variables the container expects. If you stay on AIaW, pin the release you install: the last push to master was on 2026-05-18, and the README states the project has been succeeded by Nya AI.

Frequently asked questions

Official sources

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