What ATTRIBUT collects — and what it never collects
ATTRIBUT captures counts, timings, and labels about your AI coding sessions — things like how many tokens were used, how many lines changed, and which tools ran. It never captures the work itself: not your source code, not your prompts, not the AI's responses, and not any file contents or diffs.
The short version
Every record ATTRIBUT stores is a number, a timestamp, or a short label. Specifically, ATTRIBUT captures:
Token counts (how much text the model processed, not the text itself)
Tool-usage counts (how many times a tool like a file editor or shell command ran, not what it did)
Line-change counts (how many lines were added or removed, not the lines themselves)
Timing (when a session started and how long it ran)
Model name (which AI model handled the session, e.g.
claude-opus-4-8)Branch (the git branch name you were working on)
Commit SHA (the unique ID git already assigns to a commit)
Repo path (the working-directory path on your machine, e.g.
~/code/acme/web-app)Session title (the short label your coding tool already gives the session)
ATTRIBUT never captures, transmits, or stores:
Source code
File contents
Diffs or code snippets
Prompts (what you type to the AI)
AI responses (what the model writes back)
What a coding-session record actually contains
When your connected AI coding tool finishes a session, the local collector reports a small JSON record. Here are the fields from a real one — this is a representative set, not a complete list, but every field follows the same rule:
Field | What it means |
sessionId | A random ID generated for the session — not derived from anything in your code. |
device_uuid | An anonymous, random ID for the machine running the collector — not tied to your name, email, or code. |
title | The short session label your coding tool (such as Claude Code or Codex) already assigns — for example, "Refactor checkout validation." ATTRIBUT reads this existing label as-is; it does not generate or alter it, and caps it at 200 characters. |
model | The name of the AI model that ran, e.g. "claude-opus-4-8." |
tokens_in / tokens_out | Usage counts for the session — numbers only. |
started_at / duration_ms | When the session began and how long it ran. |
repo / branch | The working-directory path and git branch name. |
commitSHA | Commit hashes produced during the session. |
num_turns / num_tool_calls | How many conversational turns and tool calls occurred. |
tool_uses | Tool names and how many times each ran — for example, "Edit" 14 times, "Bash" 9 times. Never what those calls contained. |
lines_code_added / lines_code_removed / lines_comment_added | Counts of changed lines, derived locally on your machine. Never the lines themselves. |
claude_code | If Claude Code is your coding tool: its client version, plus per-subagent counts and timings — never what a subagent was asked to do or what it produced. |
Every field in that record is a count, a timestamp, or an existing label — never the underlying text.
What ATTRIBUT never reads or stores
This isn't a policy you have to take on trust — the local collector is built so these fields can't be read in the first place:
Your source code — no file contents, ever.
Diffs or code snippets — ATTRIBUT counts changed lines; it never keeps the lines.
Your prompts — what you type to the AI never leaves your machine.
AI responses — the model's output is never captured.
Tool inputs — the actual shell commands or file contents passed to a tool.
Keystrokes, screens, or your filesystem — no keylogging, no screen capture, no file-tree listing.
Git activity, if you connect GitHub
If you connect GitHub, ATTRIBUT also records standard git metadata — the same fields GitHub itself shows on any commit or pull request: repo name, branch, commit SHA, commit message, author login and email, PR number and title, and line-change counts (additions, deletions, changed files). ATTRIBUT never stores diffs, file patches, the paths of individual files changed, or PR descriptions. This data is used to connect commits and pull requests to the sessions and people behind them.
GitHub connector setup is covered separately in "Connect your AI tools to ATTRIBUT."
Account and identity data
To show your work as yours, ATTRIBUT stores basic identity information from your sign-in — your email, your name, and your GitHub username (so commits can be matched to you). This is managed through ATTRIBUT's authentication provider, Clerk.
Standard request metadata
Like any web service, ATTRIBUT logs ordinary request metadata to keep the platform secure and reliable — not to inspect your work:
Field | Captured as |
IP address | Request origin |
Location | Country / region |
Network & connection | ASN, protocol |
Browser / agent | Client string |
This is used to detect abuse, diagnose issues, and understand where requests originate — never to inspect the contents of a session.
How this is enforced, not just promised
The boundary between what's captured and what isn't lives in the collector's code, not just in this article:
The collector reads only an allowlist of numeric and metadata fields, and validates every payload against a frozen schema before sending it.
A built-in privacy test plants secret markers in every sensitive field (prompts, responses, tool inputs, file contents) and proves none of them can appear in what gets sent.
The collector's full source is published publicly on GitHub and ships inside the package, so you can read exactly what it collects — and confirm it for yourself — rather than take ATTRIBUT's word for it.
Related reading
If you use the CLI, the Connectors → CLI collection has a CLI-specific version of this article: "What ATTRIBUT captures — and what it never sends."