Privacy policy

This policy covers how we handle your personal data when you use the agiplan.dev website, console and API. The operating entity is the data controller for the purposes of this policy.

It does not cover how upstream model providers handle data within their own services. Your requests ultimately reach one of those providers; see section 6 and that provider's own policy.

Account data: email address, an irreversible digest of your credentials, account creation time, your stated location. No third-party account identifiers — third-party sign-in is not built, so we hold none of that data.

Transaction data: orders, payment channel receipts, invoice details and tax number (only when you request an invoice), balance ledger entries. Refunds additionally involve identity verification data.

Usage metadata: call time, target capability group and model identifier, input and output token counts, the resulting CU, latency, whether a failover occurred, HTTP status code, trace ID.

Technical logs: IP address, user agent, API key identifier (never the key itself). Used for abuse prevention and troubleshooting.

Request and response bodies are never written to persistent storage. The prompts, context and attachments you send to a model, and what the model sends back, do not enter our logs, databases or object storage.

One exception, stated here rather than buried elsewhere. `/v1/responses` offers `previous_response_id` so you don't have to resend the whole context each turn; when you use it we have to keep that conversation's messages server-side to continue it. That content lives in our database for at most 5 hours and is then deleted by a scheduled job. Not using the parameter produces no such storage, and neither do `/v1/chat/completions` or `/v1/messages`. We hold this state ourselves rather than at an upstream provider so that failover stays invisible to you — those 5 hours are the price, so we write them down.

This is not "retained briefly" or "retained encrypted". It is *not written*. Nothing in the usage metadata listed above contains the content itself.

We use no cookies or equivalent technology for cross-site tracking, and integrate no third-party advertising or behavioural analytics SDK. The console sets only the session cookie required to keep you signed in.

The gateway streams request and response bodies through: data passes through memory buffers to the upstream provider and back to you, and at no point does any code hand it to the storage layer. Token counts for metering come from the upstream usage fields or a local tokenizer, neither of which requires keeping the text.

This carries a cost we accept: when something goes wrong, we cannot look at what you sent. When you report a problem we see only metadata against a trace ID. We think the trade is worth it — the difference between a system that *could* retrieve your content if it had to and one that *cannot* is a difference in kind, not degree.

If you want help diagnosing a specific call, you will need to supply the content yourself. We will not, and cannot, recover it from history.

To run the service: routing requests, metering quota, producing invoices, keeping you signed in.

To keep it safe: identifying anomalous call patterns, preventing key abuse and quota circumvention. Every such judgement rests on metadata (see section 8).

To meet legal obligations: tax, accounting and record-keeping requirements.

To notify you: quota warnings, incident notices, changes to terms. Marketing email requires separate consent and can be turned off at any time.

We do not use any of your data to train or fine-tune models, and we do not sell, rent or otherwise supply it to data brokers. This is also a contractual obligation under our Promises.

Upstream model providers. Your request body must reach the provider behind the model you selected, or no inference is possible. We transmit over API channels and enable the provider's zero-retention or no-training options wherever they exist. The console shows which provider currently serves each model.

Payment channels. Order amount and order number only. We never touch your card number or payment credentials.

Infrastructure providers. Cloud compute and managed database. They act as processors under contract and may not access business data for their own purposes.

Courts and regulators, on receipt of a legally effective demand. We check the demand's validity and scope, disclose only the narrowest data actually required, and notify you unless prohibited by law. We publish counts of such demands in a transparency report.

That is the complete list. There is no fourth category.

The service is offered worldwide and some upstream providers sit outside mainland China. When you select a model served from abroad, your request content is transmitted to that provider's jurisdiction.

Users in mainland China may use only models marked as available there (see section 4 of the Terms); inference for those models is performed within the mainland.

Account and transaction data are stored in the database of the service region. Where a transfer crosses borders we complete the assessment and notification duties applicable law requires.

Request and response bodies: not retained. The only exception is Responses session state when you use `previous_response_id`, see the next line.

Responses session state: created only when you use `previous_response_id`, kept for at most 5 hours, then deleted automatically.

Technical logs: deleted automatically after 30 days.

Usage metadata: kept while the account exists so you can query and reconcile it. On closure, handled per section 10.

Transaction and ledger records: retained 10 years from the accounting date, as financial and tax law requires.

Account data: kept while the account exists, deleted within 30 days of closure.

Access and export: the console exports your full usage detail and invoices as CSV and JSON at any time. No request, no waiting.

Correction: account details are editable in the console.

Deletion and closure: see the next section.

Withdrawing consent: you can switch off marketing notices, disable pay-as-you-go and revoke API keys at any time.

Complaints: if you think we have handled your data improperly, write to privacy@agiplan.dev. We respond within 15 working days. You are also entitled to complain to your supervisory authority.

Status first: self-service account closure is not built yet. What follows is the rule closure will follow, not a button you can find in the console today. Until it exists, email support@agiplan.dev to request deletion and we apply the same rules by hand; this sentence goes away once it ships.

Erased outright: email address, credentials, stated location, invoice and identity verification details, every API key, technical logs. Within 30 days, with written confirmation once done.

Not erased, but detached from you: transaction records, balance ledger, usage metering records.

Why. These three are append-only in our database — they cannot be modified or deleted. That is not a failure to implement deletion; it is the precondition for a ledger anyone can trust. A ledger that can be edited proves nothing in a billing dispute, and it would let us quietly paper over our own metering errors. The same rule binds us as binds you.

What detaching actually means. The user identifier in those records is replaced with an irreversible anonymous identifier and direct identifiers such as the email are cleared. Afterwards nothing in those records points back to you, and we ourselves cannot re-associate them.

We could have written "on closure we delete all of your data" here, as most policies in this category do. It would not match our implementation. We would rather state this clearly than make a promise we cannot keep.

"Unlinking" requires changing append-only ledger tables, which is a change that has to be designed carefully — we will not loosen the rules on those three tables to ship faster.

TLS end to end. The database sits on a private network with no public exposure.

API keys are stored as SHA-256 digests; the plaintext is shown once at creation and cannot be recovered afterwards, by us included. Keys can be rotated, and the old key stays valid for a 24-hour grace period so a rotation doesn't cut you off mid-deploy.

Low-entropy secrets such as sign-in credentials are stored with salted argon2id. Using different algorithms for the two is deliberate: high-entropy keys must be verifiable by constant-time lookup, low-entropy secrets must resist brute force.

Internal access follows least privilege, and any operation touching user data is written to an immutable audit log.

If an incident could affect your personal data we notify affected users within 72 hours of confirming it, describing what happened, the likely impact, what we have done and what you can do.

For incidents affecting more than 1% of users we publish a signed post-mortem within 30 days, with a timeline and remediation items.

We will not delay notification on the grounds that "we have no evidence the data was misused".

The service is not directed at children under 14. If we learn we have collected a child's personal data we delete it immediately.

Users aged 14 to 18 should use the service with the consent of a parent or guardian.

Changes are marked with the update date at the top of the page.

Material changes that broaden collection, add a category of recipient or extend retention take effect 30 calendar days after we notify you by email, and until then you may close your account and receive a pro-rata refund.

We keep every historical version of this policy publicly available.