Latest / Braid / The Bottleneck Moved, Grok 4.3 Got Worse, and Sam Altman Quietly Stopped Saying UBI

Transcript

The Bottleneck Moved, Grok 4.3 Got Worse, and Sam Altman Quietly Stopped Saying UBI · Braid

• 0:04
  Rogé Karma's piece in the Atlantic this morning is titled "Maybe AI Isn't a Bubble After All," and the framing that caught me is buried about a third of the way down.
• 0:15
  Karma argues that the bear case people have been making for the last eighteen months — that demand for these models is propped up by venture money and will collapse the moment buyers see the bill — has aged badly.
• 0:30
  Not because the bears were wrong about the bills.
• 0:33
  They weren't.
• 0:34
  The bills are exactly as large as the bears said they'd be.
• 0:38
  They aged badly because the bills are getting paid.
• 0:42
  Karma's central data point is Anthropic.
• 0:44
  Annualized revenue moved from roughly fourteen billion to roughly thirty billion dollars in two months, and almost all of the delta is Claude Code adoption inside engineering organizations.
• 0:57
  Not consumer Claude.
• 0:59
  Not the chat interface.
• 1:00
  The CLI tool that writes code.
• 1:02
  Several enterprise buyers Karma talked to are now spending close to ten percent of their engineering labor cost on AI tooling — a line item that didn't exist eighteen months ago and that, on every internal tracking dashboard those CFOs showed her, is still climbing.
• 1:21
  The revenue number isn't the part that lands; the bear thesis depended on an inflection that didn't happen.
• 1:28
  The bear thesis was: enterprises will try this stuff, the demos won't survive contact with real workloads, the contracts won't renew, and the music will stop.
• 1:39
  The contracts renewed.
• 1:41
  They renewed at higher seat counts.
• 1:43
  The music kept playing.
• 1:45
  What changed instead is which thing is scarce.
• 1:48
  The bear thesis didn't break on a model release.
• 1:51
  It broke on a substation lead time.
• 1:54
  The constraint people are hitting in 2026 isn't 'will customers pay for this.' It's 'can the hyperscalers get power and chips fast enough to deliver what's already been committed.' Karma quotes one Microsoft VP saying their twenty-twenty-eight capacity is sold.
• 2:12
  Not allocated.
• 2:13
  Sold.
• 2:13
  To customers who have signed contracts and put down deposits.
• 2:18
  That shift changes the planning horizon for almost everyone listening, and I'll come back to what it means in a few minutes.
• 2:26
  First, a follow-up from yesterday I owe you.
• 2:29
  Yesterday I flagged that internal numbers were showing Grok 4.3 had regressed against 4.2 on a non-hallucination benchmark, and I said I'd wait for a third-party harness before treating it as real.
• 2:43
  The third-party harness arrived.
• 2:45
  LMSys reproduced the regression this morning on NYT Connections — a benchmark that specifically rewards holding multiple constraints in working memory and then collapsing them into a single answer.
• 3:00
  Grok 4.2 scored ninety-three point four.
• 3:03
  Grok 4.3 scored sixty-seven point five.
• 3:05
  Same prompt, same scoring, three reproductions.
• 3:09
  LMSys notes that Connections is not a hallucination test in the standard sense.
• 3:15
  It's a working-memory test dressed as a word puzzle.
• 3:18
  The model has to track sixteen words, four hidden categories, and the constraint that each word goes in exactly one category.
• 3:27
  A twenty-six point drop on that class of problem is not a sampling artifact.
• 3:33
  Something in the 4.3 training run cost the model an ability it had two weeks ago.
• 3:39
  xAI hasn't responded publicly.
• 3:41
  There's no rollback announcement, no 4.3.1, no acknowledgment from the team.
• 3:47
  If you're routing production traffic to Grok 4.3, the regression is no longer a rumor.
• 3:53
  It's measured, on a public harness, against a specific class of task.
• 3:58
  I'd pin to 4.2 until xAI says something.
• 4:01
  A broader note, because we're going to keep running into it: the speed at which third-party harnesses can confirm or refute a vendor's release notes is one of the more underrated stories of this year.
• 4:15
  A regression like this would have taken three months to surface in 2024.
• 4:20
  It took less than forty-eight hours in 2026.
• 4:24
  The eval ecosystem is doing what eval ecosystems are supposed to do, and the labs that ship fast and hope no one notices are starting to lose that bet.
• 4:35
  Back to the Atlantic piece.
• 4:36
  Karma's framing isn't just a financial story.
• 4:39
  If you accept the premise — and I think the evidence is strong enough to act on, though I'd be careful about how confidently you state it — then several practical things change for anyone building on top of these models.
• 4:54
  First: pricing assumptions.
• 4:56
  The 'inference will be free in two years' line that's been a default in product planning decks for a while is, at minimum, on hold.
• 5:05
  If the binding constraint is power and chips, the marginal cost of a token has a floor that's set by physical infrastructure, not by software efficiency.
• 5:15
  Token costs will keep falling on the dimensions where software gets cleverer — speculative decoding, better quantization, smaller dense models that match larger MoEs — but they will not fall through the floor that's set by 'how much does it cost to build a substation.' Plan accordingly.
• 5:34
  Second: vendor risk shape.
• 5:35
  The risk of your model provider going under because they can't make money has dropped.
• 5:41
  The risk of your model provider being unable to serve you at peak because they couldn't get capacity in time has gone up.
• 5:49
  Those are different risks and they call for different mitigations.
• 5:54
  The first one you handle by having a payment relationship with two vendors.
• 5:59
  The second one you handle by having actual fallback routing and by negotiating reserved capacity into your contract.
• 6:06
  A lot of teams I see are still optimized for the first scenario.
• 6:11
  Third: timeline expectations.
• 6:12
  If a hyperscaler tells you something will be available 'in the second half of 2027,' the question to ask is no longer 'will the technology be ready.' It's 'do you have the substation.' Substations have lead times measured in years and a permitting process measured in jurisdictions.
• 6:31
  A delay on a single piece of grid infrastructure can move a product launch by two quarters in ways that have nothing to do with the model.
• 6:40
  Ethan Mollick had a thread on this yesterday I'll quote in full, because Mollick is one of the few academics who actually talks to procurement.
• 6:50
  He wrote: 'The interesting question stopped being will anyone pay for this a year ago.
• 6:56
  It's now can the grid keep up with the people who already are.' His read, from CIO conversations he's been doing, is that adoption inside large engineering organizations has outrun the public narrative by twelve to eighteen months.
• 7:11
  The 'agents are still demos' frame, he says, is mostly a consumer-side observation.
• 7:16
  B2B usage looks different.
• 7:18
  The CIOs he talks to are not asking whether to buy more.
• 7:22
  They're asking whether the capacity will be there in Q3.
• 7:26
  I want to be careful here, because the demand-side data is partial and it's coming from people who have an incentive to tell a particular story.
• 7:35
  Karma is reporting; Mollick is synthesizing; the CIOs are not under oath.
• 7:40
  But the direction of the signal is consistent across enough independent sources that I'd treat it as the working hypothesis until something contradicts it.
• 7:50
  If you're a builder making bets that depend on infrastructure timelines, this is the lens to plan in.
• 7:57
  The parallel Karma reaches for is the late-90s telecom buildout — fiber rolled into the ground, a glut, a bust, then a decade of rising demand that absorbed all of it.
• 8:08
  The shape of the analogy is right; the demand-side fundamentals look stronger this time, because the use case is being paid for at deployment instead of speculated about for the future.
• 8:20
  But analogies are analogies, and the failure mode of this one is the same as the failure mode of every analogy that ends 'and that's why this time is different.' I'd hold the parallel loosely.
• 8:33
  Sam Altman posted a long thread late last night that, on a slow news day, would have been the lead.
• 8:40
  The headline move: he stepped off the UBI framing he's been carrying since the 2021 Moore's Law for Everything essay, and replaced it with what he's now calling 'collective ownership of compute.'
• 8:59
  The thing that's actually scarce now is access to compute, and that's what we should be thinking about distributing.' The thread runs about a dozen tweets and the structure of the argument is: cash transfers solve a distribution problem in an economy where most people produce something the market wants to buy; if AI does what he thinks it will do, the production side of that equation changes shape; the lever that matters is therefore not redistributing income, it's redistributing access to the means of producing income, which in his framing is compute.
• 9:37
  The replies are heated and they break in roughly the directions you'd expect.
• 9:42
  The good-faith critique is that 'collective ownership of compute' doesn't pay rent — that there's a window between 'jobs disappear' and 'everyone gets compute credits' where actual people need actual money for actual landlords, and Altman's framing punts on that window entirely.
• 10:01
  The less-good-faith critique is that this is a convenient pivot for someone whose company would be the natural recipient of public investment in 'collective compute infrastructure.' Both critiques have a point.
• 10:15
  My own read: the substantive shift here is that Altman has moved from a redistribution frame to an access frame.
• 10:23
  That's a meaningful shift in policy ground, because it points toward a very different set of interventions — public compute clusters, subsidized API access, education vouchers denominated in tokens — and away from cash transfers that don't presuppose the existence of a particular technology stack.
• 10:43
  Whether you think that's a better or worse direction depends on your priors about what AI is going to do to labor markets.
• 10:51
  What I'd watch is whether anyone in the policy world picks up the access framing seriously, because if they do, the conversation about AI and work is going to get reshaped along lines that look much more like spectrum auctions than welfare reform.
• 11:08
  One more thing.
• 11:09
  Altman didn't say he was changing his mind.
• 11:12
  He said the situation changed.
• 11:14
  That move lets him retire a position without owning the retirement.
• 11:19
  I don't think he was wrong to update; the world did in fact change between 2021 and 2026.
• 11:25
  But the public conversation he started with the original UBI essay loses its anchor when he quietly walks the anchor away.
• 11:33
  The ARC Prize team posted a leaderboard update for ARC-AGI-3 this week, and the headline finding is one I think is interesting.
• 11:41
  Long-thinking models — the test-time-compute-scaling story that's been the dominant scaling lever of the last eighteen months — are not reliably outperforming their fast siblings on this benchmark.
• 11:55
  In several cases they score worse.
• 11:57
  The top score is still in the low thirties.
• 12:00
  The saturation curve we saw on ARC-AGI-2 — where models went from twenty to seventy in roughly a year — is nowhere in sight.
• 12:08
  And the leaderboard now reports cost per task alongside accuracy, which is the part I'd point at if you're triaging this.
• 12:17
  The most expensive runs are not the most accurate.
• 12:20
  The Pareto frontier on this benchmark is bending the wrong way.
• 12:24
  The ARC team's read is that the benchmark seems to penalize the kind of search that helps on math.
• 12:31
  They don't have a confident mechanism yet.
• 12:34
  The hypothesis they're entertaining is that ARC-AGI-3 problems reward holding a single coherent program-level abstraction in mind, and the long-thinking models — by virtue of decomposing aggressively and exploring multiple branches — actually lose track of the abstraction they're supposed to be building.
• 12:54
  If that's right, it's a story worth taking seriously.
• 12:58
  The dominant scaling lever of the last eighteen months has been 'spend more inference compute, get better answers.' If there's a class of problem where that lever doesn't pull, then either the lever isn't the right one for that class, or the benchmark is measuring something other than what we thought it measured.
• 13:19
  Either is interesting.
• 13:21
  Either matters for anyone betting on agents that have to plan over novel structure they haven't seen before.
• 13:28
  The one open question I have is whether 'long thinking hurts on ARC-AGI-3' is a property of the benchmark or a property of how the long-thinking models were trained.
• 13:39
  It's plausible that the RL signal those models were optimized against systematically favors decomposition, and that ARC just happens to be a domain where decomposition is the wrong move.
• 13:52
  If that's the explanation, you'd expect to see the gap close as soon as someone trains a long-thinker with an ARC-style RL signal mixed in.
• 14:01
  We'll see.
• 14:02
  Two things from the local-LLM side this week that file under 'capability you can run yourself just got better.'
• 14:11
  A poster on the LocalLLaMA subreddit published numbers on a speculative prefill technique they're calling PFlash, and the headline number is a ten times reduction in first-token latency at 128K context on a single RTX 3090.
• 14:28
  The mechanism: train a tiny half-billion-parameter drafter to score how much each prefill token actually moves the KV cache, then route the low-scoring tokens through a cheaper attention kernel.
• 14:43
  The author's own number on a 3090 at 128K: forty-seven seconds down to four point six seconds for first-token.
• 14:51
  Quality loss reported as 'inside noise' on three retrieval benchmarks, though they explicitly note they have not yet evaluated on long-context reasoning, which is the case I'd most want to see numbers on.
• 15:07
  The technique, if it holds up, changes what's feasible to build locally.
• 15:12
  Prefill latency is what makes long-context applications feel slow.
• 15:17
  If you can pay forty-six hundred milliseconds instead of forty-seven seconds for a 128K prompt on a consumer card, the set of things you can put in front of an interactive user gets noticeably bigger.
• 15:32
  RAG over a whole codebase.
• 15:34
  Agent context windows you actually populate.
• 15:37
  Prompts you don't have to chunk.
• 15:40
  The patch is against vLLM and a fork of llama.cpp, with a PR open against mainline.
• 15:46
  I'd watch that PR.
• 15:48
  Speculative decoding took roughly six months to go from 'cool Reddit post' to 'standard inference path.' If PFlash converges on the same trajectory, by Q4 the prefill story on consumer hardware looks very different than it does today.
• 16:05
  Second: Qwen 3.6, the 27B dense version.
• 16:08
  There's a clean writeup on the LocalLLaMA subreddit from a poster who got it running well on a single 3090 under Windows.
• 16:17
  The headline: a Q4_K_M quant fits in about 17 gigabytes of VRAM, and the throughput at 8K context lands around 25 tokens per second under Ollama.
• 16:28
  The model itself reportedly matches or beats the older Qwen 397B mixture-of-experts model on several public benchmarks — which, if you remember, we covered when it shipped as a frontier-relevant open release.
• 16:44
  The pattern keeps repeating: a smaller dense model trained with a year of additional knowhow catches a much larger MoE from twelve months ago.
• 16:55
  If that pattern holds for another generation, the case for a single 3090 as 'enough hardware to do real local agent work' gets stronger every quarter.
• 17:06
  The setup notes for Qwen 3.6 are mildly painful — there's a CUDA toolkit version pin and a tokenizer fix needed for the GGUF build that aren't in the README — but once you're past those, the throughput-per-dollar number is hard to argue with.
• 17:24
  Three smaller items to round out with, because each of them gets at a piece of how this is shaping the craft.
• 17:31
  First, Open Design.
• 17:33
  A new GitHub repository launched this week as a local-first alternative to Anthropic's Claude Design.
• 17:39
  Thirty-one skills, seventy-two design systems, MIT-licensed, and the architectural choice that strikes me as the most interesting one in this space: it does not bundle or call a hosted LLM.
• 17:52
  The README is explicit about it.
• 17:54
  Open Design treats your existing CLI agent — Claude Code, Codex, Cursor, whatever you have — as the engine.
• 18:01
  They ship the skill library, the design systems, and the local index.
• 18:05
  You bring the model.
• 18:07
  That separation of concerns is the cleanest one I've seen in this category.
• 18:12
  It dodges the lock-in question that hangs over every hosted design tool, because the skills are files on your disk and the model is whatever you already pay for.
• 18:22
  It also has the practical effect that, if you switch CLI agents next quarter, your skill library doesn't move.
• 18:29
  I'm going to spend some time with this one this weekend.
• 18:33
  It's the kind of pattern I'd like to see propagate.
• 18:36
  Second, Hamel Husain published a three-month writeup on Devin in a real codebase.
• 18:42
  Husain runs an evals consulting practice and has been one of the more measured public voices on agent reliability for the last two years, so when he writes a long post about a tool he's been using day in and day out, it weighs more than another screenshot thread.
• 18:59
  His framing — and I'll quote — is that Devin is 'a junior who's read the docs and never the bug tracker.
• 19:06
  Useful for net-new files and small refactors.
• 19:09
  Useless for anything where the answer lives in last quarter's incident postmortem.'
• 19:17
  Devin handles greenfield work and isolated refactors well.
• 19:21
  Where it falls over is on problems whose solution depends on institutional context that lives outside the repository — the postmortem from the outage three months ago, the Slack thread where someone explained why a particular function returns null instead of throwing, the design doc that nobody updated.
• 19:41
  Husain is careful to frame this as a context-availability problem, not a model-capability problem.
• 19:47
  The model could probably reason about the postmortem if it had access to the postmortem.
• 19:53
  It doesn't.
• 19:54
  I think that's the right diagnosis, and I think it points at the work that actually gets you a useful coding agent: not bigger models, but better plumbing into the institutional memory of the team.
• 20:07
  That's the bet I'd make on what separates the agents that get used in real codebases from the ones that don't.
• 20:14
  Third, a short essay from EvilGeniusLabs titled 'Learning Programming, Not Programming Languages.' The argument is straightforward and I think correct: an LLM will write you syntactically correct Rust before you finish describing what you want, but it can't decide whether your problem is a Rust problem.
• 20:34
  The author's line: 'That decision is the job, and it doesn't have a syntax.'
• 20:45
  The default education path — pick a language, do a tutorial, build a CRUD app — was already weak before the codegen tools got good.
• 20:54
  With capable codegen, it's worse than weak; it's actively misleading about what the marginal value of the engineer is.
• 21:02
  The marginal value is system design, data modeling, and reasoning about runtime behavior under load.
• 21:08
  None of those have a syntax to memorize.
• 21:11
  All of them require building enough systems, in any language, to have intuitions about how systems break.
• 21:18
  One last item, because the discourse around it is going to get worse before it gets better.
• 21:24
  WIRED published an investigation into a 501(c)(4) called Build American AI.
• 21:28
  Per the FEC filings WIRED reviewed, the funding traces to OpenAI- and Palantir-adjacent donors.
• 21:34
  The campaign pays creators five thousand dollars per TikTok to deliver a templated message.
• 21:40
  The template, per WIRED, includes the line: 'China is trying really hard to beat the US in AI, and Washington is trying really hard to stop us from winning.'
• 21:59
  The framing of the campaign positions domestic AI regulation as a national-security risk rather than a safety question, and it's effective enough that you have probably already seen the videos in your feed without registering them as a coordinated campaign.
• 22:15
  I'm flagging this not to render a verdict on whether the policy position is right or wrong.
• 22:21
  There are serious people who think US AI competitiveness with China is the most important policy question of the decade, and there are serious people who don't.
• 22:31
  My point is narrower: the 'we have to beat China' frame is shaping a lot of policy right now, and it's being amplified in part by a paid creator program that wasn't disclosed until a journalist asked.
• 22:44
  That should change how a builder weights the discourse — and it should change what they say in their own posts, if they care about the difference between sharing an opinion and unknowingly amplifying a campaign.
• 22:57
  A closing note.
• 22:58
  If there's a thread connecting today's items, it's that the constraint moved.
• 23:03
  Karma's bear thesis broke on a substation lead time, not a model release.
• 23:08
  Grok 4.3 lost working memory, not hallucination resistance.
• 23:11
  ARC-AGI-3 keeps refusing to be saturated by longer reasoning traces.
• 23:16
  And the work of programming isn't a tutorial anymore.
• 23:19
  The constraint moved in each case, and the people who keep building from yesterday's constraint are the ones who get blindsided.
• 23:27
  That's what I'm watching tomorrow.
• 23:29
  — Lenar.