AChat: a self-hosted AI chat platform where V3 is frozen and V4 is still on the canary branch

The problem AChat targets: team AI usage that lives in personal accounts

Most AI chat happens in individual accounts. A developer pastes a prompt into a personal session, gets an answer, and the conversation is gone from any shared record. The organisation cannot see what was asked, cannot reuse the answer, and cannot attribute the spend. AChat's README frames the product around exactly this gap. The first listed feature is centralized AI conversation management: "Manage all team AI dialogues in one unified platform for easy tracking and collaboration." The second is organized conversation history with search and categorisation. The rest of the feature list reads like an administrative layer on top of a chat client: usage billing and cost management, roles and permissions, content moderation, and data compliance. The intended reader is an organisation that wants the chat surface but also wants the audit trail and the invoice. This is a different product category from a desktop LLM client. A client optimises for one person's latency and key management. AChat optimises for a shared instance where the organisation, not the individual, holds the history.

What the repository actually shows about the architecture

The repository metadata gives the primary language as TypeScript and the default branch as canary. The README's version table maps branches to releases: V4 lives on canary and is marked "Under Development"; V3 is on the v3 branch and marked "No longer updated"; V2 is deprecated with the note "Flawed design"; V1 sits on main and is described as using Redis as its database with "less scalable" as the note. So the branch layout is the architecture history. V1 used Redis as the primary store, V3 was "Refactor with modern tech stack", and V4 is the current work. The README does not describe the V4 data model, the sync protocol, or how the local and remote halves communicate. Its tagline claims a combination of "local processing capabilities with seamless remote synchronization", but no document in the supplied material explains what is processed locally versus remotely, or what the sync mechanism is. Treat that tagline as a positioning statement, not a specification. The topics list (agent, ai, chat, chatbot, claude, deepseek, enterprise-solutions, gemini, llm-client, openai, self-hosted) confirms multi-provider intent, and the presence of llm-client suggests provider access is abstracted, but the concrete provider configuration is not in the README.

Getting it running: what the README does and does not tell you

This is the weakest part of the repository as supplied. The Start section contains one line: "For configuration and installation, see [documentation](https://manual.sku.moe/project/chatgpt-admin-web)". There are no install commands, no environment variable names, no Docker invocation, no database setup steps and no configuration keys anywhere in the README. The only other operational pointer is an update log at the same manual site. That means an evaluation cannot be completed from the repository alone. You have to leave GitHub for a third-party documentation host before you can answer basic questions: which database V4 expects, how authentication is configured, how provider API keys are stored, and whether there is a container image. Note also the documentation URL path: it still reads chatgpt-admin-web, which is the project's earlier name, as the Trendshift badge in the README also shows. The naming has moved on; the documentation path has not. If you are assessing this for adoption, the first task is reading that manual end to end and checking whether it describes V3 or V4, because a manual written for the older line will not match the canary branch.

The version split is the real adoption risk

The release list ends at v3.2.4, tagged 2023-12-27. The repository's last push is 2026-04-17, and the default branch is canary. Read those two facts together: active development is happening on a branch that has not produced a tagged release in the supplied material, while the newest release belongs to a line the README itself marks as no longer updated. So there is no version of this project that is both current and released. If you deploy v3.2.4 you are deploying code the maintainer has stopped updating. If you deploy canary you are deploying unreleased work with no version number and no changelog in the material provided. The README's own framing supports caution here: V2 is labelled "Flawed design" and V1 "less scalable", which shows the project has already discarded two architectures. A team that adopted V2 and migrated to V3 has now been told V3 is frozen. That is a pattern worth pricing in. The lesson is not that the project is bad. It is that the upgrade path has historically been a rewrite, and the README gives no migration guidance between V3 and V4.

Licence: NOASSERTION is not an answer

GitHub reports the licence as NOASSERTION, which means the platform could not match the LICENSE file to a known licence template. The README links to a LICENSE file and shows a licence badge, but nothing in the supplied material states which terms apply. For a self-hosted platform whose feature list includes commercial billing and payment support, this matters more than usual. If you intend to run AChat inside a company, or to resell access to it, the licence text decides whether that is permitted, and NOASSERTION tells you nothing. Open the LICENSE file and read it, and if the terms are a custom or modified licence, have someone qualified read it too. This is not a legal opinion and should not be treated as one. It is a statement that the repository metadata does not answer the question, so the question is still open.

Where AChat is the wrong tool

If you want a personal AI client on your laptop, AChat is overbuilt. The billing, role assignment, moderation and compliance features exist to serve an organisation, and they add deployment surface you would otherwise not carry. A single-user setup gains nothing from a conversation-management console. Second, if you need a supported release with a version number you can pin and a changelog you can follow, this project cannot give you that today, because the newest release is from a line marked no longer updated. Third, if you cannot read the deployment documentation on an external site before committing, you cannot evaluate this at all; the repository is not self-describing. Fourth, if your requirement is a chat interface over a single provider with minimal moving parts, the administrative layer here is cost without benefit. The right comparison is not another chat UI. It is the internal wiki or shared prompt library your team is probably already using as a substitute, which has no billing, no moderation and no per-user permissions, but also no deployment and no upgrade risk.

Maintenance cost and what to verify before you commit

The maintenance picture from the supplied material is a project in the middle of a rewrite. V4 is under development on canary; V3 is frozen; V2 is deprecated; V1 is frozen. Three of four branches in the version table are closed to updates. That means the practical maintenance question is not how often patches arrive, it is whether the canary branch is stable enough to run and whether a V4 release is close enough to wait for. The README does not say. The repository does not carry release notes for V4 in the supplied material, only an external update log. My judgement is that AChat is worth watching and worth a trial deployment for teams that already have a reason to self-host, but it is not something to put in front of a whole company until V4 ships as a tagged release with installation steps in the repository itself. Concretely, before you spend engineering time: read the LICENSE file and confirm the terms cover your intended use, read the manual and check whether it documents V3 or V4, and try to build the canary branch from source to see whether it compiles and starts. If the canary build fails and the manual still describes V3, the honest answer is that this project is between usable states, and the right move is to wait for the V4 tag rather than deploy the frozen V3 line or an untested branch.

Editorial conclusion

AChat fits teams that need a self-hosted front end for AI conversations with usage billing and moderation, and who have someone able to work from source on the canary branch. It is the wrong choice for anyone who needs a tagged, supported release today, because v3.2.4 is the newest release and the V3 line is marked as no longer updated. Before adopting, verify two things directly: the actual contents of the LICENSE file, since the repository reports NOASSERTION rather than a recognised identifier, and whether the canary branch has a working build and deployment path, since the README sends installation to an external manual rather than documenting it in the repository.

Official sources

1. AprilNEA/AChat on GitHub
2. Issues
3. Project website
4. README
5. Releases