Usage & Spend

The dashboard home page reports request volume, error rate, latency, model and provider breakdowns, and live provider spend — filterable by time range and FreeRouter key. A daily report email covers the previous day every morning.

What you see

• Requests over time — per-hour bars for the last 24 hours, per-day bars for the last 7 or 30 days, with errors overlaid and average latency as a line.
• Top models — the models your keys actually called, as a share of requests.
• By provider — how requests split across the gateways in your routing rules.
• Router overhead — under Avg latency, the FreeRouter-added slice (time-to-first-byte minus upstream wait, averaged over non-streamed requests). The rest of first-byte time is the gateway. The Logs tab shows the same split per request as Router, Upstream, and Duration. Expand a log row to see the attempt path (which gateways were tried, headers vs failed-attempt drain).
• Provider spend — live spent-vs-limit cards per provider key (see below).

What latency does FreeRouter add?

It depends on your setup — as little as sub-1 ms for simple routing, closer to 20–30 ms for complex ones:

• Simple routing (sub-1 ms) — routing decisions are served from a pre-warmed in-memory cache: every key's rule is loaded at proxy startup and re-validated each time you change a routing rule, so the hot path never waits on a config read.
• Complex setups (20–30 ms) — model remaps and request translation, plus failover where a dead attempt's response body must be drained before the next gateway is tried, add real work per request.

You don't have to guess which side you're on. Every request's Logs row splits time-to-first-byte into dedicated Router, Upstream, and Duration columns (Router + Upstream = Duration), and the dashboard averages the FreeRouter-added slice under Avg latency. A large Router number with multiple attempts is usually failed-attempt drain, not routing config — expand the log row to see the attempt path and exactly where the time went. With request-body capture switched on in Settings, the expanded row also shows the full request.

Filters

Two filters sit above the charts and apply to everything log-based:

• Time range — last 24 hours, 7 days, or 30 days.
• FreeRouter key — one key, or all keys in the workspace.

Changing either reloads the dashboard with the filter in the URL, so a filtered view is shareable and bookmarkable.

Provider spend

Only OpenRouter exposes spend via an API, so only OpenRouter provider keys show live numbers: total credits used against the key's limit, refreshed on every dashboard load. Other gateways show an "unavailable for this gateway yet" note, and a provider that can't be reached shows an "unavailable" note — the log-based charts are never affected.

Daily reports

Every member of a workspace gets a daily activity report by email at 09:00 in their own timezone, covering the previous day from midnight to midnight local time, across every key in the workspace. It is on by default and only sent on days with traffic. A quiet day sends nothing.

• Errors first — on a day with failed requests, a banner at the top gives the count and the worst offenders by status, key, gateway, and model. A full breakdown follows, with recent request IDs you can find in Logs.
• Highlights — short, rule-based insights such as an error rate well above your 7-day average, an error type you have not seen that week, a key failing a fifth of its requests, one gateway behind most failovers, a remap destination that keeps falling back, a slow day, a key that went quiet, or a model used for the first time.
• The day in numbers — requests, success rate, errors, p50 and p95 latency, failovers, and remapped requests, each compared with the day before, plus a requests-by-hour chart.
• Routing — for each key, model remap slices, percent splits, and priority failover chains. Each one shows what you set next to what actually ran, and why each failed-over attempt gave up.
• Keys, models, and gateways — volume, errors, and p95 for each.

The email links to the full report at Daily report (under More in the dashboard). It shows the same numbers with interactive charts, and you can pick any of the last 90 days.

One key's report. On API keys, open the menu next to a key's Playground button and choose Reports for the same page narrowed to that key's requests, or Logs for its individual requests. The filter stays as you move between days; Show all keys goes back to the whole workspace.

Turn the email off, or set your timezone, under Settings → Notifications. The toggle is per workspace, and your timezone applies to all of them. Until your browser reports a timezone, reports use US Eastern (America/New_York). Send me yesterday's report emails it to you straight away so you can see what arrives.

What is (and isn't) stored

Every proxied request logs routing metadata: key, workspace, gateway, model, status, latency, stage timings, attempts, the attempt path (gateways tried, header waits, failed-attempt drain), and timestamps. Response bodies are never stored, and provider secrets stay encrypted — spend lookups decrypt them in memory just long enough to ask OpenRouter. Request bodies are stored only when you switch on request-body capture in Settings (off by default, for debugging); captured requests are shown in full when you expand the row in Logs.

Retention. Log rows are kept for 90 days, then deleted — Logs, Usage, Reports and the reporting API all read from the same rows, so nothing older is available anywhere. Captured request bodies are cleared after 30 days; the row and its routing metadata stay for the remaining 60. Both windows are set by the operator (FR_LOG_RETENTION_DAYS and FR_LOG_BODY_RETENTION_DAYS, in days; 0 turns one off) and applied by a nightly job. To keep a prompt longer than 30 days, copy it out of Logs; to get rid of one sooner, switch capture off and wait for the window, or ask support.

Logs open on the last 7 days (All time is one click away) and can be narrowed to Errors (status 400 and up) or Success. Every failed row says in one line what went wrong and links to the fix — the key's routing, Providers, or these docs. Requests FreeRouter refused before calling any gateway (no routing targets, wrong API shape, IP allowlist, a revoked key) are logged too, with provider None. Totals past 10,000 show as 10,000+.

Empty states

Until your first API request lands, the dashboard shows a three-step setup flow instead of charts: add your provider keys, create a FreeRouter key (it is routed to those providers on creation), and integrate. Finished steps show a Done badge; the workspace's first logged request ever (a call to api.freerouter.com, including one FreeRouter refused) swaps the flow for the charts above for good — a quiet date range or key just shows an empty chart. Playground runs and the Test key button spend real inference but are never written to Logs, so they do not dismiss this flow.

Playground

The dashboard Playground is a prompt runner against your own FreeRouter keys. It uses the key's routing — same targets, same failover as live traffic — and returns the response, a per-attempt trace, and a curl command you can paste into a terminal.

• Key, model, prompt. Pick a live key, then pick a model from the searchable catalog — the same merged list GET /v1/models returns for that key, spanning every attached provider. Type in the search box at the top of the picker to filter. Prompts are capped at 2,000 characters; completions are capped at 512 tokens. Send runs a real inference call against the provider behind that key, so it spends against that provider's credits. If the key has MCP tools enabled, playground uses the same tool loop as live traffic.
• Endpoint. The Chat Completions / Responses toggle switches the request format the playground sends for the selected key. Responses mode skips the MCP tool loop; Chat mode is the default.
• Model pre-fill. A key that routes only to OpenRouter pre-fills openai/gpt-4o-mini; swap in openrouter/free to confirm the stack works at no cost. A key that routes only to another gateway (or to more than one) waits for the live catalog and pre-fills the first model that key actually serves, so Send does not 404 on an OpenRouter id the upstream does not offer.
• Trace. Each attempt lists the gateway, HTTP status, and latency. For a %-split key the first pick is weighted (weight 0 is failover-only, never first). If FreeRouter translated the model id for that gateway, the trace shows the upstream id.
• Response JSON. Pretty-printed, copyable, truncated for display if it is huge.
• Reproduce with curl. A ready-to-run command against https://api.freerouter.com/v1/chat/completions using a $FREEROUTER_API_KEY placeholder. The dashboard never holds a live secret (only key prefixes), so you swap in the real key yourself.
• Chat mode. The output panel has two views. Response is the raw JSON, trace, and curl described above. Chat keeps a thread with the selected key and model and shows every tool call the model made along the way as an expandable chip: server, tool, duration, the arguments it passed, and a preview of what came back. Reply in the box under the thread to keep the conversation going; the whole thread is sent each turn. The key's steering message is shown once at the top. The thread lives in your browser only; Companion Ads previews stay on the Response view.