Privacy

What we collect

Per model call, optimAIzr stores measurements:

• the model and provider
• the timestamp and the latency
• input, output, cache and reasoning token counts
• the cost, and whether the provider reported it or we computed it
• the project and route label you assigned
• promptHash (a truncated SHA-256) and promptChars, a length
• the number of tools called, and the stop reason

promptHash is one-way and truncated. It exists for one purpose: detecting that two calls shared a prefix, which is how cache-defeating churn is found. It cannot reconstruct a prompt.

Alongside that we hold what an account needs: your email address, your organization and project names, your plan, and an audit trail of security-relevant actions such as connecting or revoking a provider credential.

What we do not collect

Prompt text, response text, system prompt text, tool arguments and file contents are not stored by default, and no analysis rule except verify needs them.

There is no advertising network on this site, no third-party analytics script, and no cross-site tracker. The fonts are self-hosted, so loading a page does not tell Google you read it.

Prompt capture, if you turn it on

Prompt analysis is opt-in per organization and defaults to off. When you enable it, prompt content goes to a separate table from your usage data, and it is:

• sampled, not complete
• redacted before storage: email addresses, API keys, bearer tokens, long digit runs and card-shaped numbers are masked in memory first
• encrypted at rest with AES-256-GCM
• expiring: every row carries its own expiry
• separately deletable, without touching your usage history

Redaction is pattern-based. Treat it as a safety net rather than a guarantee: if your prompts carry regulated data, leave capture off. You lose one feature and nothing else.

Your provider credentials

Provider API keys are encrypted with AES-256-GCM before they reach the database, using a key held only in the server environment and never stored beside the data it protects. A database dump (a backup, a replica, a support export) does not yield usable keys.

Stored next to the ciphertext are a non-reversible fingerprint, so the interface can say “this is the key you connected in March”, and the last four characters as a hint. Neither can reconstruct the key, and no API response ever returns one: the response shape is an allowlist of fields rather than a list of fields to strip.

We ask for read-only usage and cost access, at the narrowest scope each provider offers. optimAIzr never needs write access to a provider account. Disconnect at any time and the stored credential is erased.

Whether your data trains anything

No. The analysis is arithmetic and pattern-matching over usage metadata. Nothing of yours is sent to a model provider for analysis, and nothing is used to train any model, ours or anyone else’s.

There is one exception, and it only happens when you ask for it: optimaizr verify replays your own recorded traffic against your own provider using your own key, to check whether a cheaper model still clears your quality bar. That is the entire feature. It requires prompt capture to be on.

Keeping tenants apart

Three independent layers: an organization identifier on every row, an application layer where access must be proved before a query can be built, and row-level security in Postgres as a backstop. Cross-tenant requests return “not found” rather than “forbidden”, so the API cannot be used to confirm that another organization exists. There are automated tests asserting exactly this.

Logs never contain API keys, session tokens, passwords, or prompt and response content. That is enforced centrally, by field name and by value shape, rather than left to each place that writes a log line.

How long we keep it

Raw usage rows are retained for a period you control (90 days by default) and then rolled into daily aggregates. Your long-term spend chart survives; the row-level detail does not. Prompt samples expire on their own schedule, which you also set.

Deleting it, and your rights

• A provider connection: disconnect it; the credential is erased immediately.
• Prompt samples: deletable on their own, and they expire anyway.
• Your organization: deleting it cascades to projects, usage, connections, recommendations, reports and audit events all go with it.

If you are in the UK, the EEA or another jurisdiction with equivalent law, you may request access to your personal data, correction of it, erasure, a portable export, or a restriction on how it is processed, and you may object to processing or complain to your data protection authority. Write to privacy@optimaizr.com and we will answer within the statutory period.

Who else touches it

The service runs on third-party infrastructure: application hosting, a managed Postgres database, a payment processor for subscriptions, and an email provider for transactional mail such as sign-in links. They process data on our instruction to run the service, and for nothing else. We do not sell your data, and there is nobody to sell it to.

What we do not claim

optimAIzr holds no security certification. It is not SOC 2 audited, not ISO 27001 certified, and not HIPAA or PCI compliant. Nothing on this page should be read as claiming otherwise.

What is described above is what the code does, and it is checkable: the schema, the encryption module, the redaction rules and the tenant-isolation tests are all in the public repository.

Changes, and how to reach us

If this policy changes in a way that affects what we collect or how long we keep it, we will say so here and date it, and tell account holders before it takes effect. Questions, requests and complaints: privacy@optimaizr.com.

The companion page is the terms of service.