Short answer

Use it when you already have provider keys and want one local endpoint with routing and fallback. Keep the dashboard private, respect every provider's quota and terms, and test failure behavior before depending on it.

What it is—and what it is not

The project documents a local router that presents OpenAI-compatible endpoints and sends requests to upstream providers you enable. Its homepage calls the software self-hosted, open source, and single-user. Provider free allowances, availability, promotions, and terms still apply.

The homepage and README currently show different catalog counts, which is exactly why this guide does not freeze a provider or model total. Consult the live catalog and your installed router. “Free” describes upstream allowances and the open-source router; it does not mean unlimited capacity.

A bounded setup sequence

  1. Read the official install guide and choose the documented desktop, Docker, or source path that fits your machine.
  2. Keep the dashboard bound to a private/local interface. The project explicitly says not to expose the proxy publicly.
  3. Create or copy the router's unified key from its local dashboard.
  4. Add only provider credentials you obtained legitimately, then use the project's key test or dashboard status for each provider.
  5. Point one OpenAI-compatible client at http://localhost:3001/v1 and use the unified key—not an upstream provider key—in that client.
  6. List models or make a small non-sensitive request, then confirm the response's routed-provider metadata before adding fallback chains.

These steps summarize the current documentation. They are not a record of an OpenDots installation test.

Where the keys live

The README says provider keys stay in the local SQLite database, encrypted at rest with AES-256-GCM, and are decrypted in memory per request. Client applications receive a single unified router bearer token. Requests then go from your machine to the upstream providers you enabled.

Encryption at rest is not permission to publish the database, environment files, dashboard token, unified key, or backups. Keep them out of Git, screenshots, issue reports, and browser URLs. Use the documented dashboard or keys add|list|remove|test commands rather than pasting secrets into chat.

Choose a client and symptom

Choose a client and symptom, then generate a local troubleshooting checklist.

The checklist collects no key, endpoint credential, error body, or telemetry.

429 and exhausted-quota troubleshooting

A 429 can mean a per-minute ceiling, daily quota, token limit, exhausted free allowance, provider cooldown, or an account-level restriction. Do not rotate accounts or keys to evade a provider limit.

  1. Identify the provider and model that actually served—or rejected—the request. Inspect router logs and the documented X-Routed-Via response header where available.
  2. Read the upstream provider's current quota dashboard and terms. Wait for a documented reset or reduce request rate, context, or output.
  3. Run the documented stored-key test for that provider. A valid key can still have no remaining quota.
  4. Confirm another enabled model/provider is eligible for the requested capabilities and is present in the active fallback chain.
  5. Make one small retry after the cooldown. Preserve the status, provider, model, and timestamp if it still fails.

Failover cannot make an incompatible model satisfy a request, restore an expired promotion, or exceed every provider's remaining quota.

Configure failover before the outage

The README documents automatic fallback on 429 and selected 5xx responses, cooldowns, key rotation, and named fallback-chain profiles. Treat that as router behavior to configure and verify—not a promise that every failure is recoverable.

Build a chain whose models support the features your client needs, such as tool calls, vision, the Responses API, or a particular context size. Send a harmless test, note X-Routed-Via, and simulate only a safe, reversible failure such as temporarily disabling your own first route. Do not deliberately exhaust provider quota.

Know the ChatGPT boundary

An already configured router can help API clients continue through a provider incident. It does not transparently migrate an ordinary ChatGPT web account, subscription, chat history, custom GPT, memory, or workspace. The repository documents a separate private MCP tunnel for ChatGPT; that is an explicit integration, not automatic failover for the ChatGPT website.

FAQ

Is FreeLLMAPI unlimited free inference?

No. It routes across provider allowances you configure. Each provider's quotas, availability, promotions, and terms still apply.

Should I expose the router to the public internet?

No. The project describes it as single-user and explicitly says not to expose the proxy publicly.

Why do the model and provider counts differ?

The catalog changes and the homepage and repository can update on different schedules. Use the current live catalog and your installed router instead of relying on a fixed count in this guide.

Can it replace my ChatGPT website account?

No. API routing does not move a ChatGPT subscription, conversations, memory, or web-app features.

Did OpenDots test the router?

No. This guide is based on the current project documentation; no third-party installation or inference request was performed.