16 · Limits, quotas, retention and privacy

This chapter is every limit a request is held to, how long what you send and what we produce is kept, what is kept for ever, what is never kept, and what reaches our servers at all. The figures are generated from the plans the service enforces; the retention statements are the ones the service's own retention document makes, in its words.

Limits

Each key is held to these, by your plan. A key may be minted narrower, never wider:

Each key	Free	Paid	Enterprise
requests_per_minute: requests a minute	20	120	500
concurrent_solves: jobs running at once	1	4	10
concurrent_solves_forest: random forest jobs running at once	1	1	1
streams: streams open at once	32	32	32
monthly_solve_seconds: solve seconds a month	1,800	10,800	360,000
wall_budget_ceiling_seconds: the longest wall budget a job may ask for, in seconds; a larger one is reduced to it	60	900	900
max_upload_bytes: the largest file, in bytes	1,048,576	8,388,608	31,457,280
max_upload_bytes_forest: the largest random forest file, in bytes	10,485,760	31,457,280	536,870,912
artifact_retention_days: days an artefact stays downloadable	30	30	30
max_proof_bytes: the largest FRAT proof kept, in bytes	268,435,456	268,435,456	268,435,456

Each month, your organisation's meters, summed over every key and every machine:

Each month, or in one request	Free	Paid	Enterprise
plan_calls: Plans read, a month.	1,000	100,000	no limit
compute_runs: Compute steps run, a month.	100	10,000	no limit
compute_seconds: Seconds of compute, a month.	300	30,000	no limit
cache_hits: Answers served from the cache, a month.	no limit	no limit	no limit
feedback_records: Feedback records kept, a month.	1,000	100,000	no limit
mine_runs: Runs of the hosted miner, a month.	10	100	no limit
catalogue_versions: Catalogue versions registered, a month.	10	no limit	no limit
tool_checks: Tool calls checked here, a month; the runtime's own checks are counted in its usage reports.	10,000	1,000,000	no limit
graph_checks: Graph jobs, a month.	50	5,000	no limit
answer_calls: Answers a model composed from your documents, a month: one per model call.	—	20,000	no limit
catalogue_tools: Tools one catalogue may declare.	50	no limit	no limit
graph_nodes: Nodes one graph may have, once its subgraphs are inlined at each use.	40	no limit	no limit

A few limits apply to every plan:

• An upload is capped at the smaller of your key's max_upload_bytes and the mode's own cap, checked against the declared size and again against the bytes themselves.
• A wall budget above your key's wall_budget_ceiling_seconds is reduced to it, not refused, and the job's run.clamped_by says so. Random forest jobs have their own ceiling, per property.
• Streams: at most 8 on one job, and 60 new ones a minute per key (chapter 9).
• Quota is checked when a job is submitted, not while it runs: a job that started under quota finishes.

The console's Usage page shows each meter this month against its cap, by day.

Retention

What you upload and what a job produces are kept for your key's artifact_retention_days, 30 days by default, and then deleted. A hold can keep one artefact longer, and is never silent: a hold placed automatically for a defect adds at most 30 days with a fixed reason, and one placed by a person, on a written request from you or a legal one, is audited and shown on your console's Storage page until it is lifted.

What is deleted at 30 days

Every artefact and every uploaded input past its window. The bytes are gone from the database. A nightly job deletes them, after the nightly backup, so that a restore of last night's backup holds the files that existed last night.

What is not gone at 30 days

In the words of the service's retention document, which asks to be quoted rather than shortened:

An encrypted copy exists off-site until the backups taken before the deletion expire. Stored objects are rows, so they are inside every weekly base backup and in the WAL archive from the moment they were written. Each is locked for 35 days from the day it was uploaded and deleted two days after that, and a base backup is the whole database — one deleted object cannot be cut out of it. So a file deleted here on day 30 remains in the newest base taken before that day, and leaves when that base expires: up to 35 days after the deletion.

It is age ciphertext there, and the identity that decrypts it is held in escrow, off every host the service runs on. The service itself cannot read it, and no customer can. The people who operate the service can reach that escrow, and its custodian is named there; a restore is the reason they would.

Two reasons this is the right trade: the backup must not propagate deletions, or a host that had been tampered with could erase the evidence of what it did by deleting locally; and the backup's window has to outlast the artefact's, or there would be no backup on the day somebody discovers a mistake. A restore ends with one deliberate purge, so it never brings back what had already been deleted.

What is redacted at 90 days

The database's own copies of what you sent inline: a policy pasted into a request, and a certificate embedded in a job's result. Purging the files while keeping these would make the promise false in the least visible way there is.

What is kept for ever

The tombstone of each artefact: its id, role, file name, digest, size, creation time and deletion time. Also each job's verdict, its diagnostics and its usage record. That cuts both ways: you can prove a certificate with that digest existed, and we can prove when we deleted it.

A deleted artefact answers 410 artifact_purged, not 404: it existed, and its record says so.

Feedback

Feedback records are kept for your key's artefact retention, or for the number of days you set on the console's Settings page, from 1 to 3,650. A record holds only the rated words and the router's reading of them (chapter 25).

Proof files

A FRAT proof asked for with frat_proof is stored as two proof artefacts, the CNF and the FRAT log, under the same retention as any artefact, and counted against your key's max_proof_bytes per job. A proof is checked by the worker before it is stored, and is discarded, never the verdict, where it fails that check or would exceed the limit. The certificate then says why, in proof_log_omitted: self_check_failed or artefact_limit, the second with the size it would have been.

The console

A console session lasts twelve hours. Every sign-in and every change is kept in the append-only administrative history, which an owner reads.

What reaches our servers

What stays on your machine: your agents' conversations, their tool calls and results, a calculation's data, function and result, and the documents your agents answer from and their index. The licensed runtime decides plans and tool checks there; only counts leave it (chapter 38). We keep no session, no tool call's arguments and no tool result, and no turn's words except those a feedback record carries.

What is sent, and scanned on your machine first: a solve and its inputs, a catalogue's tool descriptions, a rule sheet, a guardrail-writing prompt, and a thumb's feedback record, which carries the words of the turn it rates. Each is scanned for e-mail addresses, telephone numbers, payment card numbers, IBANs, UK National Insurance numbers, Brazilian CPF numbers and the identifiers you list as your own. A match sends nothing (chapter 15).

What is never kept: a model key and a guardrail-writing prompt travel to the worker and are deleted as they are read; the job keeps the prompt's digest and length, never its text (chapter 13). Request and response bodies are not logged.

Never used for training. What you send is used to answer your request, and your feedback to improve your own organisation's vocabulary. Neither is used to train models, ours or anyone's.

The limits

• Retention is deletion from our database at the end of the window, and from the encrypted off-site backups up to 35 days after that, as quoted above. It is not instant erasure everywhere.
• A hold extends one artefact, and is shown to you while it lasts.
• The scan before sending finds the kinds of data it names, and the identifiers you list; it does not find every kind of personal data there is.