---
title: 'In the News: September 21, 2026 (Extra 2)'
description: 'Six weeks of wire-log capture finds the highest effort settings delivering a median of 123 thinking tokens per model invocation.'
canonical_url: 'https://darkfactory.dev/news/2026-09-21-extra-2'
markdown_url: 'https://darkfactory.dev/news/2026-09-21-extra-2.md'
collection: news
date_published: '2026-09-21T17:10:00-04:00'
date_modified: '2026-09-21T17:10:00-04:00'
---

# In the News: September 21, 2026 (Extra 2)


A practitioner instrumented six weeks of his own Claude Code traffic and found that the
effort level he selected was not the reasoning he received. At the two highest settings,
half of 43,007 measured model invocations returned no more than 123 tokens of
uninterrupted reasoning, and 39.2% returned none at all. Also today: Linear's account of
what happened to its continuous integration once agents were writing most of the code.

## 1. The effort setting you pick is not the reasoning you get

**[The Inference Gap](https://x.com/Lon/status/2101034933284417614)** · Lon Lundgren, previously Microsoft Research and Amazon Research · X, September 18, 2026

After a perceived drop in Fable 5 quality following Anthropic's July 17 announcement that
the model would stay on subscription plans from July 20 onward, Lundgren started reading
the minified Claude Code source on July 30 and by August 1 had built what he describes as a "semantically aware proxy that
began transparently collecting live data from the wire". The resulting corpus covers 43,261
Fable 5 invocations at xhigh and max effort, with thinking totals quantified for 43,007 of
them, plus 7,853 complete assistant turns, across 65 active-usage days between July 1 and
September 7, taken from three machines, two subscription accounts, 25 project groups and
213 recorded sessions. Anthropic's own documentation, as quoted in the article, describes
xhigh as Claude "always thinks deeply" and max as "always thinks", with no constraint on
thinking depth. The measured distribution: "Half of all invocations delivered no more than
123 tokens of uninterrupted sequential thinking. In 39.2% of invocations, the model
performed no thinking at all." Comparing July against August five different ways, to stop
busy days or large projects dominating the result, the median decline in delivered thinking
runs from 21.9% turn-weighted to 50.6% at the invocation level. Lundgren is explicit about
what he has not shown. Nothing in the article "proves that a release or announcement caused
a nearby change, nor does it establish whether behavior arose from capacity management,
policy changes, routing, adaptive effort logic, or some other internal mechanism."

The finding that bears hardest on fleet work is the fragmentation table. As a turn's total
thinking grows, the longest single invocation inside that turn accounts for less and less
of it: 99.9% of the total at 2,048 turn-level thinking tokens, 26.0% at 32,768, and 12.1%
at 131,072. Lundgren's reading is that adding breadth does not buy back depth. "Parallel
sampling is not serial depth. A configured ceiling is not realized consumption." Of the 105
turns in the corpus that reached at least 48 invocations, every one contained calls
delivered zero thinking tokens. The collection and analysis code is not published. The
article says it "is not yet packaged cleanly enough for release", and that the measurements
are now defined well enough for other people holding reasoning-token traces to run the same
questions against their own data. A [Hacker News
thread](https://news.ycombinator.com/item?id=49789224) on the September 20 summary of this
work stood at 283 points against 187 comments at 16:57 EDT on September 21.

**Why it matters:** If the reasoning delivered behind an unchanged effort setting moves
week to week, a harness result cannot be attributed to the harness. Your evals, your
regression triage and your verification loop are measuring the model and the delivered
inference regime at the same time, and only one of those appears in your changelog. The
move on offer here is a reframe rather than a fix: when quality drops, ask what regime you
were served instead of asking whether the model was changed. This is one person's traffic
against one vendor, and the cause is not established. The absence of any published figure
that would settle it is the part worth carrying.

## 2. Linear rebuilt its CI after agents outran it

**[AI coding has made CI a bottleneck, so we reworked ours to keep up](https://linear.app/now/ci-bottleneck-reworked)** · Mufeez Amjad, Linear · September 21, 2026

Linear's CTO assigned Amjad an issue titled "CI costs are high" earlier this year, and
wanted CI faster while he was at it. The post reports the outcome in first-party numbers:
test suites have almost quadrupled since the start of January, and over the same period
pull request wait time fell from more than six minutes to just over five, with runner time
per test roughly halved. The individual wins are itemized. Moving off GitHub Actions to
third-party runners made jobs 34% faster on average in a like-for-like comparison of the
two days either side of the switch, with `tsc` down 52%. Switching to the native TypeScript
compiler cut the weekly median `tsc` check by 73%. Rewriting custom lint rules to work on
the syntax tree instead of type information let ESLint drop TypeScript entirely, cutting
API lint time 68% and full-repository lint 55%. Capping fetch depth on change-detection
jobs took the slowest of those gates from 94 seconds to 20. Consolidating seven small
checks into two jobs saved roughly 87,000 runner-minutes a month on June usage, 11.8% of
total CI spend. The single largest saving, about 17% of monthly cost, came from an opt-in
Vitest project running with `isolate: false`, which dropped the slowest shard from between
300 and 379 seconds down to about 195. The [Hacker News
thread](https://news.ycombinator.com/item?id=49792067) on the post stood at 49 points
against 27 comments at 16:57 EDT on September 21.

That last change is also the one Amjad flags as carrying the highest correctness risk, and
the way Linear contained it is the part with the widest application: "because agents now write
the majority of our tests, we updated our respective agent skills to account for this
performance opt-in as well, so generated tests follow the same constraints by default." The
repository is currently adding roughly 2,000 tests a week. Without this year's work, the
post estimates, the suite would now take about 11 minutes rather than the five developers
wait today.

**Why it matters:** Writing the code stopped being the slow step here, validating it became
the slow step, and the fix was ordinary infrastructure work rather than anything
agent-specific. The transferable part is the coupling at the end. A performance optimization with real correctness risk had to be
written into the agent instruction surface, because the thing generating the tests is the
thing that has to honor the constraint. If your test suite is growing at a rate set by
agents, your CI budget and your agent instructions are now one system, and changing either
alone will not hold.