Where your code actually goes

The honest version. Most privacy pages are written to make you forget the question. This one answers it, and then lets you watch it happen.


Your code reaches my gateway. I am not going to pretend otherwise.

Every AI coding agent sends your code somewhere, and mine is no different. When you use Tīrtha, your request reaches a server I run. Anyone selling you a hosted coding agent that keeps your code entirely on your own machine is either self-hosted only, or not telling the truth.

What matters is what happens to it there. And that is where the real design is.

I cache verified answers, not your codebase

The thing that gets reused is a proven solution, filed under the problem it solves rather than under who asked. But be clear about what "filed under the problem" means: the prompt text is stored with it, because the prompt is the key the entry is found under. If your prompt contains your code, your file paths or your proprietary logic, that text is in the store. Send tirtha.no_cache with a request to skip the cache for that request.

The store is shared by default. Private, isolated scopes exist and are available by arrangement, and an isolated tenant does not read the shared scope unless it is configured to, but the default is shared and you should assume it until we tell you otherwise in writing.

Corrected August 6, 2026. This page previously said there was no per-user record of your code in a shared cache "because that is not what I cache." That was wrong. We went and read the running system: every cached entry carries the prompt that produced it.

Isolation is enforced, not promised. Anything specific to you lives behind a scope wall. Cache keys are content hashes computed on my server, never built from a URL you could craft. Every read is checked against who is asking. The classic shared-cache failures, where a crafted URL or a traffic spike serves one customer's data to another, are closed by construction.

World

Shared, lower cost

Draw from and contribute verified generic answers. The whole gateway gets faster and costs less the more it is used.

Private

Walled off

Your own scope. You neither contribute to nor pull from the shared layer. Your work stays yours.

Black Box

Cannot reach in

A dedicated single-tenant stack, own key, air-gapped. Not "I will not look," but "I cannot." For regulated work.

You choose. Contribute and save, wall it off, or a stack I structurally cannot reach into.


Do not trust me. Watch it.

Everyone else asks you to trust a policy page. Paste a real coding request below and see, right now, what stays private and what could ever be shared. Nothing is sent anywhere. It runs in your browser.

Corrected August 6, 2026. This paragraph previously said that only a verified generic solution can be shared and that your prompt, code, file paths and API keys never are. That was wrong, and we went and read the database rather than the intention. A cached entry is keyed BY the prompt, so the prompt text is stored with it, and the shared scope is the default. What verification gates is whether an answer is cached at all, not whether your text is. The detector above runs in your browser and illustrates what a sensitive pattern looks like; it does not change what is stored. If a prompt carries proprietary code or secrets, send tirtha.no_cache for that request, or use a private scope.


The limits, honestly

I will not tell you your code can never be inferred, or that this is mathematically private. That would be a metaphysical promise, not an engineering one. What I can tell you is the enforced boundary: verified answers are shared, your prompts and code are not, and your data is walled off per tenant. That is a boundary you can hold me to, not a feeling I am asking you to have.