Models, limits & logs

Reference for everything around the core Chat Completions call: listing models, rate limits and quotas, fallback chains, caching, and how request logging and content capture work.

Models endpoint

GET https://api.temprhq.io/v1/models
Authorization: Bearer tvk_...

Returns the standard OpenAI list shape, filtered to the intersection of your account's configured provider keys and this key's model allowlist:

{
  "object": "list",
  "data": [
    { "id": "openai/gpt-4o", "object": "model", "owned_by": "openai" },
    { "id": "anthropic/claude-opus-4", "object": "model", "owned_by": "anthropic" }
  ]
}

Rate limits

Two independent ceilings apply to every request, and the stricter one wins:

• Key-level RPM/TPM — set per virtual key (see virtual key scoping).
• Plan-level RPM — fixed by your subscription tier (10/60/240 req/min on Free/Pro/Scale).

A rate-limited request returns HTTP 429 — see Errors.

Monthly quota & overage

Each plan includes a monthly request allotment (Free 10,000 / Pro 250,000 / Scale 2,000,000). What happens past it depends on your plan:

Every response includes an x-tempr-quota header once you're within range of your limit, carrying used, limit, and resets so you can surface a warning before your app hits a wall.

Fallback chains

Define an ordered list of provider/model candidates for a model alias on a virtual key. If the primary candidate returns a fallback-worthy error (repeated 429/5xx), Tempr automatically retries the next candidate in the chain — transparently, including mid-stream for streaming requests — before the error ever reaches your client.

# Fallback chain DSL (configured per key in the Portal)
fast: openai/gpt-4o-mini, anthropic/claude-haiku, z-ai/glm-4.6

Call the alias (fast above) as the model value; Tempr resolves it against the chain instead of a single fixed model.

Response caching

Opt a single request into exact-match caching with the x-tempr-cache-ttl header (see Chat Completions). Caching is scoped per account (or per organization for org-owned keys) — a hit on one key can be served from another key's cache write under the same account, but never across accounts.

Request logs

Every Gateway call is logged with: timestamp, virtual key, model, provider, HTTP status, latency (time-to-first-byte and total), token counts, cost, and finish reason — metadata is always captured. Prompt and response content is captured only when content capture is enabled. Logs are searchable and filterable in the Portal by key, model, provider, status, latency range, date, and any x-tempr-metadata keys you sent.

Analytics

Requests, tokens, cost, latency (p50/p95), and error rate, broken down by key, model, and day — reading from the same logged data, rolled up for the Portal's analytics view.

Content capture & privacy

Content capture is on by default so real request/response detail is available for debugging: 7-day retention on Free, longer on paid plans, truncated at 256 KB per request. It's a per-account toggle — switch to metadata-only mode at any time and nothing but metadata is stored going forward. This is separate from the Chat product, which never persists code content at all.