AIdea Server: a self-hosted Go backend that wraps many model providers behind one OpenAI-compatible API

The problem AIdea Server solves is billing and provider sprawl, not model access

Calling one model API is easy. Running a consumer app on top of five of them is not. You need per-user token accounting, a pricing table, payment callbacks from Alipay or Apple, SMS verification, content safety checks, file uploads and a queue for slow jobs such as image generation. AIdea Server exists to hold that weight. The repository describes itself as a fully open-source APP server built with Golang that integrates mainstream large language models and image generation models, and the directory table backs that up: internal/coins handles service pricing and billing policies, internal/payment contains online payment implementations, pkg/sms is a unified SMS abstraction that hides the underlying provider, and pkg/uploader stores files on Qiniu Cloud Storage. The intended user is a team shipping the AIdea client or a fork of it, or an operator who wants the managed service's feature set on their own hardware. If your requirement is a single endpoint that forwards prompts to one vendor, this repository carries a large amount of unrelated machinery.

Two API surfaces and a chat abstraction that normalises every provider to OpenAI streams

The code structure lists two distinct HTTP surfaces. The api directory exposes an OpenAI-compatible API whose endpoints, per the README, can be used directly by any third-party software that supports the OpenAI API protocol. The server directory exposes the endpoints the AIdea client itself calls. That split matters: the OpenAI-compatible layer is the portable one, and the server layer is where app-specific behaviour such as digital personas and creation features lives. Underneath both, pkg/ai/chat is described as an abstract chat model interface where all chat models are wrapped to be compatible with the OpenAI Chat Stream protocol. That is the central design decision. Instead of teaching the client about each vendor's request shape, the server translates inward and emits one streaming format outward. The cost is that any vendor feature which does not map onto the OpenAI stream shape has nowhere natural to live, and the README's own note that Room and Advisory Group in the code both refer to Digital Persona, with naming that evolved across revisions, tells you the domain model has been rewritten more than once.

Built on two in-house libraries, which is the biggest adoption risk in the tree

AIdea Server does not use a mainstream Go web framework. It builds on Glacier Framework, described in the README as an in-house modular application development framework with dependency injection support built on the go-ioc container, and on Eloquent ORM, an in-house code-generation-based ORM inspired by the Laravel PHP framework with support for MySQL and other databases. Both are maintained by the same author as the server. This is a coherent choice for a solo-maintained product: dependency injection and modular registration make it practical to wire dozens of providers and background jobs. It is also a concentration of risk. When you debug a request path, you are reading Glacier's module lifecycle and go-ioc's container semantics, not net/http and a router you already know. The README states plainly that code comments and technical documentation are currently limited and will be supplemented over time. Treat that sentence as an accurate description of the onboarding cost, not as modesty.

Getting it running: three files carry the deployment

The repository ships three example artefacts at its root: config.yaml as the example configuration file, coins-table.yaml as the example pricing table, and nginx.conf plus systemd.service as example reverse-proxy and service-unit configurations. A self-hosting path is documented in docs/deploy.md, and the README points to a separate repository, mylxsw/aidea-docker, for Docker deployment. Database schema is not created by an ORM auto-migrate call in the description; the migrate directory holds database migration files in SQL, so schema setup is a deliberate step you run yourself. A separate document, docs/deploy-vip.md, covers assisted server deployment for operators who would rather pay someone to handle setup. What the supplied material does not give is the actual command sequence, the required environment variables, or the minimum set of config keys. Those live in docs/deploy.md and config.yaml, and you should read both before provisioning anything. The release notes also signal operational churn: the 202404071800 release mentions Stripe alongside changes to output handling and model channels, so payment configuration is not static across versions.

What it does not do, and where the documentation stops

Voice output is in the tree but switched off. The README lists pkg/voice as text-to-speech backed by Qiniu Cloud with the note that it is currently disabled. That is a real gap if your product plan assumed speech synthesis from this backend. Creation Island v1 is another boundary: the README says v1 is entirely different from v2, that v1 served App versions up to 1.0.1, and that from 1.0.2 it is no longer used. Any fork pinned to an older client version therefore diverges from current code in a way that is not a configuration toggle. Two further limits are visible from the material alone. First, the licence is unknown in the repository metadata, so you cannot make a distribution decision from what is shown here; check for a licence file on the default branch. Second, the pricing layer is a YAML table, coins-table.yaml, which means changing what users are charged is a deploy-time edit rather than a runtime API call, and any mismatch between that table and the billing code in internal/coins is a class of bug that will only show up in production accounting.

Compared with a general-purpose LLM gateway

The obvious alternative category is a dedicated LLM gateway such as LiteLLM or one of the OpenAI-compatible proxies, which exist to put one endpoint in front of many providers with retries, fallbacks and key management. The difference in approach is scope. A gateway is stateless with respect to your users: it does not know who is asking, it does not hold a token balance, and it does not call Alipay. AIdea Server is the opposite: it is a product backend that happens to include a gateway-shaped surface. It owns user identity through pkg/token JWT handling, it owns the money through internal/payment and internal/coins, and it owns asynchronous work through internal/queue and its consumers. If you already have accounts and billing and only need provider fan-out, a gateway is the smaller dependency. If you do not have accounts and billing and you are building the client-side product, adopting a gateway means writing all of that yourself, and AIdea Server is the shorter path even with its documentation debt.

Maintenance cost and licence exposure

The commit history shows a burst of releases in early 2024 and a last push timestamp in March 2026, which suggests the project has continued to receive changes rather than being abandoned. That is a fact about activity, not a guarantee about any particular release. Budget for upgrade work around the areas the release notes touch: model channel configuration, output handling, payment providers and login methods all changed between releases, and the naming history of Digital Persona shows that internal renames reach the code without a compatibility layer. The licence is not stated in the material provided, and no licence file is quoted in the README excerpt. That is a blocker for anyone who needs to redistribute a modified server or embed it in a commercial product, and it is not something to resolve by assumption. Read the repository's licence file directly before you build a business on this code.

Editorial conclusion

Adopt AIdea Server if you are building or extending a consumer AI app that needs accounts, token billing, payments, SMS login and an OpenAI-compatible surface, and you are willing to read Go source because the README admits comments and technical documentation are limited. Do not adopt it if you only need a stateless proxy in front of one model provider, or if you need a clear licence before shipping. Verify three things first: the licence file on the default branch, whether config.yaml covers every provider key you intend to use, and whether the migrate SQL files match the database version your deployment expects.

Official sources

1. Issues
2. mylxsw/aidea-server on GitHub
3. Project website
4. README
5. Releases