FreeModel vs LiteLLM

The short answer

Side by side

Where LiteLLM is the better choice

These are the reasons to pick it over us, stated plainly.

1. Your traffic cannot leave your infrastructure

LiteLLM is designed for this. Routing decisions, virtual keys, and logs stay inside your network — only the actual model call goes out. If you have a data-residency requirement or a security review that forbids third-party gateways, that requirement settles the choice rather than tipping it. We cannot match it: by definition, requests through FreeModel pass through our gateway.

2. You want to pay providers directly, with no party in between

LiteLLM adds no per-token markup. You pay each provider at their published rate, and the proxy is free. If your volume is high enough that any intermediary margin matters, self-hosting removes that line item entirely.

3. You need to own the routing logic

Fallback order, retry policy, budget enforcement, caching strategy: with LiteLLM these are yours to define in configuration. FreeModel's routing is our design decision, and you get a base URL rather than a policy file.

4. You need air-gapped deployment

Available on their Enterprise tier. Not something a hosted service can offer at all.

Where FreeModel is the better choice

1. You do not want to operate a gateway

Self-hosting LiteLLM means servers, a PostgreSQL instance, monitoring, upgrades and security patching — plus the latency and failure modes that come with running another service in the request path. If getting a model endpoint is a means to an end rather than the project itself, that overhead buys you nothing.

2. You want to start without a credit card

FreeModel routes to free capacity first by default. There is no self-hosted equivalent. With LiteLLM you still need your own keys and your own provider credit, so "free" depends on what your providers give you.

3. You want Anthropic-format endpoints without assembling them

Both OpenAI and Anthropic Messages formats work against the same endpoint, so tools like Claude Code can point at it directly.

4. The operational surface is the thing you are avoiding

Worth saying twice: LiteLLM's flexibility is real, and so is its cost in attention. If you are a small team shipping a product, an endpoint you do not maintain is frequently worth more than one you control completely.

Switching in either direction

From LiteLLM to FreeModel

base_url    https://freemodel.online/v1              (OpenAI format)
            https://freemodel.online/api/gateway     (Anthropic format)

list models first:  GET /v1/models   (readable without a key)

Note the routing change: LiteLLM's fallback order is your configuration,
FreeModel's is ours. If you depended on a specific order, check it.

From FreeModel to LiteLLM

Run it:      docker run -p 4000:4000 ghcr.io/berriai/litellm:main-latest
             (a PostgreSQL instance is required for virtual keys and budgets)

Config:      model_list entries, each with a provider key you supply

Then point your client at  http://localhost:4000

Budget for:  the server, the database, monitoring, and upgrade time

What each side is actually holding

LiteLLM's coverage is whatever your keys can reach across 100+ providers. That reach is broad, but it starts at zero and grows with the accounts you open. FreeModel's coverage is a fixed list you can read before you sign up.

That list carries 199 ids. Of those, 77% are chat models, 9% generate images, and 23% cover the other modalities - video, speech synthesis, speech recognition, embeddings and rerank. Six of the entries are routes such as auto/embed and auto/rerank, each carrying a candidate count, so the depth behind a name is readable before you call it. The trade is visible in those shares: a curated list is smaller than 100+ providers and it is legible in a way an open-ended provider matrix is not.

What LiteLLM holds that we do not is the machinery around the call: virtual keys, budgets, spend tracking, rate limits, caching and a fallback order you wrote yourself. That machinery is the reason to self-host, and it is why "which is cheaper" is the wrong first question here.

Three checks before you switch

Migrating between these two runs in opposite directions depending on which way you are going, but the checks are the same three.

1. Step 1: diff the model ids. Pull curl https://freemodel.online/v1/models and compare it against every id your model_list names. Anything missing ends the migration for that workload, and it is better to learn that from a curl than from a 404 at 3am.
2. Step 2: decide who owns routing. With LiteLLM, fallback order, retries, budgets and caching are configuration you write and can read. With FreeModel they are our design decision and you get a base URL. If a policy file is load-bearing in your setup, it has no counterpart here.
3. Step 3: check the licence boundary. LiteLLM's core SDK and proxy are MIT; the enterprise/ directory sits under a separate commercial licence. Confirm which parts you depend on before you plan around the word "free".

FreeModel vs LiteLLM FAQ