FreeLLMAPI: stacking 34 free LLM tiers behind one /v1 endpoint
7.4 billion tokens per month. 34 free LLM providers. 635 free model endpoints. All behind one /v1 endpoint, plus any custom OpenAI-compatible endpoint. Smart routing, automatic failover, encrypted keys. Personal experimentation only.
At a glance
- What is it?
- FreeLLMAPI aggregates free provider tiers and custom OpenAI-compatible endpoints behind a single OpenAI-style API with a router, failover and encrypted key storage. It is built for personal experimentation, and the README says so itself.
- Who is it for?
- Adopt FreeLLMAPI if you are running personal experiments, prototypes or a local coding agent and you are willing to hold the API keys for a dozen providers yourself. Do not adopt it as shared production infrastructure for a team: the README scopes it to personal experimentation, and a router whose catalog is signed and distributed by a third party is a dependency you would have to own.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, 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 problem: thirty-four free tiers that do not compose
Free tiers are individually small. The README's framing is that each one is a toy on its own, and that stacked together they add up to roughly 7.4 billion tokens per month across 474 model families and 635 provider endpoints. The figure comes from the project's own catalog, so treat it as an upper bound on what the catalog covers rather than a number you will hit.
The real friction is operational. Thirty-four providers means thirty-four SDKs, thirty-four rate-limit shapes, and thirty-four places a request can fail. FreeLLMAPI's answer is a single OpenAI-compatible /v1 surface, so an existing OpenAI client library points at your local server instead of at a vendor. That is the whole product thesis, and it is a reasonable one for anyone who has written the same retry-and-fallback wrapper three times.
Who it is for is stated plainly in the repository description: personal experimentation only. That is not a hedge buried in a FAQ. It sets the support boundary for everything else in this review.
The router, the failover and the signed catalog
Three mechanisms carry the project. First, routing: a router picks the best available model for each request, and when a provider rate-limits, it falls over to the next one. Second, accounting: per-key usage is tracked so you stay under each provider's free-tier cap. Third, catalog distribution: the router updates its own model catalog from a signed feed, so new free models, quota changes and compatibility fixes arrive without a git pull.
The catalog feed is where the project stops being purely a self-hosted tool. The signed feed is served from freellmapi.co, and the README states the split directly. Free installs get a monthly snapshot, which means a model reaches them 30 days after it joins the live feed; premium routers get it the same day, priced at $19/yr with cancel anytime. So the same binary behaves differently depending on whether you pay, and the difference is measured in days of catalog freshness rather than in features.
What the README does not describe is the routing policy itself. There is no published scoring function, no statement of what best available means, and no description of how a rate-limit signal from one provider is detected versus a hard error. For a component called Smart routing in the repository description, that is the thinnest part of the documentation, and it is the part that determines whether failover feels invisible or erratic.
Keys are stored encrypted, per the README. The encryption scheme, the key derivation and where the store lives are not specified in the material available, so verify that in the source before you point the router at credentials you care about.
Getting it running: Docker, the desktop builds and the custom provider
The README points at four install paths. There is a Docker Compose route documented under docs/en/install/01-install.md, a published container image at ghcr.io/freellmapi, and desktop builds for macOS and Windows linked from the latest release. There is also a Google Play listing for the Android app, package id co.freellmapi.app.
The client-side change is the point of the project. The README's claim is that you point any OpenAI client library at your local server, and it routes transparently across whichever providers you have added keys for. The server exposes /v1, so the base URL is what changes, not the calling code.
Beyond the 34 free providers, there is a custom provider slot. The README describes pointing chat, embedding, image or audio models at any OpenAI-compatible endpoint, and names llama.cpp, LM Studio, vLLM, a local Ollama and a remote gateway as examples. That is the escape hatch when a free tier is rate-limited or when a task should never leave your machine. Note that the custom provider is described as covering chat, embedding, image and audio, so it is not limited to text completions.
One caveat on the free tier's catalog lag: if you rely on a model that was added to the live feed recently, a free install will not see it for 30 days. The README states this as a property of the snapshot, not as a bug.
Where it is the wrong tool
The repository description says personal experimentation only, and that single phrase rules out the most obvious deployment. Routing a production workload through free tiers means your availability is the intersection of thirty-four providers' rate limits and terms, and the project makes no availability promise. There is no mention of an SLA, a status page, or any statement about what happens when the signed catalog feed is unreachable.
The catalog dependency is the second failure mode. If the router pulls its model list from freellmapi.co, then the set of models your application can call is controlled by a feed you do not operate. For a hobby project that is a feature. For anything with a change-control process it is a supply-chain question, and the README does not describe a pinned-catalog mode or an offline fallback.
The third case is scale. Per-key usage tracking exists to keep you under free-tier caps, which is the opposite of what you want when you need throughput. If your workload is measured in sustained requests per second rather than tokens per month, aggregation of free tiers is the wrong architecture regardless of how the router performs.
Finally, the failover path is only as good as its error classification. Since the README does not document how a rate-limit is distinguished from a malformed request or an auth failure, a misclassified error could burn a retry on a provider that will never succeed. That is a design detail worth reading in the source before you trust the fallback.
The alternative: a gateway you configure yourself
The closest comparison is a self-configured gateway such as LiteLLM, or simply a thin retry wrapper around the two or three providers you actually use. The difference is where the provider knowledge lives. FreeLLMAPI ships a catalog of 635 free endpoints and updates it from a signed feed, so the mapping from model name to provider endpoint is maintained for you. A hand-rolled gateway has no catalog at all: you list each model and each base URL yourself, and when a provider retires a model you find out from a 404.
That trade cuts both ways. A hand-rolled gateway never changes underneath you, and it never sends a request to a service you did not name. FreeLLMAPI's value is proportional to how many providers you are willing to hold keys for. With two keys, the catalog is overhead. With twenty, it is the reason to use the project.
There is a second alternative worth naming for local work: point the custom provider at your own llama.cpp, LM Studio or vLLM instance and skip the free tiers entirely. You lose the aggregate token budget and the failover, and you gain a dependency on nothing but your own hardware. The README treats the custom provider as an addition to the free providers rather than a replacement, but nothing stops you from using it that way.
Licence and the cost of keeping up
FreeLLMAPI is MIT licensed. That permits commercial use, modification and redistribution, subject to the usual condition of preserving the copyright notice and licence text. It does not give you any rights to the upstream provider APIs, and the free tiers you route through carry their own terms. Whether those terms allow an aggregator to sit between you and the provider is a question for each provider, not for this licence, and the README does not address it. This is not legal advice; read the provider terms yourself.
The maintenance cost has two parts. The code is TypeScript on the main branch, with releases roughly every few days in the window shown (v0.9.6, v0.9.7 and v0.9.8 within four days). That cadence suggests active work, and it also means a self-hosted install that pins a version will drift from the catalog the feed serves.
The second part is the catalog itself. The README's pitch is that the free-tier landscape shifts weekly and that the router tracks it so you do not have to. That is real work you are outsourcing, and it is also the reason the premium tier exists at $19/yr. If you take the free snapshot, budget for the 30-day lag on new models. If you pay, you are buying freshness, not features, and the README does not describe any other difference between the two.
What to check before you point a client at it
Start with the key store. The README says keys are stored encrypted but does not name the algorithm or where the material lives. Read the implementation before you paste in credentials for providers that bill overages.
Next, confirm the catalog behaviour on your install. The README distinguishes a monthly snapshot on free installs from same-day updates on premium, and it does not describe whether you can pin or freeze the catalog. If your client depends on a specific model name, that distinction decides when your setup changes without you.
Then test the failover path deliberately. Because the routing policy is undocumented, the only way to know how the router behaves when a provider rate-limits is to trigger it. The README does not publish a way to force a provider into a limited state, so this may require a test key with a low cap.
Finally, decide whether the custom provider should be your default. Pointing it at a local llama.cpp, LM Studio or vLLM instance removes the free-tier cap problem and the catalog dependency at once, at the cost of the aggregate token budget. For a personal experiment that runs on one machine, that is often the configuration that ages best.
Editorial conclusion
Adopt FreeLLMAPI if you are running personal experiments, prototypes or a local coding agent and you are willing to hold the API keys for a dozen providers yourself. Do not adopt it as shared production infrastructure for a team: the README scopes it to personal experimentation, and a router whose catalog is signed and distributed by a third party is a dependency you would have to own. Before installing, verify three things in your own checkout: how the encrypted key store is protected on your machine, which provider terms permit routing your traffic through an aggregator, and whether the 30-day catalog lag on the free tier matters for the models you actually call.
Community notes