Negbeta

Inference API Data Policy

Effective: 23 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.
  • Location: inference and storage in the United Kingdom (Nebius region uk-south2).

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

2. What exists only in memory

  • The request and the response, while the request is being processed.
  • A prompt cache in GPU memory: the model’s internal form of recently processed prompt beginnings, so a conversation that continues can skip work already done. It is only reused for a request that starts with exactly the same content, is overwritten as new requests arrive, is cleared when the server restarts, and is never written to disk.
  • 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.

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 OpenRouter, not to individual users.
  • A salted one-way hash of the connecting network address. Requests arrive from OpenRouter, so this is normally an address of OpenRouter’s, not yours. The raw address is not stored.

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. 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.
  • If the metadata database is unavailable, metadata rows wait in local files on the same server (at most 4 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.

5. Access and sharing

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, United Kingdom) and Cloudflare (encrypted tunnel, request content in transit only), or where the law requires it.

6. Contact

Questions about this policy: [email protected].