Free Product AI API Routers

Three categories on this site all contain free access, and the distinction between them is who the free access serves. Official free tiers serve the lab's funnel — free now, paying later. Relays serve a community the upstream doesn't plan for. Free products serve the product itself: the free endpoint is the product's distribution mechanism, its data engine, its acquisition surface, and it is free for as long as the product exists. Pollinations is the cleanest example in the slice — one OpenAI-compatible API across text, image, audio and video with "free Pollen for prototypes & testing", an open-source stack and a user wallet system, where the free access is the on-ramp to an ecosystem rather than a countdown to an invoice.

The 26 entries span that shape: developer platforms whose API is free as policy, creative products (music generation, image tools) that expose API access within a free product tier, and open-model endpoints operated as products. What unites them is structural: the free access has a product team behind it, a published limits regime, and a reason to keep existing that doesn't involve your payment card. That makes it the most durable kind of free in the directory — and a different set of constraints, which is the rest of the page.

Product free tiers are engineered quotas, and they read differently from trial balances. Instead of "$30 that depletes", you get "N requests per day per user, reset at midnight", "M generations per month", or "open endpoint with soft rate limits" — the entry's credit note carries whichever applies, and where we convert a quota to USD at the product's own published rates (or the nearest comparable), the flag marks the assumption. Suno's free tier works this way for music generation: a daily generation allowance inside a product whose premium tiers exist but aren't required for the free surface — the dataset records the free shape and the premium context separately, and the credit value reflects the free side only.

Two constraints deserve explicit attention because they surprise. First, per-user sizing: product quotas are set for an individual user of the product, not a service account calling it ten thousand times a day — the moment your usage looks like a datacenter, you're in the product's abuse-prevention problem, and the limits enforce that. Second, roster control: a free product serves the models and modalities its product needs, so "free access to GPT-class models" via a product endpoint may mean "free access to whatever this product decided to serve", which changes with its roadmap. The tracked model list on each entry is the current answer; the product's docs are the live one.

Free products serve consumers, and their data terms are written for that audience: prompts may inform product improvement, outputs may be displayed or retained, and the privacy policy is a consumer document rather than an API contract. None of that is unusual — it's the stated price of the free surface — but it changes which workloads belong here. Public-content generation, personal projects, creative work you'd be fine seeing in a community feed: at home. Anything with private data, client data or compliance expectations: the terms need a read that treats them as the contract they are, and the entry links the product's documentation and policy pages where they exist. Where the data policy is thin or consumer-vague, the entry's risk file says so, the way it does for every category.

The probe data reads differently in this category than in relays, and better: product endpoints run status pages, publish changelogs, and their "down" events are incidents with post-mortems rather than terminations. An "unknown" status here usually means our probe cadence missed a window, not that the product is dying; a "down" with a fast recovery in the history is normal operations. The entries carry the probe history either way, and the last-verified dates tell you how recent the free-shape description is — product free tiers change with releases, and a quarterly product update can quietly resize your quota.

Run four checks in order. One, the free shape: daily-reset quota (buildable on — plan around the reset), per-user soft limit (fine for personal scale, wrong for service scale), or open endpoint (convenient, and the softest commitment of the three). The credit note states it; the product's docs confirm it. Two, the roster: does the product currently serve the model and modality your workload needs — check the entry's tracked model list and the product's model page, because the roster is a product decision that moves. Three, the data posture: read the product's policy on prompt retention and improvement-use and decide, explicitly, what you're comfortable sending. Four, the operator: a product with a changelog, a community and a support channel is a different durability class from one that's a weekend project wearing a product coat — the risk rationale and the community signals on the entry separate them.

The category question underneath all four: does your workload fit a consumer-shaped free surface? Creative generation, personal tooling, public-facing experiments — yes, and this is the best free in the directory for that. Production services, private data, predictable SLAs — the free product is the prototype home, and /best/free-credits or /paid-api is where the production version goes. Both belong in the same architecture, with the product endpoint behind the fallback line, not in front of it.