Get started
.MD
Menu

Legal

Data handling

This page says, in plain terms, what happens to the data you send Tarka. The privacy policy is the legal version; where the two differ, the privacy policy governs. Questions go to privacy@tarkahq.com.

Zero data retention by default

For the models that run on Tarka’s own fleet, prompts, uploaded media and model outputs are held in memory while the response is produced and discarded once it has been returned. They are not written to disk or to logs, and they are never used to train or fine-tune a model. Retention is a property of the model alias you call, not of your plan, balance or price, and for every alias it is off unless the alias is one of the exceptions below. The model documentation records the policy for each alias.

Two exceptions, both explicit in the alias name or in your own request:

  • The himalaya evaluation aliases. The six himalaya aliases without a -private suffix are evaluation endpoints. Their inputs and outputs are kept in a Tarka-controlled archive, reachable only by verified Tarka operators, for evaluation and debugging until Tarka deletes them, and this archive is not deleted when you delete your organization. They are not used for training. The matching -private aliases of the same models keep nothing.
  • Responses API conversation state. The store flag defaults to false. If you send store: true, the conversation state is kept for 30 days, or until you delete it, so you can retrieve it or continue from a previous_response_id. Nothing is stored unless you ask.

Capture into your own storage

Your organization can switch on inference capture. Admitted model calls are then written, asynchronously and on a best-effort basis, as JSON records with their uploaded media into an inference-history bucket in your own Tarka object storage, for the retention you choose: until deleted, or 7, 30 or 90 days. Remote media URLs are kept as references, not copied, and a storage failure never stops the inference itself, so there can be gaps; the console shows delivery health. Capture is off for every organization until an owner or admin turns it on, in the console under Object Storage or through the Control API or MCP.

The captured data is yours. It is separate from Tarka’s internal archive, Tarka reads it only in the cases the privacy policy allows, and you download or delete it with ordinary S3 tools. If the people using your application are not the ones turning capture on, you are responsible for telling them and for having a lawful basis to keep their data. Details are in the inference capture guide.

Partner-served models

Some models in the catalog are served by partner inference providers in the US or the EU rather than on Tarka’s fleet; the alias’s description in the catalog and the model documentation say which. Your request passes through Tarka’s router, which keeps the same metadata as for any other call and no content, and is forwarded to the partner, whose retention terms then apply. Tarka chooses partners whose published terms commit to not keeping request or response content beyond what is needed to serve the request, but the commitment is theirs, not Tarka’s, and a partner’s regional routing may fail over outside the region of the alias you chose.

Bring your own keys

Agents and applications on Tarka can call other providers with your own API keys. Those requests go to the provider you chose, under your agreement with them. Tarka does not see their content and cannot speak to what the provider keeps. The same applies to any connector you give an agent credentials for.

Agent hosts, storage, Git and sandboxes

These products store your data by design: the state and memory of a hosted agent, the objects in a bucket, the commits in a repository, the files a sandbox works on for the length of its run. That data is scoped to your organization and isolated from other customers, and Tarka reads it only to operate the service, to investigate abuse or a security incident, or at your request. Sandboxes are discarded when they finish. Other data stays until you delete it. If your credit runs out, hosts pause and storage becomes read-only, but nothing is deleted. When you close your account, Tarka deletes your stored data within 30 days; what is kept longer (billing records, and the himalaya evaluation archive) is set out in the privacy policy.

What Tarka keeps about every request

To bill you, keep the platform running and make it better, Tarka records metadata about each request and keeps it separately from content:

  • which organization and API key made the request, the request ID, the model and the location;
  • timestamps, latency, time to first token, and whether the request succeeded, failed or was cancelled;
  • token counts, audio duration or page counts, and the resulting cost;
  • the size of the request and response, but not their content.

Usage records, which are the billing part of this metadata, are kept for as long as tax and accounting law requires. Operational logs and metrics are kept for days, not months, carry no request or response content, and have API keys redacted before they are written.

Where processing happens

Tarka’s own models run on its fleet in Kathmandu, Nepal, and in its cells in Europe and US East. Partner-served models run in the US or the EU according to the alias you call. Tarka’s control plane and billing run in Europe. The data residency page lists each location and which countries are verified; the privacy policy covers transfers between them.

Enterprise

Dedicated deployments can set their own logging, retention and operator-access terms, including an agreed deletion schedule and customer-specific storage. See Enterprise.

Last updated: 2026-10-31.