Inference API Data Policy

Effective: 29 October 2026

1. Summary

Training: none. We never use prompts, images or completions to train or fine-tune any model, and we do not let anyone else do so.
Prompt and completion logging: none. Prompt text, system prompts, images, tool definitions, tool results, model output, reasoning text and tool-call arguments are never written to our logs or database.
Retention: per-request operational metadata (listed below) is kept for 180 days, then deleted automatically. Raw IP addresses and user agents are deleted after 30 days. Records of requests for the model list and the home page are kept by Cloudflare for three months (see Other records).
Location: inference and storage currently at Nebius in the European Union; UK capacity (Nebius, United Kingdom) only where a marketplace asks for it. Some models run on GPU servers rented through GPU cloud and marketplace providers (currently RunPod and Vast.ai) in the European Union and the United States, under standard contractual clauses; metadata is stored only in the European Union. Traffic from a marketplace that presents our service as hosted in the European Union stays in the European Union. Every location we use is listed here and in our API privacy policy.

This page applies to the Negbeta inference API at inference.negbeta.com. It sits alongside our API privacy policy and API terms.

2. What is held only temporarily

The request and the response, while the request is being processed.
A prompt cache in temporary storage on the server (today its GPU memory and main memory; in future also its local disk): the model’s internal form of recently processed prompt beginnings, so a conversation that continues can skip work already done. It is stored securely and used only for prompt caching, never for anything else. It is only reused for a request that starts with exactly the same content, is overwritten as new requests arrive, and today is cleared when the server restarts.
An image cache in server memory (at most 512 MB) holding the model’s encoding of recent images, with the same limits. Images linked by URL are downloaded to process the request and not kept.
Conversation fingerprints in the gateway’s memory: one-way hashes of the beginnings of recent conversations (not text), used to recognise a conversation that continues and to plan prompt cache capacity. Dropped 5 minutes after the conversation goes idle, and when the gateway restarts.

3. What we keep for each request (180 days)

Identifiers

Our request ID (returned to the caller in the X-Request-Id header), the request ID the caller sent, if any, and the model server’s response ID.
A one-way hash (first 16 hex characters of SHA-256) of the API key used. Keys are issued to the marketplaces that resell our API (such as OpenRouter), not to individual users. We store only a one-way hash of each API key, never the key itself.

Connecting client

We record the IP address of the connecting client, its country and user agent. For API traffic the client is the marketplace’s servers, not end users. Raw IP addresses and user agents are deleted after 30 days; other request metadata after 180 days.

The IP address of the connecting client, as passed on by Cloudflare (deleted after 30 days).
Its country, as determined by Cloudflare (a two-letter country code).
Its user agent, the first 200 characters (deleted after 30 days).
Cloudflare’s ID for the request (the CF-Ray value).
A salted one-way hash of the IP address.

Timings

When the request was received, forwarded to the model, and when the first and last output arrived and the response ended.
For streamed responses, the arrival time of each streamed chunk and the number of tokens in it (no chunk content), for the first 32,768 chunks; later chunks are only counted. The number of keep-alive messages sent while the prompt was processed.

Usage

Input, cached input, output and reasoning token counts, and the usage object exactly as the model server reports it (numbers only).
Request and response sizes in bytes, the number of images and the decoded size in bytes of each image.

Request settings

The API endpoint called, the model name, whether the response was streamed and whether usage reporting was requested, and the sampling settings: temperature, top_p, top_k, min_p, maximum tokens, presence, frequency and repetition penalties, seed, n, logprobs and top_logprobs.
The number of stop sequences (not the sequences themselves).
The response format type (for example json_schema, not the schema itself), the number of tools offered, the tool choice mode, the reasoning effort and thinking switch, and the names (not values) of any other top-level request fields.

Conversation shape

The total number of messages and the number per role (system, user, assistant, tool), the role of the last message, the number of earlier tool calls in the conversation, and the size in bytes of tool results.
A one-way hash of the set of tool names offered (not the names), so repeated use of the same toolset can be counted.

Tool-call quality

Counts of tool calls returned, and how many were valid JSON, named a declared tool and matched the declared parameters; the total size of tool-call arguments in bytes (not the arguments); flags for tool-call markup appearing in plain text, or more than one call when parallel calls were disabled.

Routing and outcome

A one-way routing hash used to send a continuing conversation back to the server that holds its prompt cache. It is computed from the session ID if one is sent, otherwise from the system prompt and first user message, and cannot be turned back into text.
Whether the request went to the server preferred for its routing hash, how many connection attempts it took, which server handled it, that server’s software version and configuration, the gateway version, and how many requests were in progress at the time.
The HTTP status, an error category, the finish reason, and flags for rate-limit refusals, maintenance drains and callers that disconnected early.
For failures, a short error message of at most 300 characters. Error messages from the model server or from our own request checks keep the error type and message with any quoted text removed; when the model server rejects a request as invalid, only the error type and code, the length of its message and a short one-way hash of it are kept, never its text. Connection failures keep only the error type and our internal server address. A failure while checking tool calls keeps only the error type.
Whether the request was ordinary traffic or a test request we sent ourselves.

4. Other records

Server metrics (GPU and host load, queue lengths, request rates) with no request content: 90 days.
Server configuration snapshots (model version and serving settings) with no request data: 400 days.
Requests for the model list (including unknown addresses that begin with its address), the home page and its icon (not API calls): these are answered at Cloudflare’s network edge and do not reach our servers. Cloudflare records each one for us: the time, path (without query string, first 200 characters), method, HTTP status, the raw IP address of the connecting client, its country, the Cloudflare location that answered, the client’s network operator (autonomous system number and name, derived from the IP address), its user agent (first 200 characters), Cloudflare’s request ID, and whether it was a test request we sent ourselves. Kept by Cloudflare (Workers Analytics Engine) for three months, then deleted automatically.
Other requests that are not API calls (requests without a valid API key, other unknown addresses, and home-page requests with a query string): the time, method, path (without query string, first 200 characters), HTTP status, a category, the IP address, country and user agent of the connecting client as above, Cloudflare’s request ID, whether an API key was sent (never the key), whether it was a test request we sent ourselves, and how many such requests just before it were not recorded because of a rate limit: 30 days. Requests without a valid API key to the API endpoints are also kept with the per-request metadata above.
If the metadata database is unavailable, metadata rows wait in local files on the same server (at most 16 GB per gateway process) and each file is deleted once its rows are in the database; rows beyond that limit are discarded.
If the gateway is run without the database (not how we run it in production), the same metadata rows are written to a local log file instead. It is rotated at 256 MB, with the three previous files kept and older ones deleted, so at most about 1 GB is kept. This log is limited by size, not by age.
Service logs on the same servers (start-up and error events with request IDs, never request content): deleted after 14 days. The metadata database’s own log of start-up and error events is limited by size, not by age.
When deletion runs: our database applies the time limits for the records it holds (180, 90, 30 and 400 days above) while it runs. If the server is stopped (for example between test periods), records that pass their limit during the stop are deleted within a day after it starts again.

Only Negbeta staff who run the service can read this data. We do not sell it or share it, except with our service providers Nebius (servers, currently in the European Union; United Kingdom on request) and Cloudflare (network edge in front of the API, request content in transit only; it also keeps the records of requests for the model list and the home page described above), or where the law requires it. Our GPU cloud and marketplace providers (currently RunPod and Vast.ai, which run some models in the European Union and the United States) see request content in memory only while a request runs, and none of this data. Our subprocessors and the terms on which we use them are set out in our Data Processing Agreement.

6. Contact

Questions about this policy: [email protected].