🌐 Read this issue on the web

This issue arrived about 2 hours later than usual today — apologies for the delay.

At a glance

1. Changing the model behind your coding agent is not a one-line config change. It is waiting for your tool layer to add the row that says which tool conventions this model expects. In the weeks before that row lands, success rates genuinely fall.
2. Three separate groups of outside researchers measured OpenAI's flagship doing heavy computation even when it writes no reasoning. And the ruler the vendors use to certify that their models are bad at hiding their reasoning was shown, the same week, to seriously undercount.
3. What deserves a discount on the vendor's scorecard is the presentation, not the capability. Three flaws, two of which OpenAI concedes in its own documents.

This issue draws on the research report written in the small hours of September 13 and the deep dive produced the same day; the material spans May 11 to September 13. Last night's sweep covered 19 pieces, and 19 clickable external receipts made it into this issue. This is the email edition; the full edition of this issue is the archive of record.

This week's column: Claims & Receipts

The claim under review this week: Google's in-house TPU beats Nvidia by up to 50% on performance per dollar, and the CUDA moat is shrinking. The receipts say: unresolved. A TPU is the AI chip Google designs for its own data centers. CUDA is the software ecosystem around Nvidia's graphics processors, and the moat is the layer of advantage that makes it hard for anyone else to displace. The claim comes from SemiAnalysis, the most-cited independent research house in semiconductors and compute infrastructure. Founder Dylan Patel and the firm's institutional account posted it on the same day, September 7 (@dylan522p, 2026-09-07; @SemiAnalysis_, 2026-09-07). Our September 8 issue cited that number. Today we take it back to the original text and check it.

The arithmetic is right. The problem is that the conditions stayed in the body and never made it into the headline. We read the full free section of that newsletter. All five parameters that decide whether two chips are comparable can be pulled out of it: the hardware, the model, the numeric precision, the workload and the serving mode. That is harder evidence than most benchmarks on the market offer (SemiAnalysis, 2026-09-07). But the 50% belongs to one point on the curve: 20 tokens per second per user at 256 concurrent streams. Move to 100 tokens per second and the advantage drops to 19% and 34%. Those two figures measure one thing, the TPU's performance-per-dollar edge over the B200 and B300, Nvidia's two comparison chips. They are not readings from two different operating points. Move to a 20-second median response and the edge is 8% and 25%. Around a 30-second median response, Nvidia's B200 wins outright. The newsletter says so itself: across most of the performance curve, the TPU does not beat Nvidia, and what pulls the conclusion back is total cost of ownership.

And that total cost of ownership is the research house's own estimate, not a Google price quote. The variable that flips the conclusion has the same author as the conclusion. The newsletter also thanks 15 Google engineers by name, and the software the benchmark ran on was written by Google for this exercise. Disclosing that is better than hiding it, but public is not the same as independent. As for the half about the moat shrinking, the body measures the opposite direction. In the comparison where both sides split the two phases of an answer across different chip pools, Nvidia still leads.

How to use it: when someone shows you a performance-per-dollar comparison, first ask which point on the curve it comes from. Which chip is cheaper for inference flips with tokens per second and with response time. Map your own service target onto the curve first, then ask the vendor for the reading at that point. What would prove this wrong: TorchTPU, a public software stack, is due out in mid-October. If a third party with no working relationship with Google reruns the same workloads on it and gets the same direction, we change this to holds.

Which claim should we check next? Reply and tell us

Today's main line

1. [Evidence update] (first observed July 4) The new Claude models, plugged into someone else's tool layer, invent fields that layer never defined. We found where the report came from and where the fix is. What it really rewrites is the number procurement should be measuring

One definition first. The tool layer is everything wrapped around a model when you run an AI agent: it tells the model which tools exist, what parameters each one takes and how to retry on failure. Claude Code is Anthropic's own command-line coding tool. Pi is a third-party project of the same kind.

In late August a second-hand account circulated: hooked up to Pi, the new Claude models would produce parameters like requireUnique, matchCase and oldText2, which Pi never defined. Last night we folded that account together with a separate benchmark run into one judgment. Rechecking today, both the origin and the mechanism have to change. The origin was misattributed. Those three parameter names are not August news. They are the exact words of a July 4 blog post by Armin Ronacher, the author of the Flask web framework (Armin Ronacher, 2026-07-04). The mechanism is more specific than what we wrote last night, and more fixable. The extra fields the model writes use the other tool's naming style combined with its own tool's rules. Ronacher's own explanation is not that the model memorized its home field names. It is that Claude Code's editing tool "silently filters out unexpected keys and it does not use strict mode either," so during training the model was never penalized for writing an extra field. In his words, "The harness fully absorbs the error and there is little gradient against inventing an alias, adding a stray field or using a nearby parameter name."

The core call: models can be swapped, but the swap is not a line of config. It is a row in a table. Each row says which tool conventions this model expects inside your tool layer, whether strict mode is on, and how long after a new model ships the row gets added. The extra-field bug itself is one switch away from fixed, so it does not prove that switching always degrades results. What it proves is that the tool layer has to maintain that table for every model it supports, and the weeks when the table lags a new model generation are exactly the window in which degradation really happens.

Verification: all three links in the chain can be checked by anyone. The mechanism now rests on a primary blog post plus a public code-tracker thread, not a second-hand relay. The vendor's own account is in black and white from OpenAI: its official guide states that "GPT-5.1 has been post-trained on specific tools that are commonly used in coding use cases," and gives a number. Using the officially defined tool type, rather than a hand-written function that does the same job, "decreased apply_patch failure rates by 35%" (OpenAI official guide, 2026). On the Anthropic side, we did not find an equivalent sentence in its text-editor tool documentation, and we record that as is. But its interface does offer strict mode: mark a tool definition strict and the model's output is constrained by grammar to match the definition, and the supported list covers both models reported to have the problem (Anthropic official documentation). One more correction: the 4.6-percentage-point gap we cited last night cannot be used. That benchmark has 113 problems, and the sampling error of a single run is itself 4.6 percentage points, so the gap between the two evaluators carries zero information about any cause. In its place, the same public run log has a harder number: 11 of 113 attempts were aborted because the model returned no tool call three times in a row, and the log itself says those were "tool-call format errors rather than reasoning deficits" (public per-problem log). ⚠️ One thing we cannot measure: strict mode fixes extra fields. It does not fix different habits. A model may respond by splitting work across more calls or stuffing more into the context, and whether that layer carries a success-rate cost has not been measured by anyone.

Judgment update: one of our standing records says the model and the tool layer cannot be separated in measurement. Another says control sits at the configuration entry point. What was missing was the causal link between them. Today fills it in, and in the opposite direction from last night's version: it does not weaken "control sits at the configuration entry point." It makes that claim concrete, because the table is maintained by the tool-layer vendor, not the model vendor. So the number to measure changes too. It is not a cross-tool-layer model ranking. It is the tool-call format failure rate of one model inside your own tool layer, like those 11 aborts above: you get it from a single run, with no need for anyone else's leaderboard. A tool-layer vendor that claims to support many models but cannot tell you which tool conventions each model uses, what the strict-mode default is, and how long a new model waits for its row is multi-model at the interface, not in behavior.

Investor note: the prevailing narrative assumes models are interchangeable at will, so value stays in the model layer and the tool layer is a thin adapter. This evidence weakens that assumption, and the gap is concrete: switching cost is not zero. It is a table maintained by a third party with an update lag, and the lag belongs to the tool-layer vendor.

What would prove this wrong: someone runs the same problem set on any third-party tool layer with strict mode off and then on for the same model, and edit success still lags the native tool layer clearly after strict mode is on. That would break the narrowing to "one switch fixes it." Second, if someone publishes an invented-field rate near zero for a new-generation model on the original tool definitions, then "the new generation is worse" is noise from a single generation. Verdict date: November 12, 2026.

The long-form version of this piece is today's deep dive.

2. [This week] (published September 12) Three groups of researchers who do not know each other measured Astra doing heavy computation without writing its reasoning, and the ruler the vendor uses to certify itself was called out, the same week, for seriously undercounting

Our September 10 issue covered the first outside measurement. What is new today is three more groups, plus something more awkward. GPT-6 Astra is OpenAI's flagship model, and its official system card of September 3 concedes that chain-of-thought monitorability has declined. The chain of thought is the reasoning a model writes out before answering. Humans can read it, which is what makes it monitorable. If the model can finish without writing it, monitorability falls. Today's three readings come from a long piece by Zvi Mowshowitz, an independent AI commentator, who transcribed word for word three measurements posted on LessWrong, the AI safety community's forum (Zvi Mowshowitz, 2026-09-12). The first group prepended a string of meaningless characters to the prompt and demanded an immediate answer. Accuracy on multi-step reasoning rose from roughly 10% to roughly 50%, and on old math-competition problems from roughly 60% to roughly 90%. If the model reasoned only through its written thoughts, filler characters should do nothing. That they help means computation is happening somewhere that is not written down. The second group estimated how long a task the model can complete with no written reasoning: 15 to 40 minutes. The same two researchers had earlier predicted no more than 7 minutes by the end of 2028. The third group compared scores with reasoning on and off. The previous generation's equivalent model lost 35 points. Astra lost 10.

The same week brought a second thing, and it lands directly on a number we printed on September 10. That day we published a set of CoT-Control readings. CoT-Control is a benchmark that measures whether a model can deliberately rewrite its reasoning trace to evade monitoring. Open-weight models scored between 0% and 13%. On September 11, a small independent experiment on the Alignment Forum, the AI alignment research community's forum, argued that those scores may be seriously undercounted. Simply using better prompts raised open-weight models' scores by two to three times or more. GPT-OSS-120B, the open-weight model OpenAI released, went from 5.5% to 15% (Alignment Forum, 2026-09-11). Both OpenAI and Anthropic have used this ruler in recent system cards to argue that their models are bad at concealing their chain of thought.

Verification: the two halves sit at different evidence grades, so we separate them. For the three measurements, we did not open the three original posts today. We only checked that the transcription matches the local full text. What carries weight is "three independent methods, one direction," not any decimal point. ⚠️ Nor are the three fully independent: two of them start from the same estimate, and that estimate traces back only to OpenAI's own report. For the undercount experiment, the credits and debits both need saying. The author uses a pseudonym, the work is not peer-reviewed, each mode has only 50 problems, and it tests open-weight models only, so it cannot be read as "Astra's number is undercounted too." On the credit side, its direction runs against the author's own position. He is asking the safety community to mark down a measurement it relies on, and he writes explicitly that he does not think this overturns the bottom-line conclusion that current models mostly still cannot consistently evade monitoring. He is not alone in raising the concern: Anthropic's own system card records UK AISI, the evaluation body set up by the British government, making the same point, that this ruler is highly sensitive to prompts.

Judgment update: when we recorded on September 4 that the cause of Astra's monitorability decline is disputed, we wrote an expiry condition: everyone involved was making claims, not measurements. Today that condition expired on one side. The skeptics now have three measurements. The first-party claim that the cause is "the model got smarter" still has none. We still do not rule on the cause, because none of the three directly measures it. Nobody has taken one model and switched an architectural component on and off as a control. What you can actually take away today is the second thing: the ruler the vendors use to certify themselves can be moved by prompt quality, so a guarantee of the form "we tested it and the score was low" does not stand until you know the elicitation strength. Elicitation strength means how hard the researchers pushed the model, through prompting, to show the behavior. When you receive that kind of guarantee, the questions to ask are who wrote the prompts and whether anyone tried pushing the score up with better ones.

What would prove this wrong: if someone reruns the same CoT-Control benchmark on both closed and open-weight models with a fixed, published, word-for-word reproducible set of prompts, and the scores stop jumping when the prompts change hands, then "this ruler is moved by prompt quality" should be withdrawn.

Investor note: the prevailing narrative assumes that frontier labs' safety claims are backed by checkable measurements. This evidence weakens that assumption. The gap is that nobody has published the elicitation strength behind these measurements, and that is one of the independent variables behind the score.

Also happened — not verified by us yet

1. [This week] (released September 12) DeepSeek released V4.1-Flash, which splits reading input from generating output and gives each a different parameter budget: 8 billion parameters active while reading input, 16 billion while generating output, roughly 750 billion in total, under an MIT license (official model page). ⚠️ We first read these documents this morning and they have not been through our own verification yet. But one thing can already be settled: aggregator summaries read this release as "DeepSeek is retiring the old flagship, V4 Pro," and the official pricing page says the opposite. V4 Pro stays in service after September 14 with billing unchanged (official pricing page). ⇒ When you see a relay saying a vendor is killing a product, glance at its pricing page. That check costs almost nothing.
2. [This quarter] (recorded August 31) An investor conversation pointed at a structure outsiders cannot see: a frontier lab's revenue is not whatever customers want to spend, it is however much compute the lab decides to sell. Take the same 10 gigawatts of compute and flip the split between inference and training, and annualized revenue goes from $480 billion to $120 billion. ⚠️ Those figures are assumptions the speaker introduced on the spot with "let's just assume." They are not measurements, and the two speakers have no surnames in the transcript. The only thing to take away is the structure: when you grade a lab on revenue growth, you are grading a number whose denominator you cannot see (a16z Podcast, 2026-08-31).
3. [This week] (published September 12) The September brief from Epoch AI, an independent research institute, offered several readings we have no comparable figure for. The one most worth remembering: the record for the largest power capacity in a single data center doubles every ten months. ⚠️ We read this brief for the first time today and have not checked its method. It also discloses that its Astra benchmarks ran on pre-release access provided by OpenAI. It volunteered that, and it is exactly one of the fields the checklist in item 5 below asks for (Epoch AI, 2026-09-12).
4. [This week] (interview September 12) The founder of a Japanese compute provider that markets itself on "sovereign AI" says it has 8 megawatts in operation, hardware from three chip vendors running side by side, and 90% of revenue from the United States and Europe. ⚠️ Every scale figure is self-reported. The interviewer himself writes in the piece, "that could just mean a single rack!" We have no third-party reconciliation (More Than Moore, 2026-09-12).
5. [This week] (published September 12) The same long piece breaks Astra's scorecard into three items you can check one by one, and two of the three are things OpenAI concedes in its own documents (Zvi Mowshowitz, 2026-09-12).

Chips & semiconductors

[This week] (press release September 8) Qualcomm's official press release fills in two things the regulatory filing left out: the purpose is inference, and optical interconnect goes up to 1.6T. The word Trainium does not appear anywhere in it. When we recorded the Qualcomm and Amazon deal on September 9, all we had was the regulatory filing, which was entirely about money and said nothing about purpose. So we wrote at the time that we could not tell whether this is a supplier to AWS's in-house chip line or a third path. Today's official release describes the collaboration as three things: custom silicon explicitly limited to inference, not training; optical connectivity solutions "extending up to 1.6T" that will use Qualcomm's serializer-deserializer and optical signal-processing technology; and, in the other direction, Qualcomm buying more AWS services for chip design (Qualcomm official investor press release, 2026-09-08). ⚠️ Three flags: 1.6T is "extending up to," a ceiling, not the current state; the release names no amount, no product and no timeline; and Trainium, the name of AWS's in-house chip line, never appears. ⇒ The question is still open today, but there is now a checkable way to tell: find out whether Qualcomm's serializer-deserializer parts end up in the same racks as the existing suppliers to AWS's in-house line.

Named commentary

[This quarter] (retrospective, originally posted August 23 to 24) Two people, neither of them an industry spokesman, used arguments that do not overlap at all and reached the same policy conclusion in the same week: blocking data centers does not slow AI. This column has no new named view this week; the pick is an older item that matters. Arvind Narayanan, a professor of computer science at Princeton and co-author of AI Snake Oil, proposed a conversion: translate "how many gigawatts of data centers were blocked" into "how long was AI progress delayed." His answer is that a typical one-year state-level building ban in the United States is worth about 5 to 10 hours, and a total ban across New York State less than a day (Arvind Narayanan, 2026-08-24). The conversion is clever because nobody has an intuition for "1 gigawatt blocked," while "how long until efficiency gains claw that compute back" has one. ⚠️ Three qualifiers travel with it. He writes plainly that he "used AI for the analysis and did some spot checks," so 5 to 10 hours is an order of magnitude, not a precise value. He also says explicitly that the local environmental effects are "a highly contested topic that I won't comment on here," so this is not evidence that bans are unjustified. The most fragile assumption is that 90% of blocked capacity gets rebuilt elsewhere. We checked his key parameter ourselves. He puts inference efficiency at 5x per year, and his text does refer to the inference side. Against an inference-side price benchmark, the unit price of GPT-4-level capability fell from $50 per million tokens to $0.14 in about two and a half years, an annualized rate of roughly 11x, so his description of 5x as conservative holds. The training-side benchmark is a different figure, measured by Epoch AI: the compute needed to reach the same performance halves roughly every 8 months. Even if you misapplied that benchmark, the delay would only grow by a factor of 1.55. The order-of-magnitude conclusion is not sensitive to this parameter. The same week, Miles Brundage, formerly head of policy research at OpenAI and now founder of an organization for external AI audits, reached the same conclusion from the other direction: a national building ban is a bad idea, for safety reasons. A ban would hurt the "basic safety, security, and auditing requirements," which he notes "we essentially still don't have" (Miles Brundage, 2026-08-23). ⚠️ His "it will not happen" refers to a national ban. State-level bans have already happened, and his post does not separate the two layers. Which of our calls it supports or rebuts: all four pieces of material on our data-center-ban thread are counts of political events. This is the first one to give an effect size. The operational conclusion is direct: delete "regulation will slow my competitors down for me" from your deck. The system-level effect is measured in hours. What is actually rising is the probability that your own project fails to get a permit, and that has to be modeled as a permitting probability, not as schedule slack.

Model watch

1. [Trend] (paper dated 2026-05-11, checked by us September 13) A benchmark built from knot diagrams pins frontier vision-language models' failure to a named gap: they can see what is in the picture, but they cannot work forward a few steps from it. It is being discussed now because the community only dug it up this week. The benchmark is called KnotBench. Its corpus is 858,318 knot diagrams drawn from 1,951 prototypes, and scoring is tied to a standard external library used across mathematics rather than the authors' own rubric, so it is immune both to memorized answers and to authors grading themselves up. The results: of 56 task-by-model cells, 15 do no better than random guessing; on 8 of 14 tasks the best score is under 1.5 times random; and on the transcription task no model produced a fully correct string (arXiv 2605.09900). ⚠️ Three qualifiers: this is a May 2026 reading; the only models tested were Claude Opus 4.7 and GPT-5, each with and without reasoning, four configurations in all; there is no Google model and no open-weight model. The operational takeaway is direct: asking a model "what is in this picture" is safe. Asking it to "work forward a few steps from this picture" is not safe right now, however accurately it describes the picture.
2. [Trend] (preprint February 2025, published August 2026 in Nature Human Behaviour) A large-scale measurement shows that polishing text with a large language model keeps the core content but compresses the population-level variance of writing complexity by 21% to 50%. It comes up now because it only cleared peer review and was formally published in August. The population is 3 studies, 7 datasets and more than 880,000 texts (arXiv 2502.11266). What collapses is the variance, meaning everyone writes more alike. It is not a decline in the quality of any single piece. And the convergence is not random. It moves toward the mainstream. Why this matters for business: language has long served as a cheap signal. Mental-health screening reads word choice, marketing reads reviews, recruiting reads personal statements. If every text passes through an AI first, those signals get washed out. ⚠️ Four qualifiers: the abstract's word is "linked," not "caused"; the design compares text before and after polishing, not people's own writing tracked over time; the 21% to 50% range is wide; and "writing-complexity variance" is an operational definition. How close it sits to "does the piece have a personality" depends on the body of the paper, and we read only the abstract today.

Product moves

No product news this issue. Nothing shipped from an application vendor in the past 48 hours, and we do not pad the column with a feature tour of an existing product.

From the archive

No archive pick this issue. The reusable older material in our own back catalog is exhausted.

Sources & accounting

The past 24 hours. September 12 to 13 added 19 pieces. By category, with names: industry newsletters and blogs, 10 pieces. Of the 76 feeds we subscribe to, only 8 had anything new: More Than Moore 1, Data Center Dynamics 1, Latent Space 2, Simon Willison 2, Epoch AI's Gradient Updates 1, Zvi Mowshowitz's Don't Worry About the Vase 1, Gary Marcus 1, Qualcomm's official newsroom 1. Podcast transcripts, 8 pieces, all from one a16z channel. Speech-to-text, 1 piece. Academic papers 0, company filings 0, X posts 0. Those three zeros are not filtered out. Nothing arrived today. Five pieces of material used in today's body are not among those 19: DeepSeek's model page and pricing page, Epoch's September brief, the experiment on benchmark undercounting, and the interview with the Japanese compute provider. All were pulled directly from their original sites this morning.

A second set of material is not inside that 19, and it is not from the past 24 hours either. Last night's catch-up reading covered 21 X posts from August 21 to 24. The whole of today's named-commentary column and item 2 in the not-yet-verified section have event dates between August 23 and 31. They are not things that happened today, and each carries its event date beside its tag. We publish them because readers have not seen them. We do not present them as today's news. New long-term sources added in one pass today: 0.

Source concentration. Today's flag: main-line item 2 and item 5 in the not-yet-verified section rest on the same long piece by the same commentator. If the transcription is wrong, both fall together. Two mitigating factors: the load-bearing counter-reading inside item 5 comes from the benchmark's own author, whose incentives run opposite to the vendor's, and the second half of main-line item 2 rests on an entirely different experiment whose direction runs against its own author's position. Where the independent second view sits: the load-bearing sources across the main line are, respectively, official model documentation and a pricing page, official developer documentation from two model vendors, one developer's personal blog plus a public benchmark log, an independent commentator's long piece, and a public experiment by a pseudonymous author.

What you are not getting today. Three things. One, we got no X posts from today at all, so the named-commentary column and item 2 in the not-yet-verified section could only use older August material, with event dates marked item by item. Two, both routes to DeepSeek's official blog returned 404 today, so the first not-yet-verified item rests on two official documents, the model page and the pricing page, without the vendor's own release note. Three, we read the Epoch brief and the Japanese compute provider's interview for the first time today and have not matched their figures against a second source, which is why they sit in the not-yet-verified section and not the main line.

The sources we track. 529 named speakers in total. The spread: X 302, podcasts 90, outlets 51, blogs 48, paper authors 48, newsletters 46, earnings calls 26, keynotes 23 and a scattering of others. ⚠️ Those count venues, and one person can occupy several, so the parts sum to more than 529. Representative names: on X, Arvind Narayanan, Miles Brundage and Susan Zhang; among blogs, Simon Willison, Armin Ronacher and Sebastian Raschka; among newsletters, Dylan Patel, Ben Thompson and Zvi Mowshowitz; on the institutional side, SemiAnalysis, Epoch AI and More Than Moore. Several identically named numbers count different populations. The roster's 302 X accounts and 46 newsletters are the long-term totals we watch. What actually reached today's material was 0 X posts from today, 21 older posts from the August catch-up, and 10 pieces from 8 newsletter feeds. Different populations.

I finished today's issue / I didn't finish

This is not a news digest: we hunt each day's AI firehose for the insights that actually matter and the practitioner judgments worth tracking over time, and we show how every item was verified — the point is always "which judgment got harder, and who's been right," never "what happened today."

— SecondSource · generated by our research system · 19 sources · Got a view? Reply and tell us

Written from the same research and judgments as the Traditional Chinese edition; every claim links to a primary document.

SecondSource publishes industry analysis, not investment advice. We do not evaluate, rate, or recommend any specific security, and nothing here should be treated as financial guidance — verify independently and use your own judgment.

EN English edition|繁 中文版 Traditional Chinese →