AIdea: a Flutter client for multiple LLM and image models, and what self-hosting actually costs

What AIdea is for, and who it is actually aimed at

AIdea is a chat and image generation client. The README describes it as an app that integrates mainstream large language models and image generation models, built with Flutter, with fully open-source code. The repository topics name the categories rather than a single vendor: chatbot, gpt, gpt-4, stable-diffusion, tongyiqianwen, wenxinyiyan. So the pitch is breadth. One interface, several model families, chat and image generation in the same app.

The audience is narrower than that pitch suggests. This is not a library you import. It is a desktop and mobile application, and the repository ships build targets for Android, iOS, macOS, Windows, Linux and web. Two groups get value. The first is people who want a prebuilt client and will use the hosted service at aidea.aicode.cc. The second is developers who want to read or fork a Flutter codebase that already handles multi-model chat, and who are prepared to run the companion server themselves. A third group, teams that want an internal chat tool with no external dependency, has to do the most work, because the client alone does not generate anything.

The client, the server and the Docker deployment are three repositories

The README lists three open source repositories: the Flutter client, a server, and a Docker deployment repository. That split is the architecture. The client holds the UI and the platform shells. The server holds the model credentials and the upstream calls. The Docker repository packages the server side.

What the client repository itself contains is mostly Flutter scaffolding: android/, ios/, macos/, linux/, windows/, web/, lib/, assets/, plus a Makefile full of build targets. There is a Dockerfile, but it is not an application container. It is a static web host:

FROM nginx:1.25

COPY build/web/ /data/webroot
COPY nginx.conf /etc/nginx/conf.d/default.conf

That means the Docker image serves the compiled Flutter web build, and nothing else. The model calls still go somewhere else. If you read the Dockerfile as a self-hosting story for the whole product, you will be disappointed. It is a web front end behind nginx, with the API endpoint configured in the client.

The Makefile confirms the client is the build surface. Targets like build-all run flutter build for Android, iOS and macOS in sequence and then move the artifacts into build/release. The macOS path signs with a specific Developer ID Application certificate. That is the maintainer's own signing identity, not a placeholder you can reuse.

Building the client: what the README tells you to do first

The README is explicit that the default branch is the v2 version and that self-hosters should switch to v1.x. That is the first command, and it comes before any Flutter invocation:

git checkout v1.x

After that, the README does not give a step list. It points to a series of articles: one on setting up the Flutter frontend, one on the Golang server, one on the Windows build environment, and one on creating a Windows installer. Those links are the install documentation. There is no install script in the repository root and no documented single command that produces a running stack.

The Makefile does expose the build steps directly. For a release Android APK:

flutter build apk --release --no-tree-shake-icons

The --no-tree-shake-icons flag appears on every build target in the Makefile, which suggests the icon tree shaking step is a recurring source of failures for this project. If you build without it and the build breaks, that is the flag to add.

For local development the README's own advice is worth quoting rather than paraphrasing: some users encounter build failures, and the README says this is not a bug but a known characteristic of Flutter, because build failures are common as the Flutter version changes. It then points at the maintainer's local environment configuration image. If you are planning to build AIdea, pin your Flutter version to whatever that image shows before you file anything.

Self-hosting means a second repository, and the README says so

The client does not talk to model providers directly in a self-hosted setup. The README's self-hosting section says that if you do not want to use the managed cloud service, you can deploy the server yourself, and links to a deploy document in mylxsw/aidea-server. That document is where the actual deployment instructions live. The client repository does not duplicate them.

The README also mentions a VIP deployment service for people who would rather not set it up themselves. That is a commercial option attached to an MIT-licensed project, which is worth knowing before you assume the whole stack is free to operate. The licence covers the code. It does not cover someone else's time, and it does not cover the model API costs your server will incur.

One practical consequence: the README does not document rollback, migration between server versions, or what happens to stored conversation data when you upgrade. The client repository is silent on all three. If you are deploying this for a group rather than yourself, treat the server repository's documentation as the source of truth and read it before you pick a version.

Where AIdea is the wrong tool

The clearest limitation is the build story. The README states plainly that build failures are common as the Flutter version changes and that this is a known characteristic rather than a bug. That is an honest statement, and it should shape your decision. If you need a tool that compiles reproducibly on whatever CI runner you have, a Flutter application with six platform targets and a pinned signing identity is a poor fit. The v1.x branch is the supported self-hosting path, and v2 is described as under development on main, so the code you are told to deploy is not the code under the most recent work.

Second, the client is not useful on its own. Without the server, there is no model access. That rules out the common case of wanting a single self-contained binary that talks to an API with a key in a config file.

Third, the repository gives no evidence about model coverage per deployment. The topics list model families, but nothing in the README states which models a given server build exposes or how they are selected. If your requirement is a specific model on a specific provider, verify that before you build anything.

Finally, licensing is MIT, and the README carries a FOSSA status badge, but the repository does not document the licences of the models or hosted services the app connects to. Those are separate from the code licence and are not addressed here.

How this differs from a thin chat client over one provider

The usual alternative is a small desktop chat client that stores one API key and talks to one provider's HTTP endpoint. Those tools are typically a single binary, install in one step, and update by replacing a file. The trade is that they do not abstract over providers, so switching models means switching tools or editing config by hand.

AIdea takes the opposite position. It puts a server between the client and the providers, which is what makes multi-model support and a hosted service possible from the same codebase. The cost is everything the thin client avoids: a second repository to deploy, a server to keep running, and a client whose builds depend on the Flutter toolchain and its version churn. If you are one person chatting with one model, the server layer is pure overhead. If you are building something where users should not hold provider keys, or where you want to change models without shipping a new client, the server layer is the reason to pick this.

The three-repository layout also means the Docker deployment repository is the piece to inspect if container deployment is your goal. The Dockerfile in the client repository only serves the web build.

Maintenance, versions and what to check before you commit

The last push to the repository was on 2026-03-04. The most recent release is 2.0.0, dated 2025-02-20, described in the release notes as a full upgrade. Before that, 1.0.15 landed on 2024-07-30 and 1.0.14 on 2024-04-07, which introduced Stripe payment, stop output, quick model selection and an admin entry point. The release cadence is uneven: a long gap, then a large version jump.

Upgrade cost is the part the README does not answer. It does not describe a migration path from v1.x to v2, and it does not say whether a v1.x client works against a v2 server. Given that self-hosters are told to stay on v1.x, the safe reading is that the two are separate lines for now, and you should confirm compatibility against the server repository's documentation rather than assuming forward compatibility.

On licence: the project is MIT, copyright 2025, mylxsw. MIT is permissive and short, but it covers this code only. It says nothing about the terms of the model providers your server calls, about the hosted service at aidea.aicode.cc, or about the VIP deployment service. Those are separate agreements and this is not legal advice, so read them yourself before you build a product on top.

Editorial conclusion

Adopt AIdea if you want a Flutter codebase that already wires several language and image models into one interface and you are willing to run the companion Go server, or if you just want the prebuilt app from aidea.aicode.cc. Do not adopt it if you need a single-binary self-hosted tool, if you cannot tolerate Flutter build breakage across SDK versions, or if you expect the main branch to be the deployable one: the README directs self-hosters to v1.x. Before committing, check the v1.x branch against the deploy guide in mylxsw/aidea-server, confirm which models your server build actually exposes, and read the MIT licence text rather than assuming what it covers.

Frequently asked questions

Official sources

1. License: MIT
2. mylxsw/aidea on GitHub
3. Project website
4. README
5. Releases