Privacy Policy
Effective 29 August 2026 · Last updated 19 September 2026
Kibble counts what your coding agents spent. It does not read what they wrote.
The collector on each machine sends token totals, model names, opaque session ids and repository names. It never sends prompts, file contents, tool arguments, file paths, hostnames or hardware ids. That is not only a promise: the collector is open source, and the server rejects any request carrying a field it does not expect.
01Who we are
Kibble is operated by Nhan Duc Nguyen, a sole proprietor in Japan, at usekibble.com and app.usekibble.com. In this policy, "Kibble", "we" and "us" mean that operator.
For anything in this policy, including access, correction and deletion requests, write to hello@usekibble.com. Our postal address is given without delay on request to that address.
Where the GDPR applies, we are the controller for the account data described below, and we act as a processor on your organization's instructions for the usage data your engineers' machines push to us. Where the Japanese Act on the Protection of Personal Information applies, we are the business operator handling that data.
02What the collector sends
The collector is the CLI your engineers install (npm install -g @usekibble/cli). For laptops, it reads the usage logs the coding agents already write, plus metadata captured by supported Cursor hooks, and pushes one summary per day, per agent, per model. Cursor hooks are installed explicitly or under the organization’s automatic-collection policy. In CI, an explicitly wrapped agent run or collection from a selected job session directory produces counts-only receipts which can be uploaded with a separate automation credential. Every field it can send is listed here.
| Field | What it is |
|---|---|
| date | The day being summarised. |
| agent | The tool that ran, for example claude-code or codex. |
| model | The model name the agent reported. |
| token counts | Input, output, cache read, cache write and reasoning totals, plus a message count. |
| cost estimate | Those counts priced at published list rates, or a cost estimate reported by the agent, as an integer. Missing local model prices produce zero estimates. CI receipts leave unknown cost unavailable rather than reporting zero. |
| session ids | The opaque identifier the agent already assigned to a session, so a session is not counted twice. It is a random string, and it carries nothing about the conversation. |
| repository name | The name of the checkout the session ran in, for example web. The name only: never the path, never the remote URL, never the contents. A branch name is stored and is not shown anywhere in the product. |
| activity counts | Per repository and day, how much work happened: tool calls, how many of them errored, human and agent turns, durations, edits with the number of lines added and removed, hook failures, compactions. Alongside them, the names of the tools, models, versions and outcomes involved, each from a fixed list the server will not accept an addition to. Counts and names, never what a tool was asked to do or what it returned; the line numbers come from the header of a diff, not from its contents. |
| capability names | While your organization asks for it, the names of the skills, slash commands and MCP servers installed on the machine, how often each one fired, and how large its description and body are. Names and sizes only: never a skill's contents, never the arguments passed to one. Which folder a skill came from and what version it is are worked out on the machine and are not sent. An owner can switch this off for the whole organization, and the server then drops the section from any push that still carries it. |
| billing mode | Per agent, whether this machine runs on a subscription and which tier (for example Claude Max 20x, ChatGPT Pro), on an API key, or through a cloud provider's account. It is read from the login file the agent already keeps on the machine, which also holds account ids, your email and sign-in tokens; the collector copies out the mode and the tier and sends nothing else from that file. |
| Cursor account snapshot | After an explicit kibble cursor sync, an opaque SHA-256 account key, snapshot fetch timestamp, start and end dates, explicitly covered UTC dates, and per-day/model token counts, message counts and integer cost estimates. Credentials and the original Cursor account ID stay on the machine. Subsequent pushes reuse the saved snapshot until refreshed or disabled. |
| CI receipt | A random execution id or a stable hash-based session id, receipt revision and collection source; an opaque session key when available to prevent duplicate stream and file accounting; the agent and its accounting scope; UTC start and end timestamps and elapsed milliseconds when known; the process exit code and termination signals when known; fixed run, agent-result and collection statuses; token buckets, per-model usage and integer cost estimates with their basis when available; observed tool call and error counts; the repository name and git branch name of the checkout the run worked in, when known, and never a path; and fixed collection issue codes. Saved sessions report observed usage as partial, with unknown completion and duration. Missing usage or prices stay unavailable. Raw session ids, paths, streams, prompts, answers and command arguments are not sent. These fields are sent only when CI receipt upload is requested. |
| device | A label for the machine, its operating system family, and a random identifier the collector generated on first run and keeps in ~/.config/kibble/device.json. It is a number the machine chose, not a fingerprint: no serial, MAC address or hardware id is read to produce it. |
An owner gives each CI connection a name and optionally assigns it to a team. These are settings chosen by the owner, not information discovered from the runner. Owners see organization-wide CI reports; managers see connections assigned to their managed teams. CI receipts follow the organization’s retention window and remain after a credential is revoked.
What it never sends: prompts, replies, file contents, diffs, tool arguments, file paths, directory names, environment variables, hostnames, IP addresses gathered on the machine, hardware identifiers, or an inventory of the software on the machine beyond the agent capabilities named above. The server's ingest schema is strict, so a request carrying a field outside the list above is refused rather than trimmed.
Widening that list would mean changing the collector in public. If it ever changes, this page and the source change with it.
03What the dashboard holds
Your account
Sign-in is Google only. From Google we receive the name, the email address Google has verified, and the profile picture URL on the account you choose. We store those, a session record for the browser you signed in with, and the role and team you hold in your organization. We never receive your Google password.
Your organization
The organization name, its members and their roles and teams, invitations that have been sent (the invited email address, who sent it, when it expires), and the plan it is on.
Usage
The rows in section 02, per member and per day, together with derived counts such as sessions, and, where the agent reports them, non-content activity signals such as lines added or removed and commits.
Cursor account usage
The server binds one Cursor account to one member within the organization. Account totals replace local Cursor estimates on explicitly covered days so multiple laptops do not duplicate them. The account key is hashed; Cursor credentials stay on the machine. Usage follows the organization’s history policy.
CI connections
The connection name and optional team chosen by an owner, its creation time, last upload time, revocation status and hashed credential. CI run receipts carry the fields in section 02 and are retained under the organization’s history policy.
Usage estimates from your own vendor account
If an owner adds your organization's Anthropic Admin API key on the settings page, we read your Claude Console's Claude Code analytics every hour. It reports usage and estimated cost, which replaces matching local estimates without claiming to be an invoice. The key is verified once, then stored encrypted (AES-GCM) and never shown again beyond its last four characters. An owner can clear it at any time. It is your organization's key, used only to read your organization's usage.
Machines
One row per linked machine, holding what section 02 lists plus the time of its last push and a hashed copy of that machine's push credential. Credentials are stored hashed, never in the clear.
Billing
If you subscribe, Stripe holds your payment details, and we hold your Stripe customer and subscription identifiers, the plan, the seat count and the state of the subscription. No card number, and no billing address, ever reaches a Kibble form or a Kibble server. Checkout and the billing portal are Stripe's own pages.
Logs
Our server keeps ordinary operational logs (request paths, status codes, timestamps, and the IP address the request arrived from) for a short period so that faults and abuse can be investigated. The dashboard carries no analytics product of ours. Both sites are served through Cloudflare, whose Web Analytics counts page loads and reports the browser's own performance timings without a cookie or an identifier, which section 09 describes. The marketing page and the blog also count visits with PostHog, without cookies and without an identifier that survives the day, described there too. There is no advertising pixel on either site.
04Why we hold it
- To provide the product you asked for: the account, the dashboard, the rollups, the alerts. Under the GDPR, performance of a contract.
- To take payment: subscriptions and invoices, through Stripe. Performance of a contract, and a legal obligation for tax records.
- To keep the service working and safe: operational logs, rate limits, backups. Our legitimate interest in running a service that stays up and is not abused.
- To write to you about your account: invitations, receipts, and notices that matter, such as a change to these documents. Performance of a contract. We do not send marketing email to an address that reached us through a Kibble account.
We do not sell personal data, we do not share it with advertisers, and we do not use it to train machine learning models.
05Who else touches it
| Who | What for | Where |
|---|---|---|
| Hetzner | The server and the database that run the dashboard. | Germany |
| Sign-in, and the web fonts both of these pages load. | Global | |
| Cloudflare | Serving usekibble.com, and holding the nightly database backup in R2 object storage. | Global |
| Cloudflare Web Analytics | Counting page loads and performance timings on both sites, without cookies or an identifier. | Global |
| PostHog | Counting visits to the marketing page and the blog, without cookies. Not present on the dashboard. | United States |
| Stripe | Taking payment and holding payment details, if you subscribe. | Global |
| Anthropic | Read only, with your organization's own Admin API key, if an owner added one. | United States |
| TypeSafe | Deciding whether a question typed into Ask Kibble is answered by an existing dashboard card, before any other model sees it. Receives the question text only and returns a choice, never text. Does not train on it. | United States |
| DeepSeek | Writing the answer to a question typed into Ask Kibble when no dashboard card answers it. Receives the question and the scoped usage figures needed to answer it, including member names when the question is about people. Never any content from a coding session. | China |
| Resend | Delivering invitations and account email over SMTP. Receives the recipient's address and the message. | United States |
| Slack | Telling us when an account is created, a colleague joins, a machine is linked or a Checkout is opened. Receives the organization name and the email address of the person who did it, never any usage. | United States |
Ask Kibble, the question box owners and managers see on the dashboard, is the one place where something you type leaves our server. Each question goes first to TypeSafe, whose model only decides whether an existing dashboard card answers it; if one does, the card is shown and nothing else is sent. Otherwise the question and the scoped usage figures needed to answer it, the same totals and model, agent, repository-name and member figures the asker can already see, go to DeepSeek, which writes the answer. Never a prompt, a transcript, a file, a path or a credential, because we never hold those. We do not store the conversation: it lives in the browser tab and is gone when the tab closes.
Otherwise we disclose personal data only where the law requires it, and, if Kibble is ever sold or transferred, to the acquirer, who would be bound by this policy until it is replaced by one no less protective. You would be told before that happened.
06Where it lives, and for how long
The dashboard, its database and its backups run on a virtual server rented from Hetzner in Germany. A backup is taken nightly, kept fourteen days on the server, and copied to Cloudflare R2 object storage. Data in transit is encrypted with TLS.
If you are in the European Economic Area or the United Kingdom, the services in section 05 that operate outside it do so under the transfer mechanisms in their own terms, which for each of them are the European Commission's standard contractual clauses.
- Usage history: on the free plan, the last 30 days. Older rows are deleted by a job that runs every night, so what a free account can see and what the server still holds are the same month. On Pro, history is kept for as long as the organization exists.
- Account and organization records: for as long as the account exists.
- Backups: a deletion works through the backups as they roll over, within 30 days.
- Billing records: kept as long as tax law requires, which in Japan is seven years.
Ask us to delete your account and we delete the user record, the membership, the machines and every usage row attached to them. Write to hello@usekibble.com and we will act within 30 days.
07Who can see what, inside your organization
Kibble is for visibility, not surveillance, and the product enforces the difference:
- An owner sees the whole organization: totals per person, team, model and repository.
- A manager sees the teams an owner assigned them, read only.
- A member sees themselves only.
- Machines are visible to their owner only. The only screen that lists a person's devices is that person's own. Everyone else, owners included, sees a count.
Nobody in your organization, at any role, can see a prompt, a file or a line of code through Kibble, because we never receive one.
08Your rights
You can ask us to give you a copy of the personal data we hold about you, correct it, delete it, hand it to you in a portable form, restrict what we do with it, or object to a use we base on legitimate interest. Write to hello@usekibble.com. We answer within 30 days and do not charge for a reasonable request.
Some of this data reaches us because your employer asked us to collect it. Where we hold it as a processor for your organization, we will point a request at the organization's owner and help them answer it.
If you are in the EEA or the UK you may complain to your local supervisory authority. In Japan you may contact the Personal Information Protection Commission.
09Cookies
The marketing page and the blog set no cookies. They count visits with PostHog in its cookieless mode: no cookie is written, nothing is placed in local or session storage, and no identifier follows you between visits or off the site. PostHog's servers turn each request into a hash of that day's secret salt, your IP address, your browser's user agent and the hostname, and the salt is thrown away every night, so tomorrow you are counted as somebody new. What we get is aggregate: pages viewed, where the visit came from, which links were clicked, and the browser's own performance timings. There is no session recording, no advertising pixel and nothing sold or handed to an advertiser.
Both sites, the dashboard included, also carry Cloudflare Web Analytics, which Cloudflare adds as it serves the page. It sets no cookie, stores nothing in the browser and uses no identifier, fingerprint or IP-derived key; it reports each page load and the browser's timings for it as an aggregate. It is the only measurement present on the dashboard.
The dashboard sets three cookies, all of them necessary and none of them used for tracking or advertising: a session cookie that keeps you signed in, a cookie holding your language choice (kibble-locale), and one holding your light or dark preference. There is nothing to consent to and no banner to dismiss, on either site.
10Children
Kibble is a tool sold to businesses. It is not directed at children, and we do not knowingly collect data from anyone under 16. If you believe a child's data has reached us, write to us and we will delete it.
11Security
Sign-in is delegated to Google. The browser session, each machine's push credential and each CI automation credential are stored hashed. CI credentials are write-only and never expire. An organization owner can rotate or revoke them at any time; rotation immediately invalidates the previous credential. Your vendor API key is stored encrypted. The database is not reachable from the public internet. Traffic is TLS only. No system is perfect: if a breach ever affects your data, we will tell you and the relevant authority without undue delay.
12Changes
If we change this policy we will change the date at the top, and for anything that materially affects you we will email the address on your account before it takes effect. Continuing to use Kibble after that date means the new version applies.
Questions about any of it: hello@usekibble.com.