Use /v1/chat/completions for most OpenAI-compatible SDKs and applications.

Use /v1/responses for Codex and clients built around the Responses API.

Use /v1/messages for Claude Code and Anthropic-compatible clients.

Add any valid provider model slug, such as qwen/qwen3-coder-next, without editing the deployment configuration.

Only the selected active model is sent upstream. Inactive saved models are never silently attempted.

Models show healthy, unavailable, unauthorized, rate-limited, error, or not-tested state without incorrectly opening the provider circuit for a model-specific 404.

Add, activate, test, edit, and delete saved models from the provider card. The active model cannot be deleted until another option is selected.

The provider remains openrouter, groq, or nvidia regardless of which saved model is active. Model slugs never become part of provider IDs.

Rate limits, timeouts, connection failures, upstream 5xx responses, and malformed successful responses.

Client-side validation or unsupported request errors are returned without repeatedly calling every provider.

When every candidate fails, the router returns a sanitized providers_exhausted response.

Provider defaults describe the API transport. Each saved model can override those values with its own supported, unsupported, or unknown capability state.

Every model value identifies whether it came from a user override, capability probe, runtime request, built-in model catalog, or provider default.

Successful real requests verify support. Only clear capability-specific rejections mark a feature unsupported; rate limits, timeouts, and generic provider failures never change it.

Flexible mode keeps unknown models as lower-confidence fallbacks. Strict mode excludes unknown support for required capabilities before any upstream call.

See authentication, alias resolution, filtering, ranking, provider starts, outcomes, retries, backoff, and final delivery with elapsed milliseconds.

Skipped-provider events preserve capability mismatches, quota exhaustion, cooldowns, open circuits, and half-open recovery probes.

Expand raw details for any event or copy the complete plain-text timeline for debugging and issue reports.

The same event format is stored for successful failover, exhausted routes, invalid provider keys, and deduplicated requests.

Send a valid x-request-id, or let the gateway create a collision-resistant req_... value. Unsafe and oversized IDs are replaced.

Every retry forwards the same safe x-request-id to the selected provider without exposing router keys, account IDs, or storage identifiers.

The ID appears in response headers, structured error bodies, streaming headers, request timelines, and the Analysis record.

Headers show the winning provider, provider model, requested alias, strategy, attempt count, fallback usage, latency, quota warning, circuit state, cooldowns, and retry-stop reason when applicable.

Each duplicate keeps its own request ID while x-free-llm-original-request-id points back to the upstream operation that produced the reused response.

Paste a request ID into the Analysis search box, copy it from the drawer, inspect every returned routing header, or jump from a duplicate to its original record.

Measures authentication, account loading, alias resolution, capability checks, quota checks, circuit checks, and provider ranking before the first upstream call.

Separates time to upstream headers from response-body or stream consumption and preserves an independent breakdown for every retry.

Captures time to first provider token, active stream duration, output throughput when token usage is available, and final stream-processing time.

Shows configured backoff separately from provider latency, so a slow response can be distinguished from deliberate recovery waiting.

Failed requests retain partial timing evidence, while reused responses report deduplication latency without inventing a provider call.

Performance headers provide quick client-side measurements, while the Analysis drawer adds metric cards, timing bars, per-provider details, and a copyable report.

Compare input, output, reported, and estimated usage without double-counting deduplicated requests.

See how often the first provider fails and which provider sequence ultimately completes the request.

Track tool-enabled requests, generated calls, requested tool names, and structured-output validation.

Group traffic into Codex CLI, Claude Code, OpenAI SDKs, cURL, and unknown clients without storing sensitive headers.

Compares completed requests, upstream attempts, success rate, average and P95 latency, token consumption, fallback starts, and recovery wins for every provider.

Shows traffic, success, latency, streaming share, tool usage, token volume, attempts, and fallback rate by API compatibility format and model alias.

Compares Codex CLI, Claude Code, OpenAI SDKs, Anthropic SDKs, cURL, and unknown clients by volume, reliability, latency, tokens, tools, API mix, and aliases.

Time range, provider, API, status, alias, application, delivery mode, tools, and search apply consistently while switching dashboards.

Every comparison table includes a View logs action that opens Request Logs with the matching provider, API, alias, or client filter already applied.

Client demand still includes deduplicated responses, while provider attempts, tokens, and fallback metrics count only real upstream work.

Remove an active rate-limit cooldown when you know quota is available again.

Run a real half-open probe immediately against an open circuit.

Manually close the circuit and clear its failure state.

Configure request limits, token limits, or both from each connected provider card.

Every upstream attempt updates request counters. Successful responses add provider-reported or estimated token usage.

Providers above the warning threshold are deprioritized. Providers at a configured limit are skipped until the relevant UTC window resets.

Request details show input, output, total tokens, and whether usage was reported or estimated.

Set the normal provider timeout, hard total-request deadline, streaming connection timeout, and shorter half-open recovery-probe timeout.

Cap upstream calls per request so a long provider list cannot create unlimited failover work.

Provider-specific 401, 403, and 404 failures move immediately to the next provider. Configured transient statuses, network failures, and malformed responses use retry pacing.

Configure the initial delay, maximum delay, multiplier, and randomized jitter used between retryable failures.

Give one slow provider a longer timeout or force an unreliable provider to fail fast without changing every provider.

Specialized aliases can override provider timeout, total deadline, and maximum attempts while inheriting every other router setting.

Two identical requests arriving together share one provider operation. Both clients receive the same completed response.

Successful non-streaming responses may be replayed during the configured one-to-300-second window.

Fingerprints include the router identity and endpoint, so different accounts can never share cached work.

The alias, messages or input, temperature, token limits, tool definitions, and structured-output settings all affect the match.

Clients can explicitly identify one logical operation. The key takes precedence over automatic request fingerprinting.

Streaming is always excluded. Tools, multimodal inputs, and explicitly non-deterministic settings are bypassed by default.

Signed-in users load only their own router settings, aliases, provider keys, and analytics.

The full flm_... key is shown once and should be treated like any production secret.

Run with local JSON for development or Redis/KV for persistent deployment state.

Provider credentials can be encrypted at rest with AES-256-GCM when the encryption secret is configured.