ai-beehive: a Java multi-model chat backend that stopped being maintained

What ai-beehive actually solves, and who it was built for

Every team that ships a chat product with more than one model provider ends up writing the same glue: one adapter per provider, one permission layer, one place to store per-provider parameters, and one way to switch a feature off when a provider breaks. ai-beehive is a Java backend that packages that glue. Its README describes chat rooms as honeycomb cells and provider integrations as drawings (图纸), and the stated design goal is that new room types arrive by adding a new drawing rather than by editing the core.

The intended user is a Java developer or a small product team that wants a self-hosted backend for ChatGPT, OpenAi Image, Midjourney, NewBing and ERNIE behind one frontend. The repository ships a separate frontend project, chatgpt-shuowen, and a hosted demo at front.aibeehive.icu. It is not a library you add to an existing service. It is an application with its own MySQL schema, its own Redis token store and its own admin concepts, so adopting it means adopting its data model.

Cells, drawings and rooms: the data flow behind a message

The unit of integration is the cell (图纸). The README lists the implemented cells: OpenAi GPT 3.5, OpenAi GPT 4, the official ChatGPT 3.5 and 4, OpenAi Image, Midjourney and NewBing. A cell carries a status, and only cells in published status can be used. That status check is enforced at send time, so a broken provider can be switched off without deleting the rooms that depend on it.

Access is a separate table, bh_cell_permission, with cell_code, user_id and a type column where 1 is browse and 2 is use, and type 2 implies type 1. A user_id of 0 means every user holds that permission. Each cell also has configuration rows, and the README states that essentially all of a provider's parameters can live in that config table, including defaults, whether a field is required, whether the user may see it, whether the user may change it, and whether it can be changed after the room is created. This is the part that ages well: provider parameters change often, and moving them out of code into rows means a new OpenAI parameter does not require a redeploy.

One implementation note the README gives is OpenAi ApiKey polling, which spreads requests across multiple keys. Authentication uses SaToken with the token stored in Redis, and the README mentions that removing a user's Redis token forces a logout. The Midjourney cell is described as implemented with reference to the midjourney-proxy project, and it covers imagine, upscale, variation and describe.

Installing ai-beehive and getting a first room working

The README is blunt about setup: it says to install MySQL and Redis first, that the schema lives in beehive-bootstrap/src/main/resources/db/schema-mysql.sql, and that the deployment instructions are still being completed. It also states that running it should not be a problem for Java developers. Treat that as the level of guidance you get.

The README gives no concrete install commands, so the only step it names explicitly is importing the schema file it points to, and it says the database contains a default account, [email protected] with password 123456. Change or remove that account before the service is reachable from anywhere but localhost.

Registration behaviour is controlled by a row in bh_sys_param under the param key email-registerLoginConfig. The README shows the shape of that JSON, including registerVerificationRedirectUrl, registerVerifyCodeExpireMinutes, registerTemplateSubject, registerAllowSuffix, registerEnabled, loginAllowSuffix and registerCheckEnabled.

{
  "registerVerificationRedirectUrl": "http://localhost:1002/#/emailValidation?type=email&verifyCode=",
  "registerVerifyCodeExpireMinutes": "验证码过期时间（分钟）",
  "registerTemplateSubject": "邮件标题",
  "registerAllowSuffix": "@qq.com,*",
  "registerEnabled": true,
  "loginAllowSuffix": "@qq.com,*",
  "registerCheckEnabled": true
}

If registerCheckEnabled is true, a new account lands in a pending state and an administrator has to approve it before login works. The README describes three login states, forbidden, pending review and normal, and notes that a forbidden user can be forced out by removing their Redis token. That is the first thing to check when a test registration appears to succeed but cannot sign in.

If the application starts but no cell is usable, the likely cause is that no cell row is in published status, since the README states unpublished cells cannot send even inside an existing room. The README also notes that drawings and their configuration items currently have to be edited by hand in the database, so setting up the first usable cell is a SQL task, not a UI task.

The maintenance status is the headline, not a footnote

The README opens with a line stating that maintenance has stopped. The last push to the repository was on 2026-04-13, and the newest release listed is v2.1.0 from 2023-07-30. Whatever the intervening commits contain, the release line has not moved in years, and the documentation still carries unfinished markers: the IDEA instructions say they are pending, the deployment section says it is being improved, and the implementation section ends with a note that it is to be updated.

That combination matters more than any single missing feature. It means the parts of the system that depend on external providers are the parts most likely to be stale, because provider APIs are exactly what changes. The README itself already records one such failure: NewBing is described as working locally and not working online, with the problem still being investigated. A reader in 2026 should assume other provider integrations have drifted the same way.

The second limitation is operational. The README states that drawings and their configuration items currently have to be edited by hand in the database, and that the admin UI for drawing and config management is on the planned list. So the permission model and the config model are real, but the interface to them is SQL. For a single operator that is tolerable. For a team, it is a support burden.

ai-beehive versus midjourney-proxy and a plain provider SDK

The most useful comparison is with midjourney-proxy, which the README names as the reference for the Midjourney cell. midjourney-proxy is a focused service: it exposes Midjourney operations over an API and leaves accounts, rooms, permissions and chat history to whatever calls it. ai-beehive is the opposite shape. It bundles Midjourney alongside OpenAI, NewBing and ERNIE, and pays for that breadth with a larger schema, a Redis-backed session layer and an application you have to host whole.

If your only requirement is Midjourney, midjourney-proxy is the smaller dependency and the one whose scope matches the problem. If your requirement is a multi-provider chat product with per-user permissions and per-cell parameters, ai-beehive's cell model is the more interesting design, even though you would be adopting it without upstream support.

The third option is to skip both and call the provider SDKs directly. The README notes that the ChatGPT integration uses the Grt1228 chatgpt-java SDK. That SDK is the layer ai-beehive wraps. Building your own room and permission tables on top of it gives you the same control without inheriting a stopped project, at the cost of writing the cell registry and the config table yourself.

Licence, upgrade path and what maintenance costs you

The repository is Apache-2.0, which permits commercial use, modification and redistribution, and includes a patent grant. It also requires that you keep the licence and notice files and state significant changes. This is a general description of the licence text, not legal advice; if you plan to redistribute a modified version, read the LICENSE file in the repository root and get your own review.

The upgrade cost is the harder question. Releases stopped at v2.1.0 in July 2023 while the default branch received commits later, so there is no tagged path to follow between those points. Anyone building on it inherits the schema as their own: the MySQL tables, the bh_sys_param JSON blobs and the cell config rows are now your data model, and no upstream migration scripts will arrive for them.

The practical consequence is that you should treat a fork as the real starting point, not a temporary one. Pin the commit you build from, keep your provider credentials and keys out of the database rows you copy, and expect to maintain the OpenAI and Midjourney adapters yourself as those APIs move.

Editorial conclusion

ai-beehive is worth reading if you are a Java developer who wants to study how a multi-provider chat backend is structured: the cell, room and cell-config tables are a workable model for adding providers behind one API. Do not adopt it as a running product. The README's first line states maintenance has stopped, the last push was on 2026-04-13, the latest release is v2.1.0 from 2023-07-30, and the deployment section still says it is being improved. Before doing anything else, verify three things: whether beehive-bootstrap/src/main/resources/db/schema-mysql.sql loads cleanly on MySQL 8, whether the bh_sys_param key email-registerLoginConfig still matches the code, and whether the default credentials [email protected] and 123456 exist in your imported data. If you need a supported backend, pick a provider SDK and build the room layer yourself.

Frequently asked questions

Official sources

1. hncboy/ai-beehive on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases