AIHelms: a self-hosted AI gateway that separates what you pay vendors from what you charge departments
企业级 AI 资源纳管平台，提供统一 AI网关、Token调度能力，纳管 OpenAI、Azure、Claude、DeepSeek 等主流模型，并支持 MCP 工具与 Skill 的集中注册分发。具备内外双轨定价、成本归因、统一身份认证、安全审计与效能报表，帮助企业精准控制成本、量化 ROI，高效治理 AI 资产。
At a glance
- What is it?
- AIHelms is a Docker-deployed Python and Vue platform that puts model access, per-person API keys, budgets and cost reporting behind one endpoint. Its distinguishing design choice is dual-track pricing: external vendor cost and internal chargeback price are accounted separately.
- Who is it for?
- AIHelms fits organisations that already pay several model vendors and need per-person keys, department budgets and chargeback reporting in one self-hosted service. Skip it if you only call one provider, or if your legal policy rules out GPL-3.0 and you are not prepared to buy a commercial licence.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The bill arrives before the explanation does
Most companies that adopt AI in more than one team hit the same sequence. A few developers get API keys directly from OpenAI, Anthropic or DeepSeek. Usage grows. The monthly invoice shows a total with no breakdown by team, project or person. Finance asks which department caused the increase, and nobody can answer without reading raw provider dashboards that use different account structures.
AIHelms targets that gap. It is described as an enterprise AI resource management platform, and its README frames the problem in three audiences: decision makers who need an investment-to-return view, administrators who issue identities and set budgets, and employees who need one key that works across clients. The product is not a model. It is the layer between your staff and the vendors.
The scope is broader than a proxy. Alongside model routing, the repository lists a Skill and MCP registry with approval flow, sensitive information detection, high-risk prompt interception, and administrator audit logging. Some of those items sit in the roadmap rather than the shipped feature list, and the README marks AI employee as in progress. Treat the roadmap table as intent, not inventory.
One endpoint, two price books, and a per-call attribution record
The architecture visible in the material is a FastAPI backend with Celery workers, PostgreSQL 16 for state, Redis 7 for cache, and a Vue 3 frontend, all shipped through Docker Compose behind Nginx. Model access is built on LiteLLM; release 0.1.19 records an upgrade of the model management base to LiteLLM 1.93. That dependency matters, because provider coverage and request/response format translation largely come from it rather than from AIHelms itself.
The accounting model is the part worth reading twice. The README describes dual-track pricing: external cost, meaning what the vendor actually charges, and internal settlement price, meaning what the company bills a department. An organisation can pass cost through at cost or add a margin. Every call is attributed to a person, department, project and model at token granularity, and release 0.1.18 added token columns to cost detail with drill-down to individual users.
Budget control operates at several dimensions (person, department, project, model) with two enforcement modes: soft limits that warn and hard limits that stop usage. Rate limiting is also layered; version 0.1.9 notes both a total cap and per-model speed limits on AI identities. Model registration supports multiple deployments of the same model with load balancing, and the README claims compatibility with both OpenAI and Anthropic request formats, with 0.1.8 adding Anthropic-format access for vLLM deployments.
Two mechanisms deserve scrutiny. First, the internal price is a number an administrator types in, so the accuracy of every chargeback report depends on someone maintaining that table as vendor prices change. Second, hard budget limits stop traffic. If a department hits a hard cap mid-month, the failure surfaces as a client-side API error, not a warning email.
Deployment is a compose file and four environment variables you must not leave at default
The quick start is short. Clone the repository, copy the sample environment file, edit it, and bring the stack up:
git clone https://github.com/beizhu-1209/AIHelms.git cd AIHelms cp .env.example .env docker compose up -d
The stated minimum is Docker 20.10 with Compose v2, and 4 cores with 8 GB of memory. Three URLs come up afterwards: the user hub at the root path, the admin console at /admin, and the API documentation at /api/docs. The default administrator account is admin, with the password taken from SUPER_ADMIN_PASSWORD in the environment file.
The documented environment variables are POSTGRES_PASSWORD, SECRET_KEY for JWT signing, SUPER_ADMIN_PASSWORD, and WEB_PORT. The README points to .env.example for the full list, which means the four named here are the ones the maintainers consider essential rather than complete. SECRET_KEY and SUPER_ADMIN_PASSWORD are the two that must be changed before the instance is reachable from anywhere untrusted.
Onboarding is three steps in the admin console: add a supplier credential, create a model, associate it with the credential and publish it, then have the user copy the key and endpoint from the hub. Release 0.1.24 changed publishing so authorisation is granted by department scope, and unpublishing revokes authorisation and invalidates approval records; new users get keys initialised according to their visible scope. If you upgrade across that version, expect existing authorisations to be re-evaluated rather than carried over silently.
A development path also exists, with ./dev/setup for first-time configuration and separate scripts to start middleware, the API with hot reload, and the web frontend with HMR. The repository points to docs/INTERNAL.md for the release process.
Where the platform will not save you
The gateway is only as good as the accounting underneath it, and the material does not describe how token counts are obtained for streaming responses or for providers that report usage differently. That is a real gap for anyone planning to reconcile AIHelms numbers against a vendor invoice to the cent. Verify it against your own providers before you promise finance a matching figure.
The release history is also a warning about maturity. Between 0.1.4 and 0.1.24 there are repeated fixes to cost calculation, log statistics and log synchronisation (0.1.7, 0.1.20), a fix for long agent logs being misattributed in codex /goal requests (0.1.11), and a fix for role and status filtering pagination in personnel management (0.1.21). These are the kinds of defects that erode trust in a reporting tool. The version numbers are all 0.1.x, and the project is not marked archived, but nobody should read this as a settled system.
Scale is unstated. There is no published figure for concurrent requests, throughput, or the number of keys a single instance handles. The 4-core, 8 GB minimum tells you the floor, not the ceiling, and the architecture puts PostgreSQL and Redis on the same host in the default compose setup. If your traffic is heavy, you are planning a database topology that the README does not discuss.
Finally, the wrong-tool case is straightforward. If your organisation has one team, one vendor and one key, AIHelms adds a database, a cache, a message queue, an identity model and an upgrade cadence to solve a problem you do not have. A provider dashboard and a spending alert would cover it.
LiteLLM Proxy is the alternative, and the difference is the chargeback layer
The most direct comparison is LiteLLM itself. AIHelms states that its base application is LiteLLM community edition under the MIT licence, and version 0.1.19 records an upgrade to LiteLLM 1.93. So the routing, provider abstraction and OpenAI-compatible surface are largely inherited.
The difference is what sits on top. LiteLLM Proxy gives you a unified endpoint, virtual keys and spend tracking against provider pricing. AIHelms adds a second price book for internal settlement, a department and project hierarchy, budget enforcement across those dimensions, an approval workflow for Skill and MCP registration, and a Chinese-language admin console and user hub with the reporting views built around them. If your requirement is one endpoint and one spend number, LiteLLM is the smaller thing to operate. If your requirement is a monthly report that tells a department head what their team consumed and what it costs the company internally, that reporting layer is the reason to run AIHelms instead.
The trade-off is coupling. AIHelms inherits LiteLLM's provider behaviour, including its bugs, and the upgrade path runs through a third-party project's release schedule. The 0.1.19 note shows the maintainers tracking that dependency deliberately, which is a good sign, but it also means a LiteLLM regression can reach your cost reports.
For teams whose main concern is prompt-level safety rather than cost, a dedicated gateway with policy plugins may fit better; AIHelms lists sensitive information detection and high-risk prompt interception, but the README does not document their rules or bypass conditions, so the depth is unverifiable from the material.
Licence, upgrades and what the GPL-3.0 choice costs you
AIHelms is GPL-3.0. The README states this plainly and then adds something unusual: if your organisation's policy forbids GPL-3.0 software, or you want to avoid the licence's obligations, you can email the maintainers about a commercial licence. Release 0.1.16 added enterprise licence management and platform branding customisation, which suggests the commercial track is a real product line rather than a footnote. This is not legal advice; if your company has a policy on copyleft software, the decision belongs with whoever owns that policy, and the dual-licensing offer is the mechanism to raise with them.
Upgrade cost is visible in the release cadence. Between 2026-06-04 and 2026-09-10 the project shipped roughly twenty tagged versions, with ten of them in July alone. That is a fast-moving 0.1.x line. Operators should expect to read release notes before each bump, because the notes contain behavioural changes rather than only fixes: 0.1.24 altered how model publication authorisation is granted and revoked, 0.1.22 made export task history auto-cleanup configurable, and 0.1.19 changed static asset hosting. Each of those can affect a running deployment.
Running cost is the stack itself: PostgreSQL, Redis, Celery workers, the API and the web frontend, plus whatever the LiteLLM layer needs. The README gives no resource guidance beyond the 4-core, 8 GB minimum, so capacity planning is on you. Backups are also undocumented in the material, which for a system whose main output is financial attribution is the first thing to solve before go-live.
Editorial conclusion
AIHelms fits organisations that already pay several model vendors and need per-person keys, department budgets and chargeback reporting in one self-hosted service. Skip it if you only call one provider, or if your legal policy rules out GPL-3.0 and you are not prepared to buy a commercial licence. Before committing, verify three things in your own deployment: that the LiteLLM version pinned in the compose stack supports every provider and format you need, that the PostgreSQL and Redis containers survive your backup and restore procedure, and that the .env values for SECRET_KEY and SUPER_ADMIN_PASSWORD are rotated away from the sample before the first real user is issued a key.
Community notes