Free-LLM-Collection: A Curated Index of OpenAI-Compatible Free LLM Endpoints

What the collection solves, and who it is written for

Free LLM access is scattered. Each provider issues keys through a different console, publishes limits in a different unit (requests per minute, requests per day, requests per hour, or nothing at all), and documents its endpoint under a different path. The repository collapses that into one Markdown page. The stated problem is discovery plus triage: which free endpoints exist, which ones are OpenAI-compatible, and which ones are worth the signup.

The audience is narrow and clearly stated. The README says only OpenAI-formatted APIs are accepted, so anyone using a provider SDK that expects a native protocol is out of scope. The other filter is the selection rule, quoted from the README as: long-term usable > limit request rate over token count > more sources > newer and better models > sufficient rate limits. That ordering is the interesting part. The maintainer prefers an endpoint that will still answer in six months over one that offers a larger quota today, and prefers a provider that meters requests rather than tokens, because a request cap is predictable while a token cap depends on output length.

This is a reference page for a developer choosing where to point a test harness, a small agent, or a local client. It is not an SDK, not a proxy, and not a router. Nothing in the repository executes.

The entry format and what each provider record actually contains

Every provider is a Markdown section with a consistent shape: a link to the provider site, an API base URL, a rate limit line, and a list of recommended or available model identifiers. The base URL is the operative field, because it is what you paste into a client's base_url setting. SiliconFlow is listed at https://api.siliconflow.cn/v1 with 1000 RPM per model. OpenRouter is listed at https://openrouter.ai/api/v1 with 20 RPM and 200 RPD per model, and its model list includes entries such as openrouter/free and google/gemma-4-31b-it:free. Google Gemini appears at https://generativelanguage.googleapis.com/v1beta/openai, which is the compatibility path rather than the native Generative Language API, and the entry splits models into tiers: gemini-3-flash-preview at 5 RPM and 20 RPD, a second group at the same limits, a lite group at 15 RPM and 500 RPD, and gemma models at 15 RPM and 1500 RPD.

Some entries carry operational notes that are easy to miss. Intern AI is listed with a 10 RPM limit and a note that the key is valid for six months, which turns key rotation into a scheduled task rather than a one-off. Cohere is listed at https://api.cohere.ai/compatibility/v1, again a compatibility surface, with a note that binding a payment method gives access to a Production Key with looser limits. Bigmodel, Mistral, and OpenCode Zen are listed with rate limits marked Unknown. ModelScope is listed with a single 2000 RPD figure rather than a per-minute number. Those asymmetries are the point of the document: limits are reported as the maintainer found them, not normalised into a uniform schema.

Model identifiers are given verbatim, which matters because the identifier is what you pass as the model parameter. NVIDIA NIM lists 40 RPM and identifiers such as deepseek-ai/deepseek-v4-flash. Groq lists 30 RPM and 1000 RPD with openai/gpt-oss-120b and qwen/qwen3-32b. Because the identifiers are copied rather than generated, they are the most perishable part of the file.

Getting a request through: base URL, key, model string

There is no install step. The repository ships a README and an image, Taple.png, which the README describes as a table rendered by a separate project called Taple. The Markdown sections are the machine-readable part; the image is a visual duplicate of the same data, generated by an LLM according to the README.

To use an entry you need three values from the page and one from the provider. The base URL comes from the entry, for example https://api.groq.com/openai/v1/. The API key comes from the provider's console, not from the repository. The model string comes from the model list under that entry. With those, any client that accepts an OpenAI-compatible base URL works, because that is the only compatibility guarantee the collection makes.

A minimal check with the OpenAI Python client would set base_url to the entry's URL and api_key to your provider key, then call the chat completions method with the model string copied from the list. The repository does not document an environment variable name, a config file, or a wrapper script, so there is no project-specific configuration key to learn. That is a deliberate simplicity: the artefact is data, and the integration surface is whatever client you already use.

The cost of that simplicity is that nothing validates the data. If a provider changes its path from /v1 to something else, the README has no test that would catch it. The only signal is a failed request on your side.

Where the list breaks down: staleness, unknown limits, and single-maintainer drift

The README is explicit that maintenance is a one-person effort, described as updating and maintaining the project as well as possible while currently being the only contributor. There are no retrieved releases, so there is no versioned snapshot to pin and no changelog to diff. Combined with a last push timestamp, the only way to know whether an entry is current is to compare the file against the provider's own documentation.

Several entries already carry Unknown for rate limits: Bigmodel, Mistral, and OpenCode Zen. An unknown limit is not a neutral fact for anyone building around a free tier, because it means the failure mode is a surprise 429 rather than a planned budget. The same applies to ModelScope's single 2000 RPD figure with no per-minute number, which tells you the daily ceiling but not how fast you may burst.

The larger structural limitation is scope. Only OpenAI-format APIs are accepted, so a provider with a generous free tier and a native-only protocol is excluded by design, not by oversight. The model lists are also recommendations rather than inventories, so the absence of a model from an entry does not mean the provider lacks it. And because the file is a static document, it cannot express conditional facts such as a limit that differs by account age or by region. Treat every number as a snapshot with no expiry date attached.

How this differs from a routing gateway

The obvious alternative approach is a gateway that holds your provider keys and routes a single request across many upstreams, retrying on failure. OpenRouter, which appears in this collection as one entry among many, is that kind of service: you point at one base URL, and it decides which upstream serves the request. The difference in approach is where the routing decision lives. In a gateway, the routing is a runtime concern handled by the service. In this repository, the routing is a reading decision handled by you: you look at the table, pick an endpoint, and hardcode it.

That difference has consequences. A gateway can absorb a provider outage or a rate limit without your code changing. A curated list cannot; if Groq returns 429, your client sees the 429 unless you wrote your own failover. On the other side, a list keeps you in direct contact with the provider's own console and limits, and it does not add a hop or a second set of terms between you and the model. It also covers providers that are not aggregated anywhere, such as Intern AI or Bigmodel, which a single gateway may not expose.

A second alternative is simply reading each provider's own pricing and limits page. That is more work per provider, but it is always current, and it is the only source that will tell you about a limit change the day it happens. The repository's value is the shortlist and the compatibility filter, not the numbers.

Maintenance cost and the licence question

The material does not state a licence. The repository metadata shows the license field as unknown, and the README contains no licence section. That is a real gap for anyone who wants to copy the table into their own documentation or tooling: without a licence file, the default position is that no permission has been granted, and the safe reading is that you may link to the repository but should not assume you may redistribute its contents. This is not legal advice, and if redistribution matters to you, ask the maintainer directly rather than inferring terms from the absence of a file.

Upgrade cost is effectively re-verification cost. There is no dependency to bump and no migration to run. What you pay is the time to re-check each endpoint you rely on, because the file has no test suite, no CI signal, and no releases. The Intern AI note about six-month key validity is the clearest example of a maintenance item the list surfaces but cannot automate: you have to track the expiry yourself.

Given a single maintainer, the practical expectation is that entries are added faster than they are pruned. A provider that quietly stops offering a free tier may sit in the file for a while. Budget for that by treating the list as a starting point and each provider's own console as the authority.

Who should use this list, and what to check before you do

Use it if you are prototyping, comparing model outputs across providers, or need a fallback route for a side project where a 429 is an inconvenience rather than an incident. The selection rule is a useful filter: it steers you toward endpoints that meter requests rather than tokens, which makes capacity planning arithmetic instead of guesswork, and toward providers the maintainer judged durable. The compatibility requirement means every entry plugs into the same client code with only base_url and model changed, which is exactly what you want when you are swapping models to compare them.

Do not use it as the source of truth for a production system. A static Markdown file with one maintainer, no releases, and no stated licence is not a dependency you can pin, audit, or get support for. If you need failover, a gateway is the right shape of tool, and this list is not one.

Before you wire anything in, check the licence situation, confirm the specific entry's limit line against the provider's current documentation, and confirm that key issuance still works from your region. Then copy the base URL and model string, and keep your own note of the date you verified them, because the file itself carries no per-entry timestamp.

Editorial conclusion

Adopt this list if you need a shortlist of free OpenAI-compatible endpoints for prototyping, model comparison, or a fallback route, and you are willing to re-verify each base URL and rate limit yourself before wiring it into anything. Do not adopt it as a production dependency: the repository is a static document with one maintainer, no releases, and no stated licence, so there is no version to pin and no support channel. Verify three things first: the licence file, whether the entry you want still lists the same rate limits, and whether the provider's key issuance still works for your region.

Official sources

1. for-the-zero/Free-LLM-Collection on GitHub
2. Issues
3. README