Free Relay AI API Routers

Take an upstream model API — a lab's endpoint, a cloud platform, sometimes a cluster of them — and put a middle layer in front that offers access for free: a shared endpoint anyone can call, a community server that pools capacity, or a project that grants keys that map to free upstream usage. That middle layer is the relay, and this category is the 33 of them the directory tracks. The operators range from named community projects with documentation to smaller efforts that are effectively a server and a README; the entry pages carry whatever evidence exists for each, and the risk rationale says what that evidence does and doesn't establish.

Relays solve a real problem: they extend model access to people and projects that the upstream free tiers don't reach — no card, no quota gaming, no signup wall. They also import a real problem: the upstream access being relayed is usually itself free-tier access, and free-tier terms are written for individual developers, not for a reseller audience of unknown size. That mismatch is the center of gravity for everything else on this page.

Upstream providers are explicit that their free access is personal. OpenAI's usage policies prohibit sharing accounts or credentials and reselling access to the API; other labs' terms carry the same shape in their own words. A relay that pools many users' free-tier keys — or a single operator's keys serving a public endpoint — sits on the wrong side of those clauses, which means the access it provides can be revoked upstream at any time, for the operator, with you inheriting the revocation. Some relays are more careful: they relay access the operator legitimately controls (its own paid capacity offered free as a project, open-weight models served on self-hosted infrastructure where no upstream clause applies at all). The difference is visible in the entry evidence — self-hosted open-weight relays have a structurally cleaner file than pooled-key relays — and it's exactly what the risk tiers separate.

The dataset scores this per entry rather than per category: the category tells you the mechanism (relay), the risk tier and rationale tell you the specific exposure (pooled keys, vague operator, unclear data handling — or, for the cleaner ones, "self-hosted open models, no upstream dependency"). A uniform "relays are risky" would be lazier than the data, and less useful.

Appropriate: learning projects where the goal is understanding the API surface; prototypes and demos that will either die or get moved to a real backend; batch work on public, non-sensitive data where a dead endpoint costs an afternoon of re-runs; and fallback paths — a relay as the second option behind an official tier is cheap resilience. Inappropriate: anything carrying private or regulated data (a relay's data handling is exactly as documented as its operator is, and several entries document little); anything on a user's critical path; and anything where you'd be surprised to lose the endpoint, because surprise is the default operating condition of this category.

There's an economics note that surprises people: relays are often free in cash but expensive in attention. Reading the README, discovering the endpoint moved, re-pointing your config, re-testing after an upstream model rotation — that time is the real price. Budget it like a cost, and the category compares honestly against a $5/month official tier that does none of that.

The probe data is the most decision-relevant column on this page. "Up" is a recent clean check from our network; "down" is a failed check; "unknown" is no recent clean probe — common for relays, whose operators don't run status pages, and not a verdict. The probe history on each entry shows the shape of the endpoint's life: steady, flapping, or a long decay. A relay that has been "up" with a stable latency profile for months is a different asset than one that probed cleanly once. None of this is a guarantee — probes measure from our location on our schedule, and a relay can be fine for you and dead for us, or the reverse — but it is dated, repeatable evidence, which is more than this category typically gets from anywhere else.

Work the entries in this order. First, infrastructure: self-hosted open-weight serving (no upstream dependency, no pooled keys) is structurally the safest shape; pooled free-tier keys is the shakiest; "the operator's own paid capacity offered free" is the middle and worth reading the terms on. The entry evidence and risk rationale name which shape each entry is. Second, documentation: a relay with a README, an operator identity, a contact route and a published endpoint history is an organization; one without is a server. The gap between them is most of the risk difference in this category. Third, data handling: anything documented at all (even "we don't store prompts") beats silence, and silence on a relay carrying your data is a decision, not an absence of information. Fourth, the probe shape: stable history over months beats a single clean ping, on the evidence above.

And the meta-decision, which matters more: does this workload even belong on a relay? The same question answered "no" points at /best/free-credits (official tiers with real terms) or /paid-api (the $5 tier that never moves). Relays win on zero-cost access to models the official free side doesn't serve — if that's not your need, the category is the wrong room for your problem.