Linux Retires Its Assisted-by AI Tag While Use of It Was Still Rising, and What Replaces It Mostly Lives Outside the Git Log

On October 14, Jonathan Corbet committed a patch from Sasha Levin that deletes the Assisted-by rules from the Linux kernel’s documentation, and Linus Torvalds’s docs-7.4 merge, timestamped 00:38 UTC on October 21, brought it into mainline. Two outlets generalized the story. The Register’s column said the change means “you no longer need to say if you used AI in your code submissions,” and Tom’s Hardware wrote that the team is changing its policy to “no longer require that patch authors disclose they used an AI tool.” The commit message is narrower. It removes one tag, says maintainers “do still want to know how a patch was created,” and says the kernel’s guideline on tool-generated content “is not changed here.”

I wanted to see what the tag had recorded while it was in force, and the kernel’s git history can answer that. I cloned it as a shallow, tree-less history from November 15, 2025 through October 25, 2026 (85,422 non-merge commits) and counted trailers myself. The denominator the maintainers cited reproduces exactly: 18,533 non-merge commits in Linux 7.3 through -rc7. I count 1,877 of them carrying the tag, 10.1 percent, against the 1,884 in the commit message. The shape matters more than that gap. The share rose at every release, from 0.2 percent in 7.0 to 14.5 percent of the 7.4 merge window so far, so the rule was retired at the highest share the tag had reached. Only 13.8 percent of the authors in 7.3 had used it even once. And the plain-prose disclosure that remains is nearly empty in the history so far: 33 of the 16,656 untagged 7.3 commits mention an AI tool’s role in their messages.

Below I set the commit and the coverage side by side, go through the numbers, and say what they mean for anyone who reads kernel history to learn how much AI is in it. Where I computed something myself I say so, and the commands to repeat the count are in the closing sections.

What the commit changed, and what it left alone

The text that was removed

Commit 1e035297ffda, titled “docs: remove Assisted-by references,” takes the Attribution section out of coding-assistants.rst, deletes the “Using Assisted-by” section from submitting-patches.rst and from its Italian, Brazilian Portuguese and Traditional Chinese translations, and strips the tag out of scripts/checkpatch.pl, which listed it as a recognized trailer and had a special case that warned when the tag carried no value. The tag was a trailer line in the commit message, in the same family as Signed-off-by. The original rule asked for Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], with Assisted-by: Claude:claude-3-opus coccinelle sparse as its example. A change committed on August 3 simplified it to Assisted-by: LLM [TOOL1] [TOOL2].

What stayed

The accountability rules are untouched. coding-assistants.rst still says “AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO),” and still makes the human submitter responsible for reviewing all AI-generated code, for licensing compliance, for adding their own sign-off and for “taking full responsibility for the contribution.” The commit message says so itself: “The rules on the DCO and on the submitter’s responsibility for the patch stay as they are.”

The disclosure guidance also stays, in a different file. generated-content.rst, the kernel’s guidelines for tool-generated content, tells contributors to “be transparent about the origin of content in cover letters and changelogs.” It suggests saying what tools were used, what input they were given, which portions of the content they affected and how the result was tested, and it adds that “if a tool was used to find a problem addressed by a change, that should be noted in the changelog.” For doubtful cases it says “choose transparency and assume these guidelines apply to your contribution.” It leaves each maintainer free to treat a contribution normally, review it with extra scrutiny or at lower priority, or reject it. It also warns that if a submitter cannot explain and defend the changes and sends them anyway, “maintainers are entitled to reject your series without detailed review.”

So the accurate summary is that a mandatory label went away and an expectation of transparency in prose stayed. The two documents differ slightly on where that prose belongs. The commit message says the view at the Summit was that tool-use information belongs “in the cover letter, where it can describe how the tools were used, rather than in the changelog,” while generated-content.rst still names both cover letters and changelogs. A contributor reading both has to decide which applies, and the guideline’s own “if in doubt” rule points toward saying more.

A short history of a short-lived rule

The rule was in force for four kernel releases, 7.0 to 7.3, and was removed in the fifth. The commit history and LWN let me date each step.

I could not read the mailing-list thread for the removal patch. lore.kernel.org answered my scripted requests with a proof-of-work page, so for the reaction there I rely on Phoronix, which reported on October 13 that the thread showed “mixed views over whether this tag should be removed” but that the change would “likely proceed as planned.” The decision itself is documented in the commit message, which says there was “a strong, though not unanimous, consensus in the room to drop it” and that Kroah-Hartman, who had argued for keeping the tag in July, supported removing it.

What the coverage did and did not say

Phoronix described the change accurately in its headline: kernel developers plan to remove the “Assisted-By” tag requirement. LWN’s summary of the Summit is similar: “The requirement to add Assisted-by tags to patches created with LLMs will be removed, but maintainers still want to know about how a patch was created.” The Register’s column and Tom’s Hardware turned a tag requirement into a statement about disclosure in general. That reading is understandable, because dropping the tag does end the one rule that prescribed a format for disclosing. It is still broader than the text, which keeps the DCO duties and the transparency guideline.

What the git history says about the tag

Everything in this section is my own count from the clone unless a source is named. I call a commit tagged when a line of its message starts with Assisted-by:, in any letter case. The closing sections have the rules and the commands.

The share rose at every release

Two comparisons with other people’s numbers. The 18,533 denominator is exactly what Levin’s commit message and LWN report, and LWN calls it a record. 7.3 is also the largest of the four complete releases in my clone (18,765 in the final release against 14,156, 15,850 and 16,418). My tagged count is 1,877, or 1,878 if the string may appear anywhere in the message and 1,879 with looser spacing, while the commit message and LWN give 1,884. I could not reproduce 1,884 with any matching rule I tried. The difference is 0.4 percent and does not change the finding that the tag was on about one commit in ten.

Counted by the month a commit was applied rather than by release, the share climbs from 0.2 percent in February to 4.1 percent in May, 8.6 percent in July, 14.6 percent in September and 17.7 percent in October so far. October counts only commits that had been applied and merged by October 25, so it will move. But no month in the history I counted shows a fall. That is the context for the Summit’s decision. The case against the tag was that it was a weak signal, and the commit message puts it directly: “its absence says nothing about how a patch was made, and for developers who use these tools for almost everything, its presence says little more.” The tag was not fading, though, and whether use drops now that the rule is gone is the open question I return to at the end.

Few authors used it, and most who did used it on some commits only

Across the 18,533 commits in 7.3 through -rc7 I found 3,136 distinct author identities (name plus address). Of those, 433 (13.8 percent) wrote at least one tagged commit. They wrote 4,159 commits, 22.4 percent of the release, and tagged 45.1 percent of their own. The other 2,703 authors wrote 14,374 commits, 77.6 percent of the release, and tagged none. Among the 462 authors with at least 10 commits in the release, 342 (74.0 percent) never used the tag, 73 used it on fewer than half of their commits, 39 on half or more but not all, and 8 on every one. The ten heaviest users account for 31.0 percent of tagged commits and the twenty heaviest for 43.6 percent.

That pattern fits what the Summit described, a label that depends on each contributor remembering it and each maintainer asking for it. It cannot separate omission from non-use, though. Among the 120 prolific authors who used the tag at all, 73 used it on fewer than half of their commits, and some of those untagged commits may simply have been written without an LLM.

The share varies by area

The text before the first colon or slash in a subject line is a rough proxy for the area of the kernel, though it is not the MAINTAINERS file. Among groups with at least 250 commits in the release, the tagged share runs from 1.4 percent for dt-bindings to 29.7 percent for perf. In absolute terms drm leads with 318 tagged commits. My data cannot say why the rates differ; the mix of contributors, the habits of maintainers and the kind of change could all matter.

The simplification took two months to show up

The July change replaced the agent-and-model form with plain LLM to stop what the commit called free advertising for vendors. It reached the documentation tree on August 3 and mainline in the docs-7.3 merge on August 20. By the month a commit was applied, the share of tags saying only LLM was 0 of 608 in June, 35 of 873 (4.0 percent) in July, 34 of 851 (4.0 percent) in August, 569 of 1,439 (39.5 percent) in September and 648 of 1,143 (56.7 percent) in October. In the 7.4 merge window so far, 953 tags (45.2 percent) say only LLM and 996 (47.3 percent) still name an agent and a model. About half of the tags written since then use the new wording, and the model names already in history will stay there.

What the simplification gave up is visible in the 7.3 tags. Reading the first Assisted-by line of each tagged commit, 857 (45.7 percent) named a Claude model, 302 (16.1 percent) a GPT, Codex or OpenAI model and 199 (10.6 percent) a Gemini model; the rest said only LLM or used other wording. These are self-reports from one commit in ten and no guide to market share, but they show what was lost: a field that let anyone count which tools contributors say they use.

What the tag could not see

Contributors who used LLMs and did not tag

LWN’s account of the Summit gives the maintainers’ own estimate of the gap. Jonathan Corbet, writing in the first person, reports telling the room that “huge numbers of contributors are not placing those tags despite using LLMs,” sometimes from ignorance of the rule and “other times contributors want to actively hide their LLM use,” while “few maintainers are asking contributors about LLM use and ensuring that those tags are present.” The conclusion LWN records is “As a result, Assisted-by provides no useful signal.” LWN reports Airlie saying that probably 90 percent of contributors are using LLMs now, many fearing an anti-LLM witch hunt, and Torvalds thinking many submitters were “simply ashamed to admit that they were using those tools.” It adds that Gleixner suggested, “not entirely seriously,” a Not-assisted-by tag instead.

Set beside my counts, the estimates fit. Of the 3,136 authors in the release, 13.8 percent had tagged anything, against an estimate that most contributors use LLMs. That comparison is mine and loose, since one number counts tag users and the other estimates LLM users, but if the 90 percent is anywhere near right, most contributors who use LLMs never used the tag.

Credit that lives in other trailers

The history also holds AI involvement that the tag never covered. Sashiko, the automated patch review system LWN describes, is named in 537 of the 18,533 commits (2.9 percent), 301 of them with a Reported-by line naming it, and 448 of those 537 carry no Assisted-by tag. These credit a tool with finding a problem, the case generated-content.rst says should be noted in the changelog. LWN adds that Sashiko’s developer has changed it to leave pre-existing bugs out of patch reviews and store them in a separate database, which may change how often such credits appear.

Plain prose is the other channel, and it is thin. I read the 53 untagged commits in 7.3 through -rc7 whose messages contain an AI-related word somewhere other than a Signed-off-by, Reviewed-by, Acked-by, Reported-by or similar line. Of those, 33 describe a tool finding or writing part of the change; the rest were product names such as BeagleY-AI and Gemini ethernet, or documentation about the policy itself. Eleven of the 33, all in Intel’s graphics drivers, carry the same sentence, “Discovered using AI-assisted static analysis confirmed by Intel Product Security.” Others say a bug was “found by an AI coding assistant (Claude Code)” or “caught by LLM,” one credits “AI Mode in Google Search” in an Analyzed-by trailer, and one carries a Co-authored-by trailer naming Cursor. The 33 are 0.20 percent of the 16,656 untagged commits. Whatever the new guideline produces in prose, the history today offers almost no baseline for it.

The most prominent example is Torvalds’s own. A fix committed on August 20 for an Intel Xe graphics bug, which shipped in 7.3-rc1, carries no Assisted-by trailer but a bracketed note saying the debug session was “enormously helped by an AI doing much of the grunt-work” and ending “I let the AI write the commit message above.” The note is the form of disclosure that the surviving guideline describes, written in the changelog rather than in a trailer.

Two reports sit oddly beside it. LWN says there was “general agreement” at the Summit that, even if an LLM writes the code, the changelog should be written by the human behind the work, while Torvalds told the column’s author that arguments against using AI for commit messages are “entirely misguided.” And LWN’s summary of Torvalds’s remarks says Torvalds “hadn’t used one on the kernel until last week,” while Tom’s Hardware calls a later patch series, for cache contention when many CPUs read the same file, Torvalds’s “first LLM-assisted patch.” Those accounts may mean developing a patch series rather than debugging, and I could not check Torvalds’s own wording, but the history shows an AI-assisted fix seven weeks before the Summit. Without a trailer, that kind of use is easy to miss.

No agent sign-offs in the merged history

One rule that remains looks respected in the merged history. I scanned 36,163 Signed-off-by lines in 7.3 through -rc7. Ninety-nine matched an agent-like word or address, and every one was a human name, several with addresses at AI companies. I found none that identifies an AI agent as the signer, which is what “AI agents MUST NOT add Signed-off-by tags” asks. The history only contains merged commits, so this says nothing about patches that were rejected.

The pressure behind the decision

Torvalds told The Register that the kernel has “two independent AI problems”: a large codebase in which AI finds real bugs and so adds work for overworked maintainers, and people who use AI to generate patches without understanding the code. The tag was meant as a triage signal, a way for maintainers to review LLM-assisted patches accordingly, and the Summit concluded that it was not working as one. Both problems have a record on this site. A Harvard study of 718 firms found AI coding agents raised code output while pull requests waited longer to merge, Anthropic’s OSS Scanner emails maintainers model-generated vulnerability reports with no human review, and as of October 23 a Linux kernel local-root bug had public exploit code and no merged fix. LWN reports that Kroah-Hartman said many more security findings are coming and that the next year of work will be focused on working through them.

Where the disclosure goes now

A cover letter is the introductory message of a patch series on a mailing list. The kernel merges the patches, not the letter, so unless a maintainer copies the letter into a merge commit, which I did not measure, the text does not enter the commit log. The shift is from a structured trailer that anyone with a clone could count to free-form text on lists, whose archive at lore.kernel.org turned away my scripted requests. The maintainers’ reasoning is that a cover letter can describe what a label cannot. LWN reports that “Maintainers still want to know if there is a human involved in the development process,” and the commit message says a cover letter can describe how the tools were used. For researchers and downstream consumers it means that after this cycle the main machine-readable AI signal in kernel history is likely to be the credits for tools that find bugs, plus whatever contributors keep adding voluntarily.

What this means in practice

If you read kernel history to estimate AI use

Treat an Assisted-by count as a floor with a narrow meaning: willingness to label under a rule that few maintainers enforced. The 10.1 percent was never the AI share, and the maintainers said so themselves. If a compliance, provenance or research process in your organization counts these trailers, plan on the count likely changing meaning after this cycle. Mailing-list archives, credits to review bots in Reported-by lines and prose passages in changelogs are the remaining sources, each with its own gaps, and no single one will give a number.

If you contribute upstream

The human submitter’s responsibility did not change. Sign off yourself, never let an agent do it, and be ready to explain every line. The transparency guideline asks what tools were used, what input they were given, which portions of the content they affected and how the result was tested; put that in the cover letter and, where a tool found the problem, in the changelog. The guideline says to expect scrutiny in proportion to how much was generated, and LWN reports that Torvalds and others “repeatedly said low-quality contributions from new developers should receive low priority.”

If you run a project that is thinking of copying the tag

The kernel’s experience is a compact lesson about self-reported labels. A required tag with little enforcement ended up recording the contributors who chose to follow the rule: 13.8 percent of authors, under a rule that few maintainers checked. The commit message frames the choice as one between “finding a way to enforce the requirement and dropping it.” If the signal matters to you, the options are enforcement, such as a required field or a check in the submission flow, or a channel that does not depend on the contributor, such as a bot credit like Sashiko’s Reported-by line. The kernel dropped the tag and relies on prose for the rest.

What to watch next

A merge window usually runs two weeks from the previous release, but LWN reports that Torvalds was considering a third week because of a two-week vacation, so the 7.4 window may close around November 1 or November 8. Commits applied after the removal land mostly in 7.5. If the removal reduces use, the tagged share of 7.5 should fall below the 14.5 percent of the 7.4 window; if it stays near that level or climbs, contributors kept the label for their own reasons. The count is cheap to repeat. This is the clone and the loop I used:

git clone --filter=tree:0 --no-checkout --shallow-since=2025-11-15 --single-branch --branch master https://github.com/torvalds/linux.git linux
cd linux
for r in v6.19..v7.0 v7.0..v7.1 v7.1..v7.2 v7.2..v7.3 v7.3..HEAD; do
  echo "$r $(git rev-list --no-merges --count $r) $(git rev-list --no-merges --count -i -E --grep='^[[:space:]]*Assisted-by:' $r)"
done

Each line is the range, the number of non-merge commits and the number whose message has a line starting with Assisted-by:. This is the output from my snapshot, where the clone is about 65 MiB. The last line moves as the 7.4 window fills.

v6.19..v7.0 14156 31
v7.0..v7.1 15850 294
v7.1..v7.2 16418 1110
v7.2..v7.3 18765 1933
v7.3..HEAD 14503 2107

The bottom line

The kernel did not stop asking contributors to say where AI came from. It stopped asking for one label, at the highest share that label had reached, because the label told maintainers little about the many contributors who never used it and few maintainers were checking. What remains is a transparency guideline whose compliance has not yet been measured, written in prose that git history mostly cannot hold, plus structured credits such as Sashiko’s for tools that find bugs. For anyone tracking AI in open source, the useful numbers are the denominators: 3,136 authors of whom 13.8 percent used the tag, 33 prose mentions among 16,656 untagged commits, and 537 commits that name a review bot. A future claim about the share of kernel code that AI wrote should be tested against them, and the cheapest test is to repeat the count after 7.4 and see whether the tag outlives its rule.

Sources and method

I read the removal commit, Brauner’s simplification and Levin’s original document commit with their diffs through GitHub’s commit API, and I read generated-content.rst and coding-assistants.rst at the snapshot commit from my clone, plus coding-assistants.rst at v7.3 for the earlier text. For the Summit I read LWN’s report by Jonathan Corbet (October 12) in full, apart from the reader comments. I also read Phoronix’s October 13 report, The Register’s October 23 column and Tom’s Hardware’s report on a Torvalds patch series. lore.kernel.org blocked scripted requests, so I did not read the mailing-list thread itself.

My counts come from a clone of torvalds/linux made with --filter=tree:0 --shallow-since=2025-11-15, which held 85,422 non-merge commits at the snapshot, commit 21a7f44fd076, committed October 24, 2026 at 20:11 in a UTC-10 time zone. I read every message with git log. Release windows come from tags, and the 7.4 window is v7.3..HEAD at the snapshot. I left out the 6.19 window because the clone starts before most of that cycle’s commits were applied (only 5,471 are present). Authors are name plus lower-cased address, so a person with two addresses counts twice, and a case-sensitive count of the same pairs gives 3,141 rather than 3,136. Subject-prefix groups use the text before the first colon or slash. Format and family counts use the first Assisted-by line of each tagged commit, with families assigned by the first keyword matched in this order: claude or anthropic; gpt, codex or openai; gemini; copilot. I read by hand the 53 untagged commits with AI-related words outside the usual sign-off and credit trailers and counted 33 as describing a tool’s role; that classification is mine. The Signed-off-by scan used a pattern for agent-like words and addresses over 36,163 lines. Only merged commits are in git history, so none of this describes patches that were never merged, and nothing here measures how much code AI wrote.

What I could not check: the private notes from Torvalds that The Register’s column quotes, the 1,884 figure, how often cover letters reach merge commits, and whether use of the tag falls after the removal. The last one will only show in the next releases’ history.