The three fears are legitimate and they have concrete answers. Training: reputable gateways don't train on your traffic and can force no-training terms upstream — Standard Compute sets no-training and zero-data-retention as mandatory defaults on every request. Retention: ask specifically about prompt/response payloads, not 'data' — Standard Compute passes payloads through in memory and does not store or log them; account metadata (email, usage counters) is what's retained. Quiet downgrades: routing does choose models per request — that's the product, not a trick — but the honest test is whether you can pin a model when it matters and whether requests are protected against silent cross-model fallbacks (ours are). The uncomfortable truth for the whole category: a gateway adds a party to your data path, so the right posture is verifying each link — which is why we publish a 95-provider residency and retention directory instead of asking you to trust adjectives.
| Fear | What to verify | Standard Compute's answer |
|---|---|---|
| 'They train on my code' | Gateway's own training policy AND whether it enforces no-training upstream | We don't train on your prompts/outputs; no-training is a forced, non-optional flag on upstream requests |
| 'My prompts sit in logs forever' | Payload retention specifically — not account metadata | Prompt/response payloads pass through in memory and are discarded on delivery; not stored, not logged |
| 'Routing = quietly serving the cheapest model' | Can you pin? Are fallbacks cross-model? Is the served model visible? | Pin any model in the dashboard; requests are pinned against cross-model fallbacks; routing otherwise picks per request — openly, it's the product |
A gateway request has two hops: the gateway's routing layer, then an upstream inference provider. The second hop is where most privacy variance lives — providers differ enormously on retention, training defaults, and where their GPUs physically sit. We mapped that landscape across ~95 providers (residency, retention, training posture, verified from primary sources) and published it as the /providers directory; it exists precisely because 'trust the gateway' is not an argument.
For regulated work, region enforcement matters more than promises: our Regions & privacy controls restrict inference to selected regions (EU and/or US) using exact provider endpoint allowlists — requests that can't be served inside the policy fail before any content is sent, rather than silently routing elsewhere. Restricting regions can reduce model availability and consume budget faster; that trade-off is disclosed before you save the policy.
There is no zero-trust option in hosted inference — someone's GPUs see your prompts. The choice is between vendors you verify and vendors you assume. Concretely: get the payload-retention answer in writing, confirm no-training flows upstream, test that model pinning works, and treat any gateway that answers with adjectives instead of mechanisms as a no.
Standard Compute's posture: no payload storage (in-memory pass-through), mandatory no-training and zero-data-retention flags upstream, region enforcement with fail-closed behavior, model pinning with no cross-model fallbacks, and the /providers directory documenting where 95 providers actually stand on residency and retention. Full details at /data-privacy and /security — written to be checked, not skimmed.
Yes — function/tool calls are part of the standard API shape and pass through unchanged; agents like Cline that lean hard on tool calls run against gateways daily (client-side tools work; server-side stateful features are the thing to check per gateway). The practical test: run one tool-heavy task before committing a workflow.
Routing overhead is a fraction of a second per request — slightly more when the router classifies, less on pinned models. For agent workloads, model generation time dominates round-trips by an order of magnitude, so the hop rarely shows up in wall-clock time; still, measure end-to-end on your own tasks rather than trusting any vendor's number, ours included.
Plan-dependent, and this is a sizing question, not a trust question: parallel agents multiply budget consumption, and entry tiers on any flat service are sized for one agent at a time. On Standard Compute, parallel-agent work starts at the Economy tier and up; the budget and pacing behavior are visible in the dashboard, not hidden concurrency caps.
Yes — MCP servers run client-side in Claude Code and are unaffected by where the model requests go; the base-URL swap changes the inference endpoint, not your local tool integrations. Server-side features that depend on Anthropic's own infrastructure are the exception to verify.
It is exactly the config change in reverse — base URL and key back to the original provider. No data migration, no lock-in mechanics; your code and history never lived at the gateway. This reversibility is worth using: run a two-week real-work trial before moving anything permanent.
Billing runs on Stripe subscriptions, which issue standard monthly invoices suitable for expensing; business plans put the whole team on one company subscription — one invoice instead of five expense claims.