compare · what each instrument counts

causari and the other ways to count

Each cell is a fact we can defend from public documentation or from the code. Where a vendor has not published something, the cell says not stated publicly rather than guessing. If a cell is wrong, open an issue; it is corrected in public.

Different tools answer different questions. git blame answers "which commit last touched this line". A vendor's usage dashboard answers "how much was this product used". A churn report answers "how much code changed soon after it was written". A DORA dashboard answers "how fast and how safely does this team ship". re audit answers one question only: of the lines that commits with AI authorship metadata introduced, how many does git blame still attribute to them. None of these replaces another.

	`git blame` alone	Copilot metrics API / dashboards	GitClear-style churn reports	DORA-type dashboards	causari (`re audit`)
What it counts	Which commit and author last changed each line of a file at one revision.	Usage of one vendor's product in an organisation: active users, suggestions shown and accepted, lines accepted, chat use, per day, editor and language, as documented for the metrics API.	Code-change patterns over the repositories it analyses: lines added, deleted, moved, updated and copied, and churn, meaning lines changed again shortly after they were written; the window is the vendor's definition.	Four delivery measures: deployment frequency, lead time for changes, change failure rate, time to restore service. Nothing about who or what wrote the code.	Lines introduced by commits carrying machine-readable AI authorship metadata, and how many of them `git blame -w -M -C` still attributes to those commits at HEAD, with a per-commit cap and a sample floor. Rules.
Needs the agent's cooperation?	No. It also has no notion of an agent: every line has a human committer.	The data is the product's own telemetry, so it covers that product and only that product.	No. It works from diffs. Attribution to AI, where its reports make one, is statistical over time, not per commit.	No. It does not attribute code to anyone.	Yes, in the weak sense that the commit must carry a trailer, a bot author or a git-ai note. Untagged commits are UNKNOWN and never counted; inline completions are invisible.
Needs a vendor account?	No.	Yes: a GitHub organisation or enterprise with the product enabled, and admin access to call the API.	Yes for your own repositories: a hosted service. Its published reports are readable without one.	Depends on the implementation. The four definitions are public; most dashboards that compute them are hosted products, some are self-built.	No. One static binary; no telemetry, no account, no server.
Works on any git repo?	Yes.	No: repositories and organisations where the product is enabled, as reported by the product.	Repositories connected to the service. Its public reports describe the repositories it analysed.	Git alone is not enough: it needs deployment and incident data from the delivery pipeline.	Yes, any full clone, local or by `owner/repo`. Shallow clones are refused.
Records the prompt?	No.	No: the documented metrics are daily aggregates.	No.	No.	Not the audit. The optional local ledger does (`re hook claude-code`, `re proxy`), on your machine, gitignored. Evidence classes.
Verifiable by a third party?	Yes: anyone with the clone gets the same output.	No: the figures come from the vendor's telemetry and cannot be recomputed from the repository.	The reports state a method; the per-repository data behind them is the vendor's. Independent recomputation: not stated publicly.	Depends on the data source. The definitions are public; the inputs are usually internal.	Yes: `re audit owner/repo --json` reproduces the bytes, `--seal` signs them, `re seal verify` or /verify checks the seal offline.
Open source?	Yes: git, GPL-2.0.	No: a hosted product with a documented API.	No: a hosted product. Its reports are published as documents.	The definitions are public research. Implementations vary: some open source (Four Keys), most hosted.	Yes: Apache-2.0, github.com/croviatrust/causari.
What it cannot see	Which commits involved AI. Without `-w -M -C`, a formatter pass or a moved function re-attributes the line.	Code from any other tool. What happens to an accepted suggestion after acceptance is not among the documented metrics.	Which specific lines were AI-written, and the prompt. Attribution is aggregate.	Anything about which code was written by AI, or what became of it.	Inline completions (Copilot, Cursor Tab, Windsurf, …); untagged agent commits; a human's edits inside an AI co-authored commit; whether a line is good. Full list.

Notes on the cells

Copilot metrics. The column describes the vendor's documented metrics API and the dashboards built on it, as of September 2026. Coding-agent commits made through the same product carry a Co-Authored-By trailer and are visible to re audit; the Survival Report lists them under the agent github-copilot.
GitClear-style churn reports. The column describes the published reports and the service as they describe themselves. The churn window and the exact classification rules are the vendor's; we do not reproduce them. Our own report reads next to theirs, not instead of them: Survival Report.
DORA-type dashboards. Included because the question "is AI making us faster" is often answered with them. They are about delivery, not authorship, and the two columns measure different things.
causari. The column is derived from the code and the method page. A survival ratio is a count, not a grade: deleted lines include removed features and rewritten prototypes; surviving lines include dead code.

Check our numbers yourself

Every row of the Survival Report names the command that reproduces it. Report #1 counted 462,838 of 754,476 lines from 12,349 AI-tagged commits still at HEAD across 10 repositories (61.3 %, 95 % bootstrap interval over the sample 53.0 % to 64.9 %). Run the audit, sign it, and verify the seal with nothing but the file.

re audit owner/repo --json        # the exact bytes behind a row
re audit --seal                   # signed, bound to the commit
re seal verify audit.seal.json    # offline · or drop it on causari.dev/verify

Verify a seal in the browser