Understanding coverage and unattributed spend
Coverage is the share of your AI spend that's tied to work you actually shipped — sessions that trace back to a merged pull request. Spend that isn't tied to a merged PR yet is "unattributed," and ATTRIBUT surfaces it as exploration on your Overview rather than hiding it. Some unattributed spend is normal and expected, especially on active or greenfield projects.
What coverage means
On your personal Overview, the Checkpoints row includes a "Merged PRs" tile with a sub-line like "82% shipped." That percentage is your coverage for the selected period: the share of AI spend that went into sessions which trace back to a merged pull request in a connected repo.
The Footnotes row underneath shows the same split from the other direction. The "Exploration" card gives the percentage of spend that went to tokens on unmerged work, with a short note that this is typical for greenfield work rather than a problem to fix. The "Cost / merged PR" card then turns that same spend into a per-PR figure — this period’s total AI spend divided across each merged pull request, compared with the same work metered at public API rates.
Coverage and the exploration percentage are two sides of one number: coverage is 100% minus the exploration percentage for the same period.
Why some spend is unattributed
Every AI coding session ATTRIBUT captures gets an attribution status based on how confidently it can be traced to your git history. You can see this status on any individual session by opening it from your Sessions list — the detail panel has an "Attribution" section labeled with one of three states.
Status | What it means |
Linked | ATTRIBUT matched the session to one or more pull requests through a verified developer-identity link — the strongest evidence it has. This is the only state that counts toward your "shipped" coverage. |
Inferred | ATTRIBUT matched the session to a repo and commit by parsing a branch name, but no pull request has merged yet. The commit is real, and the session automatically becomes Linked once its PR merges — no action needed on your end. |
Unlinked | No repo or commit could be matched to the session at all. The detail panel shows "No linked work" for these sessions. |
Both Inferred and Unlinked sessions count as unattributed (exploration) spend, because neither has resolved to a pull request yet. Only Linked sessions count toward the shipped share shown on your Overview.
Why this isn't necessarily a problem
Unattributed spend often reflects normal engineering work: prototyping, spiking on an approach, or working on a branch that hasn't merged yet. ATTRIBUT's exploration copy calls this out directly — it's framed as its own kind of insight, not a defect, and is typical for greenfield work where more of the codebase is still in flux.
Coverage also isn't static. An Inferred session self-heals to Linked the moment its branch's PR merges, so your period's coverage can rise after the fact as work lands — you don't need to relink anything manually.
How to improve coverage over time
Merge branches rather than leaving long-lived work unmerged — an Inferred session only becomes Linked once its PR merges.
Make sure your git host is connected so ATTRIBUT can match sessions to commits and pull requests in the first place; see "Connect GitHub" for setup steps.
Expect a nonzero exploration percentage on any actively developed project — treat a sudden jump as a signal to check what's still sitting unmerged, not as an error.