Privacy and safe use
Three separate things are described here: this website, the Ophiuchus Alpha you run on your own machine, and a relay we operate. They collect different amounts of data. The CLI collects nothing and sends no telemetry, by design. This website collects nothing today, only because its analytics are configured but not yet switched on; the section below describes what changes the day they are, so that this page does not have to be rewritten to become true. There is no hosted relay yet — the relay that exists today is the loopback one you run yourself — but the code that would count two facts about requests a relay we operate serves is shipped, and it is described in full, and in the same spirit, under "A relay we operate counts two things".
Last updated 2026-08-20, for v0.0.0.
This website
The analytics tool used is Google Analytics 4 (GA4), loaded only when a
measurement ID is configured for this deployment. If no ID is configured — which
is the case until the GA4 property is created and wired to the hosting
environment — no analytics script loads, no gtag call is made, and no request
reaches Google. You can verify by opening your browser's developer tools and
checking network requests for googletagmanager.com or google-analytics.com.
When GA4 is active, it records a small set of acquisition events:
| Event | What it means |
|---|---|
landing_view | A visitor arrived at the landing page |
try_alpha_click | A visitor clicked the "Try the Alpha" button |
docs_quickstart_click | A visitor reached the quickstart page, from any link |
pricing_view | A visitor arrived at the pricing page |
payment_click | A visitor clicked the founding-plan payment link on the pricing page; the plan parameter records which plan (founding). This only fires when a Dodo Payments hosted checkout link is configured — see the pricing page. This is a click, not a confirmed payment: a confirmed payment is a Dodo notification the founder handles manually, and is never sent to GA4. |
fake_door_click | A visitor clicked a Fake Door validation card; the feature parameter identifies which (team_context, smart_routing, or private_deployment) |
fake_door_signup | A visitor followed the early-access link inside an expanded Fake Door validation state; the feature parameter identifies which (stronger-intent signal, separate from the click) |
The hosting provider sees the ordinary request metadata any web server sees — IP address, user agent, the path requested — as part of serving and protecting the site. That is infrastructure logging, not a product analytics pipeline, and it is not joined to anything.
What is never sent to GA4: Context Capsule body or content, prompts, source code, repository or file paths, capability tokens, relay URLs, company or customer names, or database identifiers. None of those values exist anywhere in this website's code or its build output — it is a static site with no connection to the Ophiuchus CLI, no relay credentials and no server of its own, so there is nothing of that kind for it to send. The precise limit of that claim: it holds because of what this site is, so it would stop holding if the site were ever given a backend or made to read a capsule, and this page would then need rewriting rather than merely re-reading.
There is no tag manager, no advertising pixel, and no other analytics endpoint.
The Ophiuchus Alpha
Ophiuchus sends no telemetry. No usage counts, no error reports, no timings, no crash reports. Nothing phones home. This is a design decision recorded in ADR-0005, "Privacy and data minimization", not an unshipped intention.
The only outbound network call Ophiuchus makes is to the relay you point it at. If that relay is the loopback default, nothing leaves your machine.
Two things it never writes anywhere, at any verbosity:
- Capability tokens. Not in logs, errors, argv, tracebacks or CI output.
- Capsule payloads, at default verbosity. A payload can appear only behind an explicit debug flag you set yourself, on your own machine.
A relay we operate counts two things
This is the part of the page most worth reading closely, because "no telemetry" and "we count something" both need to be true at once, and they are — but only because of where the counting happens.
We do not measure your installation. A relay measures its own traffic. When a
capsule is handed to a relay, that relay serves an HTTP request; a POST is a
send and a GET is a receive, so it already knows both happened in order to do
its job at all. The relay can now keep two counts derived from those requests: a
capsule was stored, and a capsule was fetched for the first time. This is recorded
in ADR-0009, "Relay-side usage measurement". It does not supersede ADR-0005,
because nothing about it phones home: no code was added to the CLI to report
anything, and if you run your own relay — including the loopback default — this
does not exist for you. Counting is off unless the relay's operator turns it
on, so on the loopback relay you run today nothing is recorded at all; we would
turn it on for a relay we operate ourselves, and that is the only place it would
ever be on.
Each recorded row holds exactly seven things, and there is no eighth field it could hold:
- which of the two events it was;
- the capsule's locator — the opaque public id you already see in a send receipt. It is not the capability token and it grants no access to anything;
- when the relay served the request;
- the relay's own version;
- the client version, and only if it is a released version number. Anything else
is stored as the single word
unknown, deliberately, so that this field cannot be used to tell two installations apart; - whether the send asked for
--delete-after-read; - when the capsule was due to expire.
There is no installation identifier, and that is a decision rather than an omission. Any stable per-installation value is a tracking identifier however carefully it is generated, so none exists — not a random id in a config file, not a hash of your hostname, username, repository or machine address, not a pseudonymised IP. Nothing records who sent or fetched anything, and no two capsules can be attributed to the same person by us. The honest cost is that our measure of whether people come back is weaker than it would otherwise be: we can see that repeat handoffs happened, not that a particular installation performed them.
Never recorded, in any form: capsule bodies or content, prompts, source code, repository, file or branch names, shell commands, capability tokens, private relay URLs, IP addresses, hostnames, usernames, company or customer names.
The client does now identify itself honestly in its User-Agent header as
ophiuchus/<version>, where it previously sent the HTTP library's default. That
replaces one value with a more accurate one; it does not add a request, a field or
a recipient, and it is how the client-version count above is obtained.
If per-installation or client-side telemetry is ever introduced, it would need a new architecture decision to supersede ADR-0005, and this page would be amended first.
What a Context Capsule contains
A capsule is not a transcript. Dumping a whole session is the thing Ophiuchus exists to beat. A capsule carries the least-sufficient working context: the goal, current state, the repo/branch/commit the work was grounded in, evidence observed, hypotheses already rejected, constraints, open questions, and the requested next action — plus who produced it, when, and when it expires.
Process environment variables are never serialised into a capsule. The schema has no field that invites pasting an environment dump or a raw transcript, which is a deliberate way of steering the data model away from the riskiest content.
Retention and expiry
- A capsule has a TTL and then it is gone. The relay stores the bytes plus the minimum metadata a TTL needs, for no longer than that TTL.
- The relay's ceiling wins. It will not keep a capsule past its own maximum, one hour by default, even if the capsule advertises a later expiry. Believe the earlier of the two times.
--delete-after-readremoves it on the first successful fetch.- No copy is kept. The relay keeps no copy of a capsule after expiry beyond what the storage engine has not yet reclaimed, and no log of who fetched what — no IP address, no identity, nothing attributable to a person.
- Where counting is switched on, the two counts described above do outlive the capsule. They have to, or they would be gone before anyone could count them. What remains is the capsule's opaque locator and the six other low-cardinality facts listed above — and only on a relay whose operator turned counting on, which is not the loopback relay you run. The capsule itself is gone, and the locator that remains cannot retrieve it: the bytes are deleted and the token was never stored.
A capsule is a directed handoff, not durable team memory. If you want something kept, keep it somewhere built for that.
Safe use
Read this before you put real work into a capsule.
The relay operator can read your capsules. There is no end-to-end encryption
in v0.0.0. Transport confidentiality is ordinary HTTPS/TLS, assumed from the
deployment, not implemented or enforced by Ophiuchus. Do not put anything into a
capsule that you would not let the relay operator read.
A bearer token is the only access control. Anyone holding it can fetch the capsule until it expires. There are no accounts, no identities, no permissions, and no revocation beyond deleting the capsule.
The secret scan is a seatbelt, not a vault. The producer runs a best-effort,
advisory scan and refuses to emit a capsule that trips it. It will miss novel or
obfuscated secrets. A secret it does not catch is a secret you have sent. It also
errs the other way: it may refuse a capsule that quotes a 32-character hex
locator, because it cannot tell that from a real credential. --allow-secrets
exists for that case, and it still reports every finding it waved through, masked
on stderr. It never masks or strips content for you.
A received capsule is untrusted input. It came from another machine and may contain anything. Ophiuchus quotes the sender's text as the sender's claim and refuses control characters in it, but the content itself is data to verify, never instructions to obey.
Do not use the Alpha for regulated data, customer data, or production secrets. This is an experiment on non-sensitive or synthetic material. It makes no compliance claim.
What is not shipped
So that nothing here is read as more than it is:
- No end-to-end encryption.
- No self-hosting story beyond running the same open loopback relay yourself.
- No enterprise controls: no SSO, no SCIM, no RBAC, no audit log, no DLP, no retention policy, no data-processing agreement.
- No account system, and no hosted application.
None of these are in v0.0.0, and none should be assumed from anything else on
this site. See the docs for what does work.