Choose Peer-to-Peer for elastic capacity or EU for dedicated EU processing. The Peer-to-Peer tier keeps the API value global. Both S1-Region: global and S1-Region: p2p select this tier; responses use global. Peer-to-Peer first uses spare EU capacity, with EU requests taking priority. When busy, Peer-to-Peer may use on-demand GPU capacity rented through Lium (lium.io), operated by independent third-party providers in various countries, including outside the EU/EEA. This happens only for keys with “Allow worldwide processing” enabled. Without opt-in, Peer-to-Peer stays on EU capacity and may be queued or rejected when busy. Existing customers keep EU-only processing unless they opt in. Request and response content is not stored on any node. EU-tier requests always stay in the EU. A key has an allowed tier and default region. An explicit S1-Region header may override the default only when the key permits it.
PEER-TO-PEERElastic capacity
Peer-to-Peer — capacity that scales with your workload
Built to scale worldwide. Peer-to-Peer starts on spare EU capacity. When it is busy, keys you opted in can use on-demand GPU capacity rented through Lium, operated by independent third-party providers in various countries, including outside the EU/EEA.
Today
EU requests have priority. Enable “Allow worldwide processing” for each key that may leave the EU. Without opt-in, Peer-to-Peer stays on EU capacity and may be queued or rejected when busy. Existing customers keep EU-only processing unless they opt in. Request and response content is not stored on any node.
s1-fast $0.032 · s1-pro $0.038 per 1M input tokens
EU — for the strictest data-protection requirements
For teams with the highest data-protection demands or strict EU regulatory requirements. EU requests run only on contracted operators inside the EU, and inference data never leaves the EU. EU requests have priority, even if a key allows worldwide Peer-to-Peer processing.
s1-fast $0.034 · s1-pro $0.040 per 1M input tokens
Inference data stays in the EU
Contracted EU operators only — EU requests have priority
Sign-in (Google) and payments (Stripe) are handled by the sub-processors listed on our sub-processor page; they never receive your prompts.
Current routing
Peer-to-Peer first uses spare EU capacity, with EU requests taking priority. When busy, Peer-to-Peer may use on-demand GPU capacity rented through Lium (lium.io), operated by independent third-party providers in various countries, including outside the EU/EEA. This happens only for keys with “Allow worldwide processing” enabled. Without opt-in, Peer-to-Peer stays on EU capacity and may be queued or rejected when busy. Existing customers keep EU-only processing unless they opt in. Request and response content is not stored on any node. EU-tier requests always stay in the EU. Choosing S1-Region: global alone does not enable worldwide processing: the customer must opt in for that key. New content sub-processors remain subject to the 30-day notice and objection process. Do not send personal data on worldwide keys unless an adequate transfer basis applies to your use. The published DPA covers both tiers.
Retry semantics
A retry does not replay a stored answer
For 24 hours, the record may retain only a keyed request digest, request ID, status and usage receipt; it does not store the request or answer. While an attempt is running, the same key and body return 202 in_progress. After a settled or settlement-uncertain attempt, the same key returns 409 idempotency_replay_unavailable with its receipt and no second charge. If an attempt is confirmed to have produced no answer and no charge, its claim is released and the same key and body may retry. Settlement uncertainty stays held until reconciled; recovery resolves stranded claims before expiry. A same key with a different body returns 409 idempotency_conflict.
Account controls
Usage history is not inference payload retention
The dashboard retention setting controls usage-history visibility. It does not control, extend or change inference-payload retention: EU payloads are not stored by default. Financial ledger records remain auditable account records.
