What the install script actually does.

The command on the homepage runs two shell scripts. Both are served as plain text from this site, so you can read every line before anything touches your machine: install.sh sets things up once, and collect.sh is what runs on the schedule afterwards. Together they are under 400 lines of bash, a good share of it comments.

If you would rather not pipe anything into bash, download them, read them, and run the installer yourself. It behaves identically:

curl -fsSL tokken.site/install -o install.sh
curl -fsSL tokken.site/collect.sh -o collect.sh
less install.sh collect.sh   # read both
TT_TOKEN=<your device token> bash install.sh

One directory in your home folder and one scheduled job. No sudo, nothing system-wide, nothing added to your shell profile or PATH.

Installs to

~/.token-tracker/

Contains

config.env (your token, mode 600), collect.sh, state.env, collector.log

Schedules with

launchd on macOS (co.tokentracker.collector), cron on Linux

Needs on your machine

bash, curl, jq, and node — ccusage runs through npx

The schedule runs collect.sh every few minutes. On macOS a second, one-line launchd job (co.tokentracker.watchdog) checks hourly that the collector is still loaded and reloads it if not; it does nothing else. Neither script ever updates itself — the code you read is the code that keeps running until you reinstall.

The collector does not parse your AI tools’ logs itself. It runs ccusage, an open-source, widely used CLI, pinned to one exact version and invoked as ccusage daily --json --offline. ccusage reads the usage logs Claude Code already keeps on your disk and produces a per-day, per-model summary of token counts. --offline means ccusage itself makes no network calls; it prices from a bundled rate table.

The collector keeps only that summary. It never reads a conversation, a file you were editing, or anything about the projects the tokens were spent on.

One HTTPS request per run, to tokken.site/api/ingest, carrying a list of rows. Each row has exactly these fields and nothing else:

POST /api/ingest
Authorization: Bearer <your device token>

{
  "rows": [
    {
      "tool": "claude-code",
      "date": "2026-08-31",
      "model": "claude-sonnet-5",
      "input_tokens": 184203,
      "output_tokens": 21877,
      "cache_creation_tokens": 96410,
      "cache_read_tokens": 2310556,
      "cost_usd": 4.1273,
      "accuracy": "exact"
    }
  ]
}

Two things are derived on our side of the request rather than sent. The hosting platform tags each request with the city it came from, which we round to about 11 km and use to place a pin on the map on the homepage; the IP address itself is used in memory for rate limiting and is never written anywhere. And if you told us your city at signup, that is used instead and the request’s location is ignored.

• It only authorises writes. A token can add usage rows for its own device. It cannot read anything back — not your data, not anyone else's.
• We store a hash, not the token. The raw token is shown once when you add a device and is kept only in config.env on that machine. Our database holds its SHA-256.
• Revoke it in one click. Removing a device on the Devices page deletes the token and every row it ever sent. The collector on that machine starts getting 401s and stops being able to report.

Removing the directory and the schedule is the whole uninstall. Nothing is left behind.

launchctl unload ~/Library/LaunchAgents/co.tokentracker.watchdog.plist
launchctl unload ~/Library/LaunchAgents/co.tokentracker.collector.plist
rm ~/Library/LaunchAgents/co.tokentracker.*.plist
rm -rf ~/.token-tracker

crontab -l | grep -v '.token-tracker/collect.sh' | crontab -
rm -rf ~/.token-tracker

Then remove the device from your Devices page if you also want its history gone from the dashboard.

If you spot a problem in either script or in how the service handles what they send, write to hello@tokken.site. What happens to the data once it arrives is covered in the privacy policy. Tokken is a small product; you will get a person.