DEV Community: Hunter G

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.

The Inference Engineering Masterclass — Philip Kiely & Ali Taha, Baseten

Hunter G — Sat, 08 Aug 2026 10:46:52 +0000

The Inference Engineering Masterclass — Philip Kiely & Ali Taha, Baseten

The same open-weights model, served by different providers, can differ by 4x to 10x in speed. So "which model" only answers half the question. The other half is whose inference.

Baseten's Philip Kiely and Ali Taha went through the whole stack on Latent Space. A few things worth stealing:

What actually happens to a 200k-token request

The first question is not "which GPU." It is "have you sent me this before?" Cache-aware routing looks for a replica with free prefill workers and some of your input already cached, so it can skip part of prefill. Then prefill and decode run on separate GPU sets. A speculator model sits in front, and if it was trained assuming you write code, your draft-token acceptance rate is high. Ask it to summarize every Harry Potter book instead and it slows down.

The counterintuitive one

Industry common sense says quantization is lossy, so compressing harder is strictly worse. Baseten's research shows quantization errors can cancel each other, and you can predict which layers will cancel. Quantize those. A model with layers 1, 5 and 10 quantized can beat one with only layers 1 and 2. Their GLM-5.2 quant ends up 20 percent more quantized than NVIDIA's, which means 20 percent more throughput at better quality. They proved it with KL divergence against the full-precision logit distribution, not benchmarks.

How the gains stack

A 1T-parameter model on an off-the-shelf engine with no speculator, no KV routing, no disaggregation runs around 30 to 50 tokens per second. Optimized, 300 to 400. The multipliers: BF16 to NVFP4 is roughly 2x, speculative decoding roughly 2x, prefill/decode disaggregation roughly 2x, plus double digits from better kernels. Ten times is aggressive. Four to six is realistic. Hold hardware constant and pure inference work gets you 2x to 4x. Speculation plus quantization is about 95 percent of it.

How to tell when a field is mature

My favorite line was about exactly this. In finance you measure progress in basis points, and five is big news. In inference the numbers are still 20 percent, 100 percent, 200 percent. You will know inference is solved when researchers start publishing about getting 1 percent faster.

Takeaway

For anyone building on model APIs, this is uncomfortable. Models are swappable. Inference quality is not. Which means the real decision was never just which model. It is which model, on whose inference, at what price.

Based on the Latent Space episode with Philip Kiely and Ali Taha of Baseten. Technical details per the original episode and Baseten's published research.

Alibaba Launches Qwen3.8-Max, Its Largest AI Model Yet

Hunter G — Tue, 04 Aug 2026 05:31:04 +0000

Alibaba Launches Qwen3.8-Max, Its Largest AI Model Yet

Alibaba shipped Qwen3.8-Max at 2.4 trillion parameters. The headline is "largest yet." The actual story is that the open weights land next week.

The specs: 2.4T total MoE with 95B active, 1M token context, text plus image plus video. API at $2 per million input and $6 output, about 20 percent cheaper than 3.7. It sits at #4 on the Frontend Code Arena, roughly one point behind Claude Opus 5, and reportedly edges Fable 5 by about 2 percent on Terminal-Bench. Alibaba says it ran solo on a real project for 16 days and produced 265 commits and 127 PRs.

Three things stack here

1. The largest open model ever is about to exist

The current open-weights record is DeepSeek V4 Pro at 1.6T. This is 2.4T. And it is the first time Qwen has opened the Max tier at all. They used to open the mid-size models and keep the flagship behind an API. This is a strategy decision, not a technical one.

2. A receipt for a prediction from three days ago

In The Economist interview published July 29, Musk argued that Chinese labs got to the frontier on relatively little compute, so if they ever get a lot of compute they will probably lead. That was a deduction at the time. Reports now say Alibaba deployed this 2.4T model on entirely domestic infrastructure. I do not know whether his claim about lithography being closer than people think is correct. But a domestic stack carrying frontier-scale MoE in production moves that constraint down a notch.

3. The price war changed shape

Last week DeepSeek hit $0.14 per million input tokens. This week Qwen is $2 and $6. Those look opposed, but they are different attacks. DeepSeek is going after volume with a price nobody has to think about. Qwen is making the strongest tier self-hostable. For enterprises the second one may hit harder, because once flagship weights are downloadable the procurement question stops being "whose API do we buy" and becomes "which workloads are worth hosting ourselves." That is a completely different negotiating position.

What I take from it

As someone who watches token prices daily because we run a gateway:

Largest is not the point. Open is the point. When the top of the leaderboard is separated by one point, the assumption that you must be on a closed model starts to loosen. And this week Qwen, last week DeepSeek, the week before an 80 percent cut from OpenAI. No model stays best. The value was never in picking the right one. It is in having a layer underneath that trades off cost and capability for you.

Based on Alibaba's Qwen3.8-Max release and public reporting; benchmarks and pricing per official sources. Musk quote from The Economist's full-length interview, 29 July 2026.

OpenAI Model Solves Ten Long-Standing Math and CS Problems

Hunter G — Tue, 04 Aug 2026 05:10:39 +0000

OpenAI Model Solves Ten Long-Standing Math and CS Problems

OpenAI's unreleased model solved ten long-standing open problems in math and theoretical computer science. The number worth staring at is not ten. It is $200 per problem.

The results

The model is called Astra, an internal version. Reported results include:

The first explicit non-sofic group, a problem open for 27 years (paper title: Nonsofic Groups Exist)
A counterexample disproving Connes's rigidity conjecture
High-dimensional sphere packing: the exact strength of the Cohn-Elkies method
Quantum parallel repetition for all entangled games
Ramsey lower bounds, CVP hardness, Ehrhart-related results
Three Erdős problems resolved

Some of these had been sitting there since the 1940s. This is the same model that disproved an Erdős conjecture in May, and the same one Sam Altman has been demoing for Congress. OpenAI's Noam Brown called it a major step for scientific reasoning.

The number that matters

Total cost to solve all ten, at GPT-5.6 Sol API pricing: about $2,000. Roughly $200 per problem.

Andrew Wiles spent seven years on Fermat's Last Theorem, a problem nobody solved for 350 years. Different difficulty class, so the comparison is unfair. But the direction is right, and direction matters more than precision here.

Someone asked the correct follow-up: what happens if you throw $20,000 of compute at harder problems? $200,000?

Why this matters if you build things

I watch token prices daily because we run a model gateway. Last week DeepSeek shipped at $0.14 per million input tokens. The week before, OpenAI cut one of its models by 80 percent. Inference cost is collapsing on a quarterly cycle.

Stack that against $200 per proof and you get an uncomfortable conclusion:

Compute budget has stopped being a finance line item. It is a research strategy variable.

Deciding whether to attack a hard problem used to depend on finding a sufficiently brilliant person and convincing them to spend five years. There is now a second path: deciding how much you are willing to pay. Discovery has acquired a purchasable component.

The detail everyone skipped

Every proof shipped with a machine-checkable certificate.

That is the foundation the $200 stands on. If a model hands you a result and you need three PhDs and two months to confirm it, then $200 was never the real price. Verification was. When the proof checks itself, verification cost collapses along with inference cost.

Which points at the pattern I keep hitting:

The bottleneck is moving from "can we produce it" to "can we verify it."

Mathematics is the cleanest demonstration, because it is one of very few domains where verification can be fully formalized. Most businesses are not that lucky.

So the practical question is not whether AI will do your work. It is which steps in your process still require a human to confirm the output. Those steps are your actual ceiling on throughput, and cheaper inference does not move them at all.

Three takeaways

Watch $200, not 10. Ten proves the capability exists. $200 proves it can be bought with a budget.
Machine-checkable proofs are the foundation. Without them, $200 just moves cost from inference to review.
The bottleneck is shifting to verification. Wherever you still verify by hand is your real ceiling.

None of this means mathematicians are finished. The opposite. Choosing which problem is worth attacking, and judging whether a result matters, just became the scarce skill.

Based on OpenAI's public announcement of Astra and statements from Noam Brown (@polynoamial). Cost figures are estimates at GPT-5.6 Sol API pricing from public reporting. Results and numbers per OpenAI.

We Put Flatkey on a Billboard on Highway 101

Hunter G — Mon, 03 Aug 2026 18:01:12 +0000

We Put Flatkey on a Billboard on Highway 101

If you drive south past Brittan Ave this week, you'll see it: One API key. More AI models. More tools. Lower cost.

I want to be honest about why we did this, because "startup buys billboard" is usually a punchline.

Why a billboard

Not for impressions.

Because 101 is where our customers actually are. The people building AI products in this valley drive that road every morning. And a physical object on a highway buys something a CPM number can't — it says we're here, we're real, and we're not going anywhere.

There's also a detail I keep thinking about. A few hundred meters from our board, another billboard is selling 115 megawatts of dedicated AI compute.

That's the whole supply chain, on one stretch of road: someone selling the power, someone selling the silicon, and us selling the layer that decides which model your request should actually go to.

Why that layer exists

Every builder now has the same problem: the best model changes almost weekly.

GPT, Claude, Gemini, Grok, Qwen, DeepSeek, Kimi, GLM — prices and capabilities move constantly. Last week DeepSeek shipped a model at $0.14 per million input tokens. The week before, OpenAI cut one of its models by 80%.

You should not be spending your time hand-picking models and rewriting integrations every time the leaderboard shuffles. You should describe what you need, and have a layer underneath trade off cost and capability for you.

That's the whole product: one key, one bill, 300+ models, 1,000+ tools.

The second board says it more plainly: One gateway to every AI model and tool.

But a billboard isn't traction

I've been building for a long time, and I've learned to be suspicious of moments that feel like victory.

A billboard is not traction. It's a promise made in public — which is a useful thing to make, because it means we now have to be worth the drive-by.

So if you saw it on your commute and you're curious: go try it. If it doesn't save you money or time, tell me and I'll want to know why. That's more useful to me than any impression count.

And to the team that shipped this — thank you. Building the thing is hard. Believing it deserves to be seen is harder.

flatkey.ai — one key to every AI model and tool.

How Elon Musk Sees China's AI

Hunter G — Sun, 02 Aug 2026 08:18:56 +0000

How Elon Musk Sees China's AI

The Economist just released its 85-minute interview with Elon Musk — his first long one since the SpaceX IPO. About ten minutes of it is on China's AI, and he doesn't hedge.

The line that matters: China will probably be the leader in AI. Not "might be." Not "worth watching." It's the conclusion he reaches after working through the constraints.

He starts by conceding ground

Asked about Kimi K3, released last week and reportedly almost as good as Fable, he says realistically Fable is still clearly the smartest model — but adds that the Kimi model is getting quite close. There are, he says, several very competent Chinese AI companies.

The actual argument

Then comes the deduction. Chinese AI companies got here with relatively little compute. So: what if they had a lot? "There's a good chance that they would be the leaders. And at some point they probably will have a lot of compute. So they will be the leaders."

Notice the structure. He turns "China leads" from a position into a deduction — the premise is compute, and compute is just a matter of time.

The constraints: electricity and chips

He reduces AI to two things: electricity and AI chips.

Then the number most people haven't internalized: China already produces more electricity than the United States, Europe and India combined. And it's still climbing — his estimate is China eventually reaches four times US electricity production, roughly proportional to population.

The asymmetry

The most interesting part is an asymmetry. Outside China, the binding constraint is electricity — AI chips are now being manufactured faster than new power comes online, and the real bottleneck is power and cooling, not silicon. (He also debunks a popular claim in passing: AI's water usage is negligible. It's the electrical demand that's high.)

Inside China, the constraint is chips, because the US banned exports of the latest AI chips. China is, in his words, somewhat chip starved.

But that asymmetry is being flattened by two things: China is getting much more efficient with the chips it has — Kimi K3's efficiency being the example — and, more consequentially, he says China is closer than most people realize to solving the lithography problem, which would let it manufacture AI chips at very large volumes.

On export controls

He's blunt. The US can pass a law stopping American companies from using Chinese models, but it can't stop the rest of the world. And: "I don't think that helps. That won't stop China from being the leader in AI."

Robots

He adds a piece people often miss — robotics. China has very good robot companies. He mentions their robot sporting events, including boxing matches, and a clip he saw of a robot that kept fighting after its head was knocked off.

Safety runs through China

His conclusion on safety is the part worth sitting with. He has proposed that leading labs get a week of private cross-testing before frontier releases — via API, not handing over the model. Talking about China, he widens it himself: that mechanism should probably include the Chinese companies doing frontier models too. And when it comes to enforcement, only two governments actually have the power to act — the US and China.

Takeaways

Two things I'm taking from this. First, don't treat "Chinese models are cheap" as the whole story; doing near-frontier work on far less compute is itself hard power. Second, electricity is the underrated variable. While everyone argues about chip bans, the real bottleneck may be the grid — which is why compute and token supply chains will be some of the most valuable real estate of the next few years.

Source: The Economist, "The full-length interview with Elon Musk," 29 July 2026.

6 Questions Every Enterprise Has to Answer About AI

Hunter G — Sun, 02 Aug 2026 07:42:30 +0000

You've probably sat in this meeting.

Someone asks, "so where are we with AI, actually?" — and six people give six different answers.

Last year, the questions were "should we do this?" and "how do we prove ROI?" This year, those questions have mostly disappeared.

What replaced them are harder, more foundational questions. If nobody at your company is asking them yet, that's the thing to worry about.

NLW came back from KPMG's annual Tech and Innovation Symposium with six questions that kept surfacing there. Almost none of them have answers right now. But they're the right questions.

First, the shift itself

The paradigm change already happened: from assisted AI (it helps me work) to agentic AI (it does the work).

Enterprises spent three years anticipating this. Now that it's here, every question has been swapped out — they're all about how to solve the new problems this new way of working creates.

NLW's read: 2026 is the year "AI is not a technology problem, it's a transformation problem" finally came home to roost.

Question 1: Are you redesigning, or bolting on?

The keyword is redesigning.

The strongest warning from KPMG's Steve Chase on the panel was this: bolting an AI strategy onto existing processes and systems is a recipe for trouble.

In the assisted-AI era, bolting on just meant you under-used the potential. In the agentic era, the cost gets much worse.

Question 2: Are you thinking in architectures, or still picking vendors?

When a new challenge arrived, the old corporate reflex was "which vendor solves this best?"

That's no longer sufficient.

Thinking in architectures means three concrete things:

A multi-model system — different intelligence tiers for different task difficulties
A routing layer — off-the-shelf or bespoke, getting requests to the right model
Harness design — which people and functions get which context, data, and system integrations, and what guardrails surround them

Question 3: How do you provision cost across groups?

The third question is about money: who spends what.

Underneath it sits another systems requirement — monitoring and measuring AI usage.

NLW put it vividly: you haven't heard the word "token" this often at an event since the height of the crypto era.

Without visibility into AI cost and its relationship to output, you can't decide which individuals, teams, or projects should get which models, at what magnitude.

Question 4: Enablement is messy work, not cute videos

This is the one I related to most.

The consensus in the room: this will not be a set of nicely-produced corporate training videos.

It's real, messy work — pushing people to use new tools to do new things, then figuring out how to transmit knowledge from the parts of the org that have figured it out to the parts that haven't.

The pattern that kept recurring was pairing: putting AI-redesigned engineering teams and early adopters together with business units.

Note what nobody was saying: that marketing will replace engineers. What they were discussing is how the 10–20% of skills — and more importantly the mindsets — that engineers and PMs carry become part of the essential toolkit for marketing, sales, and back-office people.

Question 5: What about externally? How do business models change?

Everything above is internal transformation. But there's an external dimension too.

Directions discussed on site:

Moving from input-based pricing (like hourly billing) to outcomes-based pricing
New categories of products and services
Re-evaluating what the old product even is — if agents can run an audit persistently, what is an audit?

Most organizations, though, treat themselves as "patient zero": shore up how they work internally first, then decide whether to radically change what they sell.

The hard part is that nobody gets to shut down for six months to figure it out. You do it in real time, while still servicing legacy customers on legacy products through legacy delivery.

Question 6: How do you design for becoming obsolete?

The last question is the most counterintuitive.

If you're building new systems, how do you build dynamism, planned obsolescence, and ephemerality into them from the start?

Harnesses will change. Interaction patterns will change. Customer expectations will change. Markets will change. Policy will change.

So anything you build today has to assume: a few months after it's ready, it will likely need rebuilding.

Almost none of these six questions have answers right now.

But that's exactly what should feel reassuring — people are finally asking the right ones. Last year the room was full of "how do I convince others this is real?" This year it's "how do we redesign for a new era?"

If I compress it to one line: AI isn't a tool you buy and install. It's redesigning the organization around agentic work.

And that stack in questions 2 and 3 — multi-model tiering, routing, token-cost observability — is precisely why we're building Flatkey. Every enterprise is going to need that layer eventually.

Based on The AI Daily Brief (hosted by NLW), "6 Questions Every Enterprise Has to Answer About AI," recorded around KPMG's annual Tech and Innovation Symposium. This is a structured secondary read; views and data per the original podcast.

DeepSeek V4-Flash Update Delivers Top Scores at Ultra-Low Prices

Hunter G — Sun, 02 Aug 2026 06:48:02 +0000

DeepSeek shipped the official V4-Flash on July 31 — open weights, MIT license, and a technical report, all on day one.

The striking part isn't that the score is high. It's that the score and the price arrived together: 50 on the Artificial Analysis Intelligence Index, at $0.14 / $0.28 per million tokens.

The day before, OpenAI had cut GPT-5.6 Luna by 80%. In a single day, the token price war opened.

It got better without getting bigger

The key facts, per DeepSeek's release and technical report:

DeepSeek-V4-Flash-0731 is the official release, superseding the preview, with substantially enhanced agentic capabilities.
The architecture didn't change: the same efficient MoE core (~284B parameters, ~13B active), a speculative decoding module attached, 1M context.
The price didn't change either — same as the preview.

Which means it got stronger not by scaling up, but through post-training.

The result: the smaller Flash beats DeepSeek's own larger V4-Pro preview on Terminal-Bench 2.1 (82.7), DeepSWE (54.4), Toolathlon (70.3), and Cybergym (76.7).

Artificial Analysis puts it at 50 on the Intelligence Index — a 10-point jump over the April V4 Flash, 6 points ahead of V4 Pro, and among the top 3 open-weights models.

The price is the payload

Per million tokens (input / output):

Model	Input	Output
DeepSeek V4-Flash	$0.14	$0.28
GPT-5.6 Luna	$0.20	$1.20
GPT-5.6 Terra	$2	$12

Artificial Analysis reports DeepSeek completing equivalent benchmark tasks at roughly 105x lower cost than Fable (some independent runs put the range at 105–137x).

One comparison making the rounds: Opus 5 shipped just 7 days earlier. On one task, Opus 5 got it right in one shot where DeepSeek took three — but DeepSeek did it in ~900 lines versus ~3000, and the run cost one cent.

Be honest: cheap tokens ≠ cheap outcomes

Here's the counterpoint, and it matters.

A developer hid 105 bugs across two real codebases. V4-Flash fixed 8 — last place. But the same run cost $0.61, versus $68.08 for Fable 5. Note the unit: cost per task, not per million tokens.

That points at a real shift in measurement:

Cheaper per token can be misleading. If a model needs more turns, the total cost per task can end up higher.

So the right question isn't "which model is cheaper per token." It's "what did it cost to actually get this done, and in how many turns?" Watch the verifiable outcome, not the proxy metric.

Open weights + MIT is a distribution move

The most strategically loaded part isn't performance or price — it's how it shipped: weights open on day one, MIT license, technical report included.

The timing wasn't lost on observers: in the same week Washington floated AI controls and Congress introduced a kill-switch bill, a frontier-class model was published as free software.

Stack that on OpenAI's 80% cut the day before — "an 80% price cut isn't a discount, it's a weapon" — and the shape of the fight is clear: frontier intelligence is being pushed toward zero, and open weights plus near-zero pricing is redrawing who controls distribution.

Three takeaways

Getting better no longer requires getting bigger. Same structure, same price, post-training pushed Flash past its own Pro.
Measure cost per task, not price per token. Cheap tokens don't guarantee cheap results.
Open weights + near-zero pricing is a declaration of war on distribution. Who gets to price "access to the frontier" is no longer settled by a handful of labs.

Two implications for anyone building. First, when the best model changes weekly and prices can drop 80% overnight, you shouldn't be hand-picking models — you want a routing layer that trades off cost and capability for you. That layer gets more valuable as the price war escalates.

Second, when intelligence trends toward free, the scarce thing is no longer intelligence. It's judgment, and the taste to point it somewhere that matters.

Based on DeepSeek's official release (DeepSeek-V4-Flash-0731 weights, MIT license, technical report), Artificial Analysis benchmarks and cost comparisons, and independent developer tests discussed publicly. Data and specs per official and third-party sources.

Don't build another app — build an MCP server: the real signal of MCP's biggest update

Hunter G — Wed, 29 Jul 2026 19:17:37 +0000

Anthropic just shipped the biggest MCP update since launch (MCP 2026-07-28). Most write-ups read like a changelog: stateless core, extensions, auth hardening.

But if you actually build things, the update has one real signal: your distribution channel just got upgraded.

MCP is now the HTTP of the AI era — and the pipe is enterprise-grade, runs on serverless, and can render your UI inside Claude itself. Which points at a very concrete move: stop building another app to fight for attention. Build an MCP server, and let the agent ecosystem be your distribution.

(Based on a 新智元 / 36kr write-up and Anthropic's official MCP blog; specs per Anthropic.)

The standard war is over

400M+ monthly SDK downloads (4x this year).
TypeScript and Python each past 1 billion cumulative downloads.
950+ MCP servers in the Claude store, used by millions daily.

As Anthropic frames it: HTTP wired the world's computers into the internet; MCP is wiring the world's software, data, and APIs into a network an AI orchestrates. For builders, "should I use MCP" is settled. The question is whether you're on the rail.

Signal 1: the core went stateless — so your server can run serverless

The change developers wanted most: MCP moved from stateful (session state, connection handshakes, hard to scale in cloud-native setups) to a pure request/response model. Every request is self-describing (identity and capabilities live in _meta).

The payoff:

Serverless / edge: deploy the server to AWS Lambda, Vercel, Cloudflare Workers — no renting a persistent box for a few KB of session state.
Unlimited horizontal scaling: put it behind a plain round-robin load balancer; any machine can handle any request.
Need state? Generate an explicit Handle the model passes back as a parameter — not hidden in the transport layer. Cleaner, and it fits how the model thinks.

Translation: building an MCP server now costs about as much as writing one serverless function. The channel got bigger and the bar to get on it dropped — those two happening together is the actual opportunity window.

Signal 2: extensions are first-class — you may not need a front-end

Anthropic promoted Extensions to first-class citizens with an official framework. Three launch features, and the first is the one that should reframe how you think about products:

MCP Apps: your server renders an interactive UI right inside the Claude chat (a sandboxed iframe). Ask Claude for revenue data → it renders a live interactive dashboard in the thread. Ask it to run a cloud server → a control panel pops up. No more tab-switching between Claude and every SaaS app.
Tasks: long-running async work (analyze 100GB of logs, render a 3D video) via polling + a subscription stream.
Enterprise Managed Auth (EMA): central access control through Microsoft Entra, Okta; zero-touch SSO.

MCP Apps is the punchline: your interface can live inside Claude. You don't build a front-end, pull a user base, and educate a market. You make the capability; the channel carries the interface and the users.

Signal 3: the pipe now reaches inside the firewall

The protocol got an 18-month production-hardening pass: MRTR (multi round-trip requests) replacing long-lived connections, header-based routing (Mcp-Method/Mcp-Name so gateways/rate-limiters route without parsing JSON), cacheable list responses (ttlMs + cacheScope — prompt cache is money), and military-grade auth (production OAuth 2.0/OIDC, RFC 9207, deprecating DCR for CIMD — finally killing the localhost redirect_uri pain for CLI clients).

The headline for enterprises is MCP Tunnels (research preview): connect Claude to an internal MCP server with no public IP, no inbound firewall rules, no IP allowlist — an encrypted tunnel under the corporate firewall, so finance/health/gov data can reach AI safely. Figma, Intuit, Netlify, and Zoom are backing it — their hardest requirements (design assets, finance-grade auth, serverless-native statelessness, low latency) all satisfied at once. That's MCP crossing from "geek toy" into the enterprise deep end.

The takeaway: build a capability, not another app

The real signal of this update isn't "the protocol got better." It's that distribution got upgraded and the bar to get on it dropped, at the same time — standard established, enterprise-grade, serverless-runnable, UI-lives-in-Claude.

So the concrete move for builders: don't build another website or app to fight the whole world for attention. Build an MCP server, and let the agent ecosystem be your distribution. API first, UI later — because the interface (MCP Apps), the users (millions), the enterprise access (Tunnels), and the billing/caching are already laid down for you.

Agents are the new distribution channel. This update paved the road into a highway. All four Tier-1 SDKs (TS/Python/Go/C#) are updated, with a 12-month deprecation window for the old way. The cheapest ticket into the age of agents is to go refactor one MCP server of your own — the next hit might be sitting in that list of 950+.

Based on 新智元 (author ASI启示录), republished by 36kr, and Anthropic's MCP blog / @ClaudeDevs. Data and specs per Anthropic; this is a structured secondary read.