---
title: 'In the News: September 21, 2026 (Midday)'
description: 'A widely shared figure for AI-written Linux kernel patches says one thing in its text and another on its own chart.'
canonical_url: 'https://darkfactory.dev/news/2026-09-21-midday'
markdown_url: 'https://darkfactory.dev/news/2026-09-21-midday.md'
collection: news
date_published: '2026-09-21T12:16:19-04:00'
date_modified: '2026-09-21T12:16:19-04:00'
---

# In the News: September 21, 2026 (Midday)


A figure circulating since last night puts AI-generated code at 17.25% of Linux kernel
patches this month. The chart attached to that claim labels the same data "Patches
Assisted By AI LLM". Assisted and written by are not the same measurement, and nothing in
the post says which one the number counts. Also today: a frontier coding model priced at
the bottom of its class, and a spec-workflow tool whose verification command turns out to
be off by default.

## 1. A kernel-patch figure that contradicts its own chart

**[In September, AI generated code has made up 17.25% of all Linux Kernel patches](https://x.com/LundukeJournal/status/2101841277432070210)** · The Lunduke Journal · X, September 20, 2026

The post reads, in full: "Yet *another* record week for AI development of Linux. Last week
there were 1,634 code submissions to the Linux Kernel which were written by AI. So far, in
September, AI generated code has made up 17.25% of all Linux Kernel patches." Two charts
are attached. The first carries the title "Patches Assisted By AI LLM / Week" on the image
itself, a weekly bar series legible from late February to late August and rising over that
span. The second is a monthly percentage series, cropped in the carousel, legible at 0.33%
for February and 0.83% for March. The post states no method for classifying a patch and no
denominator. At 12:15 EDT on September 21 it showed 5,048 views, 85 likes and 11 reposts.
The [Hacker News thread](https://news.ycombinator.com/item?id=49784366) carrying it stood
at 31 points against 71 comments at 12:17 EDT, more than two comments for every point,
which is what a contested claim looks like rather than an endorsed one.

**Why it matters:** If you are trying to work out how much accepted upstream work agents
are actually doing, this is the number people will cite at you. The gap between the prose
and the chart's own label is the whole question. A patch a human wrote with completion
assistance and a patch an agent produced end to end are different facts about software
production, and one count cannot stand for both. Ask what the classifier was before you
repeat the percentage.

## 2. A frontier coding model at $2 and $6 per million tokens

**[Introducing Grok 4.7](https://x.ai/news/grok-4-7)** · SpaceXAI · September 21, 2026

SpaceXAI released Grok 4.7 today at "$2 per million input tokens and $6 per million output
tokens", the same price as Grok 4.6, with a fast variant at twice the output speed and
twice the price. The release page says the model is available in Cursor and Grok Build, and
through the Grok API, "third-party coding harnesses, and model routers and cloud
platforms". The vendor's own comparison table sets those prices against $4 and $20 for
GPT-5.6 Sol and $10 and $50 for Fable 5.1. On the same table, Grok 4.7 scores 46.3% on
CursorBench 4.0 and 38.0% on Terminal-Bench 4.0, against 51.8% and 57.9% for Fable 5.1, and
71.0% at high effort on DeepSWE v1.1 against 72.7% for GPT-5.6 Sol. Every figure here is
the vendor's. SpaceXAI describes the training as "a longer reinforcement learning run on a
harder mix of tasks, weighted toward problems that take many hours to complete".

**Why it matters:** The claim on the page is price-performance, and the vendor's own numbers
support that reading rather than a frontier-capability one: level with Grok 4.6 at the
bottom of the four on both token prices, behind Fable 5.1 on two of the three coding
benchmarks it publishes. For anyone routing a harness by cost per completed task rather
than by leaderboard position, that is the trade to price out this week.

## 3. OpenSpec ships its verification command off by default

**[OPSX Workflow](https://github.com/Fission-AI/OpenSpec/blob/main/docs/opsx.md)** · Fission-AI · project documentation, read September 21, 2026

OpenSpec's front page presents the `/opsx` loop with a verify stage among its commands. The
project's own documentation adds a qualification the front page does not: "By default,
OpenSpec uses the core workflow profile (propose, explore, apply, update, sync, archive).
If you want the expanded workflow commands (new, continue, ff, verify, bulk-archive,
onboard), configure them with `openspec config profile` and apply with `openspec update`."
The command table lists `/opsx:verify` as "Validate implementation against artifacts
(expanded workflow)". The same document describes apparatus the front page leaves out:
artifacts form a directed acyclic graph, state is read from whether a file exists on the
filesystem rather than held in a phase variable, and the stated principle is "Dependencies
are enablers, not gates".

**Why it matters:** A verification stage you have to opt into is a different adoption story
from one every installation gets. If you were counting OpenSpec as evidence that
spec-conformance checking is spreading as a default convention, the count is smaller than
the front page suggests. The part that does ship by default, a dependency graph that
reports readiness from the filesystem instead of from a declared phase, is the more useful
piece of harness design in the documentation.