Sign in Book a demo 135

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:

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

Third parties your browser contacts

Loading a page here issues requests to these hosts, which necessarily see your IP address:

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.

ProviderWhat it doesApplies to
RenderHosts the Cloud API, worker and Postgres database, and this websiteCloud, website
CloudflareDNS and CDN in front of the Cloud web app and this websiteCloud, website
ClerkSign-in, organizations and membership for CloudCloud
GitHubSource of commit and pull-request metadata for organizations that install the App; also serves the star count on this websiteCloud, website
GoogleAnalytics and webfontsWebsite
Cal.comDemo booking; holds the name and email a booking requiresWebsite
ResendDelivers the in-app feedback email from Cloud; also holds any address collected by the website's retired signup formCloud, 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.