Privacy Policy

Version 2026-10-22-en · effective 2026-10-22

What we process

TokenMeter processes usage metadata: the account, device, team, tool and model behind a request, the token counts, the timestamps, the cost, and the verification status. With a consent you give separately, it also processes counts that describe how the projects on your own device are organized — counts only, described under "Devices" below. Separately from all of that, it records the fact of signing in, keeps a record of each session you have open, and keeps what you write to us when you ask for help — each described under "Retention" below. Human-authored message text is also read for on-device usage classification; with external content classification enabled, message text is sent through our gateway to the model provider your workspace (shown in the console as your organization) chose — described under "Devices" below.

Signing in

When someone signs in, or tries to and fails, we record the time, the address that was entered, the internet address the request came from, and the description the browser gives of itself. The address that was entered is not stored in readable form: we can check an address against what we hold, and we cannot read an address back out of it. That makes the record harder to read, not anonymous — the internet address, the browser description and the time stand as recorded. We record this to investigate accounts that have been locked and attempts to break into the sign-in page, and for nothing else: not for analytics, not for marketing, and never added to anyone's account record. We record it whether or not the address belongs to an account here — an address somebody types by mistake is recorded the same way as one that works.

While you are signed in, each session also carries the internet address and browser description it was opened from, so that you can recognize your own sessions and end the ones you do not. You see them under Settings › Me › Sign-in security (Signed-in sessions).

Whose data it is

The workspace is the controller of its members' usage data; we process it on the workspace's instructions. A workspace records the legal ground on which it processes its own people's data — we do not choose that ground for it.

Sign-in records are different. We hold them for ourselves, not for any workspace, and we are the controller of them — including for an address that belongs to no account here and to someone who has never had one. Our ground is our own legitimate interest in keeping the sign-in page safe (GDPR Article 6(1)(f)); we weighed that interest against the people recorded, and we will show you that reasoning if you ask. That is the one category in this product where the choice is ours rather than a workspace's, and it is why the rest of this notice's routes through a workspace administrator do not apply to it.

Where it lives

The hosted service runs on infrastructure we operate in Seoul (ap-northeast-2). Each workspace's rows are isolated from every other workspace at the database level, enforced by the database rather than by application code. Sign-in records and what you write to us are outside that isolation because they are ours rather than a workspace's; a workspace's administrators do not see them. On-device analysis runs on the device itself. External content classification sends message text through our application server, our classification relay and the LiteLLM gateway we operate for the workspace on AWS in Seoul (ap-northeast-2), and on to the model provider the workspace chose. We configure the relay and gateway not to log message text. This does not certify the model provider’s retention policy.

Devices

Device registration and approval are separate from the choices for each kind of data. An approved device sends per-request usage records and the account identity described below; an administrator, or the workspace's automatic-approval setting, approves a device, and these are not switched off under Settings › Me › My collection — they stop when the device's approval is revoked or the device is removed. Members receive these as a workspace default: device metadata, on-device content classification, browser collection and external content classification, without recording you as the person who gave consent. Existing personal ON, OFF and future-dated decisions are preserved. Missing external-classification grants are recorded prospectively, never backdated. Project checks and provider quota collection remain off by default. Each kind is listed below with what is read on the device and what is sent to us. You can change each choice in the console under Settings › Me › My collection. Device-side changes take effect at the next consent check and collection cycle.

A workspace feature setting alone does not start collection. A recorded default or personal grant is required on the personal path. Some axes can instead be authorized by a separately applicable organization collection policy, with its own notice, device confirmation and scope conditions. These are distinct authorization sources; an organization policy does not record personal consent on your behalf.

Device · metadata

What is read on the device: the session records your AI tools already write for themselves — when a session ran, which tool and model it used, and the token counts. What is sent: those token counts by day, tool and model, with their timestamps, and two further figures per day — how many sessions ran, and how many of the tokens the model read went to subagents, the helper agents a tool starts to work on part of a task, so that the console can show that share. Both are counts. This metadata read does not extract conversation text; the separate content-classification read below does.

Device · content classification

Under on-device content classification, the agent reads human-authored message text from Claude Code and Codex session logs in memory to label usage as work, non-work or ambiguous and count credential-pattern matches. The agent does not write that message text to disk. This local path sends per-day token totals and counts, rather than the message text.

External content classification has a default-ON policy. An actual dated grant, or separately applicable organization-policy authority, is still required; absence of a grant is not permission. Your existing OFF choice remains OFF. The workspace must also enable classification and provide a model connection, and on-device content classification must be allowed. A compatible agent checks each input against its authorization period and sends at most the first 2,000 characters of the newest human turn after checking known sensitive patterns; a detected turn is not sent. Content passes through our application server, classification relay and operated LiteLLM gateway to the workspace-selected model provider. We configure the relay and gateway not to log message text; this does not certify the provider's retention policy. We store violation-category counts and masked findings retaining at most the first four and last two characters of a matched value, up to twelve per day, tool and category. Turning this permission off is available even when organization classification is unavailable. Existing records and consent history follow the separate deletion process.

Device · account identity

On macOS, Linux and Windows, the agent reads the account section of the Claude Code account file and sends six fields: account email, the provider's organization identifier, the provider's organization type, the provider's organization rate-limit tier, subscription creation time and seat tier. For Codex, it reads verified identity claims from the local identity file and sends account email, the provider's default organization and plan type; it also reads plan type from Codex session logs. This identity path does not send ID, access or refresh tokens to us. This identity read runs under the device's approval, not under a per-kind choice.

Browser collection

On macOS and Windows, browser collection reads Chromium local storage account identity fields and history for claude.ai, chatgpt.com and gemini.google.com. The local account read extracts email, the provider's organization, account identifier, plan and rate-limit information. What is sent by the browser activity path: the provider site, account email, aggregate visit and conversation counts, per-day counts, hour-of-day buckets and last-visit timestamps. It does not send page titles, conversation bodies or full URLs. This collection requires the device's collection approval and your browser collection choice; it skips devices reported as managed or whose management status cannot be determined.

Device · provider quota

Off by default, Codex quota collection reads the current user's local Codex identity and access credentials on macOS, Linux and Windows, verifies identity, and uses the access token only to request usage from a fixed OpenAI (chatgpt.com) HTTPS endpoint. We receive collection status and observation time, and, for successful observations, account and subject references, usage percentages, window durations and reset metadata. The server stores the subject reference as a digest scoped to the workspace. ID, access and refresh tokens and the provider's response body are not sent to us.

Gateway · request analysis

Gateway request analysis is not currently available. A workspace-default permission may be on record, but that permission does not mean analysis is running. Existing permission records are retained and can be withdrawn. A new withdrawal is recorded with immediate effect; previously recorded effective times are not rewritten. Separately, for requests already passing through the gateway, we collect request identifiers, account or key references, model identifiers, timestamps and token counts from its usage records for usage and cost reporting. This collection does not enable request analysis or external classification of device message text.

How your own projects are set up

Off by default: nothing described here is read until you turn it on. When it is on, the device looks at how the project folders your sessions ran in are organized — and only at two fixed places inside each: the documents folder (docs) and the skills folder (.claude/skills). It looks at structure only: whether a folder or file is there, how many files there are, whether a document opens with a metadata block that names its type, and whether the first 4 KiB of a skill's entry file (SKILL.md) holds a line that starts with verdict: or triage: — the rest of that line, and the rest of the file, are never read. It does not read what any document says, and it does not read the value of any metadata field. Of the projects it looked at, it reports on one — the one you worked in most recently that had something to count.

What is sent, for each check: the check's name and revision; a verdict — applied, partly applied, not applied, or could not be judged; the number of items that passed and the number examined; how many projects had something to count; how many files were left out because they could not be read within the limits below; the reason, when no verdict could be reached; and the date from which the result has been observed. Every one of these is a word from a fixed list or a number. No path, no folder or file name, no file content and no error message leaves the device.

The look is bounded, and hitting a bound gives "could not be judged", never a partial figure: at most 256 project folders per pass, most recent first; no deeper than sixty-four levels below the two places above; at most 2,000 entries per project; at most 4 KiB read from any one file; and at most ten seconds for the whole pass, checked at every step.

Who sees device results

You see the results for your own devices in the console under Usage › Recommendations, with the view set to My devices. Your workspace's administrators, and group leads for the people in their groups, see the same results per device with the view set to Organization — not a ranking and not a score. The workspace defaults described above are grants made without your individual action; you can turn each off.

When you write to us

If you send us a question or a report from the console, we keep what you wrote along with your address and the name on your account, and our staff read it to answer you. Write only what you want us to have: the box is free text and we do not inspect what goes in it.

Mail you send to info@token-monitor.com is forwarded to Gmail and handled with Google Workspace/Gmail. Mail is received by AWS in Seoul and a copy is kept there for thirty days before deletion.

Your rights

You can ask for access, erasure, portability or correction of your personal data, and the product implements all four. Erasure removes or pseudonymizes the data that identifies you while keeping the financial record the workspace needs — your identity is severed from it, and figures that would otherwise misstate what a workspace spent are preserved. Erasure also deletes the per-day device figures and the check results described above for every device that was yours. Ask your workspace administrator to raise the request.

If you have no workspace here — because an address of yours appears only in a sign-in attempt — there is no administrator to ask, so write to us at info@token-monitor.com. Tell us the address that was entered; that is what we search on, and we will tell you what is held against it or that nothing is, and delete it if that is what you ask. Because we record attempts on addresses that have no account here as readily as on ones that do, an answer about an address tells you nothing about whether an account exists under it. We answer these by hand rather than through the console, because the console's request screen belongs to a workspace and you are not in one.

Retention

Usage data lives as long as the workspace does, except for provider quota observations and recorded limit-reached events, which are deleted after ninety days by the next successful scheduled cleanup. Closing a workspace ends access to it and stops collection. When you close one you choose what happens to the usage already collected: erase it as part of closing, or keep it — and if you keep it, those records stay until we erase them. The account records themselves are retained until erasure.

Sign-in records are deleted on a schedule and are not kept beyond ninety days. That period does not change when a workspace closes, because these records are not the workspace's to close. The session records described above last as long as the account does, and you can end a session yourself at any time. Console support messages are subject to a hundred-and-eighty-day deletion schedule. Console support messages are copied to Linear, which we use to track them, and that copy is deleted on the same hundred-and-eighty-day schedule. Linear keeps a deleted copy in its trash for up to thirty days before removing it permanently. That schedule does not delete mail forwarded to Gmail.

Contact

Write to us at info@token-monitor.com, or ask your workspace administrator, who can reach us on your behalf. If you have no workspace here, that address is the only route and it is enough.