Skip to content

Free Tiers and Free Models: What They Really Cost

5 min read · updated August 3, 2026

“Free LLM” describes at least four unrelated offerings with different risks, and the confusion between them is why the question is usually argued rather than answered. Separate them first.

Four things called free

What it isDescription
free tierA paid API with a no-charge allowance: some requests per minute or per day at $0. The model is the commercial one. The constraint is rate, and sometimes the data terms differ from the paid tier.
trial creditA fixed amount of paid usage granted up front. Not free, prepaid — and it expires. Useful for evaluation, dangerous as a basis for a launch plan because the cliff arrives on a date rather than at a usage level.
open-weight modelWeights you can download under some licence. Free to acquire, not free to run: the cost is GPU time, and it is usually the largest number in the comparison.
hosted open model at $0Someone else runs an open-weight model and does not charge for it, typically with tight rate limits. Free at the point of use; the economics are the host's, which means the offer can change.

The first and fourth are the ones people build on and the ones this page is mostly about. The third is a different decision entirely and has its own break-even.

The questions to ask of any of them

Not a list of accusations — a diligence checklist. Every one of these has a documented answer somewhere in the provider’s terms, and the point is that you should read them for the specific offer you are considering rather than assume anything from a generic warning.

  • What is the rate limit, in what unit? Requests per minute, tokens per minute and requests per day are different ceilings and you can hit any of them first. Find the smallest one relative to your traffic shape.
  • What happens when you hit it? A 429 you can back off from is one thing. A queue that adds thirty seconds is another. Silent degradation to a smaller model is the worst, because your quality metric moves and nothing in your logs says why.
  • What are the data-use terms for this tier specifically? Free tiers sometimes carry different terms from paid ones at the same provider. Whether your prompts may be retained, reviewed or used for training is a question with a written answer, and it is the one your customers will eventually ask you in a security questionnaire.
  • Is the model version pinned? If “free” means “whatever we are currently pointing that alias at”, your quality baseline can move without a deploy on your side.
  • Is there an SLA, and does it apply here? Usually not, on a free tier. That is not a scandal — it is information, and it decides whether this can sit in a user-facing path.
  • Can you upgrade without a code change? The single most important operational question. If moving to paid means the same endpoint with a different key, the free tier is a low-risk starting point. If it means a different API shape, you have a migration in your future and should price it now.

The arithmetic of outgrowing a free tier

A free tier is worth using when the spend it avoids exceeds the cost of the eventual migration plus the risk of hitting the ceiling unprepared:

free is worth it when:

  M * S  >  h * rate  +  R

  M      months you expect to stay under the limit
  S      monthly spend the free tier avoids
  h      engineer-hours to migrate off it
  rate   loaded hourly cost
  R      expected cost of the disruption when you outgrow it

Worked, all inputs assumed. Suppose the free tier covers your traffic for 8 months, your paid spend would have been $200 a month, migration is 12 hours at $120, and the disruption — a day of degraded service while somebody scrambles — you value at $2,000.

saved   = 8 * 200          = $1,600
cost    = 12*120 + 2,000   = $3,440

Free loses by $1,840.

Now change one input: make the migration a key swap, so h = 1 and the disruption is nil because you tested the paid path in staging. cost = $120, and free wins by $1,480 on identical usage. The conclusion is not “free tiers are bad”. It is that the value of a free tier is almost entirely determined by how cheap it is to leave, and that is a property you can engineer for on day one by keeping the provider behind an interface and testing the paid path before you need it.

The other term worth attention is M. It is the one people overestimate, because free tiers are sized for evaluation and product growth is not linear. Compute it: M is when your projected request rate crosses the limit, using the growth model rather than a feeling.

What a zero price does not include

  • Rate limits become an architecture. Living under a tight limit means a queue, a backoff layer, a dead-letter path and somewhere to buffer bursts. That is real code with real maintenance, and it exists solely because of the limit.
  • Reliability is your problem. Without an SLA the mitigation is a fallback to a paid provider, which means you have built and are maintaining two integrations to avoid paying for one.
  • Evaluation is not free. If the free model is different from the paid one, everything in your prompt is tuned for it, and switching later means re-tuning and re-validating.
  • Support does not exist. When something is wrong at 2am, the free tier is a forum thread. Price the on-call hours.
  • Offers change. A $0 hosted model is somebody else’s cost centre. Treat its continued existence as an assumption with a review date, not as a platform.

When free is the right answer

There is a clean set of cases, and they share one property: the consequence of the free tier disappearing tomorrow is bounded and known.

  • Evaluation and prototyping. Obviously, and this is what the tiers are for. Use them, and do not build the production path on the assumption they continue.
  • Internal tools with patient users. A rate limit that would be intolerable in a product is fine for a nightly job somebody in your own company runs.
  • A fallback for a fallback. Degraded service is better than no service, and a free tier is a reasonable last leg of a chain — as long as it is not the first.
  • Genuinely low-volume features. If a feature makes forty calls a day and will never make four thousand, the free tier may simply be the correct permanent answer and there is no migration in your future at all.

And one case where it is clearly wrong: a user-facing path in a product people pay for. The saving is small relative to revenue, the failure mode is visible to customers, and you will spend more engineering hours working around the limits than the paid bill would have cost.

Free Tiers and Free Models: What They Really Cost · Multigrid