Free LLM API models: what you get at $0, where the limits are, and when to pay

What "free" means on this platform

A free-tier model id costs $0.00 per million tokens for both input and output. You still authenticate with an API key, you still receive usage counts, and the request goes through the same chat completions endpoint as every paid model. The difference is purely in billing: free-tier requests never check your prepaid balance and never return 402 Payment Required. The current list is on the pricing page with the free filter, and the live table below is read from the catalog on every page load.

Why a provider can offer models at $0

Free-tier ids are open-weight models served on FastInfra's own GPU capacity, so there is no per-token upstream cost to pass on. The platform recovers the GPU cost from paid traffic and from GPU Cloud and server rentals; the free tier is how developers evaluate the API before committing credits. That economic model is also why the free list changes over time as capacity is reallocated: pin the model ids you depend on and watch the changelog for additions and removals.

Where the limits are

The complete and current limits are listed in the rate limits section of the documentation; anything that can return 429 is on that page, and limits are never lowered under load. When you hit one, the response includes a Retry-After header. There is no monthly token cap on the free tier.

What free models are good at

Mid-size open models handle a large share of production tasks well: classification and routing, entity extraction, summarising short documents, rewriting and formatting, SQL and regex generation, and first-pass drafts that a human edits. Where they fall behind frontier models is long multi-step reasoning, very long contexts, and tasks that need deep world knowledge. A useful habit is to build every feature against a free id first; you learn the prompt shape and the token profile for nothing, and you have a measured baseline to compare paid models against.

Using a free model as the production fallback

Because free ids never return 402, they make a dependable safety net. A minimal pattern:

def complete(messages):
    try:
        return client.chat.completions.create(model=PAID_MODEL, messages=messages)
    except openai.APIStatusError as e:
        if e.status_code == 402:
            return client.chat.completions.create(model=FREE_MODEL, messages=messages)
        raise

Pair it with a balance alert in the console so the fallback is a bridge, not the steady state. The same two-model configuration is what makes gradual rollouts safe: shift a percentage of traffic to a paid id and compare quality and cost side by side.

Signals that it is time to pay

• Quality. Your evaluation set shows a gap on the tasks that matter, and prompt changes have stopped closing it.
• Concurrency. You are hitting free-tier 429s at peak and backoff is lengthening user-visible latency.
• Context. You need longer context windows or capabilities (vision, tool calling at scale, video) that only paid ids offer.
• Latency. Time to first token on the free route is above your budget and a smaller paid model would be faster.

None of these is a calendar event. Teams that move too early pay for capacity they do not need; teams that move too late ship a worse product to save cents.

Beyond free: the cheapest paid step up

The first paid rung is not expensive. The cheapest paid chat route today starts at $0.0179 per million input tokens and $0.021 per million output tokens, and the median paid model costs $0.2835 in and $0.882 out. For most features that is a few dollars a month at prototype volume. The LLM pricing guides cluster has the estimation formula if you want to size it precisely before topping up.

Getting the most out of the free tier

Three habits make the $0 tier go further. First, keep prompts tight: free-tier models are smaller, so a clear system prompt with one task and an explicit output format gets better results than a sprawling instruction set. Second, cache aggressively on your side; identical requests (classification of the same input, repeated summaries) should never hit the API twice. Third, batch where the API allows it: the embeddings endpoint accepts up to 2,048 strings per call at $0, so index documents in bulk rather than one request per chunk.

When you do hit a 429, honour Retry-After and queue the work rather than hammering the endpoint; the limits are per key, so a second key does not buy more capacity for the same account. If free-tier throughput is the only thing holding a feature back, the first paid rung is cheaper than most teams expect, and the model catalog shows exactly which ids sit just above $0.