Projects and data
Projects
A project is a group of inference keys with its own monthly spend limit. GET /v1/usage splits usage by project, and takes ?project_id=. Archiving a project stops its keys at once.
Spend alerts
POST /v1/alerts/settings sets which percentages of a monthly spend limit raise an alert (thresholds_percent, 50, 80 and 100 by default), an optional low_credit_usd and an optional https webhook_url. Alerts appear at GET /v1/alerts and in the console. A failed auto-reload raises one too.
Webhooks are signed. X-Signature is t=TIMESTAMP,v1=HMAC, the SHA-256 HMAC of TIMESTAMP.BODY with the secret you get when you set the URL.
Training data
POST /v1/datasets takes a model, a brief and a JSON schema, and writes three records for you to look at, at normal token prices. POST /v1/datasets/{id}/promote with {"count": 1000} writes the rest in the background, up to 10,000.
- A record that comes back invalid is billed but doesn't count.
- Credit is reserved one record at a time, so running out pauses the dataset. Auto-reload keeps it going, or promote again to resume.
- Records can repeat, so check for duplicates before training.
- Download with
GET /v1/datasets/{id}/records?format=jsonl, orcsvorjson. - Your policies and the platform rule apply to the brief and to each record.
Your data
We don't store prompts or completions. We keep request metadata for billing: time, model, token counts, GPU time and cost, plus policy decisions, which hold scores but no text. Requests and policy checks run on third-party GPU workers, where a job's input and output are kept for up to 30 minutes and then deleted.
The one exception is training data: a dataset's brief and records are stored so that you can download them, until you delete the dataset or 30 days have passed. See the privacy policy.