Privacy Policy

1. Who we are and what this policy covers

1.1 INVERGENT S.A., Sos. Pipera 43, Bucharest, Romania, company number RO31021453 ("Surogate", "we", "us") runs llm.buzz. This policy explains what personal data we handle when you:

• visit the public website at https://llm.buzz;
• use the console at https://app.llm.buzz;
• call the model API at https://api.llm.buzz/api/v1;
• apply to sell model access through llm.buzz as an independent provider.

1.2 Surogate is the controller of account, billing and usage data. [COUNSEL: Surogate's role for the content of requests, controller or processor for business customers, and whether a data processing agreement is offered.]

1.3 Privacy contact: our Discord server, https://discord.gg/eVTq93BrQ4. Sales and general questions: sales@surogate.ai. [COUNSEL: a UK representative, if one is needed.]

2. Summary

• The website and the console count visits with PostHog. Until you accept analytics cookies, the count is anonymous and sets no cookies. If you accept, PostHog keeps a cookie, records sessions with what you type masked and, in the console, links them to your account.
• The console uses one session cookie to keep you signed in.
• Each request's content goes to the provider that serves it. Each provider declares whether it trains on prompts, how many days it keeps them and whether it is in the EU. You can require zero retention, or no training and no retention, on any request.
• By default we keep the prompts and completions of chat requests for 30 days. A request that asks for zero retention is never kept.
• We keep usage records without content (tokens, cost, timing, the calling app) for billing and reporting.
• Google Firebase handles sign-in. Stripe handles card payments.
• Statistics on the public website are aggregates that never name a customer.

3. What we collect

3.1 Account data. At your first sign-in, Firebase Authentication gives us your email address, your display name and your Firebase user ID. We record your role, when the account was created and whether it is disabled. Your password, if you use one, stays with Firebase and never reaches us. The Firebase project is shared with Surogate Ops, another Surogate product: the same sign-in works for both, and each product keeps its own accounts in its own database.

3.2 API keys. For each key we store its name, kind, spending limit, expiry, state, when it was last used, and a peppered fingerprint of the key. We do not store the key itself and cannot show it again.

3.3 Billing data. Your balance and credit history (purchases, auto top-ups, refunds and adjustments, with their fees, status and notes), your Stripe customer ID, Checkout and payment IDs, your auto top-up settings, and the brand and last four digits of a card you saved. Stripe holds the card itself.

3.4 Request content. What you send in requests and what the models return. Section 4 says what we keep and for how long.

3.5 Usage records. For each request and each attempt, without content: the request ID, your account and key, the model and API used, when it was accepted and finished, its result, which provider and model served each attempt, tokens (input, output, cached, cache writes, reasoning), cost, latency and time to first token, a SHA-256 digest of the request, a hashed form of a session ID you send, and the calling app: your User-Agent, X-Title and HTTP-Referer headers and the app we recognize from them (for example Claude Code or Codex).

3.6 IP addresses. The API reads your IP address from our proxy while it handles a request. It does not store it in usage records or prompt logs. Cloudflare and our hosting provider see IP addresses as traffic passes through them (section 7). [OWNER: access log retention at the ingress and at Cloudflare.]

3.7 Aggregated metrics. Five-minute and hourly totals per model and provider (requests, tokens, availability, latency), across all customers.

3.8 Console activity. Changes you make in the console, such as keys, limits and auto top-up. Administrator actions, such as credit adjustments, record the administrator who made them.

3.9 Website visitors. The website has no forms and no sign-in. Cloudflare, which serves it, processes your IP address and request details to deliver the pages. Product analytics (section 9.5) records the pages you view and what you do on them, such as searches and filters.

3.10 Independent provider applicants. The company's legal name, country, postal address, tax or VAT number, a contact name and email, the email the account signs in with, the terms version accepted, endpoint details and keys, listings and their check results, monthly statements, uploaded invoices and payment records. We seal endpoint keys with AES-256-GCM and show only their last four characters. We never publish legal names, addresses, contacts, tax IDs, statements or payments.

3.11 Messages to us. Emails you send us and our replies.

3.12 Product analytics. On the website and the console we record page views, clicks, searches, errors and named actions (for example creating an API key, sending a Playground request or starting a checkout), with your browser, device and the referring page. PostHog never stores your IP address. If you accept analytics cookies, it derives your approximate location (country and city) from it first, records your sessions (section 9.5) and, in the console, links the record to your account ID, email address, display name and the organization you have open. We never record the content of API keys, prompts or answers.

4. Request content and prompt logging

4.1 What a prompt log holds. For each completed Chat Completions, Responses or Anthropic Messages exchange that is logged, we store:

• the request as sent to the provider: messages, system prompts, images and files included inline, tool definitions, tool calls and results, and generation settings;
• the response, including reasoning text the provider returns in plain text, and tool calls;
• the model and provider that served it, token counts and timing;
• a preview of up to 200 characters of your last message;
• a session or conversation ID you send (X-Session-Id, session_id or metadata.conversation_id).

We never store your API key, provider credentials or other request headers in a prompt log. An exchange larger than 1 MiB is not logged. Embeddings, image generation, the Responses WebSocket and the other APIs are not logged.

4.2 When content is logged. Each account decides whether its content is logged. Prompt logging is on by default, and you turn it off or on again on the console's Prompt logs page. A change applies from your next request. Turning it off deletes nothing already logged. Whatever the setting, we never log:

• a request that sends "provider": {"zdr": true};
• a request that sends "provider": {"data_collection": "deny"};
• any request while your account's data policy is "no training and no retention" (section 5.5).

A request that is not logged is served the same way and at the same price. We can also run the service with content logging off for everyone; usage records stay on.

4.3 Who can read prompt logs. You, on the console's Prompt logs page, which shows text only and opens no links or images. The console shows an account's logged prompts to that account alone: other customers, Surogate's console administrators, independent providers and API keys cannot read them there. [OWNER: who at Surogate can reach the database, and how that access is controlled.]

4.4 Why we keep them. [OWNER: confirm the purposes, for example troubleshooting requests, investigating abuse and security incidents, and support you ask for. State whether logged prompts are used for anything else, such as product research or training models.] We do not sell your content.

4.5 How long. Logged prompts are kept for 30 days from when they were captured. The retention job then deletes them, usually within about a minute. Surogate may change this window for the whole service, from 1 to 3,650 days; a shorter window applies at once to prompts already stored. You can delete all of your logged prompts at once on the Prompt logs page, and deleting your account deletes them too (section 13.3). Deleted data can stay in database storage until it is reclaimed, and in backups until they are replaced (section 10).

4.6 Stored as readable text. Prompt logs are stored in our database in readable form. The application does not encrypt them. [OWNER: whether the hosting provider encrypts the disks.]

4.7 Short-term stores. Two stores keep request content only to make the API work. They are not prompt logs, they are not shown in the console, and they apply even when a request asks for zero retention:

• a request sent with an Idempotency-Key is kept in the memory of the server that answered it, for up to 24 hours, to answer retries;
• each Responses turn is kept for up to 24 hours so that previous_response_id can continue it. It lives in memory, in a Valkey server that does not write to disk. A Responses request that sends store: false is not kept, and cannot be continued.

5. How your requests reach model providers

5.1 What providers receive. We send each request to a provider that serves the model you named. The provider receives the content and parameters of the request, as it needs them to answer. We do not add your name, email or account ID. For some providers we add a hashed key that groups a conversation's requests for prompt caching; it does not reveal who you are. We do not forward the raw X-Session-Id you send. Fields you set yourself in the request body reach the provider as part of the request.

5.2 Two kinds of providers.

• Cloud providers: model companies and cloud platforms that we hold accounts with. All llm.buzz customers share our account with each of them.
• Independent providers: companies we approved through the llm.buzz marketplace. They see neither who sent a request nor any other customer data. [COUNSEL AND OWNER: state what limits independent providers' use of content.]

5.3 Declared data policies. Each provider has a declared policy: whether it trains on prompts, how many days it keeps them (0 to 3,650), and whether it is EU-resident. Independent providers make their own declaration and are bound to it. For cloud providers we make the declaration, based on the provider's terms and the settings of our account with it. A provider can also be "not declared". The website, the console and the API's endpoints listing show each provider's policy. The provider's own privacy policy governs what it does with the content it receives. [OWNER: whether to link each provider's policy.]

5.4 Your choices on each request.

• "provider": {"zdr": true} sends the request only to providers that declare 0 retention days.
• "provider": {"data_collection": "deny"} sends it only to providers that declare no training and 0 retention days.
• A provider that has not declared a policy never meets either demand. If no provider of the model qualifies, the API answers 404 model_not_available_under_data_policy and sends nothing.
• provider.only and provider.ignore name the providers a request may use. An EU-resident provider's tag ends in /eu.
• /api/v1/models?region=eu lists only models with an EU-resident provider.

These demands apply on the first try and on every failover.

5.5 Account and service policies.

• You can set your account's data policy to "no training and no retention" on the console's Prompt logs page. Every request of your account then goes only to providers that declare both, on the first try and on every failover, and no request is kept in prompt logs. A request can make it stricter but never looser.
• Surogate can offer an EU host name, which sends every request sent to it only to EU-resident providers, including on failover. When no EU provider can serve, the request fails; it is never sent outside the EU instead [OWNER: whether one is offered, for example an eu. host].

5.6 Routers. Some cloud providers are routers, for example OpenRouter. A request sent to such a provider goes on to a provider it selects, under its own terms. We forward your zdr and data_collection fields to OpenRouter.

5.7 llm.buzz. The provider named llm.buzz is a route we operate over inference partners we select. A request it serves goes to one of those partners, which may pass it on to the model's maker or a cloud platform, under the partner's terms. llm.buzz's declared data policy is the least protective one among those partners. We name the partners to business customers on request, under a data processing agreement. A request that must avoid them can exclude llm.buzz with "provider": {"ignore": ["llm-buzz"]}.

5.8 Prompt caches. Providers may cache the start of a prompt for a short time, from minutes to an hour, to make repeated requests cheaper. On a cloud provider all llm.buzz customers share one account, so identical prompt beginnings from different customers can share a cache entry, and response times can reveal that someone recently sent the same beginning. Requests that demand zero retention cannot ask OpenAI for 24-hour cache retention, and do not use the explicit Google context cache.

5.9 Other services that can see a request. These are not filtered by zero-retention demands:

• web search: when a request asks for web search and we offer it, the search query goes to our search provider, Exa [OWNER: whether web search is enabled on llm.buzz];
• content checks: if we turn on guardrails that call an outside classifier, the request goes to it [OWNER: none configured in deploy/k8s on origin/main].

6. How we use personal data

We do not sell personal data and do not use it for advertising. We do not send marketing email today. [OWNER: add consent and opt-out wording if that changes.] We make no decisions about you based solely on automated processing that have legal or similarly significant effects. [COUNSEL: confirm.] Emails about your account come from Firebase (address verification, password reset) and from Stripe (receipts and invoices).

7. Sub-processors and other recipients

We may also disclose data when the law requires it, to protect people or the service, or to a successor if the llm.buzz business is sold. [OWNER: whether the public sub-processor list states countries, and how customers learn of changes to it.]

8. The public website and published statistics

8.1 The website shows the public catalog: models, their makers and logos, their providers and their logos, prices and price history, limits, latency, throughput and uptime, each provider's location and declared data policy, each independent provider's declared precision, and service facts such as the purchase fee and the refund window.

8.2 Performance figures (latency, throughput and uptime) are published; usage figures are not published yet. A figure from customer traffic is an aggregate that passes floors:

• it counts at least 5 organizations (a setting from 3 to 100) in its period;
• a performance figure needs at least 30 samples;
• for usage, once published, an organization counts only with at least 1,000 tokens in that figure, and no single organization supplied more than 80% of its tokens;
• usage counts are rounded to three significant figures.

Where customer traffic is too thin, a performance figure comes from llm.buzz's own test requests instead, which carry no customer data, and the website marks it as such.

With few customers, floors limit what someone can infer about one customer but cannot rule it out. Each console account is an organization of its own, so the floors count customers.

8.3 Apps appear only under names from our fixed list of known apps. We never publish the X-Title or HTTP-Referer you send.

8.4 We never publish account, organization or key IDs, prompts or prompt logs, request headers, provider costs, customer rates, or anything about a model that is restricted or disabled.

9. Cookies and browser storage

9.1 Website. The website loads no third-party scripts. Its content security policy lets it run only its own scripts and load images only from itself and from the logos the API at https://api.llm.buzz publishes. Its analytics calls go to its own /ingest path, which forwards them to PostHog. Its cookies are the consent cookie and, if you accept analytics, PostHog's (section 9.5).

9.2 Console session cookie. When you sign in, the console sets one session cookie. It is HttpOnly (page scripts cannot read it), SameSite=Lax, limited to the /console path, marked Secure over HTTPS, and lasts 30 days or until you sign out. We store only a SHA-256 digest of its value. It is needed for the console to work.

9.3 Sign-in hint cookie. Signing in to the console also sets sgr_console=1 on llm.buzz and its subdomains for 30 days (SameSite=Lax, Secure), and signing out clears it. It holds no identity and grants nothing. The website's script reads it in your browser only to show "Open console" instead of "Sign in"; nothing else uses it.

9.4 Browser storage. Firebase's sign-in library keeps your sign-in state in your browser's storage. The console keeps your view choice in session storage, which the browser clears when you close the tab. Firebase's sign-in pages, which Google hosts, may use their own storage while you sign in.

9.5 Analytics and consent. On your first visit a banner asks whether you accept analytics cookies. Your choice is stored for one year in the llmbuzz_consent cookie on llm.buzz and its subdomains, so it holds on both the website and the console; clear the cookie to be asked again.

• Until you choose, and if you reject: PostHog counts visits without cookies or browser storage. It tells visits apart with a hash of your IP address and browser details that changes every day, so a visit cannot be linked to you or to another day. Nothing is recorded as a session.
• If you accept: PostHog stores a random ID in a cookie and in your browser's storage and records sessions: what the page shows and how you move through it, with every field you type in masked. In the console it links the record to your account (section 3.12). The console never records its request logs, prompt logs, Playground, provider endpoints or operator pages, and masks a new API key. Signing out of the console starts a new anonymous ID.

Analytics run only on llm.buzz and app.llm.buzz, never on a self-hosted gateway's console. We use no advertising cookies. [COUNSEL: confirm the cookieless count may run before consent under legitimate interests, and the banner wording.]

10. How long we keep data

11. Where data is processed

11.1 The API, its database and its Valkey store run on a Kubernetes cluster at a hosting provider in Germany.

11.2 Providers process requests where they operate. EU-resident providers declare that they process requests, and store any content they keep, in the EU or the EEA.

11.3 PostHog stores analytics in its EU Cloud in Frankfurt. Cloudflare, Google Firebase and Stripe may process data outside the EU and the EEA, including in the United States. [COUNSEL: the transfer mechanism for each, for example standard contractual clauses or the EU-US Data Privacy Framework.]

12. Security

• The API and the console are served over HTTPS.
• API keys are stored only as peppered fingerprints. Console session values are stored only as SHA-256 digests. Provider endpoint keys are sealed with AES-256-GCM under a key held only by the API servers.
• Usage records and service logs contain no request content.
• In the console, an account's prompt logs are readable by that account alone.
• Database dumps are kept on the cluster's control node with owner-only permissions.
• The console sends a strict content security policy, refuses cross-site writes, and shows every logged value as text.

No system is fully secure. If you find a vulnerability, tell us on our Discord server (section 16). If a breach affects your personal data, we will tell you and the authorities as the law requires.

13. Your rights and choices

13.1 Depending on where you live, you may have the right to access, correct, delete or export your personal data, to object to or restrict its use, to withdraw consent, and to complain to a data protection authority: in Romania the National Supervisory Authority for Personal Data Processing (ANSPDCP, www.dataprotection.ro), or the authority where you live or work. To use these rights, write to us on our Discord server (section 16). We may need to confirm your identity first. [COUNSEL: US state law disclosures, if needed.]

13.2 Choices you control yourself:

• send provider.zdr or provider.data_collection: "deny" to keep a request out of prompt logs and away from providers that keep or train on prompts;
• on the Prompt logs page, turn prompt logging off, set your account's data policy, and read and delete your logged prompts;
• send store: false on Responses requests you do not need to continue;
• revoke API keys, and sign out of the console;
• turn auto top-up off, and remove saved cards in Stripe's customer portal (Manage billing);
• delete your account on the Settings page (section 13.3).

13.3 Deleting your account. You delete your account on the console's Settings page by typing its email address. Any credit left in it is lost; a negative balance is not cleared by deleting the account. The deletion, which happens at once and whole:

• ends your console sessions and removes the account;
• revokes every key, and removes your account's names, budgets and model grants;
• turns auto top-up off and clears the saved card from our records (the card stays with your Stripe customer record until you remove it in Stripe's customer portal);
• turns prompt logging off and deletes your logged prompts, which are removed from the database within about a minute;
• clears the free text stored with your requests: the X-Title, HTTP-Referer and User-Agent values and providers' error text.

We keep, for accounting: your usage records (amounts, tokens, models, providers, key IDs, times and states), your credit history, your purchase and payment records and your Stripe customer ID. A key ID is made from the name you gave the key, so that name stays in these records. The console does not delete your sign-in record at Google Firebase or your customer record at Stripe; ask us on our Discord server (section 16) to have them deleted. Deleted data can stay in database storage and in backups until they are replaced (section 10).

14. Children

The service is not for anyone under 18. If we learn that we hold data of someone under that age, we delete it.

15. Changes to this policy

We will publish each new version with its date. For a material change we will also email account holders at least 30 days before it applies.

16. Contact

• Privacy requests and security reports: our Discord server, https://discord.gg/eVTq93BrQ4
• Sales and general questions: sales@surogate.ai
• Postal address: INVERGENT S.A., Sos. Pipera 43, Bucharest, Romania