A model count does not measure usable access
- A directory can count many models without showing whether a new user can obtain a credential, which route works, or when the entry was last checked. The first comparison column should therefore be evidence status: official source, eligibility, verification date, and a reproducible request result.
- A smaller group of verified routes can be more useful than a larger untested catalog. FreeToken.link's purpose is to connect discovery to a key guide, current evidence, direct testing, and change monitoring instead of treating every listed model as equally obtainable.
Record what free means for each route
- Free can describe a model variant, a project tier, a temporary credit, or another conditional route. OpenRouter documents that adding :free requests a free variant, but also warns that those variants can have different limits or availability from paid versions. The qualification belongs in the comparison, not in fine print.
- Record the signup requirements, billing requirement if any, credential scope, available region information, and the exact model identifier you tested. Do not translate today's successful request into an unsupported promise of permanent free access.
Turn rate-limit dimensions into workload tests
- Google's Gemini documentation explains that request, token, and daily limits can independently stop a project, and that limits vary by model and tier. Groq likewise documents several request and token dimensions at organization scope. A single requests-per-minute number cannot represent either system.
- Use a small workload fixture: expected prompt size, output size, requests per minute, daily volume, and acceptable retry delay. Compare that fixture with the limits visible in the actual account, then test 429 handling and backoff. This produces an operational comparison rather than a marketing table.
Use a repeatable evidence matrix
- Score each candidate on verified access, required capabilities, usable capacity, observable errors, documentation quality, and change risk. Keep model quality as a task-specific test with a fixed prompt set; do not substitute a general benchmark or model count for your own acceptance criteria.
- Publish the source and verification date beside the result, and schedule rechecks through the FreeToken.link Watchlist. A transparent matrix can be updated when conditions change, while a ranked list with hidden assumptions quickly becomes stale.
Frequently asked questions
Why is model count a weak way to compare free AI APIs?
Because it does not show whether access is obtainable, which capabilities work, how limits apply, or when the route was last verified.
Which comparison fields matter first?
Start with official evidence, eligibility, verification date, required capabilities, account-level limits, and one reproducible request result.
How often should a free API comparison be rechecked?
Recheck when the provider announces a change, a test starts failing, a model ID changes, or your scheduled review date arrives.
AI assistance is disclosed; every factual claim was reviewed.
The first draft was produced through the locally hosted basketikun/chatgpt2api wrapper from a fixed pack of official-source facts. That wrapper uses a ChatGPT web-session route and is not the official OpenAI API. A human editor verified every retained claim, removed unsupported performance implications, and added the workload and evidence-matrix steps before publication.