Privacy
What data TokenJam handles, organised by where it lives: the open-source CLI on your machine, the hosted Cloud service, and this website. Last updated 2026-09-29.
The short version
The open-source tj CLI stores everything in a database on your own disk and sends
nothing to us. TokenJam Cloud stores the telemetry your organization sends it, with prompt and
completion text stripped on arrival, for 30 days by default. If an admin connects GitHub,
Cloud also stores commit and pull-request metadata from the chosen repositories, never file
contents or diffs. This website runs Google
Analytics and loads a few third-party assets. We do not sell personal data, we do not run
advertising, and we do not use your data to train models.
1. The open-source CLI
tj reads your agent telemetry into a DuckDB file at
~/.tj/telemetry.duckdb and keeps it there, next to its config file and logs in
the same ~/.tj directory. The local dashboard binds to
http://127.0.0.1:7391, which is reachable only from your machine.
What it stores
For each model call and tool call: token counts, model and provider names, computed cost,
timestamps, tool names, session identifiers, and the file paths and search queries that tool
calls used. Prompt text is stored too, because three of the analyzers need it. Four toggles in
the [capture] section of tj.toml control the content that gets kept:
prompts(on by default): the prompt sent to the model.tool_inputs(on by default): tool-call arguments, such as the paths a Read or Grep call touched.completions(off by default): the model's response text.tool_outputs(off by default): what the tool returned.
A toggle that is off strips that content before anything is written to the database, on every
ingest path. Turning one off later does not delete what was already stored;
tj reset deletes the whole local history and config.
What it sends
Nothing, on its own. The package has no usage reporting and no update check that contacts us.
Data leaves your machine only through actions you take: exporting to an OTLP endpoint you
name, alert channels you set up (webhook, Discord, Telegram, ntfy), backfilling from a
tracing provider you point it at, tj summarize --via api, which calls Anthropic
with your own API key, or tj upgrade, which runs pip or pipx against PyPI. If you
send telemetry to TokenJam Cloud, the next section applies.
2. TokenJam Cloud
Cloud is the hosted service at cloud.tokenjam.dev. Anyone can create an
organization there. Everything below is scoped to an organization:
each row carries the organization it belongs to, and members of one organization cannot read
another's data.
Account data
Sign-in runs through Clerk. Clerk holds your email address, name, sign-in method and session; we store the Clerk user id, the organization id, and your role (member or admin). When an organization is created we log the email domain of the person who created it, to limit abuse. If you send us feedback from inside the app, the message and the optional reply-to email you type are emailed to us through Resend.
Telemetry your organization sends
Cloud receives telemetry over HTTPS at its ingest endpoint, authorized by your organization's
ingest key, from whichever exporter you run: the tj package, the TokenJam SDKs,
or a standard OTLP exporter. For each span it stores: span, trace, session and conversation
identifiers; span name, kind and status; start and end times; provider and model names; tool
names; input, output and cache token counts; computed cost; billing account and plan tier;
agent and sub-agent identifiers; and the remaining span attributes and event names after the
content strip described next.
Which attributes appear is decided by the exporter you run. With the tj package
those include the file paths that tool calls touched. Telemetry carries no developer identity
of its own: spans are keyed to agents and services, not to people, unless your exporter puts
a person's identifier in a span attribute. The GitHub source described below is the one place
Cloud stores identifiers of people.
What is stripped on arrival
Content capture is off for every organization by default. With it off, Cloud removes prompt
text, completion text, tool inputs, tool outputs and request sampling parameters from each
span before it is written, using the same strip function the open-source package uses. It
also drops any attribute whose name ends in content, prompt,
completion, text, message or body, and the
input.value / output.value keys some frameworks use, so vendor
instrumentation we did not anticipate is covered. Event attributes are dropped wholesale;
event names and times are kept. A hash of each tool call's arguments is kept so the retry-loop
analyzer can work without the arguments themselves.
An organization can ask us to turn content capture on. With it on, prompts and tool inputs are stored; completions and tool outputs are still dropped. There is no self-serve switch for this today.
GitHub (optional source)
An organization admin can install the TokenJam Ledger GitHub App from the Connect screen in Cloud. Nothing in this section applies until an admin does that. The App is installed on a GitHub organization or user account, on the repositories the installer picks, and the installation is bound to exactly one TokenJam organization. The admin's Clerk user id and the GitHub account name the App was installed on are recorded with the installation.
The App asks for four read-only permissions and nothing else: repository Contents: read, Metadata: read and Pull requests: read, and organization Members: read. It does not request write permission of any kind and never acts as a user. Cloud only ever issues read requests to GitHub. The Members permission is used for one thing: a GitHub team whose name matches a department you already created in Cloud has its members placed in that department. Teams with no matching department are left alone.
What is stored
For each chosen repository: its GitHub id, full name, URL, default branch and whether it is
private. For each commit on the default branch, going back 360 days from the install
and forward from then on: the commit SHA, the author's git email (lowercased) and GitHub
login, authored and committed timestamps, the pull-request number parsed from the commit
subject, the commit's trailers (such as Co-Authored-By) as a key-to-value map,
the AI-tool signals derived from those trailers, and added and removed line counts when
GitHub's response includes them. For each pull request: number, title, state, draft flag,
opened, closed and merged timestamps, merge commit SHA, head and base branch names, the
author's GitHub login, label names, the issue numbers parsed from the title, line counts
when supplied, and the AI signals derived from the labels and author. Only closed pull
requests are backfilled; open ones arrive through GitHub's events once the App is installed.
What is never stored
File contents, diffs, commit message bodies and pull-request bodies. Commit messages are parsed in memory for their trailers and issue references and then discarded; the pull-request body is never fetched. The Contents permission is requested because GitHub requires it to list a repository's commits; Cloud uses it for that listing and does not read files.
Developer identity
Each commit author and pull-request author becomes a developer record keyed by a pseudonymous id: the first sixteen hex characters of a SHA-256 hash of the lowercased email, or of the GitHub login when no email is available. The email and login themselves are stored as identity links so that one person seen through two identities resolves to one record. The API returns only the pseudonymous id: no report row carries an email or a login. Accounts that Cloud recognises as coding-agent bots are flagged and excluded from developer counts.
Per-developer views are available to organization admins only, and only once the organization has at least five developers on record. An admin can raise that cohort floor for the organization; it cannot be lowered below five. Reports show no ranking of developers. There is a developer-visibility setting an admin can turn on; with it off, which is the default, no display name is shown for any developer.
Retention and disconnecting
Repository, commit, pull-request and developer records are not covered by the 30-day telemetry window above. They are kept until your organization is deleted, at which point they are purged with everything else. Uninstalling the App from GitHub, or suspending it, stops all further reads at once; removing a repository from the installation stops reads for that repository and drops it from reports. Neither action deletes the records already stored. You can ask us to delete them at support@tokenjam.dev.
Retention and deletion
Each organization keeps 30 days of telemetry. A nightly job deletes spans, sessions, outcome events and the hourly rollups built from them once they are older than that. Records from the GitHub source follow the different rule stated in that section. Deleting your Clerk organization purges the organization's data from Cloud, including its ingest keys and everything read from GitHub. Ingest keys are stored so that an admin can retrieve them from the app; the key used to verify incoming telemetry is a salted hash.
Who can see what
Members of your organization can see your organization's reports. Admins can additionally change attribution settings, manage ingest keys, connect GitHub, view the per-developer ledger, and change the organization's privacy settings. We, as the operator, can access stored data to run the service, investigate a problem you report, or respond to a legal requirement.
Where it runs
Cloud's API, background worker and Postgres database run on Render. The web app is a static site on Render, served through Cloudflare. It loads no analytics and bundles its own fonts; the only third-party script it loads is Clerk's sign-in library.
3. This website
- Analytics. Google Analytics 4 (measurement ID
G-C3WCWQW0WR) runs on every page. It sets cookies, records the pages you visit, and derives an approximate location from your IP address. We use it to see which pages get read, not to identify individuals. - Server logs. The site is hosted on Render and served through Cloudflare. Ordinary request logs include IP address, user agent, requested path, and timestamp, retained by those providers under their own policies.
- Email. No form on tokenjam.dev collects an address, and there is no mailing list. Some links hand you to another party that asks for one. Every demo-booking link, wherever it appears, opens a Cal.com booking form, which requires your name and email, and the booking reaches us. Every link into Cloud, including the header's sign-in link, opens Clerk; section 2 covers what Clerk holds. A signup form existed between June and July 2026, sending addresses to a Resend audience. Any address collected then is still held at Resend until we delete it, and we do not mail that list. There is no longer a form to unsubscribe from, so write to support@tokenjam.dev and we will remove yours.
Third parties your browser contacts
Loading a page here issues requests to these hosts, which necessarily see your IP address:
- Google: the analytics tag (
googletagmanager.com) and the webfonts (fonts.googleapis.com,fonts.gstatic.com). - GitHub: pages fetch the public repository star count from
api.github.comin your browser. No credentials are sent and the result is cached in your browser for fifteen minutes. - Cal.com: the demo-booking embed loads from
app.cal.comon every page, since a demo-booking link is in the site header and footer. Booking requires your name and email; those and anything else you type go to Cal.com, and reach us as a booking on a TokenJam event type.
Browser storage is limited to one localStorage entry for the cached star count.
It never leaves your browser.
4. Subprocessors
These are the companies that process data on our behalf. Each one is named in the sections above; this list is the same information in one place.
| Provider | What it does | Applies to |
|---|---|---|
| Render | Hosts the Cloud API, worker and Postgres database, and this website | Cloud, website |
| Cloudflare | DNS and CDN in front of the Cloud web app and this website | Cloud, website |
| Clerk | Sign-in, organizations and membership for Cloud | Cloud |
| GitHub | Source of commit and pull-request metadata for organizations that install the App; also serves the star count on this website | Cloud, website |
| Analytics and webfonts | Website | |
| Cal.com | Demo booking; holds the name and email a booking requires | Website |
| Resend | Delivers the in-app feedback email from Cloud; also holds any address collected by the website's retired signup form | Cloud, website |
The open-source CLI has no subprocessors. Its data does not leave your machine unless you send it somewhere.
Legal basis, retention, and your rights
We process website data on the basis of legitimate interest in running and improving the site; for the name and email a demo booking requires, on taking the steps you asked for by booking; and, for an address left by the retired signup form, on the consent given when it was handed over. We process Cloud data to provide the service your organization asked for. Analytics data follows Google's configured retention period; we keep what a booking contains until we delete it, and we delete one on request; any address left from the retired signup form is kept until you ask us to remove it; Cloud telemetry follows the retention window above. Wherever you live, you can ask us what we hold about you, ask for a copy, ask for a correction, or ask us to delete it. Email support@tokenjam.dev and we will handle it. You can also block analytics outright with any content blocker; the site works without it.
Children
TokenJam is a developer tool and is not directed at anyone under 16. We do not knowingly collect data from children.
Changes
When what the software, the service or the site does changes, this page changes with it, and the date at the top moves. There is no mailing list for policy updates. Questions go to support@tokenjam.dev. The terms of service cover the rest of the relationship.
Metabuilder Labs publishes this description in good faith based on how the software, the service and the site are built today. It is a plain-language notice rather than counsel-reviewed legal text.