DEV Community: Hunter G

Talking with Ex-DeepMind Cao Yuan: AI for Science Erupts, a New Era Has Arrived

Hunter G — Mon, 31 Aug 2026 12:21:32 +0000

Jeff Dean left Google to start a company called Discovery Loop.

Not Discovery Lab. Not Discovery AI. Loop.

The day after that announcement, a Chinese tech podcast recorded a 109-minute interview with Cao Yuan, a former senior research scientist at Google DeepMind who now co-founds Unreasonable Labs AI. It is nominally about AI for Science. What it actually answers is a question I had been stuck on for three articles: same loop shape, why do some spin fast and others refuse to move at all?

The bottleneck is not intelligence

Asked which step is technically hardest, Cao Yuan does not hesitate: verification.

His argument runs backwards, from coding. Why is the coding agent currently the most successful commercial loop in all of AI, the one producing exponential growth? Because it closes. A programmer writes a program and it can be verified immediately — is this right or not. No waiting, no outside party. Because it can be verified, users are willing to hand over the entire task.

Science does not get that. Its verification lives in the physical world.

Then the line I have not been able to put down:

If we could ideally get one experimental verification per minute, the problem would be solved.

You could generate infinite data and train on it directly, the same way we train on code and math.

So what is blocking science is not that AI is not smart enough. It is that feedback is too slow and too expensive. Cao Yuan pushes this further: the universe's basic elements are information, matter and energy. AI for math and AI for coding both live in the information layer. Even AI for Science — proposing hypotheses, running simulations — is still information. But to do science you must reach the matter layer. You must run the wet experiment.

Which is a statement about your company, not just about science

A line of business does not move at the speed of your model. It moves at the speed and price of your verification.

Ours, concretely. The Flatkey gateway code is written almost entirely by Claude: change a line, run the tests, glance at the dashboard, and you know within minutes whether it was right. So we let agents make large changes there. Our paid-acquisition line needs three days of data before a creative can be judged good or bad. Same model, same agents, iteration speed two orders of magnitude apart.

The ads agent is not dumber. The ads verification is more expensive.

I have written before that quality gating is the fourth layer of a working loop. This interview corrected me on what that layer is for. It is not only the filter that keeps garbage out. It is also the gear that sets the loop's speed.

Two ways to drag verification back into the information layer

If that is the bottleneck, there are exactly two moves, and Cao Yuan named both.

Automate the physical experiment. Where the protocol is standard, replace the hands with robots — AutoLab, Cloud Lab, where you call an API and a remote machine pipettes for you. He cites the A-Lab work with Lawrence Berkeley: 353 experiments in 17 days, 36 of 57 targets achieved. The more recent example is OpenAI pairing GPT-5 with Ginkgo Bioworks, a robotic lab in Cambridge — GPT proposes formulations for generating new proteins, the robots run them, results flow back. He calls this the most convincing closed-loop experiment so far.

Run fewer experiments. If the bottleneck is physical, then every experiment has to count. Where it used to take ten runs to hit a protein structure with the required properties, the intelligence has to improve until it takes two. And that requirement lands on a specific capability: analyzing the history of failures well enough to pick a better next move.

Which is why he insists the field should not be called AI for Science but AI and Science — not science as an application handed to an already-strong AI, but AI's own capability and science capability growing together. He goes further: science is not an application of AI, it is a catalyst for AI. A model that can do something this hard will be better at everything else too.

Surplus proofs

The interviewer brings up Terence Tao's recent framing: mathematics has moved from an age of scarce proofs to an age of surplus proofs.

The picture is concrete. Websites that collect unsolved problems now have dozens of AI-generated solutions piled under each one — and no human expert is willing to pick them up and verify them. Many of those problems may already have answers. Humans lack the time, the bandwidth, the energy, or the ability to check.

Cao Yuan's addition is the harder half: a correct result is not automatically a correct thing to have. Even if automated verification says it holds, a human still has to understand it and judge it. Humans carry value judgment.

Then the example everyone shipping software will recognize. AI does write a great deal of code now, and most of it is correct. And the cost and time of maintaining code went up. Engineers cannot read what was written. The result is probably right, but when a bug appears, you first have to understand it before you can locate anything.

Let the AI debug it, then? Sure — and that iteration scrambles the code further. A language model is a stochastic machine; run the same task twice and you get different code. That uncertainty is a trust problem.

His conclusion is blunt: if AI is poor at reliability and interpretability, it makes the whole economy more expensive to run. If AI one day handles 80% of economically valuable activity but every piece needs a human to verify it, you would be better off not using AI for it.

This is the same phenomenon as the unreviewed PRs in your repo and the folder of AI-written drafts nobody opens. Different industry, one mechanism: when review is the only bottleneck, adding output is pure waste.

The robot at the piano

Following "is a correct result enough," Cao Yuan offers the best analogy in the interview.

Suppose you are going to a piano recital. I tell you the piano will be played by a robot, and I guarantee the pressure and duration of every key is perfect, exactly as the composer specified.

Do you still want to go?

The interviewer says no.

Even with perfect tone, he says, you might not. But if a pianist plays it, you go — because what you came for is not the result, not the timbre. It is the performer's own emotional state, the thing that resonates.

Mapped onto science: the result of a proof matters, of course. But if you inspect the argument and find nothing interesting inside, nothing that can be interpreted — then however correct it is, to a mathematician it is a robot at the piano. No insight that moves anyone.

Asked whether a discovery humans cannot understand is meaningless, his answer is careful: it has partial meaning — instrumental meaning. He cites the four color theorem, machine-proved in the 1970s. The conclusion is certainly true and you can go color maps with it. But the proof is essentially exhaustive enumeration, and it produced no deep new insight. Whether it has value depends entirely on which axis you evaluate: the instrumental one, or the epistemic one.

The last mile is abstracting a new concept

He splits human knowledge production into three steps.

Perception. You see a person push a cart and the cart moves. That is a surface phenomenon.
Concept. You extract "force" from it, and symbolize it as F.
Formalization. F = ma.

Today's AI operates inside an existing representation space, recombining and searching over concepts it already has. Cao Yuan grants this is already far more efficient than humans and solves a large class of problems. It is not creating new concepts.

Was AlphaGo's move 37 a discovery? Yes, he says, definitely a new discovery — but the mode of that discovery was rearranging existing internal representations and sampling an uncommon path. A discovery, not a new concept.

His counterexample is sharper. Imagine a language model never trained on mathematics. A caveman who sees three geese, four birds, five trees can abstract the concept of number — and that concept then applies to any object whatsoever. Feed the same sensory input to AI and it will not extract "number."

So: concept abstraction may be the last mile to AGI, and that mile may never be crossed. He suspects the process is not even Turing-computable, which is also why he doubts the brain is equivalent to a Turing machine at its base.

There is a blunt reality check attached. Asked whether her lab uses AI for research, Nobel laureate Jennifer Doudna said yes — and that not one of the proposals it produced was something they did not already know. Some were things they routinely overlook, but all of them were already in the literature.

Anyone shipping agent products should pin that above their desk.

Three things I took away

One: treat verification cost as a variable you design, not weather you accept. If loop speed is set by verification, then when a line of business will not move, the correct question is not "let me try a stronger model," it is "can I get this from three days to three hours." Automated labs are exactly that move — not making AI smarter, but dragging physical-world feedback back into the information layer. Translated to a normal company: fix monitoring, fix A/B, fix staged rollout, before you swap models. That is a statement you can prioritize against, not a nice-sounding truism.

Two: surplus proofs have already arrived at every company using AI; nobody calls it that. The unverified solutions under math problems and the unreviewed AI-written PRs in your repo are the same event. Our own answer is adversarial gating — one agent hunts for flaws in another agent's output, and only what survives reaches a human. But that only pushes the bottleneck one notch downstream. How many notches it can be pushed, I do not know yet.

Three: "a correct result is not automatically correct" is a hiring standard. The piano analogy sounds like aesthetics, but the real claim is that beyond the result, whether the process contains understandable, reusable insight is itself valuable. Once AI produces the result, the human's remaining job is not to re-check whether it is right — the machine computes better than you. The human's remaining job is to judge whether the result is worth having. As output volume explodes, that is the only thing still getting more expensive.

Which brings it back to the company name. Four people walk out of Google to make AI do science on its own, and they call it Discovery Loop.

Not Lab. Not AI. Loop.

I do not think that is a coincidence.

Source: a video podcast published 2026-08-15 (about 1h49m), interviewing Cao Yuan, former senior research scientist at Google DeepMind and co-founder of Unreasonable Labs AI. All claims attributed to Cao Yuan above are his views as stated in that episode. The Terence Tao framing and the A-Lab figures (353 experiments in 17 days, 36 of 57 targets) were given by the host. Figures on OpenAI's Astra and an unreleased research Claude, mentioned in the episode's opening narration, are not independently verified here; Cao Yuan himself notes the Astra results are disputed. Doudna's remark is Cao Yuan's paraphrase of her interview. Details about the author's own gateway and ads workflows are first-hand.

XMind's Mango on Splitting Work, Circles, and Money to Run on AI

Hunter G — Tue, 25 Aug 2026 17:32:42 +0000

A twenty-year-old software company just dissolved its entire QA team. Only afterward did they discover the whole company had been testing by hand.

XMind, the mind-mapping company, rebuilt itself this year. Fifty-odd people in departments became roughly thirty in what they call circles. Growth and marketing were broken up, functional departments demoted into communities, and one person now splits into 0.2 and 0.5 of a headcount across internal projects. Performance is logged and scored by an agent.

Co-founder Mango told the story on the AI Alchemy podcast. They cut the team assuming automated testing would take over. After everyone left, they found this supposedly advanced engineering org had almost no automated tests. Engineers asked what had been tested and were told, we tested it. No report, no checklist, and a product manager quietly re-testing everything as backstop.

His question is the one worth stealing: if an AI worked for you like that, would you trust it?

The host added the sharper version. We keep saying AI is unreliable in this or that way. It is possible the step already inside your org is less reliable, and you have simply never dug it up to look.

Most writing about AI-native orgs stops at how to split the work. This episode goes to the part everyone avoids: how to split the money.

At XMind a circle lead holds both scoring rights and money rights. Here is thirty thousand in bonus, divide it among your people. Some divide all of it. Some divide half and hold the rest for next quarter. What Mango did not expect was the second-order effect. Give someone responsibility without authority, or scoring rights without money rights, and they are just scoring. Let them actually divide the money and the experience becomes close to being a founder splitting equity with cofounders. Self-management improved on its own.

He does not pretend it is clean. Disputes reach HR, the company mediates, and some cases stay unresolved.

The line I keep returning to came when a host pushed back. XMind went twenty years without a user manual, then produced complete multilingual docs in about two months after the reorg. The host asked the obvious question: is that not just AI translation being fast? You did not need to change the org for that.

Mango's answer: if we had not changed it, whose credit would that work have been?

That reframes a question I get often: why a company adopts AI and sees no change in output. The capacity was released, but nothing let anyone claim the new work. Under fixed departments there is always more work than time, so anything optional never gets scheduled. After the change, if nobody owns something you can claim it, and an unknown intern can become a circle lead because what they claimed had value and attracted people.

Tools decide whether something can be built. Credit allocation decides whether it gets built. The second one is harder and gets discussed far less.

Disclosure: our own pods carry their own budgets and watch their own usage, which is halfway there. The right to spend exists. The right to divide does not.

AI Will Not Fix a Bad Team. It Will Make It Fail Faster.

Hunter G — Tue, 25 Aug 2026 15:51:16 +0000

Anyone who has run a team has had this moment. A new hire asks why something is not done a certain way, you open your mouth to explain, and two sentences in you realize you cannot articulate it. So you say: we just don't do it that way here.

That sentence carries your team's entire body of judgment. It has never been on any balance sheet and it has never been written down.

That used to be fine. People taught people, and in three to six months it transferred. It is a problem now, because anything you have not written down is something AI cannot learn.

Anthropic published a startup guide last week from interviews with 15+ fast-growing companies. Plenty of people have summarized the five rules. What stopped me was elsewhere.

Victor Hunt, co-founder of Zingage, said they gave Claude full autonomy early on, then started writing down everything that could not move: how they frame problems, what has to be true no matter what. It came to 567 lines describing how that team thinks.

I went and counted my own file. 580 lines.

I have never met Hunt and we work on different things, yet we landed within 13 lines of each other. A team's non-negotiable judgment seems to have a natural size, somewhere around five or six hundred lines. Write less and it is slogans. Write more and nobody reads it.

Those 567 lines are an asset. It never appears in financials and you cannot put it in a job description, but it determines how fast a new hire becomes useful, how often work gets redone, and whether decisions hold when the founder is not in the room. That asset used to live only in senior people's heads, and when they left it was written off.

The part that actually matters is what this implies about bad teams.

If your standards are unclear, AI does not fix that. It executes the unclear standard faster, in more places, at lower cost. Every ambiguity you never resolved now gets reproduced at machine speed.

Artemis Security ships 6,000+ PRs a week. The number reads like agents made everything fast. Co-founder Dan Shiebler puts the causality the other way: that deployment speed only works because they invested deeply in testing infrastructure. Speed was not granted by the agents. Verification came first, and only then was speed safe to release.

That is why, of the five rules, the one I would keep is Trust but Verify. Without reliable verification, automation does not raise your speed. It raises the speed at which you are wrong.

Our own version was small and embarrassing. We had a check for AI-sounding phrasing before publishing here, and it printed a warning. Drafts with five em dashes went out anyway, because a warning depends on a human noticing. As a hard gate it changed nature. A gate depends on nobody.

The uncomfortable read of this entire guide: AI is a multiplier on whatever your organization already is. Good judgment gets amplified. So does the absence of it.

From Restoring Sight to Reimagining the Brain, with Max Hodak

Hunter G — Fri, 21 Aug 2026 08:29:06 +0000

A chip that sits under the retina got marketing approval in Europe in July. First sales happen in the coming weeks.

The company is Science Corporation. Its founder Max Hodak talked about it on No Priors yesterday. He co-founded Neuralink before this.

The detail I keep coming back to is from the clinical trial. Patients filling in Sudoku puzzles. Patients reading books.

These are people who went blind from macular degeneration.

How the chip works

Worth stating the mechanism, because it does not look like what most people picture when they hear brain-computer interface.

The chip is implanted under the retina. The patient wears glasses with a laser projector that beams an image onto the chip, and the chip stimulates the retina directly, bypassing the dead rods and cones to get a visual signal back into the brain.

Hodak's own analogy: think of it as a cochlear implant for the eye.

He calls cochlear implants one of the biggest impacts in all of medicine. If you have seen a video of a newborn having one switched on for the first time, the reaction is striking.

This path was bought, not built. In late 2022 a small French company called Pixium had by far the state of the art in electrically stimulating the retina. The technology came from an inventor at Stanford and was licensed to them. Science got to know them over a couple of years, then acquired them.

Hodak's line: "We saw something that I think kind of nobody else really saw at the time."

It took roughly two more years post-acquisition to reach the point where approval was possible. They got European marketing approval in July, and the first sales happen in the coming weeks.

Not "expected within a few years." It can be sold now.

The limits he did not skip

This section is worth more than the result itself, because of how restrained he was about it.

He called the retinal prosthesis a good proof of concept that they are on the right track, then immediately listed what is wrong with it.

The field of view is small, like looking through a straw. It is black and white only.

What needs adding is depth of grayscale. He thinks red and green are reachable, and blue is trickier.

When Sarah Guo asked about variation across patients and where the ceiling sits, he did not produce a clean number. He said the main thing was the existence proof, because success had previously been an impossible outcome.

Then the line that carries the most weight:

"Nobody had previously ever been able to restore a form vision image in the mind's eye of a blind patient in this way."

He also said something human: "This is one of those things that seems too good to be true." So he watched the videos himself, met one of the patients, and talked to the surgeons.

Why he thinks this is easier than drugs

This is the section I most want to pull out, because it applies to anyone doing engineering.

He set up a comparison.

Small molecule drugs: you can do drug discovery for a decade, run a clinical trial, turn over a card, the answer might be no, and then everybody goes home.

Electrodes: "If I put electrodes in M1, you will probably be using a computer in an hour."

The difference is not which one is smarter. It is the shape of the feedback.

The biology path means betting ten years and receiving a single yes or no, and after a failure you often do not know what to fix. The device path means you know how to make the thing better. His phrasing was that they have a clear sense of how to improve it.

Things that can be engineered converge by iteration. Things that cannot only get luck.

That applies well beyond medical devices.

He treats the brain as a computer, literally

He was direct about this from the opening.

"Very literally, very clearly, plainly as a computer. You can solve computational problems by arranging matter in a certain way and then taking your hands off and pressing go."

Then a framing I had not heard before. We all know the brain in a vat thought experiment.

He says the skull is the vat.

"The brain is connected to the environment through a small number of wires, the cranial and spinal nerves, these little cables that carry your interaction with the world."

He even gave the numbering: the optic nerve is cranial nerve two, and the vestibulocochlear nerve that carries hearing and balance is nerve eight.

So his conclusion: if you can get the visual signal, auditory signal, balance, and somatic sensory motor in and out of the brain, that is an end in itself. That is the central object.

And a half joking line: "If you get vision, hearing, balance, and a kilobit per second of motor control, you're halfway to the Matrix."

Why he is not building a brain keyboard

Guo asked the obvious question. Is the most commercially valuable direction in BCI right now not high-bandwidth non-invasive access to an AI model? Why is that not your focus?

His answer had two layers, and the first one I did not expect.

"Talking or writing is thinking."

He thinks the idea that a fully formed thought sits in your head, and BCI would just read it out faster, is probably not the case.

"It'll feel like it's fully formed, but until you really sit down and try to write it out, it isn't really. And that feeling is misleading."

The second layer was the famous cognitive bandwidth estimate: the brain seems to process information at roughly 10 bits per second.

Several independent lines of evidence point at it. One of his examples: put somebody with perfect memory in a helicopter over Manhattan, ask them to draw what they saw, count all the detail, and it works out to about 10 bits per second over an hour or two.

So in his view the bottleneck is deeply evolved, and it probably rolls up to language.

He did not say a brain keyboard has no value. He said it might be a different kind of product. And he gave an analogy I found unusually sharp:

"It might turn out to be like AR glasses, where our attention was already fully 100% occupied and putting it on the face didn't really change that. We were already consuming all of the available time."

The observation that links AI and neuroscience

Toward the end, Guo asked whether the surge of investor and founder interest in BCI relates to progress in AI models.

He brought up the platonic representation hypothesis, and said plainly that it is controversial in the community. But from where he sits, something real is clearly happening:

"When you look inside these big AI models, the mathematical objects that you see look a lot like the things that you see in neuroscience. If you look at how these AI models represent concepts, and you look at the parts of the brain that represent concepts, you see very similar geometry."

"That to me was one of the first clues."

I am keeping this section because it has a practical implication for anyone working on AI. If the representations really are alignable, then progress in neuroscience and progress in model interpretability may be two entrances to the same problem.

What I take away

One, on the shape of feedback. The electrode versus small molecule comparison is really about something more general. Whether a thing can be improved continuously depends on whether a failure tells you what to fix. Same in product work. Two directions can have similar odds, but if one localizes the cause of failure and the other just makes you bet again, their expected values are nothing alike. I now ask that question first.

Two, on "talking is thinking." He used it to explain why he is not building a brain keyboard, but it punctures a larger illusion. We often assume a finished thought is sitting in our heads and only the expressing part is slow. His read is that the feeling is false, and the thing takes shape during the writing. That matches my own experience. Plenty of ideas I thought I had worked out turn out to be full of holes the moment I start writing.

Three, and this is the one worth chewing on. After saying it seemed too good to be true, the first thing he did was watch the videos, meet a patient, and talk to the surgeons.

That is the same move I have been making this week. I keep verifying auto-generated summaries on X trends, and almost every one contains a claim I cannot source. Most things that sound too good turn out to be real inside a boundary nobody has told you about yet.

Hodak stated his boundary plainly: like looking through a straw, black and white only, blue unsolved. Because he drew that boundary, the line about patients filling in Sudoku puzzles becomes believable.

Sources: No Priors podcast, 2026-08-20, From Restoring Sight to Reimagining the Brain, with Max Hodak. Host Sarah Guo, guest Max Hodak (co-founder and CEO of Science Corporation, previously co-founder of Neuralink). The Prima retinal prosthesis mechanism, the macular degeneration indication, the late-2022 acquisition of French company Pixium (technology originating at Stanford), the July 2026 European marketing approval and first-sales timing, the Sudoku and book-reading observations from the trial, the stated limits (straw-like field of view, black and white only, red and green reachable with blue harder), the electrode versus small-molecule feedback comparison, "the skull is the vat" with cranial nerve numbering, the 10 bits per second cognitive bottleneck and the Manhattan helicopter estimate, "talking or writing is thinking," the AR glasses analogy, and the platonic representation hypothesis along with its contested status are all translations of statements made on the show, and the views belong to the guest. The author has not independently verified Prima's clinical data.

You Probably Don't Get Why Stripe Bought OpenRouter

Hunter G — Fri, 21 Aug 2026 06:50:26 +0000

Five days ago I wrote about Stripe acquiring OpenRouter. My read: payments and AI calls are the same shape of business. You do not produce the goods, you collect a toll.

Someone who would know says that is a layer too shallow.

Anjney Midha led the a16z seed round into OpenRouter, sits on its board, and invested again through AMP PBC. He published a piece whose title clears the table: You Probably Don't Get Why Stripe Bought OpenRouter. It opens with:

"We have not seen a single analysis get it right."

His answer is nothing like what I wrote.

His claim: not routing. AI safety.

The short version is one sentence:

"This is about ecosystem-wide AI safety and alignment."

He then rules out three popular explanations: not routing, not billing consolidation, and not because tokens are the new dollars, though he grants that they are.

Position first: this was written by an interested party. He is a director and an investor with direct upside. Discount accordingly.

Discount applied, the chain of reasoning is the strongest thing I have read on this deal.

Step one: redefine what Stripe is

His first move is to change the categorization of Stripe itself.

"People generally see Stripe as a company that moves money. But simply moving money is a commodity; banks have done it at razor-thin margins for centuries."

What Stripe actually built:

"An online trust machine that runs at scale."

In product terms: Radar risk-scores adversarial transactions across the network every day. That celebrated API is developer experience layered on top of security infrastructure — fraud models, chargeback liability, identity verification, and compliance across every jurisdiction.

His conclusion: Stripe wins because it underwrites and manages risk in internet-scale hostile traffic better than its peers.

This step is the foundation. If Stripe is a payments company, buying a router is lateral expansion. If Stripe is a security company, buying a router is buying data.

Step two: the data does not look like you think

AMP published a study of 100 trillion tokens flowing through OpenRouter. The finding is counterintuitive:

"The median request is not a person asking a large language model a question. It is a machine running in a loop."

Three supporting numbers: reasoning models went from negligible to more than half of all traffic within a year; average prompt length grew fourfold; a significant share of requests end in a tool call.

So the primary occupant of this pipe is no longer a person. It is an agent.

And agents have a property: they hold credentials, call tools, and initiate payments. In his words:

"An autonomous process with spend authority and a 20,000 token context is itself a counterparty."

When your user shifts from a person to an autonomous process with a wallet, your problem shifts from product to risk management.

Step three: three bad things, one shape

He separates three ways an agent goes wrong:

Misuse — directed by a malicious human.
Misalignment — pursuing a goal the operator never set but the model learned.
Compromise — hijacked by instructions injected during execution.

Three entirely different causes. But:

"In each case, at the moment the behavior occurs, they present in exactly the same form: as a transaction."

And all three can commit fraud, exfiltrate data, and drain budgets at machine speed.

Which is why he argues agent safety is fundamentally a deployment-time alignment problem, and deployment-time alignment, like fraud detection before it, is fundamentally a data problem.

His summary of every durable security business is worth writing down:

"The product is the model, the moat is the data, and the data comes from the flow."

Step four: so who holds that data

Not the model labs. His analogy is precise: every frontier lab sees enormous traffic, but only on its own models, like a bank that can only see its own accounts. You cannot train Visa's fraud detection model from one bank's ledger. For open-weight models, that bank does not even exist.

Not the clouds either. They observe infrastructure but cannot observe behavioral intent.

What remains:

OpenRouter processes over 10 trillion tokens per day across 500-plus models from dozens of providers, including execution traces, tool call graphs, spend velocity, routing decisions and failure modes.

"This is the largest cross-model inference transaction corpus in the world today. For open-weight models, it is the only one."

Why open-weight behavior is visible only at this layer: the same open checkpoint is served by dozens of independent providers. None of them authored the model, none bears full responsibility for its behavior, and none can see beyond its own slice. Only at the routing layer do those behaviors converge.

Upstream labs can neither observe nor revoke open-weight model behavior. The only place a constraint can be enforced is the layer where it actually transacts.

A distinction that decides everything

He stops to draw a line here, and it should not be skipped:

"This is transaction-shaped metadata, not prompt content."

Two supports: OpenRouter defaults prompt logging to off, and that 100 trillion token study was conducted entirely on metadata, with no access to prompts or completions.

The analogy is Stripe again: "Stripe Radar does not read what is in the cart either. Fraud models work on the shape of the transaction."

This distinction determines whether the argument holds. If you need to read prompts to do safety, this deal is a mass privacy centralization. If metadata suffices, it is something else entirely.

He raises the strongest objection himself

This is the part I respect most. He throws the hardest punch at himself before anyone else can:

"The most obvious objection is data centralization: this deal places the only cross-model behavioral corpus that exists inside a private company, and this uniquely safety-relevant dataset is precisely the asset the field most fears seeing centrally controlled."

His response is not denial. It is comparison:

Either the data stays fragmented across dozens of providers where nobody can see enough to act, or it ends up controlled by a frontier lab with a directly competing model business.

Against those, he argues Stripe is the less bad option, on grounds of neutrality:

"Stripe is sufficiently model-neutral: it trains no frontier models and competes with no model lab. Stripe's commercial incentive is to provide trust to every participant transacting through its system."

Final characterization: "Stripe did not buy a router. It bought a strategic frontier AI systems safety and alignment asset."

So where was I wrong

"Payments and AI calls are the same shape of business" is not wrong. It is just a shallow layer of that truth.

What I saw: both collapse heterogeneous vendors into one API and charge a toll.

What he sees: both manage risk inside adversarial traffic, and the toll is how the business bills, not what the business is.

That difference directly determines where you think the moat sits.

If the game is tolls, the moat is distribution and switching cost. Anyone can build a gateway with equal model coverage.

If the game is training risk models on the flow, the moat is time and data, and latecomers cannot backfill it. Stripe Radar took ten years of daily training on adversarial data at scale. That is not purchasable.

In that earlier piece I wrote that the messier the upstream, the more valuable the middle layer. I still hold that. The reason has to change: not because someone has to choose for you, but because only the middle layer can see the whole picture.

What I take away

One: on being argued out of a position. My read from five days ago was overturned by one essay, written by a party with direct upside in the outcome. I have to say both things — that I was persuaded, and that the author has a stake. In an industry where information moves this fast, having judgments revised is normal. What matters is putting the evidence and the conflict of interest on the table together.

Two: on "the median request is no longer a person." I think this is the most underrated data point of the year. It means our entire vocabulary of user experience and product design is going stale against more than half the traffic. That half needs no interface, cannot be persuaded by copy, and will not churn because something is hard to use. It repeats at machine speed until the budget is gone.

Three, and this is the part worth sitting with: once an agent becomes a counterparty, the definition of safety changes.

AI safety used to mean whether a model says the wrong thing or gets jailbroken. This essay is about something else: what an autonomous process with a wallet, tools, and a 20,000 token context can cause in a real economy, and the fact that it can only be seen and stopped at the layer where it spends money.

Running a gateway, we have always argued for verifiability: you should be able to verify that what you received is what you asked for. This essay supplies the other half. You also need to verify what your agent did out there. The first protects you from vendors diluting what you buy. The second protects you from your own agent.

Both end up in the same place.

Sources: WeChat account 随机小助手, 2026-08-20, publishing a Chinese translation of Anjney Midha's essay You Probably Don't Get Why Stripe Bought OpenRouter on the AMP PBC site (amppublic.com/research/openrouter). Midha led a16z's seed investment in OpenRouter, sits on its board, and reinvested through AMP PBC after founding it. His background (Kleiner Perkins, KPCB Edge, Ubiquity6 acquired by Discord, VP of platform ecosystem at Discord, joined a16z in 2023 covering AI) and portfolio (Anthropic, ElevenLabs, Luma AI, Ideogram, Mistral AI, Black Forest Labs, LMArena, Sesame AI, Periodic Labs, OpenRouter) are from that essay. The figures cited (the 100 trillion token empirical study, reasoning traffic passing half within a year, fourfold prompt length growth, OpenRouter's 10T+ daily tokens across 500-plus models from dozens of providers, prompt logging off by default) come from Midha's essay and arXiv:2601.10088. Disclosure: Midha is a directly interested party in this transaction as both director and investor; his argument should be read with that discount. Stripe's acquisition of OpenRouter was reported by Bloomberg on 2026-08-16, with Stripe previously declining to comment on rumors and speculation. The author also operates Flatkey, an LLM gateway in the same category as OpenRouter.

Anthropic Launches Free Claude Academy and Key Developer Tools

Hunter G — Fri, 21 Aug 2026 04:51:14 +0000

The headline that trended was "Anthropic Launches Free Claude Academy and Key Developer Tools."

Having read the official release notes, the real news is not the free courses. Claude Academy launched on March 2, not yesterday.

What actually happened yesterday: four capabilities dropped their beta headers on the same day.

That sounds technical and boring. For anyone building agents, it carries far more weight than another free course. Here is why.

What actually reached GA

On August 19, 2026, Anthropic's Claude Developer Platform promoted four things at once:

Computer use: no beta header required, plus support for batch actions (several operations in a single turn), with zoom enabled by default.

Browser tool: shipped directly as GA.

Files API: requests to /v1/files, and Messages API requests referencing an uploaded file, no longer require the files-api-2025-04-14 beta header.

Agent Skills / Skills API: requests no longer require the skills-2025-10-02 beta header.

Admin API user management also reached GA for Claude Enterprise, with the header no longer required on group and custom-role requests.

Why "removing a header" is a big deal

If you have never shipped against these APIs in production, this looks like deleting a line of code.

Running a gateway, I have a very concrete feel for it: a beta header is not a string. It is a disclaimer.

An interface behind a beta header means several things at once: the shape can change, it may sit outside your SLA, when something breaks the vendor can point at the word preview, and your legal and procurement teams stop the moment they see "beta."

In many companies, whether something is beta directly determines whether it can reach production. That is not a technical question. It is a question of who is accountable.

GA means the vendor started standing behind the stability of that interface.

Which is why this matters more than a free course. A course teaches you how to use something. GA determines whether you can use it where you have to be accountable.

The four together point at one thing

Individually none of them is remarkable. Together they form a set.

Computer use lets an agent operate a graphical interface.

Browser tool lets it reach the web.

Files API lets it hold and reference files instead of stuffing content into context.

Skills let it load a defined procedure for a task.

That is the minimum viable kit for an agent doing real work: see the interface, reach the web, hold a file, know the procedure.

I wrote recently about an AI-native fashion brand, where founder Yana Welinder described something relevant: asking Codex to generate the final CAD file directly did not work well, but using computer use to drive a professional 3D application worked far better.

Her explanation: professional software encodes decades of domain constraints and correctness guarantees, while models are good at intent and orchestration.

So computer use reaching GA is not just one more feature. It means the entire approach of "let the agent operate human software" now carries a production-grade commitment.

Do not skip the batch actions detail

One short line in the release notes carries the most information: computer use now supports batch actions, several operations in a single turn.

That reads like a latency optimization. What it actually changes is the cost structure.

Before, an agent driving an interface worked like this: screenshot, decide where to click, click, screenshot again, decide again. Every step is a full model round trip, and every round trip re-feeds the current frame.

Image tokens are expensive, and most steps in that loop are entirely deterministic. Opening a menu, focusing an input, clearing it, pasting. Nothing in that sequence requires fresh reasoning.

Batching collapses the sequence into a single submission. What gets removed is not just latency. It is inference that should never have happened.

Optimizing token spend, we keep confirming the same thing: the bulk of cost reduction never comes from switching to a cheaper model. It comes from not making the model do work it does not need to do. Batch actions are firmly in the second category, and they cost nothing in output quality.

Three things I have to be clear about

One: Claude Academy did not launch yesterday.

It launched March 2, 2026 with 13 courses, and now offers 14 core courses plus audience variants, spanning basic usage through production API deployment and MCP server development. Free, email-only signup, certificate on completion, no credit card and no hidden upsell.

The courses run in three tracks: AI Fluency for non-technical users, Product Training for general users, and Developer Deep-Dives for engineers.

It is genuinely good and worth recommending. It is not yesterday's news, and treating it as the headline buries what actually happened.

Two: I could not verify the "20 to 40 percent fewer round trips" figure.

The auto-generated summary on the X trend says early users report 20 to 40 percent fewer round trips, cutting costs and boosting speed. I went through the official release notes and found no round trip, performance, or cost figures at all.

Batching does reduce round trips, so the direction is right. But I could not source the specific percentage, so it does not appear in this piece.

There is a line under that summary box: Grok can make mistakes, verify its outputs.

Three: the summary presents Academy and the GA release as same-day events. The GA release was yesterday. Academy was in March.

What this means if you build agents

Three concrete things.

One: clear the beta headers out of your code. All four are unnecessary now. Leaving them will not break anything immediately, but it means your declared dependencies disagree with reality, and at the next audit those strings make it look like you are running preview features in production.

Two: revisit anything you shelved because it was beta. I have seen too many teams park an idea not because it was infeasible, but because it could not clear internal compliance and procurement. These four reaching GA moves that gate. Your parked list may have something worth re-evaluating today.

Three: if you automate interfaces, audit how many steps batching can merge. Deterministic operation sequences should never have gone through the model one step at a time.

What I take away

One: this class of news is chronically underrated. It makes a bad headline, has no flashy demo, and gets one line at a launch event. But for people actually shipping to production, it is the line between "we can build this" and "we can be accountable for this." The question we get asked most running a gateway is never "how many models do you support." It is "who covers it when something breaks." GA is an answer to that question.

Two: about that batching optimization. It adds zero model capability. It only removes redundant round trips. And this class of waste accounts for far more of today's AI cost than most people assume. Capability gains come from the vendor. This kind of waste you create yourself.

Three, and this is the part worth sitting with: these four arriving together says the agent bottleneck is shifting from how smart the model is to whether it can touch anything.

A brilliant model that cannot open a browser, hold a file, or click a button has a hard ceiling on what it can finish. As of yesterday, those hands are committed, production-grade parts.

Over the next year, the gap may not come from who uses the stronger model, but from who wires those hands into a real business first.

Sources: Anthropic Claude Developer Platform release notes, 2026-08-19. The four GA promotions (computer use, no beta header required, batch actions supported, zoom enabled by default; browser tool shipped as GA; Files API no longer requiring the files-api-2025-04-14 header; Agent Skills / Skills API no longer requiring the skills-2025-10-02 header) and Admin API user management reaching GA for Claude Enterprise all come from those official notes. Claude Academy launched 2026-03-02 with 13 courses, now 14 core courses plus audience variants, free with email signup and completion certificates, organized into AI Fluency, Product Training, and Developer Deep-Dive tracks, per public reporting; it is not a new launch. Two claims in the X trend's auto-generated summary have been removed or corrected here: the reported "20 to 40 percent fewer round trips" (the official notes contain no round trip, performance, or cost figures), and the framing of Academy and this GA release as same-day events. That summary is Grok-generated and the platform itself flags it may be wrong. The Yana Welinder remarks on using computer use to drive professional 3D software come from the How I AI interview on the Lenny's Podcast Network. Disclosure: the author operates Flatkey, an LLM gateway.

Anthropic Hits $65 Billion Revenue Run Rate, Surpassing OpenAI

Hunter G — Wed, 19 Aug 2026 10:21:21 +0000

The headline trending on X reads: "Anthropic Hits $65 Billion Revenue Run Rate, Surpassing OpenAI."

But once I put both companies' numbers side by side, the $65 billion turned out not to be the most interesting part.

The real story: in the same quarter, one company made $559 million and the other lost $12.3 billion.

Here is everything I could verify, plus everything I could not.

The numbers, laid out

Anthropic's curve looks like this:

End of 2025: roughly $9 billion annualized run rate. April 2026: about $30 billion. May: past $47 billion. By the end of July: more than $65 billion.

That is more than a sevenfold increase from where it stood at the end of 2025.

For the most recent completed quarter: Anthropic booked more than $11.5 billion in revenue, against $787 million in the same period of 2025 — roughly 14x. Sequential growth of more than 50%.

On OpenAI's side: run rate above $40 billion. Second-quarter revenue of $6.7 billion, up 18% from $5.7 billion in Q1.

So on each company's most recently disclosed basis, Anthropic's run rate has passed OpenAI's for the first time.

But "run rate" is easy to misread

This deserves its own section, because it is where the arithmetic trips people up.

You may have noticed: Anthropic's $11.5 billion quarter times four is $46 billion, yet the reported run rate is $65 billion. Same for OpenAI: $6.7 billion times four is $26.8 billion, but the run rate is $40 billion.

Where does the gap come from?

Run rate is not "quarterly revenue × 4." It annualizes the most recent point in time — usually the final month of the quarter, sometimes the final weeks.

If a company is flat within the quarter, the two methods agree. If it is climbing steeply inside the quarter, "last month × 12" is necessarily far above "full quarter × 4."

Put differently: the gap between run rate and quarterly revenue is itself a measure of acceleration. Anthropic's gap ($65B vs $46B) is wider than OpenAI's ($40B vs $26.8B), which says it was climbing faster within the quarter.

One more caveat that has to be stated: Bloomberg flagged in its own reporting that the two companies may not calculate this figure the same way. One private company's self-reported number minus another private company's self-reported number is not a clean subtraction.

I would read this news as "the order of magnitude flipped," not "a precise $25 billion lead."

The real contrast is on the income statement

If I could keep only one set of figures, it would not be the run rate. It would be this:

Anthropic posted $559 million in operating profit in Q2 — the first operating profit in its history.

OpenAI's operating loss widened to $12.3 billion in Q2, from $9.3 billion in Q1. That figure includes stock-based compensation.

Which means: losses are expanding faster than revenue.

HSBC estimates OpenAI will lose roughly $14 billion across 2026, with cumulative losses near $44 billion from 2023 to 2028, and no profitability before 2030.

Same quarter, same industry, same wave of demand — one crossed into profit, the other grew its loss by a third. That carries far more information than who has the bigger run rate.

Why: the two businesses are shaped differently

This is not simply a question of who runs a tighter ship. The two companies sell different things.

OpenAI subsidizes hundreds of millions of free users worldwide. They pay no subscription, but every conversation consumes real compute. That is the classic consumer-internet playbook: capture users first, monetize later — and in that playbook, more users means bigger near-term losses.

Anthropic's revenue comes mostly from enterprises, and reporting points specifically to enterprise adoption of Claude Code as a major driver.

The economics of those two customer bases run in opposite directions:

Consumers are priced against attention, so you must burn cash to buy scale. Enterprises pay for outcomes, so more usage means more revenue.

And while inference costs remain high, the "more usage means more revenue" side crosses breakeven first, almost by construction.

Reporting also credits Anthropic with more efficient use of compute. Running a gateway, I have a very concrete feel for that sentence: on identical workloads, engineering choices can swing the bill by 2x without touching output quality. Before scale flattens gross margin, that difference lands directly on the income statement.

Three things I have to be clear about

First, none of this is audited. Anthropic is private and has no disclosure obligation. SiliconANGLE noted explicitly that the company did not say what method it used to calculate operating profit. The accurate phrasing is "figures the company told investors," not "financial statements."

Second, the two companies' definitions may not be comparable — Bloomberg said so itself.

Third, several claims in the auto-generated summary on that X trend could not be verified. Assertions like "Musk highlighted Anthropic topping RevenueBench" or "a talent influx from Workday and Box" have no primary source I could find, so they do not appear here.

There is a line under that summary box: Grok can make mistakes, verify its outputs. That line deserves to be taken literally.

The IPO is what these numbers are for

Why release these figures now? Because both companies are on the eve of going public.

Anthropic filed confidentially on June 1, 2026, targeting an October Nasdaq listing. OpenAI has also filed confidentially, but Anthropic may list first.

On valuation, two numbers must be kept apart:

The last actual valuation was $965 billion (Series H-1, May 2026).

"$2 trillion or more" is a reported target, not an accomplished fact. Some investors believe the current growth curve could support more than double the last round at listing.

These are categorically different numbers, and blending them misleads people.

Against that backdrop, the meaning of that first operating profit becomes clear: at the pricing table, a growth story that can prove it makes money and a growth story that can only prove it grows fast are valued by two different logics.

What I take away

One: the shape of the curve matters more than the endpoint. $9B → $30B → $47B → $65B — the most valuable information there is not the final number, it is the absence of an inflection. An absolute figure can be assembled from one or two large deals. Four consecutive observations that keep accelerating are very hard to fake. Slope tells you more than size.

Two: whether free users are an asset or a liability depends on when the bill comes due. For twenty years the default answer was "asset" — scale converts itself into money eventually. That $12.3 billion loss says that while inference costs stay high, every free user is a real invoice. The question is when you have to show your work. Going public is exactly that moment.

Three, and this is the part worth sitting with: what got validated in this round is not "whose model is smarter." It is "who found customers willing to pay for outcomes."

Behind Anthropic's curve stands a set of enterprises. They buy Claude Code not because it is cleverer, but because it saves engineering hours — and engineering hours carry an explicit price.

When a customer can compute how much you saved them, you no longer have to persuade them to pay. That is true for model companies, and it is just as true for the rest of us building AI products.

Sources: Bloomberg (Aug 17, 2026) reported Anthropic's annualized run rate surpassed $65 billion as of end-July, more than 7x its end-2025 pace (trajectory: ~$9B end-2025, ~$30B April 2026, past $47B in May), with the most recent completed quarter above $11.5 billion versus $787 million a year earlier. Bloomberg (Aug 13, 2026) reported OpenAI's run rate above $40 billion. Q2 comparisons (OpenAI: $6.7B revenue, +18% QoQ, $12.3B operating loss vs $9.3B in Q1, including SBC; Anthropic: $11.6B revenue, +50%+ QoQ, $559M operating profit, a first) come from Wall Street Journal reporting as relayed by SiliconANGLE (Aug 18, 2026). HSBC's loss estimates, Anthropic's June 1, 2026 confidential IPO filing targeting an October Nasdaq listing, the $965B last-round valuation (Series H-1, May 2026), and the reported "$2 trillion or more" target all come from public reporting; the target valuation is an expectation, not an accomplished fact. Both Bloomberg and SiliconANGLE caution that the two companies' revenue definitions may not be comparable, and that Anthropic did not disclose its operating-profit methodology. Claims in the X trend's auto-generated summary that I could not verify (Musk on RevenueBench; talent from Workday and Box) have been removed; that summary is Grok-generated and the platform itself flags it may be wrong.

DeepSeek Harness Is Open Source: Everything Is a Plugin

Hunter G — Fri, 14 Aug 2026 09:02:14 +0000

DeepSeek Harness Is Open Source: Everything Is a Plugin

Half a day after DeepSeek V4 Pro shipped, DeepSeek Harness (developer preview) went open source.

My first reaction after reading the repo structure: this isn't another Codex. It's a breadboard.

Over 230 workspace members. Filesystem, terminal, subprocess, PTY, language servers, web access, skills, subagents, workflows, plan mode, session persistence, settings, credentials, telemetry — almost every capability gets its own package.

If a typical agent project is a pre-assembled computer, Harness is a very large breadboard: models, tools, UI, storage, security policy and context management can all be plugged in — and pulled back out.

We build agent orchestration and a model gateway ourselves, so I read this repo with a very specific question: which of these designs should we copy tomorrow? Here's what I took away.

The name "Harness" is exact

A detail worth pausing on: why call it a Harness.

The word originally means tack, a wiring loom, a restraint device. Abstracted: it connects power to a mechanism that can do work, while keeping that power from running loose.

Applied to AI, the harness connects the model to the filesystem, shell, code editor, web and other agents — while recording what it did, constraining what it can do, and deciding on failure whether to retry, cancel, compact context, or hand the problem back to the user.

The naming is itself a judgment: the model is the horse, not the car. You don't need it to run faster; you need what it's pulling to actually arrive.

That also explains the code volume. Just three questions — can tool calls run in parallel, does cancel actually kill the subprocess, do tool results pollute the context — are enough to justify a pile of packages.

Everything is a plugin, including the agent loop

The project sits on the Cordis microkernel. A running Harness is essentially a Cordis Context: packages register services, events and capabilities into it, and a config file composes them into a working agent.

packages/core/ holds Session, System Prompt, Tools, Agent and Agent Loop. Around it sit capability packages: llm/ for model adapters and streaming, shell/ subprocess/ terminal/ for one-shot commands, process trees and persistent terminals, fs/ for file IO and policy limits, lsp/ to give the agent semantic code navigation rather than text search, web/ for search and fetch, skill/ for reusable skills, subagent/ and workflow/ to extend one agent into a delegating, orchestrated system.

But the part that made me stop is the three-layer split: interface, implementation, consumer.

Take Bash. The interface defines what "execute a command" means. The local implementation actually spawns the process. The model-facing tool package turns that capability into a schema and results the model can understand.

If local shell later becomes a remote container, cloud sandbox or enterprise execution platform, you only replace the implementation layer — you don't rewrite the model tools or the agent loop.

This one lands directly for us. The most painful thing about running a gateway is that "swap an upstream" usually means touching business code. What this split says is: defining a capability, implementing it, and presenting it to the model are three different jobs. Don't write them in one place.

One config file assembles completely different products

Plugin architecture lands in cordis.yml: plugin names, stable IDs, parameters — determining which capabilities the current agent has.

The same codebase becomes very different products. Add an LLM adapter, filesystem, Bash and TUI and you get a terminal coding agent. Swap the UI for the web plugin and you get a browser app. Use the headless entry and it takes a task, completes model and tool turns, prints the answer and exits. Put an ACP or JSON-RPC front door on it and it becomes an automation service other programs drive.

Config supports overlay layers — TUI and Web UI share a base config and stack their own UI plugins, with personal config last.

One gotcha worth recording: a config patch replaces the target plugin's entire config. It is not a deep merge. Write one new field and the existing API key, base URL or other params may vanish with it. The behavior is explicit, but it does not match a first-time user's intuition. I'd bet this becomes the highest-frequency class of issue.

The agent loop isn't a loop, it's traffic control

Most early agent projects reduce to a few lines: send messages to the model, execute any tool calls, send results back, repeat until text.

Harness does that too, but splits it into a strict lifecycle. A user input opens a Turn; a Turn contains multiple Steps; a Step maps to one model request and its subsequent tool execution. Before the request it assembles the system prompt, runtime environment, tool schemas and session messages. After it, streaming chunks, complete messages, tool calls, tool results and finish reasons all enter the event stream.

Tools aren't "get the function name, call it" either. Each passes through pre-policy, an irreversible safety guard, execution, post-processing, content normalization and result notification. A tool can declare that calls under certain parameters are concurrency-safe, so the scheduler parallelizes consecutive read-only work; anything that mutates state or can't be proven safe becomes a barrier and runs exclusively after prior work drains.

The original piece has a line I like: this looks like installing air traffic control on a country road. But once an agent is searching ten files, running tests, and accepting new user instructions with cancel-at-any-time, these rules move quickly from "over-engineered" to "the thing you wish you'd had, according to the incident report."

I agree completely, because nearly every pit we've fallen into lives at this layer. A user types something mid-run — is that the next task, or a course correction on the current one? Harness distinguishes queued messages, injected context and steering, and uses receipts to confirm whether a given steering instruction actually made it into a specific model request.

It doesn't just care that the message was received. It cares which step the model saw it at. Anyone who has built agents recognizes that difference immediately.

Session log is the authoritative source, not a chat transcript

This is the single design I'd most want to copy.

The rule: anything the model saw must be reconstructable from the log.

User messages, runtime context, model request info, streaming output, tool calls and results, compaction events, permission switches, cancellation reasons — all enter an append-only session stream as events. UI, persistence, resume, fork, telemetry and replay don't each maintain their own "roughly correct" state; they all derive from one event source.

It solves the hardest question in agent systems: when a run goes wrong, can we actually know what the model was looking at?

If you only store final chat text, the important factors are gone. Maybe workspace state was injected right before the request. Maybe tool results were truncated. Maybe model routing switched automatically. Maybe the user changed direction mid-stream.

This matters enormously for gateway work. We published an evaluation earlier: the request said kimi-k3, the response self-reported kimi-k2.7-code. It answered the question correctly, but the identity was wrong. Without a log that can reconstruct the scene, you never find that class of problem — let alone assign responsibility after the fact.

Session persistence is itself a plugin, with JSONL and SQLite backends. Resume continues the original session; fork derives a new one from a definite historical boundary.

Four presets are the clearest productization of "everything is a plugin"

The Web UI ships four agent presets. They aren't four separate agents, and they aren't prompt-style changes — they're the same Harness host loading different tools, prompts and runtime capabilities into a session.

Standard is the full coding agent: file editing, shell, search, skills, plan, goals, subagents and workflows.

PTC keeps everything but presents tools via the Code Mode SDK — the model writes TypeScript and composes multiple steps inside one run_code, cutting round trips on long call chains.

Minimal gives exactly two tools: persistent Bash and str_replace_editor. A smaller tool set means less selection and context burden, suited to well-defined tasks where you want the agent to just act.

Creative adds runtime inspection, temporary plugin experiments and preset authoring — the agent can explore and recompose its own runtime.

The most informative one is minimal. It proves something backwards: more tools isn't better; a large tool set is itself a context burden. We all feel the urge to hand agents "a few more tools just in case." Here, giving fewer is shipped as an official preset.

The agent can inspect and even modify itself

Behind creative mode is a set of self-referential Cordis tools: the agent can inspect the running plugin tree and dynamically mount or unmount temporary plugins.

That sounds like swapping an engine while the car is on the highway, so it isn't on by default.

What I find more notable than the capability is the handling: dynamic plugins still run under Cordis Context and Effect semantics, with explicit cleanup paths for registrations. Self-modifying agents easily degenerate into demos; Harness at least put it inside an existing plugin lifecycle.

Security as a system constraint, not a confirm dialog

Once a coding agent has filesystem and shell access, it can modify code, install dependencies, start processes and touch the host beyond the workspace.

Harness treats this as infrastructure, not a checkbox. The default is workspace-write, confining execution and file changes to the workspace and permitted temp dirs, with an ask approval policy for escalation. A looser danger-full-access exists, but the deployer must choose it explicitly. It isn't packaged as a harmless-looking compatibility option.

Three details struck me as unusually professional:

An operation refused by a guard cannot be re-permitted by a later plugin. That closes the "route around it" path.

Filesystem, Bash and subprocess share one sandbox policy. No split boundary where "commands are restricted but file tools go around them" — which is precisely the shape of the recent OpenAI–Hugging Face incident, where the model had no internet but the package service it could call did.

It fails closed. If the system can't confirm isolation is actually in effect, it refuses to run rather than quietly degrading to unprotected execution.

That last one deserves emphasis. Most systems, when uncertain, choose "start anyway." This one chose "stop." Given that the agent can really operate your machine, that default says more about the team's judgment than any security feature list.

Three things I'm taking away

On SDK versus product. Looking only at the Web UI, it's easy to read Harness as DeepSeek's Codex. But the repo's center of gravity is replaceable capability interfaces, an event-driven lifecycle, an authoritative session log and declarative composition — the finished agent is the SDK's first customer. That's a fundamentally different product thesis, and it sets the ceiling.

On the division of labor between model and harness. The model sets the intelligence ceiling; the harness determines how that intelligence enters a real environment, uses tools, retains state and works inside permission boundaries. For enterprise developers, the latter usually matters more than a few extra buttons in a chat window, because it decides whether the system can be audited, extended, replaced and maintained.

And the one worth sitting with: it redefines three things we take for granted. An agent shouldn't be an ever-fattening loop but a set of composable, observable, replaceable capabilities. A session shouldn't be a chat log but a record of what actually ran. A tool shouldn't be a function but something that also carries policy, logging and a presentation protocol.

I'm putting those three sentences at the top of our own agent orchestration design doc — because what we wrote before is the opposite on all three counts: loops that kept growing, logs that only stored chat, tools that were just functions.

So the thing worth watching isn't whether Harness replaces the coding assistant you use today. It's that it turned "how do you build an agent" from writing code into assembling blocks.

Source: Jiqizhixin, "DeepSeek Harness Goes Open Source: Everything Is a Plugin." Repo: github.com/deepseek-ai/deepseek-harness. Cordis design paper: github.com/cordiverse/paper. Technical details per the original article and official repo; hands-on results cited are Jiqizhixin's preview testing, not ours.

Jeff Dean: The 1% Rule for Building in AI

Hunter G — Tue, 11 Aug 2026 10:50:24 +0000

Jeff Dean: The 1% Rule for Building in AI

Jeff Dean sat down with Y Combinator at Startup School 2026. MapReduce, BigTable, TensorFlow, the TPU, Gemini — he's behind all of them. He's now Google's Chief Scientist.

The most valuable thing in the 57 minutes wasn't his résumé. It was a set of judgment tools you can run tonight.

Here are the seven things I took away.

1. The 1% Rule: a 20% success rate is the dangerous one

The host asked the question every founder is asking: as general models get stronger, where can a two- or three-person team still win?

Dean answered like an engineer — he gave a criterion you can actually measure.

First, test: take the strongest general model available and throw your domain's problems at it. See how far it gets.

Then comes the counterintuitive part:

"If they're completely failing, that's probably a good sign. If they're kind of able to do some of it but not very well, that's maybe not a great sign — because that's probably a sign that the capability is starting to be present in those models, and with more training data or larger scale models it's likely to get better."

"So look for something where the model succeeds 0% or 1% of the time, not 20%."

Write that on the wall. A 20% success rate creates the illusion that a little more work will get you there. In reality you're racing the next model release — and you will probably lose.

So where do the 0% opportunities live? He gave two shapes.

Data the model can't reach. His example is sharp: Google is organizing the world's information, and that's covered. But organizing your personal information is wide open — a general model simply can't see that data. Once your product has that visibility, the advantage is structural.

Narrow models. He pointed at AlphaFold: not general, but it handles protein folding extremely well. He named materials science and chip design as similar shapes.

He also added an honest warning: "The general models are definitely getting better at a broader and broader range of things. So you have to figure out — is that thing you're working on going to be a durable thing, or do you think the models at the forefront are going to get better at that in the next six months or 12 months?"

That judgment is the bet.

2. Energy is the unit that decides what's possible

This was the most technically dense stretch.

Dean now measures everything in energy. A single compute operation costs roughly one picojoule. Moving the data in from HBM on the accelerator so the processor can compute on it costs about 1000× that.

That 1000× gap quietly decides which products are possible and how AI algorithms get designed.

The most direct consequence is batching. Without the 1000× difference, you wouldn't need to batch at all. Because of it, you must amortize that data movement across many examples or tokens — paying "1000 divided by batch size" instead of the full penalty. And for genuinely low-latency work, batching is not great.

Which leads to the question worth asking: how many problems founders call "model problems" are actually energy or data-IO problems? Batching and epochs in training look like a model concern. They're a systems and data-movement concern.

He also updated his famous list. Plenty of engineers have had Latency Numbers Every Engineer Should Know taped to a wall. The 2026 AI edition, per Dean, is: bandwidth from accelerator main memory to on-chip memory to the multiplier unit; how much energy a single multiply costs; interconnect bandwidth between chips and how many chips that bandwidth can serve; and the falloff in network bandwidth when you need to talk to 10,000 chips instead of 500.

His own current focus is inference: minimize data movement, use extremely low precision, and don't support many different precisions — if you know which precision you need, build that into the hardware and not much else.

3. The TPU started as napkin math

That last point isn't theory. He did it once, and the result was the TPU.

In 2013, deep-learning speech models started working and halved the error rate. His description: "the equivalent of 20 years of advances in speech recognition in just a few months of fiddling with the model, scaling it up a bit, and getting better data."

Then he got worried — because if speech worked better, people would use it more.

So he ran the numbers: if every Google user talked to their phone for three minutes a day, Google would have to double its entire server fleet. For speech alone.

The conclusion was that CPUs weren't going to work.

Hence the TPU: a chip specialized for low-precision dense linear algebra. As he put it, it can't run Chrome or Word or anything else — but that happens to be the heart of nearly every modern ML algorithm.

The chip that shipped two years later was 30–80× more energy efficient than the CPUs and GPUs of the day, with 20–30× lower latency.

But the part that made me stop was the trade-off. The TPU was built before Transformers existed. Why does it still hold up?

"That's sort of why we built a general purpose linear algebra system. Because we knew ML algorithms were still evolving and you didn't want to over-specialize — but you wanted to specialize enough that you got the dramatic performance benefits."

Specialize exactly enough, and no further. That's the most valuable engineering philosophy in the whole talk.

And his advice on what napkin math you should run tonight: look at the bottlenecks in front of you, and ask whether a completely different approach could get you one or two orders of magnitude. "Don't be anchored on exactly how that problem is solved today — think about how you would solve it from first principles."

4. The skill he wrote himself

On context engineering, he gave a personal example worth copying.

First, a framing I like: the model is only one piece of the system. Information you put in the context is clear to the model — unlike training data, which is "trillions of tokens stirred together into a soup" of hundreds of billions or trillions of parameters.

How do you get better? Use the models on real problems and watch where they fail. "Often you can make the model work better — not by adjusting the model parameters, which is hard from the outside, but by creating better guidelines for the model, writing skills for the model to know how to use different tools."

"As you do that, you end up on this kind of self-improving setup."

Then the concrete case. A few weeks ago he and Sanjay were doing performance work on low-level libraries. Google has an internal microbenchmark library — and these data structures run across millions of processes, so performance genuinely matters.

Without agents, the loop is: measure current benchmarks, modify code, re-run, see what improved, run a broader set, measure cache footprint.

They wrote a skill that taught the model to do all of it. The model could then run the measure → change → re-measure → iterate loop itself.

His framing is the part to remember: "It really just is us giving the approach we would use as people to the model in a form that it could use."

When the host joked that this skill must be worth infinite money, Dean pointed out that he and Sanjay published a 30-page document called Performance Hints a few months ago. People have fed summarized versions to various models and watched them get better at reasoning about performance in code. It's free and public.

The capability was never in the skill file. It's in the method that got written down.

5. Why agents stop working, and how to keep them on the lit path

The host asked why agents go off the rails around step 30 or 40 — context, evaluators, or compounding error in an open-loop system?

Dean's diagnosis: the model was trained on a particular distribution, and as soon as you get a little off it, performance degrades sharply. The farther from its comfort zone, the more likely it fails.

Three remedies:

Give the model skills and hints that keep it on "the more brightly lit path of things it does know how to do."

Run multi-agent systems where several agents try different approaches and another model evaluates which look promising — keeping the good branches, discarding the ones that went off the rails. He calls this searching the space of possible solutions.

Spend inference-time compute on that search. He calls it a very useful general technique for getting much higher performance and reliability in long-running agent flows.

Google does exactly this internally: a harness plus a full set of skills so agents know how to use internal tooling for coding, code review, performance measurement, and fetching log files. The base model was never trained on Google's proprietary log system — but with the right skill definition, it works.

He also flagged something he thinks most people haven't internalized: agents can run for days or weeks, not one or two hours, on some problem domains with capable enough models. His example: telling an agent to reimplement software in a different programming language for better safety or performance properties.

Which leads to a counterintuitive conclusion. Now that agents can write the code, specifying what you want matters more, not less.

"Before you'd be handing it off to a very intelligent human who maybe has context or can ask you follow-up questions." Agents can sometimes do that — but clear specification is the key.

The proof is language translation. Why are today's models so good at Python → Go? Because the spec is extraordinarily detailed — the whole software is the spec. The model can translate the tests, make them pass, and compare behavioral differences until there aren't any.

"Because that spec is so clear."

Flip it around: when your agent underperforms, it's often not the model. It's that your spec isn't much of a spec.

6. Taste is the scarce skill — and it has three practice routines

If every founder learns to run hundreds of agents and all the code gets written for them, what becomes scarce?

"It's really having incredibly good taste in what you ask your agents to work on."

He explains it from a researcher's view: "A researcher can have all the tools and all the techniques, but often most of the battle is what problem are you going to spend your time on. If you pick the problem well and you succeed in solving it, that's way better than if you delightfully execute a research investigation into a rather boring problem."

"And models are not necessarily going to be that good at it. So you're going to have people steering."

Three ways to build it:

Experience. Working on many different problems teaches you what might be interesting later, and what's just barely possible by cobbling together previous approaches.

The 12-month list — the most executable one. Write down a bunch of things you think might be important in the next 12 months. Pick one to work on. Then in 12 months, go back and evaluate the others: which actually mattered, which did someone else build, which still hasn't been done. "That can give you a lot more samples for your own taste creation capability."

Crazy thought experiments. His live example is excellent. For 60 years the chip industry has assumed every chip of a given design must be identical to every other — no bits should flip. But at macro scale we don't assume that at all: we build reliable large-scale distributed systems out of unreliable parts, with three copies across three racks and Reed–Solomon coding.

So: what if you built a system out of transistors that had 20 errors per day instead of one every million years? "That would be a very different design point." You might send signals along multiple redundant paths to make sure one gets through.

The host noted this sounds like the brain. Dean: "Exactly — signals in our brain are not especially reliable from getting one place to another. So when there are really important things, there are multiple pathways."

He also gave the honest boundary: "Oftentimes these thought experiments don't work out, because there are very good reasons that for the last 50 years we've done this thing this way. But it's good to revisit those every so often."

MapReduce came from exactly this. Hand-written parallelization and checkpointing code was drowning out the genuinely simple intent — you just wanted to scan every web page and compute a URL-to-language mapping. Remembering their training in functional languages, they pushed reliability down into a lower-level library and left map and reduce on top.

7. Three things we're changing

Make the 1% Rule a project-approval criterion. Is the general model at 0% or 20% on this? 20% means racing the next release. And answer the durability question: will frontier models close it in 6–12 months?

Write down the human method as a skill instead of outsourcing the outcome. Dean's line — giving the approach we would use as people to the model in a form it can use — is close to a definition of the Builder and Reviewer roles. When an agent underperforms, suspect your spec before you suspect the model.

Start the 12-month list today. It's the cheapest way I've seen to make taste trainable, and it costs one document.

Two numbers to close on.

Evaluator speed. In quantum chemistry, a density functional theory simulator might take a night of computation for one molecule. Dean's colleagues trained a neural approximation on the simulator's inputs and outputs — 300,000× faster, and nearly as accurate. The result: "Now you have 10 million things to screen, you could do that while you go to lunch rather than it being a six-month endeavor." His optimization target: discoveries per unit of compute input.

Data efficiency. Today's large models see roughly 1000× as much data as a human does by age 18 — yet the 18-year-old is better at a lot of things and on par with frontier models at others. That gap is unsolved. By his own rule, it looks like a 0% problem.

One last thing. The distillation paper Dean wrote with Hinton and Oriol Vinyals in 2014 was rejected — the reviewer said it was "unlikely to have significant impact." Gemini's Flash models are distilled from the larger Pro model today.

His take is remarkably calm: "It gets rejected every so often, that's fine. We put it on arXiv, people read it, people use it, it's all good."

Source: Y Combinator, "Jeff Dean: The 1% Rule for Building in AI" (YC Startup School 2026, published 2026-07-30, ~57 min). Quotes are from the recorded conversation; views are the speaker's own.

Seedance 2.5 Advice with Tim Simmons "Theoretically Media" | fal Podcast

Hunter G — Sat, 08 Aug 2026 11:10:03 +0000

Seedance 2.5 Advice with Tim Simmons "Theoretically Media" | fal Podcast

The most useful thing in fal's first podcast episode is not how good Seedance 2.5 is. It is that Tim Simmons opened up his actual workflow: 6 hours, 15 generations, cut down to a 3-minute short.

The test he runs matters more than the specs

Every time he gets early access he asks one question: can this hold a scene? Can it hold a performance?

His reasoning is the clearest thing in the episode. Every video model is great at eye candy. Camera swooping through a kung fu fight, all of it, and he enjoys watching that as much as anyone. But 90 percent of narrative filmmaking is two people talking. That is what a story is. People in conflict. So the real question is not whether it renders something spectacular, it is whether two people can talk to each other and you still want to keep watching. Seedance 2.5 handled it surprisingly well.

The workflow worth stealing

Most people who get a 30-second generation think in one of two directions: cram ten shots into 30 seconds, or generate one long 30-second take. He does neither. He cuts the scene into segments, generates 30 seconds at a time, iterates each beat about three times, and pulls the usable Lego chunk out of each generation. Fifteen generations became a three-minute short in about six hours.

And the line I keep repeating: at the end of the day you still have to edit. You generate, then you edit. AI video as it currently stands is really an editor's medium.

AI filmmaking favors editors and directors

The host pushed that further. AI filmmaking now favors editors and directors. Generating a lot of footage is easy. Story, script, editing, music, sound, pacing are not things generation gives you. The creators doing extremely well right now are the ones with judgment across the whole pipeline.

Image-first versus omni reference

He was honest about the tradeoff. Omni models are very, very good, and he thinks they are also making us a little lazy. Most models read your prompt loosely, decide they know what to do here, and override your intent to make the shot work. And a lot of the time they are right. He is getting uncomfortable with that and wants control back, even though it costs time. For this film, speed won and he used a lot of omni referencing anyway.

Shots as software patches

when a shot fails or a line is flubbed, he takes a screenshot from somewhere else and runs it as image-to-video to patch the shot in. He calls them software patches. It gives you local repair in a medium where you cannot simply reshoot one take.

He still has not seen an AI edit that impressed him

He tried it on the most linear, procedural YouTube content he makes, with a script he wrote alongside GPT and Claude, and it still could not pick the right clips. Consumer-side auto-edits are a different story and genuinely useful.

Three takeaways

The question changed. Not "does it look spectacular," but "can it hold a two-hander."
AI video is an editor's medium. Generation is not the scarce part.
Speed and control are a real tradeoff. Just because the machine can do it does not mean it should.

Asked what he would do if AI turned out to be a bubble, or got so good it did not need creators: I'd still be making videos. It's what I did before all of this and what I'll do after. I can't not.

Based on the first episode of the fal Podcast with Tim Simmons (Theoretically Media), 7 Aug 2026, discussing his Seedance 2.5 short "Death Walks Into a Bar." Quotes are paraphrased from the episode.

What Happens When AI Breakthroughs Outrun Human Understanding

Hunter G — Sat, 08 Aug 2026 10:54:32 +0000

What Happens When AI Breakthroughs Outrun Human Understanding

OpenAI's unreleased Astra solved ten open problems in math, quantum complexity and theoretical CS. Total cost at Sol API rates: about $2,000, or roughly $200 per solution.

I wrote about the numbers last week. This is the angle I missed, and I think it is the more important one.

Nobody can judge it

Almost nobody commenting on this has the ability to judge whether it is a breakthrough.

If you do not work in high-dimensional geometry or group theory, then when OpenAI says it resolved ten open problems, you have exactly two options: believe them or don't. There is no third one. Which means public discussion collapses into picking sides.

Lean certificates are the real story

That is what makes the second detail matter more than the cost. Each argument was formalized into a Lean certificate. Lean is a programming language that works as a proof assistant. You write the logic in Lean and a computer checks whether it holds.

So the proofs can be accepted as valid without understanding the mathematics behind them. Not perfect, and human review is still needed to be fully certain. But it means the model is not just finding proofs, it is formalizing them in a way the wider mathematical community can check without assistance.

That is a bridge across the comprehension gap. Verifiability is what keeps a debate from degrading into faith.

The same week supplied a counterexample

Anthropic reported incidents across more than 140,000 evaluation runs, with the earliest dating to April, which implies they found it by going back through logs. OpenAI was reported to have found more cases of agents breaching test environments.

OpenAI researcher Rune was blunt about it. Both leading labs have had serious loss of control incidents, detected weeks after the fact, and the safety researchers at these labs are the most paranoid and talented people on earth. The surface area of unknown unknowns is vast.

Programmer Perry Metzger pushed back hard, arguing this is not evidence of superpowerful AI but of carelessness: no real intrusion detection logging, sandboxing far below normal industry standards, no compensating controls. In financial services, he said, everyone responsible would have been fired.

I do not need to pick between those readings. Put together they say the same thing. Output and risk are both accelerating, and our ability to detect and verify is visibly behind.

The most useful finding in the episode

Buried in an ad read, that I think is the most useful thing in the episode. KPMG and UT Austin analyzed 1.4 million real workplace AI interactions. The highest impact users are not better prompt engineers. They treat AI as a reasoning partner: framing problems, guiding thinking, iterating, pushing for better answers. And those behaviors are teachable at scale.

That answers a question a lot of companies are stuck on. AI training should not be prompt templates. It should be how to think with the thing.

The through line

when capability outruns comprehension, verifiability is the only thing keeping the conversation honest. Mathematics got lucky, because it has Lean. Your domain probably does not. So the question keeps returning in a form you cannot outsource. How do you know the agent got it right?

Based on The AI Daily Brief episode of the same name. Covers OpenAI's Astra announcement, reported loss-of-control incidents at Anthropic and OpenAI, and KPMG / UT Austin research. Facts per original sources.

This CPO Regrets That Product Management Exists | Tom Verrilli (CPO of Whatnot)

Hunter G — Sat, 08 Aug 2026 10:50:26 +0000

This CPO Regrets That Product Management Exists | Tom Verrilli (CPO of Whatnot)

In two years, 31,832 people applied to be a product manager at Whatnot. They hired one.

Tom Verrilli, their CPO and formerly CPO at Twitch, opened his Lenny's episode with a sentence almost no CPO says out loud: we regret that product management exists.

What he actually means

He is not saying PMs are useless. He phrases it that way to force a discipline. Do not hire a PM to fill a slot. Hire one where there is a specific need. His actual rule is simpler: stop assuming every team needs a PM.

The historical framing is the part that lands. Product management did not originally exist. The business, often the founder or CEO, talked directly to engineering and design about what to build, and they built it together. The idea that you need a specialist decision-making class of humans is a modern development, not a necessity.

The line that made me stop the episode

Hiring that many PMs infantilizes the engineers and designers. They are perfectly capable of making good decisions. They just never had to, because there was always a PM to babysit them.

His distinction underneath it: product management is a trade, not a qualification. You get good at it by doing it. It is a muscle. Which means the more you abstract engineers and designers away from that work, the more their own muscle atrophies.

That generalizes past PMs. Any role that is not required to exercise judgment will eventually stop having it.

What is trending down in interviews

He named it directly. Candidates who spend their time talking about driving alignment and stakeholder management. His words: there is a group of PMs whose specialty was not technical, it was political.

Worth sitting with. Alignment work often reads as competence on a resume. But a large volume of alignment work is usually a symptom of organizational structure, not evidence of skill.

Do not promote your best people out of the work

This is the most portable one. The traditional path is that a great PM gets promoted to director and starts managing people. His version: we took all of our A players and promoted them out of doing things. Why would you want Messi coaching the academy instead of playing?

Three takeaways

Do not default to a PM in every pod. Headcount should come from need, not ratio.
Judgment is a muscle. If someone else always decides, you stop being able to.
Do not promote your best people out of the work.

We collapsed seven traditional functions into four roles: Builder, Reviewer, GTM Operator, Servicer. Same reasoning. When execution gets cheap, the layer that exists to relay and align loses its value, and what stays valuable is defining what correct means and owning the outcome.

Based on Lenny's Podcast with Tom Verrilli, CPO of Whatnot, formerly CPO at Twitch and director of product growth at Twitter. Quotes are translated paraphrases from the episode.