Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Yoshihisa Kaino counted AI co-authored commits in his own Git history and found that 10,261 of 26,251 commits—39%—carried a Claude co-author trailer. In the public-only view, the count was 126 of 5,688, or 2%. Those figures answer a narrow but useful question: how many commits in the repositories visible to a particular query included a declared AI co-author? They do not measure the share of code written by AI or establish how developers generally use AI. Kaino’s account, published September 20, 2026, is a practical guide to counting that metadata—and to the ways the result can mislead.
What a co-authored commit count can—and cannot—tell you
A Git commit can include a Co-Authored-By trailer naming another contributor. Kaino used these trailers as a signal for AI-assisted work in his own repositories. In one repository, he counted 960 Claude-tagged commits out of 1,107; across the repositories he had touched, he reported 10,261 of 26,251 commits, or 39%.
That is a count of commits carrying a particular declaration, not a measure of lines generated, effort contributed, or code ultimately retained. A trailer alone cannot show how much the AI system wrote, how substantially a person changed the result, or whether the commit would otherwise have been made. The useful interpretation is “commits marked with this co-author,” not “this percentage of my code was written by AI.”
Kaino put the personal significance plainly: “I knew my workflow had changed. I didn’t know it had changed that much, and I couldn’t have told you so with a number before this.” His figures describe his history and the snapshot he counted, not a representative study.
How to count trailers in a local Git repository
Kaino’s first approach searched commit-message bodies for the co-author trailer. For example, this command prints commit bodies containing the phrase:
git log --format='%b' | grep -i 'Co-Authored-By'
To count matching commit bodies rather than print them, use:
git log --format='%b' | grep -i -c 'Co-Authored-By'
That simple count has a limitation: it counts matching output lines, not necessarily distinct commits. A commit body might contain more than one matching line, while formatting and trailer conventions can vary. For a reliable per-commit count, inspect or parse each commit’s body and count a commit once when its trailers match the identity you intend to track. Kaino’s reported results are his own counts; they should not be treated as an independently audited measurement.
Match stable trailer email addresses, not display names
Agent names can be ambiguous. In Kaino’s Claude comparison, searching with the name form returned 10,262 matches, while using an email address returned 10,255. He traced the additional matches to human collaborators whose trailer text also matched the name. His practical choice was to key known agents by the email address recorded in the trailer.
This matters especially for tools whose displayed co-author name changes. Kaino notes that Aider’s visible name can include the model and vary between commits, while the email address remained stable in his examples. Email matching reduces accidental matches, but it is still a convention found in commit metadata—not an official, guaranteed identity registry for every agent.
GitHub commit search: verify that the filter actually works
Kaino tested GitHub commit search using the co-authored-by: qualifier. His control searches returned different totals for different email addresses, an invented qualifier returned zero, and a search without the qualifier returned the full count. In those tests, the parser appeared to recognize the qualifier.
However, Kaino says he could not find this qualifier in the commit-search documentation he checked. Treat it as observed behavior, not a documented API contract: GitHub could change how it handles the query. A filtered result is only useful if you confirm the filter narrowed the results.
- Compare the filtered count with the unfiltered total for the same search scope.
- A zero result may mean there are no matches, but it may also indicate a malformed or unsupported query.
- If the filtered count is equal to or greater than the unfiltered total, consider the filter unusable: it may have been ignored or interpreted differently than expected.
- For implementation details, check GitHub’s current documentation rather than relying on an undocumented query behavior.
Kaino’s safety check is a defensive rule for interpreting his observed results, not a guarantee about GitHub’s search parser.
Repository visibility changes both parts of the percentage
Kaino’s private-inclusive result was 10,261 of 26,251 commits (39%). His public-only result was 126 of 5,688 (2%). The difference is not just a matter of a noisier public estimate: the public-only query could not include work in repositories outside its visibility. Both numerator and denominator changed.
| Scope in Kaino’s account | Claude co-author matches | Total commits counted | Share |
|---|---|---|---|
| Repositories including private work | 10,261 | 26,251 | 39% |
| Public-only view | 126 | 5,688 | 2% |
These are Kaino’s reported personal counts, not current platform statistics. When reproducing the calculation, state which repositories the query could see and avoid presenting a public-only result as the full measure of a private-inclusive workflow.
Kaino argues that people wanting a private-inclusive count should run the calculation in their own CI with their own token, rather than send credentials to a shared service. That is his design rationale, not a blanket security guarantee: a token’s permissions and how a workflow handles it still matter.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A personal timeline can reveal more than one lifetime total
A cumulative percentage hides when a workflow changed. Kaino reported 42 commits in October 2025 and 2,067 in September 2026 in his own history, describing the latter as 49 times higher; he also reported more than 80% in recent months. These are personal observations, not a trend for developers generally. A monthly series can make a change in one person’s habits easier to see, provided the repository scope and definition of a matching commit remain consistent over time.
What the count leaves out
- Unmarked assistance: AI-assisted commits without a co-author trailer will not appear in a trailer-based count.
- Declared co-authorship is not a measure of contribution: the trailer does not quantify generated code, human revision, or retained output.
- Visibility and scope: private repositories or repositories unavailable to the querying identity are absent from that query’s results.
- Identity conventions: name matching can produce false matches, while email matching depends on consistent trailer addresses.
- Search behavior: Kaino’s GitHub qualifier observation was undocumented in the documentation he checked and may change.
- Time of measurement: repository histories and public search totals can change, so the result is a snapshot rather than a permanent statistic.
Kaino also says his tool reads the API’s total_count, not repository names, commit messages, or diffs, and notes that commit-search enumeration is capped at 1,000 returned items even when the total count is larger. Those are details from his account; check current GitHub documentation before building a tool around them.
Making a useful personal measurement
- Choose the question. Decide whether you want a count of commits with an AI co-author trailer, a public-only view, or a view that includes repositories accessible to your own account. These answer different questions.
- Choose an identity carefully. Prefer a known trailer email over a display name when the address is available, and inspect unexpected matches.
- Count commits, not matching lines. Parse commit bodies or trailers per commit so multiple matching lines do not inflate the total.
- Validate any hosted search filter. Compare filtered and unfiltered totals and treat implausible results as a failed or uncertain filter, not as a trustworthy answer.
- Record scope and date. Keep the numerator, denominator, repository visibility, matching rule, and measurement date together.
- Use a time series if change matters. A monthly count can show when marked usage rose or fell, but only when the scope and matching definition stay comparable.
Kaino describes cocommit as MIT-licensed and dependency-free, with an npx invocation. Project details can change; consult his linked article for the tool context rather than assuming those details are current specifications.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
