The most useful thing you can do with our free API is stop using our quota
We run a free, OpenAI-compatible API that owns no models. Every request is forwarded to somebody else's free tier, and if that one refuses, to the next.
There is a daily quota, currently 5,000 requests and 500,000 tokens per account. It is not there to push you towards a paid plan, because there isn't one. It is there because the allowance we are spending is shared, finite, and not ours.
So we built the thing that makes the quota irrelevant, and it costs nothing: add your own provider key. Requests routed through a key you supply are not counted against the quota at all.
Why a free service wants you to use it less
The economics here are unusual enough to be worth stating plainly. We do not resell capacity. We hold free-tier accounts with about two dozen providers and route across them, so what we are rationing is a pool of allowances that refills on somebody else's schedule. When one caller uses a large share of it, the cost does not land on us as a bill. It lands on everybody else as a slower service, because the fast providers are already empty by the time their request arrives.
That makes heavy users a genuinely awkward problem for a free gateway. The usual answer is to start charging them, and we looked hard at that and decided against it, at least for now. A flat monthly fee on capacity we do not own is a bet that our best customer stays cheap, which is precisely the customer for whom it will not be true.
Bring-your-own-key solves the same problem from the other end, and better. If you already have a Groq or Mistral or Google account sitting idle, plugging that key in gives you your own allowance instead of a slice of a shared one. You get a higher ceiling, we get a smaller crowd around the shared pool, and the people still on the shared pool get a faster service. Nobody pays anybody anything.
Worth being clear about what we get out of it. A caller on their own key is a caller whose usage no longer constrains anyone. That is the entire benefit to us, and it is enough. There is no upsell attached and no feature held back to make this attractive.
What it actually changes
| Shared pool | Your own key | |
|---|---|---|
| Daily requests | 5,000 | not counted |
| Daily tokens | 500,000 | not counted |
| Per-minute ceiling | whatever is left of a shared free tier | whatever your account allows |
| Requests per minute, per IP | 100 | 100 |
| Cost | free | free from us, whatever the provider charges you |
Note the row that does not change. The per-minute limit is per IP and applies to everybody, because it protects the gateway itself rather than the upstream allowance. Your own key gets you past the daily quota, not past that.
Everything else works exactly as before. Same endpoint, same API key, same models, same failover. You do not change a line of your code, and there is no separate "BYOK mode" to opt into: once a key is stored, the router simply prefers it for that provider.
Handing a credential to somebody else
You should be reluctant to paste a provider key into a website. Here is exactly what happens to it, so the decision is an informed one rather than a leap.
Encrypted at rest, not hashed
It has to be reversible, because we have to send it upstream on every request. It is stored with Fernet symmetric encryption rather than in the clear, so a copy of the database on its own is not a copy of your keys. Anyone claiming a proxy can "hash" a key it needs to reuse is describing something that cannot work.
Never shown again, not even to you
After it is saved we keep the last four characters so you can tell two keys apart, and nothing else is ever rendered back into a page. A mistyped key has to be retyped rather than corrected in place. That is deliberately slightly annoying.
Checked once, on the way in
Saving a key makes one harmless call to that provider's model list. A key that does not work is rejected at the point you paste it, rather than turning into a confusing failure hours later in the middle of a request.
Revoked means revoked immediately
Revoking takes effect on the next request, with no cache to wait out. The row is soft deleted so the usage history stays honest, and the key it held stops being readable by the router the moment you click the button. If you would rather not trust that, rotate the key at the provider afterwards. That is a reasonable thing to do and we would not argue with it.
Not logged, not printed, not in an error message
The secret does not appear in request logs, in error bodies, or in the routing diagnostics we attach to a response. What we record about a request served on your key is that it was served on your key, which is what keeps it out of the quota.
Two limits worth knowing: 12 active keys per account and 20 additions per day. Both exist so that a stolen session cannot be used to farm the feature, and neither is a number you will meet in normal use.
Which providers
23 of them, which is every provider in our routing table that authenticates with a key of its own. Groq, Mistral, Google AI Studio, NVIDIA, Cohere, OpenRouter, Cloudflare, Hugging Face, Together, Fireworks, DeepInfra, Nebius, Novita, SambaNova, Hyperbolic, Scaleway, Vercel, GitHub Models, Alibaba, Upstage, AI21 and a few more.
You do not need all of them, or even several. One key for a provider you already use is enough to take your traffic off the shared pool, because that provider then handles your requests whenever it is the right hop for them and the rest of the chain stays available as a fallback.
A provider that is only free for a limited promotional window is deliberately excluded, since a key there would be worth nothing to you the moment the window closes.
How it is going, honestly
Nobody has used it.
The feature shipped, it is tested, it works end to end against real provider keys, and the number of keys stored is zero. That is not a mystery. Until today it was mentioned on the account page and almost nowhere else, and the people who would benefit most are by definition the ones talking to the API rather than reading the site.
So the quota error you get back from the API now tells you this exists, which is the only surface that actually reaches somebody mid-integration. That is a much smaller and more obvious idea than the feature itself, and skipping it made the feature worth nothing for a week.
We would rather publish that than a launch post with no numbers in it. If this page ages well, the interesting follow-up is whether putting the option in the error body was enough on its own.
You should probably do this if
- You have hit the daily quota, or you can see on your account page that you are heading for it.
- You send long prompts. A large context is exactly what a shared per-minute token budget handles worst, for reasons we measured in some detail.
- You already pay a provider and have headroom sitting unused on that account.
- You are building something where being throttled at an unpredictable moment is worse than the ten seconds this takes to set up.
And if none of those are true, do nothing. The free tier is genuinely free and is not going to start nagging you. This exists for the small number of people who outgrow it, which is a nicer problem for both of us than a paywall would be.
Set it up
Sign in, open your account page, scroll to "Your own provider keys", pick a provider and paste the key. It is checked immediately and used from your next request onwards.
Add a provider key