Traffic Sampling Addendum

1. About this Addendum

This Traffic Sampling Addendum (version sampling-tos-v1, the "Addendum") supplements the Tidbit Terms of Service and Privacy Policy and governs the Traffic Sampling program.

Traffic sampling is off. In normal operation Tidbit does not capture or persist the content of your requests or responses. Your traffic is routed, optimized, and forwarded, and the content is not retained. Nothing in this Addendum takes effect unless you turn sampling on.

You may opt in if you specifically want to, through one of the paths described in "How capture is turned on" below. Aside from those paths, the only ways your request or response content reaches us are when you submit a data dump with a support report, or when you manually enable debug logging for troubleshooting. Both are deliberate acts by you. Sampling is never enabled at signup. In the event of a conflict, this Addendum controls for the sampling program only.

2. How capture is turned on

Organization-level sampling. An organization administrator may opt in from the organization settings pane, choosing the fraction of requests captured and which keys are in scope. There is no cap on the rate: it is your organization's own traffic, and an organization debugging its own client may reasonably want every request, so any rate above zero and up to one hundred percent (100%) may be selected. The administrator chooses whether sampling applies to all of the organization's keys (including keys created later) or only to specific keys selected at the time; selecting specific keys does not include keys created afterward. Requests through keys outside this scope are not sampled under this path.

Device debug capture. Separately, an individual user can enable a device debug toggle for their own device from the Tidbit desktop installer. Turning this toggle on captures all of that user's requests and responses at a 100% rate for as long as it stays on, regardless of whether that user's keys are in the scope described above, and regardless of whether the organization has opted into organization-level sampling at all. This path is enabled and disabled directly by the individual user, not by an organization administrator.

Per-request debug capture. Separately again, a caller using the Tidbit API can mark an individual request for capture by sending the x-tidbit-debug header on it. That request and its response are captured in full, under the same redaction, retention and deletion rules as the other paths, and are attributed to the API key the request was sent with. Only requests carrying the header are captured; the header is honored only when the request also carries a valid API key that resolves to your organization, so it cannot be used to mark anyone else's traffic. Consent on this path is given by whoever sends the request: if an API key is shared among several people or systems, the person or system that sets the header consents for the traffic on that request, and the others are not asked.

Support data dumps. Independently of sampling, you may choose to attach a data dump to a support report. That content reaches us because you sent it, is used to investigate the issue you reported, and is governed by the Privacy Policy rather than by the sampling program.

What a captured sample contains. Under any of these paths, a sample consists of the full request body, the optimized request body actually sent upstream, and the response body (each truncated at 256KB and redacted as described below), together with: the requested and served model identifiers, token usage counts, cost and savings figures, and the optimization features applied; and client-supplied context, where your client sends it, including the raw User-Agent header, an application identifier and version, beta-feature flags, device name and type, an optional alias, and coarse geography or location headers. Timing is not captured. Credentials, secrets, and API keys are stripped before a sample is written (see "Redaction before storage"); everything else in the request and response content is not.

3. Redaction before storage

Samples are redacted before they are stored, but the redaction is narrow. It strips credential-bearing headers (such as an Authorization header, API keys, and cookies), and it replaces token-shaped values (API keys, bearer tokens, and JWTs) and email addresses with a placeholder. It does not detect or remove other identifying information. Any name, phone number, postal address, account number, or other identifier that you or your users type into a prompt, or that appears in a response, is stored exactly as written. Redaction is fail-closed for the categories it does check: if a sample cannot be reliably redacted of credentials, tokens, or email addresses, it is discarded rather than stored. Only the redacted form of a sample is retained.

4. Retention

Redacted samples are retained for a hard maximum of 30 days from capture, after which they are automatically deleted. We may delete samples sooner. Aggregate, de-identified statistics derived from samples may be retained on an ongoing basis.

"Aggregate" and "de-identified" here follow the standard in CCPA section 1798.140(m): information that cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer or their traffic. For any such data we retain, we (i) apply technical safeguards that prohibit re-identification, (ii) maintain business processes that prohibit re-identification and prevent inadvertent release, and (iii) publicly commit that we will not attempt to re-identify the data, except solely to test that our de-identification meets this standard.

5. Use limitation

Redacted samples are used solely in aggregate to improve Tidbit's optimization quality, measure effectiveness, and build internal benchmarks. Samples are not used to train machine-learning models, are not sold or licensed, are not shared with any third party except infrastructure subprocessors acting on our behalf under the Privacy Policy, and are not published or reported on a per-customer basis. Any external reporting reflects only aggregate results across customers.

6. Storage segregation

Sampled data is stored separately from your account, billing, and credential systems, in a dedicated Google Cloud Storage bucket used only for the sampling program (never the bucket used for any other content) and accessible only to authorized operators for the limited purposes described above. The bucket is hosted on Google Cloud Platform in a United States region. The only subprocessor that stores or processes sampled data is Google Cloud Platform; samples are not sent to the upstream model provider or to any other third party.

7. Turning it off and deletion

You may turn organization-level sampling off at any time from your organization settings. Capture under that path stops within approximately one minute and your previously stored samples are deleted. In every case, whether or not you turn it off, no sample is retained beyond the 30-day hard ceiling described above, which the storage system enforces automatically as a backstop. Independently, you may at any time request deletion of your previously sampled data while keeping the program on; this deletes stored samples without turning sampling off. Both are self-service to an organization administrator. Device debug capture is stopped by turning the device debug toggle off on that device; it is not controlled by organization settings. Per-request debug capture stops as soon as your calls stop sending the x-tidbit-debug header, since each request is consented individually; deletion of samples already captured that way is requested the same way as any other.

8. Who may turn it on

Only a signed-in administrator of your organization, acting directly, may turn on organization-level sampling. Sampling cannot be turned on by a Tidbit operator acting on your behalf: an operator using an impersonated session is refused, and the refusal is enforced in the service itself, not by policy alone. Each time organization-level sampling is turned on, we record who turned it on, when, at what rate, over which keys, and the version of this Addendum then current. That record is retained as an audit record.

This requirement governs organization-level sampling only. The device debug toggle described above is enabled and disabled directly by the individual user for their own traffic, and does not require or go through organization administrator consent. Per-request debug capture is likewise not an administrator decision: it is consented by whoever sends the request, on the request, using a valid API key of your organization.

9. Versioning and changes

This Addendum is versioned, and the version current when your organization turned sampling on is recorded with that opt-in. If we make material changes to the sampling program or this Addendum, we will publish a new version and notify affected customers. You may turn sampling off at any time, including in response to such a change.

10. Related documents

This Addendum supplements our Terms of Service and Privacy Policy. Questions can be sent to nibble@usetidbit.ai.