Data policy

The marketplace sits between your application and model providers. We record request metadata for billing and operations, and request and response content from non-dedicated endpoints for debugging. Request logs are kept in a private, encrypted storage bucket for up to 30 days. Dedicated endpoints and private installations are excluded from request logging, including when a dedicated endpoint falls back to a public model. An organization's request-log opt-out also excludes its requests.

Optimize separately stores the eval cases and candidate answers of a search, for your organization only, until you delete the search. Provider retention policies are separate from the marketplace's policy and are listed below.

Request data

Request content is kept in the request log, separately from billing and analytics:

Some details worth knowing:

• Model names appear in process logs (they are routing metadata). Buyer-controlled metadata strings in those logs are sanitized: control characters are stripped and length is capped. Request content is written separately as structured records in the request log.
• Error bodies never echo your input. Every error body is the gateway's own typed shape; a provider's raw error body is never relayed. When a refusal is translated across dialects or surfaced mid-stream, the gateway emits only the typed error class.
• Telemetry records byte sizes, not bodies. Telemetry keeps request_bytes and response_bytes so throughput is measurable without storing a single byte of what was said.
• Image requests follow the same request-log policy. On /v1/images/generations, prompts, generated image content and any revised_prompt can appear in request logs, subject to the size limits below. They are not written to telemetry or the billing ledger.
• Video creation requests follow the same request-log policy. The prompt and creation response can appear in request logs. The video file streams from the provider when you download it and is not kept by the marketplace.
• The playground keeps its chat history in your browser: conversations in local storage and images in IndexedDB, filed by your sign-in, the conversation and the reply. Requests you send from the playground follow the request-log policy above. Deleting a chat, or Clear all, deletes the browser's copy; it does not delete a request log already recorded.
• Playground decisions follow the same request-log policy. Their state, questions, options and answers can appear in request logs. Telemetry and the billing ledger keep metadata such as model, provider, token counts and cost.
• Authentication headers are excluded from request logs. Recognized API-key formats and the provider credentials used by the request are removed before a record is written. The gateway authenticates API keys by comparing a SHA-256 hash. See the redaction limits below.
• The provider request id is kept on house routes only. It is the reference number a provider gives one call, so a failed call can be traced with that provider. A house route runs on the marketplace's own provider account. A call through a provider credential you connect (BYOK) never keeps the id. A provider can put the API key into that header, so the gateway drops an id that contains the key it sent, or any 16 characters of the key in a row. It also drops an id longer than 256 characters.

Tests check that content stays out of process logs, telemetry and the billing ledger, and that request logging respects endpoint exclusions, opt-outs, credential redaction and size limits.

What we do store

Running an account requires a small amount of real data:

The marketplace does not store passwords. Clerk handles passwords, email verification and Google sign-in. Google sign-in requests basic identity information (OpenID, email and profile); it does not request access to Gmail, Drive or Calendar. The marketplace uses the verified email to find your existing account, including accounts originally created through an email link. Clerk processes authentication data under its privacy policy.

Authentication emails can be delivered through Resend, including Clerk-generated email links. The relay verifies the sender's signature and does not log or persist the email body or sign-in link. Resend processes delivery data under its privacy policy.

Request logging

• Which requests. Model requests to non-dedicated endpoints, including chat, messages, responses, compaction, image generation, decisions, video creation and token counting. Dedicated endpoints are excluded even when a request is refused or falls back to a public model. Private installations and organizations that have opted out are also excluded.
• What we store. The request as the gateway received it, available upstream request and response details, and the response returned to the caller (JSON or streamed content). Also the request metadata above, selected client headers such as User-Agent, and your key's first 12 characters, which the console shows too. Records have a size limit, normally 2 MiB and up to 16 MiB for a configured program; large fields may be truncated. Logging is best effort, so not every request is guaranteed to have a complete record.
• What is removed. The Authorization and x-api-key headers, cookies, and headers outside the request log's allowlist. Before a record is written, the gateway removes keys in recognized formats (ours, OpenAI, Anthropic, AWS, Google, GitHub, Stripe, Slack and private keys) and the provider credential that the request used, including a credential you connect (BYOK). Each becomes [REDACTED]. Other secrets in your prompts can be stored as you sent them.
• Where, and for how long. In an encrypted storage bucket in our AWS account. The bucket is not public. The gateway can write records, but it cannot read them. Records are scheduled for deletion after 30 days.
• Why. To investigate errors and replay requests in tests so that we can fix their cause. We do not train models on these records, and we do not share them.
• How to opt out. Contact support to stop request logging for your organization. This does not change the provider's own retention policy or delete records already retained under the 30-day policy.

Hackathons and similar programs

Requests from accounts in a hackathon or similar program are stored for up to 30 days to find and fix errors.

Program invitations retain their request-log notice. A program's logging mark has an end date, but requests to non-dedicated endpoints may continue to be logged under the general policy above after that date. Dedicated endpoints, private installations and organization opt-outs remain excluded.

Account authentication

Public signup and sign-in use Clerk in the browser at Sign up and Sign in. Complete the email-verification and authentication steps shown there. The local magic-link submission and programmatic signup routes have been removed. Existing accounts and API keys are preserved; Clerk connects a verified email to the same marketplace account.

After Clerk verifies a sign-in, the marketplace issues its own seven-day signed session cookie (HttpOnly). Marketplace Sign out revokes that cookie and the linked Clerk session. Clerk-backed sessions are rechecked during authenticated requests, using cached proof for at most 30 seconds. A revoked or expired Clerk session can no longer authorize new marketplace requests after that cache expires. Other devices stay signed in.

Beside the session cookie the browser holds a sign-in hint (tm_in, the same expiry, readable by script) that says only "signed in", and a display cache (localStorage["tm-acct"]: your email and your balance as the last page showed them). They let every page draw your account menu and credits at once. Neither opens anything, and both are cleared on sign out.

Previously issued marketplace email links and operator-issued links use stored SHA-256 token hashes; a leaked database row is not a working link. These links are single-use and expire. They do not provide a public account-creation route.

See Authentication for browser onboarding and API keys.

What providers do with your prompts

The provider serving your request has its own retention policy, separate from the marketplace's request logs. Every provider in the catalog must declare its prompt retention in its manifest before it can serve traffic:

{
  "provider": {
    "id": "anthropic",
    "privacy_policy_url": "https://www.anthropic.com/legal/privacy",
    "prompt_logging": "retained"
  }
}

prompt_logging is a closed enum — "none" or "retained" — and a manifest without it (or without a privacy policy URL) fails conformance and never goes live. The flag is surfaced where you make decisions:

• On every model page: the Data policy card links to this policy and says how many of the model's providers offer zero data retention. The providers table has a Retention column per provider; that describes the provider, not the marketplace's request log.
• In the machine-readable catalog, per provider of each model:

curl -s https://app.routerplus.com/api/models.json | python3 -c \
  'import json,sys; [print(m["id"], "—", [(p["id"], p["prompt_logging"]) for p in m["providers"]]) for m in json.load(sys.stdin)["models"]]'

Every provider in the catalog today declares "retained", per their published policies, except Fastino, Cloudflare Workers AI, Perplexity, DeepInfra (its open models) and RouterPlus. Levanto, which serves the decision model Sage, keeps no ordinary request, but keeps the full request of a failed or slow one for 30 days to debug it, so it declares "retained" too. Fastino, which serves the decision model GLiNER-2.5-Decide, declares "none". Fastino keeps an inference unless the request says store: false, and the gateway sends store: false on every request. Fastino's terms let it train on inputs unless a team has Zero Data Retention on; our Fastino team has it on. So Fastino keeps nothing and trains on nothing. Cloudflare Workers AI, which serves the decision models Clef and Clef-flash, declares "none", on Cloudflare's own statements. Of Clef, Cloudflare says: "we don't read, store, or train on your requests or responses (unless you want to use our fine-tuning product)". We do not use that product. Cloudflare's Workers AI data-usage page says that Cloudflare does not use a customer's content to train any AI model on Workers AI, or to improve any Cloudflare or third-party service, without the customer's explicit consent. It also says that Cloudflare stores the content only if the customer uses a Cloudflare storage service (R2 or KV, for example) with Workers AI. We use none. The gateway calls the Workers AI REST API directly. It never sends Cloudflare's AI Gateway header (cf-aig-gateway-id), so our requests do not go through AI Gateway, whose logs are on by default and can hold the full prompt and response. Cloudflare's replies to our calls carry none of AI Gateway's cf-aig-* headers. Perplexity, which serves the decision model Perplexity Decider v1 27B, declares "none", on Perplexity's own statements. Its API FAQ says: "We do not retain any query data sent through the API and do not train on any of your data." It also says that the API has zero day retention of user prompt data by default, never used for AI training, and that its compute is hosted on Amazon Web Services in North America. Perplexity keeps the usage metadata it bills from, such as the number of requests and tokens (its API FAQ). The gateway calls Perplexity's API directly, with our one Perplexity key. DeepInfra, which serves fifteen open chat models (DeepSeek, GLM, Kimi, MiniMax, Hy4, Gemma, MiMo and gpt-oss), declares "none", on DeepInfra's own statements. Its data-privacy page says that it does not store the data sent to its inference APIs on disk, holds it in memory only while it runs the request, and does not log request content: it records only metadata such as the request id, the cost and the sampling parameters. DeepInfra does not train on API data (its exceptions are Google's and Anthropic's models, which this listing does not carry). The gateway calls DeepInfra's OpenAI-compatible API directly, never its bulk inference API (which may keep data longer). Google's and Anthropic's models are DeepInfra's second listing, deepinfra-labs: Claude and Gemini, which DeepInfra relays to Anthropic and Google under their own data and training policies. It declares "retained", as our Anthropic listing does, and is Claude's fallback after Anthropic direct. Morph, which serves its Fast Apply models, Kimi K3 Fast and five open models, declares "retained": Morph publishes zero data retention only for self-hosted deployments, not for its hosted API, which records requests for its traces dashboard. Its inference runs in the US, and DeepSeek V4.1 Flash in Japan. Mistral AI, which serves its own models (Mistral Large, Medium, Small, Ministral and Codestral) and is GLM 5.3's last route, declares "retained": Mistral keeps API prompts and answers for 30 days to monitor abuse, unless zero data retention is switched on for the account. Bespoke Labs, which serves the decision models Bespoke Nimble v4 and v4 Max, declares "retained": Bespoke keeps API inputs, outputs and request logs for up to 30 days, to debug the service and check for abuse, and then deletes them. It also keeps the metadata it bills from (token counts, times, key id, status). Bespoke does not train on API content unless an organization opts in, and ours does not. OpenAI, which serves the decision model GPT-6 Luna Decisions (deployment openai-decisions), declares "retained": OpenAI keeps abuse-monitoring logs of /v1/decisions requests for up to 30 days. Zero Data Retention needs an eligible account and an agreement with OpenAI, and our organization does not have it. OpenAI does not train on API data by default. The gateway calls OpenAI's API directly, with our one OpenAI key.

We report the flags; we do not editorialize them.

RouterPlus

RouterPlus is our own decision-model service. It serves our models Decider 2B and Kev 4B, and this page is its data policy. Its GPUs run in the United States. The RouterPlus model service writes no request logs. It keeps a cache of its answers: each answer and its usage, for 600 s (10 minutes). The cache key is the RouterPlus API key, the model and the exact request body, byte for byte, so only an identical request gets a cached answer. A cache entry is never shared across RouterPlus keys, but the gateway sends every request with our one RouterPlus key: an identical request from any of our buyers within 600 s can get the cached answer, which repeats your option names. The cache is all it keeps, so the listing declares "none". RouterPlus does not use your states, questions or answers for training. The marketplace side is the same as for every provider: requests through non-dedicated endpoints follow the request-log policy above.

Reading your own metadata back

You can read your billing and usage metadata back with your API key:

curl -s -H "Authorization: Bearer $TM_API_KEY" https://api.routerplus.com/v1/usage
curl -s -H "Authorization: Bearer $TM_API_KEY" "https://api.routerplus.com/v1/generation?id=<request_id>"

Both endpoints read the billing ledger — balance, attempts, token counts, settled cost. Neither returns message content.

See Authentication for account and API-key access, and Errors for the error taxonomy referenced above.