Privacy Policy

Blips inside a terminal only work if the privacy story is beyond reproach. This document is the complete inventory: every field the SDK can ever send, why it exists, how long we keep it, and everything that never leaves your machine.

Effective: June 12, 2026 · Applies to the OpenCrater package (opencrater on npm), the API at api.opencrater.to, and opencrater.to.

The one-screen summary

We never collect prompts, code, credentials, file contents, file paths, or anything you type into your terminal. Full stop. The SDK sends coarse, sanitized signals — never your work.

No account is required to use a tool that shows Blips — terminal users are anonymous.
Raw IP addresses live at most 72 hours (fraud analysis), then only a one-way hash remains.
Topic personalization runs on short keyword tokens that are aggressively redacted on your machine and re-sanitized on our servers — never raw text.
Politeness rules (frequency caps, dismiss memory, render cooldowns, audio play caps) are enforced with files on your machine that are never uploaded.
One command opts a machine out of everything: npx opencrater off. Opted-out machines send nothing — not even the install ID.
We do not sell data. We do not run third-party trackers. There is no advertising identifier shared across apps.

1. Who we are & scope

OpenCrater (“we”) operates a sponsorship network for terminal tooling: open-source CLI tools, MCP servers, and AI coding agents show small Blips, and their maintainers are paid for every impression and click. This policy covers four audiences, each with its own data footprint:

Terminal users — developers whose sessions display cards. Anonymous; the smallest footprint, documented field-by-field in section 3.
Publishers — maintainers who register packages and receive payouts. Have accounts (section 11).
Advertisers — sponsors who run campaigns. Have accounts (section 11).
Site visitors — people browsing opencrater.to. We serve no third-party analytics, no tracking pixels, and no advertising cookies; the only cookies are httpOnly session cookies set after sign-in.

2. What we never collect

The clearest way to state a privacy posture is the negative space. None of the following ever leaves your machine, under any setting, in any SDK:

Prompts you type to Claude Code, Codex, Antigravity, or any other tool — the SDK extracts at most a handful of sanitized keywords (section 4), never the text itself.
Model responses, code, diffs, or terminal output.
File contents, file names, or directory paths. The single exception is the basename of your working directory (e.g. my-project), which passes through the same redaction pipeline as everything else — and is dropped entirely if it resembles a username or home directory.
Credentials of any kind. The tokenizer explicitly destroys anything shaped like an API key, bearer token, JWT, password assignment, email address, URL with credentials, or hex/base64 secret before tokens are even considered for sending.
Keystrokes, clipboard, screen contents, or the contents of other windows.
Your contact details — terminal users are never asked for an email, name, or account.
Precise location. Geo resolution stops at country (and US state where resolvable) and happens server-side from the connecting IP.
Cross-app identifiers. The install ID (below) is OpenCrater-only, random, local, and resettable; it is not derived from your hardware and is not shared with anyone.

3. Terminal users: every field, explained

When a hook fires and a card may render, the SDK makes one HTTPS request to api.opencrater.to. This is the complete list of fields that request can carry — there are no others.

data	what it is	why we collect it	kept for
publisherKey	The package's serve key (an opaque token identifying the tool showing the card, not you).	Identifies which package displayed the card so its maintainer gets paid.	Account data — kept while the publisher account exists.
packageName	The registered package's name (e.g. "agenticmail").	Attribution and reporting for the maintainer.	Account data.
placement	The hook event name that fired (e.g. SessionStart, Stop, PreToolUse).	Placement targeting and per-placement analytics.	Aggregated into daily rollups; raw impressions per the retention schedule (section 8).
host	Which CLI is running (claude_code, codex, antigravity, generic).	Host-specific rendering rules and analytics.	Same as placement.
installId	A random UUID minted on your machine, stored in ~/.config/opencrater/state.json. Not derived from hardware; contains nothing personal.	Machine-level frequency capping, fraud detection (e.g. one machine clicking everything), and the local interest profile (section 6).	Until you delete or reset it; profile entries decay with a 7-day half-life regardless.
topics	Up to 12 short keyword tokens (e.g. "postgresql", "kubernetes") after on-device redaction. See section 4 for the full pipeline.	Matching relevant Blips to what kind of work is happening — never to identify you.	On impressions per section 8; in the decaying install profile with a 7-day half-life.
os / termProgram	Coarse platform strings: the OS family (darwin / linux / win32) and the terminal program name (e.g. iTerm.app, vscode).	Render-capability decisions (which terminals draw images) and environment analytics.	Same as placement.
sdkVersion	The SDK's own version string.	Debugging and staged rollouts.	Same as placement.
IP address (transport)	Not a request field — the connecting IP, visible to any server you contact.	Resolved to country / US state for rate cards and geo policy, and used in fraud analysis.	Raw IP at most 72 hours, then only a salted one-way hash (HMAC) remains for fraud correlation.

What comes back, and what gets recorded

The response is the card content plus display rules. Server-side, the serve creates an impression record (package, campaign, placement, country, hashed IP, install ID, topics, timestamps). If you click the card's button, a single-use signed token redeems into a click record with the same coarse fields plus time-since-render (a fraud signal). If you press ✕, the impression is marked dismissed — dismissal rates are shown to the advertiser as feedback and to our ranking as a negative signal.

4. Session topics — the full pipeline

Topics are the most sensitive-adjacent thing the SDK touches, so they get the most machinery. The goal is to know a session is “about Postgres” without ever seeing a prompt. The pipeline, in order:

Source material — only two inputs: keywords from the hook payload's prompt metadata, and the basename of the current working directory. Never file contents, never the full prompt as a unit.
On-device redaction — before tokenizing, the SDK destroys anything matching secret shapes (API keys, JWTs, bearer tokens, hex/base64 blobs, email addresses, URLs) and locator shapes (absolute paths, home directories, usernames). A token like sk-proj-… or /Users/jane/… never survives this step.
Tokenization — survivors are lowercased, split, stop-worded, and canonicalized against a curated synonym map (“k8s” → “kubernetes”). Single letters, numbers, and non-technical words are dropped.
The cap — at most 12 tokens accompany a request, cached for at most 6 hours on your machine before re-derivation.
Server-side distrust — the API re-runs the entire redaction + tokenization pipeline on whatever arrives. The SDK is open source, but the server never assumes the client behaved: garbage in, empty out.
Decay — tokens fold into a per-install interest profile whose weights halve every 7 days without reinforcement. What you worked on last month effectively vanishes from the profile.

You can see exactly what would be sent: run any hook with OPENCRATER_DEBUG=1 and the SDK prints its sanitized topic list to stderr before any request.

5. Files that stay on your machine

Several behaviors are enforced entirely with local files under ~/.config/opencrater/. These are never uploaded — listing them here so nothing about the SDK is a mystery:

data	what it is	why we collect it	kept for
state.json	Install ID, frequency-cap timestamps, cached remote config, cached placement selections, session topic cache.	Core SDK state.	Local only. Delete it to reset everything, including the install ID.
blocked-ads.json	Campaigns you ✕-dismissed, each with an expiry 10 minutes out.	A dismissed Blips does not re-render on your machine for 10 minutes.	Local only; entries self-expire.
reported-ads.json	Campaigns you ⚑-reported, with the report timestamp.	A reported Blips never renders on your machine again. The list itself is never uploaded — the report you submit carries only the impression ID, reason, and optional note.	Local only; permanent until you delete the file.
recent-renders.json	Campaigns that just rendered, each with an expiry 5 minutes out.	The same Blips never repeats on your machine within 5 minutes.	Local only; entries self-expire.
audio-plays.json	Timestamps of the last audio playbacks.	Blips audio plays at most twice per 10 minutes, machine-wide, across all SDKs.	Local only; pruned on every read.
last-ad.json	The last rendered card's payload.	Lets the SDK recognize an already-shown card so it never re-counts the impression.	Local only; overwritten each render.
runtime/	A local copy of the SDK that hooks prefer over npx.	Eliminates cold-start races; self-updates at most once a day.	Local only.

6. How data is used

Serving & relevance — topics, the decaying install profile, and the package's own type/categories pick which card to show. Relevance is computed per request and never builds a cross-site profile.
Payment — impressions and signed click tokens are the billing ground truth: advertisers pay per confirmed click plus a small per-impression fee, and publishers earn their share of both.
Fraud prevention — click velocity, time-to-click, datacenter-IP signals, and hashed-IP correlation protect advertisers from fake clicks and the network from abuse. Suspicious clicks are held, human-reviewed, and never billed if rejected.
Rate cards & geo policy — country (and US state) determine pricing and where regulation requires excluding certain Blips categories.
Product analytics — aggregate counts (impressions, clicks, dismissals per campaign/package/day). No individual-level analytics product is built or bought.

We do not use any of this data to train machine-learning models on your content, and there is no “lookalike audience” or identity-graph product of any kind.

8. Retention schedule

data	what it is	why we collect it	kept for
Raw IP addresses	Connection IPs.	Fraud window.	≤ 72 hours, then deleted. Only the salted hash remains.
Impressions & clicks	Per-event records (coarse fields only).	Billing ground truth, fraud review, advertiser reporting.	13 months, then reduced to daily aggregates.
Daily aggregates	Counts per day/package/campaign/country.	Long-term reporting.	Indefinite (contains no per-person data).
Install interest profile	Topic → weight map per install ID.	Relevance.	Weights halve every 7 days; entries near zero are dropped. Reset any time by deleting state.json.
Account data	Publisher/advertiser identity, payout details, audit log.	Operating accounts; financial-records obligations.	Life of the account + the period financial law requires for money-touching records.

9. Security measures

All transport is HTTPS. The SDK refuses non-https media and target URLs.
Publisher serve keys are stored as argon2 hashes — we cannot read them back, only rotate them.
Dashboard sessions use httpOnly, SameSite cookies; OAuth sign-in only (GitHub, Google, GitLab) — we never see or store passwords.
Click URLs are single-use, HMAC-signed tokens with 24-hour expiry — clicks cannot be replayed or forged.
Money movement is double-entry ledgered; every transaction must sum to zero and is audited nightly.
Admin actions that touch money or review state are written to an append-only audit log.
The ✕ dismiss button and the audio play/pause control talk to a loopback server on 127.0.0.1 — those clicks never cross the network.

10. Your controls & opt-out

data	what it is	why we collect it	kept for
npx opencrater off	Machine-wide kill switch.	Stops all rendering and all requests — not even the install ID is sent.	Until you run `npx opencrater on`.
OPENCRATER_DISABLE=1	Environment-variable equivalent of `off`.	For CI, scripts, or shells where you want zero activity.	While set.
OPENCRATER_MUTE=1	Audio-only opt-out.	Cards render, sound never plays.	While set.
npx opencrater x	Dismiss the current card from anywhere.	Instant, offline-safe dismissal; starts the 10-minute block for that Blips.	Per card.
Delete ~/.config/opencrater/	Full local reset.	New install ID, empty profile, cleared caps and caches.	Immediate.

11. Publishers & advertisers

Dashboard accounts store the email, display name, and avatar from your OAuth provider; the packages or campaigns you create; payout or deposit details you provide; and an audit trail of money-touching actions (required for financial integrity). Advertiser creatives — including text, images, and audio tracks — are reviewed by humans before serving and stored in our media bucket.

Account deletion: email privacy@opencrater.to. We delete account data except records financial law requires us to keep (payouts, deposits, and their audit trail), which are retained for the legally mandated period and then deleted.

12. Payments & public blockchains

Payouts and deposits use USDC on public blockchains (Base, Ethereum). A blockchain is a public, permanent ledger: the payout address you provide, the amounts, and the transaction hashes are visible to anyone, forever, by design — we cannot delete or amend on-chain records. Choose a payout address with that in mind. We store the address you give us and the transaction hashes as part of the financial audit trail.

13. Your legal rights (GDPR / CCPA)

Depending on where you live, you may have the right to access, correct, export, restrict, object to the processing of, or delete your personal data, and the right to complain to a supervisory authority. For California residents: we do not “sell” or “share” personal information as the CCPA/CPRA defines those terms, and we honor deletion and access requests.

A practical note for terminal users: we usually cannot identify which anonymous records are yours — that is deliberate. The strongest right you have is also the most direct one: npx opencrater off and deleting ~/.config/opencrater/ ends and resets everything attributable to your machine. For account holders, email privacy@opencrater.to and we will act on requests within 30 days.

14. Children

OpenCrater is built for professional developer tooling and is not directed at children under 16. We do not knowingly collect personal information from children; if you believe a child has created an account, contact us and we will delete it.

15. International transfers

Our infrastructure runs in the United States. If you use OpenCrater from outside the US, the fields described in this policy are processed there. Where transfer mechanisms are legally required, we rely on our providers' standard contractual clauses.

16. Changes to this policy

When this policy changes, the effective date at the top changes with it, and the full history stays available in the website's public repository. Material reductions in protection will be announced to account holders by email and in the dashboard before they take effect. The SDK's data behavior is versioned with the SDK itself — a given SDK version's behavior never changes after release.

17. Contact

Privacy questions, access or deletion requests, or anything this document leaves unclear: privacy@opencrater.to. For the rules about what may be advertised and how the marketplace works, see the network policy.