Latest / Braid / Fogbank for Code, Pinned Carriers, and a Frontier Model in 90 Gigabytes

Transcript

Fogbank for Code, Pinned Carriers, and a Frontier Model in 90 Gigabytes · Braid

• 0:04
  DeepSeek V4-Flash now fits on a 128 gigabyte Mac.
• 0:07
  Prince Canuma posted the recipe a few hours ago: a 2-bit dynamic quant, with the experts at Q2 and the rest of the model at Q4, ninety gigabytes on disk.
• 0:18
  He credits Salvatore Sanfilippo — antirez — for the mixed-precision tip.
• 0:23
  The quantized weights are live on the mlx-community Hugging Face org as I'm recording this, with compute donated by Lambda.
• 0:32
  We mentioned this yesterday as a one-line note.
• 0:35
  Today it has shipped weights and a working laptop demo, so it's worth slowing down for a minute.
• 0:42
  The recipe is the part that earns the slowing down.
• 0:45
  A flat 2-bit quant of an MoE model with this many experts loses too much signal — you can feel it in the first few tokens of any non-trivial generation.
• 0:56
  The mixed scheme keeps the routing layers and attention heads at four bits, where the precision matters, and pushes the per-expert FFN weights down to two.
• 1:07
  You give up the least where you can't afford to.
• 1:10
  The practical line for a developer: if you have an M-series Mac with 128 gigabytes of unified memory, you can pull this collection down today and run a model in the V4 family on the machine you write code on.
• 1:25
  Not a stripped-down distill, not a 7B with the same name slapped on the front — the actual V4-Flash weights, quantized to fit.
• 1:34
  Canuma also slipped in an operational note in a separate thread that I think is the most useful sentence I've read about this hardware all week: traditional profiler metrics on Apple Silicon don't always translate to end-to-end performance.
• 1:51
  You can save ten milliseconds in a module and see no overall improvement, because the bottleneck is somewhere else in the unified-memory bandwidth picture.
• 2:02
  You need custom metrics.
• 2:04
  If you're optimizing inference on this platform, take that seriously.
• 2:09
  The altitude here isn't 'frontier model goes to the laptop' as a headline.
• 2:14
  It's the smaller, more specific thing — another point on a curve that has been moving for two years now, where the gap between something existing on a cloud cluster and running on the machine in front of you keeps closing.
• 2:30
  Six months ago, V4 on a single workstation was a server-rack fantasy.
• 2:34
  Today it's a download.
• 2:36
  From a download to a hang.
• 2:38
  Shubham Raizada published one of the cleanest writeups of a real production failure I've seen this month.
• 2:46
  The post is called 'Java Virtual Threads: The Pinning Problem, the Deadlock, and the Fix in Java 24,' and it's worth reading even if you're not a Java person, because it's a small, exact map of how a feature designed to make your service faster can stop it cold.
• 3:05
  The setup: Java 21 introduced virtual threads.
• 3:09
  The promise is that you can have millions of them, scheduled by the JVM onto a small pool of carrier threads — typically one per CPU core.
• 3:19
  The blocking calls you used to write — socket reads, future.gets, Thread.sleeps — get rewritten by the JDK to unmount the virtual thread from its carrier when it blocks, save the call stack to the heap as a continuation, and let the carrier pick up another virtual thread immediately.
• 3:40
  M virtual threads multiplexed onto N carriers.
• 3:44
  Same idea as goroutines.
• 3:45
  Here's where it breaks.
• 3:47
  If a virtual thread is inside a synchronized block when it tries to do blocking I/O, the JVM cannot unmount it.
• 3:55
  The reason is structural.
• 3:57
  A Java monitor — what synchronized acquires under the hood — tracks ownership by OS thread.
• 4:04
  When a virtual thread enters a synchronized block, the JVM records that the carrier owns the monitor.
• 4:11
  If you let the carrier swap in a different virtual thread, that new thread is now executing on a carrier that holds a lock it never asked for, and if it tries to enter the same synchronized block, monitor reentrancy lets it walk straight in.
• 4:29
  Mutual exclusion is gone.
• 4:31
  The JVM's only safe move is to keep the virtual thread pinned to its carrier until monitorexit.
• 4:38
  One virtual thread, one carrier, parked together for the duration of the I/O.
• 4:44
  Pinning by itself is just a missed throughput win.
• 4:48
  The deadlock arrives when enough virtual threads pin enough carriers that there are no carriers left to make progress on anything.
• 4:58
  Quote: 'VT-1 is now pinned to CT-1.
• 5:00
  VT-2 tries to enter the same synchronized block.
• 5:04
  It blocks waiting for the monitor.
• 5:06
  VT-2 is now pinned to CT-2.
• 5:08
  All carrier threads are now pinned.
• 5:11
  No carrier is available.'
• 5:15
  It's also what hit Netflix, who wrote up the same shape of incident — sockets piling up in CLOSE_WAIT, traffic stops moving, switching back to platform threads makes it disappear.
• 5:28
  Raizada walks both writeups and ties them to the JEPs.
• 5:32
  Then, because he's a working engineer, he ships a runnable demo.
• 5:37
  Save the file, run it with parallelism set to 2, watch four virtual threads complete in six seconds because they trip over their own carriers; switch to ReentrantLock and the same workload finishes in two.
• 5:52
  ReentrantLock works because it parks on LockSupport.park, which is virtual-thread-aware and unmounts cleanly.
• 6:00
  synchronized was written decades before the JVM had any concept of a virtual thread.
• 6:07
  Java 24 fixes this.
• 6:08
  JEP 491 rewrites monitor ownership to track the virtual thread, not the carrier, so synchronized stops pinning.
• 6:16
  Until you're on 24 in production — which most shops are not yet — the practical advice is unglamorous and important: do not call into blocking I/O from inside a synchronized block.
• 6:30
  Audit your codebase for that pattern before you flip the virtual-threads switch on a hot path.
• 6:37
  If you have library code you don't control that does it, you have a Netflix-shaped problem waiting for you.
• 6:45
  What I like about this post is that it doesn't editorialize.
• 6:49
  It treats virtual threads as a real feature with a real, well-documented edge, and walks the developer through the mental model carefully enough that you could explain it to a coworker without going back to the JEP.
• 7:05
  That kind of writeup is worth more than three keynotes.
• 7:09
  Denis Stetskov wrote the most considered piece I've read this month on what we talked about yesterday — the METR study showing experienced developers were 19% slower with AI tools while predicting they'd be 24% faster.
• 7:24
  His angle is unusual.
• 7:26
  He runs engineering teams in Ukraine, and he frames the AI coding question through the lens of the defense industry's last twenty years.
• 7:35
  The first half of the essay is a tour.
• 7:38
  In 2023, Raytheon's president stood at the Paris Air Show and described what it took to restart Stinger missile production after a two-decade pause.
• 7:48
  They brought back engineers in their seventies to teach younger workers how to build a missile from paper schematics drawn during the Carter administration.
• 7:59
  The seeker component was out of production.
• 8:02
  The nose cone still had to be attached by hand.
• 8:06
  An order placed in May 2022 wouldn't deliver until 2026.
• 8:09
  Four years, not because of money, because the people who knew how to build them had retired a decade earlier and nobody replaced them.
• 8:19
  In 2023 the EU promised Ukraine one million artillery shells in twelve months.
• 8:24
  They delivered about half.
• 8:26
  France had halted domestic propellant production in 2007 — seventeen years of nothing.
• 8:32
  A Nammo plant in Denmark had been shut down in 2020 and had to be restarted from scratch.
• 8:38
  Europe's defense industry had been optimized for small batches of expensive custom products.
• 8:45
  Nobody had planned for volume.
• 8:47
  On paper, efficient.
• 8:48
  In practice, one bad day from collapse.
• 8:51
  The load-bearing example, the one that gives the essay its title, is Fogbank.
• 8:56
  Fogbank is a classified material used in nuclear warheads.
• 9:00
  Produced from 1975 to 1989, then the facility was shut down.
• 9:04
  When the government tried to reproduce it for a warhead life-extension program in 2000, they discovered they couldn't.
• 9:13
  After spending sixty-nine million dollars and years of reverse engineering, they finally produced viable Fogbank — and then discovered the new batch was too pure.
• 9:24
  The original had contained an unintentional impurity that was critical to its function.
• 9:30
  That fact existed nowhere in any document.
• 9:33
  Only the workers who made the original batch knew it, and they had retired years earlier.
• 9:39
  That's the parallel he draws to software.
• 9:42
  Quote: 'It's Fogbank for code.
• 9:44
  When juniors skip debugging and skip the formative mistakes, they don't build the tacit expertise.
• 9:51
  And when my generation of engineers retires, that knowledge doesn't transfer to the AI.' His own hiring data is brutal: a recent round, 2,253 candidates, 2,069 disqualified, four hired.
• 10:04
  A 0.18% conversion rate for the rare combination of technical skill and the judgment to push back on a confidently wrong machine.
• 10:13
  I want to be careful with this one.
• 10:15
  The defense parallel is rhetorically strong, and rhetorical strength can paper over differences.
• 10:22
  The defense industry's collapse was driven by a deliberate Pentagon consolidation policy in 1993 — fifty-one major contractors squeezed into five — and by the absence of any market signal demanding the capability.
• 10:37
  Software has different incentives.
• 10:39
  Companies that lose the ability to maintain their own code base do find out, sometimes within a quarter, sometimes within a year.
• 10:48
  The feedback loop is shorter than thirty years.
• 10:51
  The part of his argument I can't shake is the timeline.
• 10:55
  Every defense ramp-up Stetskov cites — Stinger, Javelin, 155mm shells — took three to ten years to recover from optimization away.
• 11:04
  He maps that onto software: a junior needs three to five years to become competent mid-level, five to eight to become senior, ten or more to become principal.
• 11:15
  That timeline can't be compressed by money or by a model.
• 11:19
  If we're three years into the experiment of replacing junior hiring with AI assistance, the soonest we'd see the bill is in the late 2020s, when the seniors we should be growing aren't there.
• 11:33
  He's not predicting that bill comes due.
• 11:35
  He's saying we're betting that the models are good enough by then to make the bet pay off, and the defense industry made the same bet about peace.
• 11:45
  The sentence I'd put on a sticky note: 'Crises don't send calendar invites.' I think that's the right register for this argument.
• 11:54
  Not 'AI coding is a disaster.' Not 'we're all going to lose our jobs to it.' Just: this kind of optimization compounds invisibly for a long time before it shows up, and we are early enough in it that we can still do something different.
• 12:11
  He's reworked his own pull request templates to force structured context, added dedicated reviewers per project, refused to let AI review AI's code.
• 12:21
  None of those are revolutionary.
• 12:23
  All of them are in tension with the throughput gospel.
• 12:27
  I'd take them seriously.
• 12:29
  Matt Carey works on MCP and agents at Cloudflare, and he gave a talk at AI Engineer on Friday with the title 'MCP = Mega Context Problem.' The talk is the cleanest articulation I've heard of why the current MCP default — load every tool definition into the agent's context — was always going to fall over.
• 12:51
  The specific number is the one that anchors the whole talk.
• 12:56
  Cloudflare's full REST API has roughly 2,600 endpoints.
• 13:00
  Their OpenAPI spec is 2.3 million tokens.
• 13:03
  Compiled into MCP tool definitions, the tools alone are about 1.1 million tokens.
• 13:09
  Quote: 'That's never going to fly even with the biggest foundational models.' He's right.
• 13:15
  You don't get to use any context window for actual reasoning if the tool list itself has eaten it.
• 13:23
  The industry's first response — the one Cloudflare took, the one most providers took — was to split a single API across many product-scoped MCP servers.
• 13:34
  Cloudflare ended up with sixteen of them.
• 13:37
  That gives you context discipline and loses coverage.
• 13:41
  Most of those servers expose six or seven hand-picked tools out of thirty endpoints in the underlying product.
• 13:49
  The agent can't do everything the API can do, only what someone remembered to wire up.
• 13:55
  Carey walks three patterns for getting past this.
• 13:59
  First is the CLI route — let the agent shell out to your CLI, which has its own help text and discoverability.
• 14:07
  Cloud Code uses this heavily.
• 14:09
  The cost is that you need shell access.
• 14:12
  The second is in-protocol tool search: keep the full tool catalog on the server, expose a search tool, let the agent ask for the eight tools relevant to its current request and load only those into context.
• 14:27
  That's how Anthropic now does it for some integrations.
• 14:31
  It works, but it's still discrete tool calls.
• 14:34
  The third is what Cloudflare published last summer and what Carey is clearly excited about: code mode.
• 14:42
  Generate a typed SDK from your OpenAPI spec, give the agent the types, and let the agent write TypeScript code against your API.
• 14:51
  The model is good at TypeScript.
• 14:54
  Types are a concise representation of inputs and outputs.
• 14:58
  The agent writes code, the code runs.
• 15:01
  Quote: 'We just let the model write code.
• 15:04
  We benefit from the model getting better.
• 15:07
  We benefit from improving our OpenAPI spec.'
• 15:16
  Carey acknowledges this and frames the answer as a primitives question.
• 15:22
  Cloudflare's answer is V8 isolates — Workers, basically — with explicit capability flags.
• 15:28
  The generated code runs in a sandbox where process.env returns nothing because there is no Node compatibility, where outbound network calls are blocked unless you flip a boolean, where the only way out is through allowed channels you configured.
• 15:46
  He demos all of this on stage: agent writes a list-workers script, runs it; agent tries to read secrets, gets blocked; flip a flag, agent can call the external API.
• 15:58
  What I take from the talk isn't 'code mode is the future of MCP' — it's that the question 'how does an agent talk to my API' has gone from 'expose tool definitions' to 'expose a runtime.' That's a meaningful shift in posture.
• 16:15
  The protocol is fine.
• 16:17
  The default of stuffing every tool into context is dead.
• 16:21
  If you're building an MCP server in 2026, the design question is which of these three patterns you support, and how you reason about untrusted code.
• 16:32
  Pivot.
• 16:32
  The Asahi Linux team posted their progress report for Linux 7.0 yesterday and it deserves its own beat.
• 16:40
  If you only read AI news for a month, you forget what work looks like when the model can't help you, and this report is a long, calm reminder.
• 16:50
  Three gains worth naming.
• 16:52
  First, the team finally landed proper power management on M1 Pro and Max — chaos_princess wrote drivers for the Power Management Processor that lets it accept reports from SoC blocks the way macOS does.
• 17:07
  The result is roughly half a watt saved at idle on a 14-inch M1 Pro, which sounds like nothing until you realize that's a 20% drop in idle power consumption.
• 17:19
  Battery life on Linux on these machines just got materially better, on existing hardware, from a software update.
• 17:27
  Second, ambient light sensor support is in.
• 17:30
  Apple's True Tone uses a multi-channel light sensor with calibration data baked into a binary firmware blob, and the team can't redistribute Apple's binaries.
• 17:42
  Their solution: the installer pulls the firmware from macOS at install time, stores it on the EFI System Partition, and a Dracut module mounts it where the driver expects to find it.
• 17:55
  They've also added the ability for the installer to top up the firmware bundle on an existing install, so future hardware support won't require manual surgery on the EFI partition the way it did when they added webcam support.
• 18:11
  Third, and this is the part I want to read straight from the post because it's a textbook reverse-engineering moment.
• 18:20
  The display controller — DCP — has a parameter that the team had been setting to 0 every time a DCP powered up for an external display.
• 18:30
  They'd assumed for years it was part of some power-on sequence.
• 18:35
  Then, while tracing macOS toggling Variable Refresh Rate on and off, the team noticed that same parameter being flipped between 0x300000 and 0x0.
• 18:45
  The display they were testing has a minimum refresh rate of 48Hz.
• 18:50
  In DCP's fixed-point format, 48 is 0x300000.
• 18:53
  Quote: 'The parameter we had been setting this entire time had nothing to do with power sequencing, it was the minimum refresh rate toggle for VRR.'
• 19:12
  Two function calls turn into a working VRR implementation.
• 19:16
  The catch is that DCP requires a modeset to transition VRR states, which violates the VESA spec, so they can't expose it cleanly to KMS yet — for now you set a kernel module parameter and DCP handles VRR without telling the compositor.
• 19:33
  Kwin handles that gracefully.
• 19:35
  Other compositors may not.
• 19:37
  They're explicit about it.
• 19:39
  I want to point at the shape of this work because it's the opposite of the agent-coding discourse.
• 19:46
  There is no model that's going to ship you the answer to 'what does parameter 0x...
• 19:52
  on Apple's DCP firmware do.' The only path is to read the firmware blob, trace what macOS does, hypothesize, test, get burned, refine.
• 20:02
  That's still how the bottom of the stack gets built.
• 20:06
  The progress report is also a reminder of how thin the headcount is — most of the heavy work in this report is signed by two or three handles.
• 20:16
  If you use Asahi, or you might use it next year, the project takes donations.
• 20:22
  Speaking of existing hardware: DHH posted a benchmark note this morning that's worth a minute, because it's a small, useful counter to the upgrade cycle.
• 20:34
  Quote: 'Even if AMD is now beat on battery efficiency, it's worth remembering that the HX370 still performs (exactly!) as well as Panther Lake on heavy multi-core runs like HEY's 30K-assertion test suite.
• 20:49
  Might be some good deals to be had on those machines soon!'
• 21:06
  Panther Lake's win is on battery efficiency.
• 21:10
  If you're a developer who buys laptops to compile and to run tests, that's not the same number as the developer who buys laptops to read email on a plane.
• 21:22
  I'd take this as a general note rather than a specific recommendation.
• 21:27
  Run your own workload before you upgrade.
• 21:30
  Vendors benchmark on what flatters their chip.
• 21:34
  Your test suite won't be the workload Intel benchmarked on.
• 21:38
  DHH happens to publish his and have an actual production codebase behind it; most of us don't, but most of us could spend an hour with cargo, npm, or a CI runner and see what our own real numbers say before we sign a purchase order.
• 21:56
  The 'last generation' silicon doesn't always need replacing on the cycle the marketing implies.
• 22:04
  Three smaller items to round this out.
• 22:06
  Eden AI hit the HN front page today as 'European alternative to OpenRouter.' The pitch is straightforward: one API across about 500 LLM and expert models — OCR, speech-to-text, translation — with smart routing, region pinning, and provider fallbacks.
• 22:24
  The structural pitch for an EU buyer is data residency and GDPR posture.
• 22:29
  OpenRouter routes to whichever inference provider wins the price auction, which is fine for a hobby script and not always fine for a regulated workload where the answer to 'where did this prompt go' matters legally.
• 22:43
  I'm not endorsing the product, I haven't run traffic through it.
• 22:48
  I'm flagging that procurement requirements for AI plumbing in the EU are tightening, and the second OpenRouter-shaped player is the kind of plumbing that quietly shows up in a vendor questionnaire two quarters from now.
• 23:03
  GnuPG announced post-quantum crypto landing in mainline.
• 23:07
  The note went out to the gnupg-announce list this week.
• 23:11
  If you ship long-lived signed artifacts — release archives, package signatures, anything that has to remain verifiable in twenty years — this is the upstream you should track.
• 23:23
  The argument for migrating now isn't that quantum computers are about to break RSA.
• 23:28
  It's that anything you sign or encrypt today and care about in 2045 has to survive whatever happens between now and then.
• 23:37
  Mainline GnuPG is the canonical place that migration starts.
• 23:41
  And one for the watchlist: Nathan Lambert posted a photo from a meeting with two engineers from Xiaomi MiMo and said, quote, 'I smell something big coming soon.' That's the entire signal — Nate doesn't bluff often, but it's a tweet, and a tweet about a vibe is not a release.
• 24:00
  I'm noting it because Xiaomi MiMo has been quietly shipping interesting open-weights work, and 'big coming soon' from someone with Lambert's vantage is worth a calendar reminder.
• 24:12
  I'm not going to spin it into more than that.
• 24:15
  We'll see what shows up.
• 24:17
  Two threads from earlier in the week to pick up.
• 24:20
  The Lambda Calculus Benchmark — LamBench — that we promised to look at: I went looking for primary methodology this morning, and the writeup that has the methodology in it is gated behind a paper that hasn't hit arXiv yet.
• 24:34
  I'd rather wait and read it before I narrate it than narrate it from the press release.
• 24:39
  So that one rolls another day.
• 24:41
  The METR 19% study from yesterday: the Stetskov essay we walked through is the most thoughtful response I've seen to it, and I'd put the two next to each other.
• 24:51
  The Anthropic study said developers feel faster while being slower.
• 24:55
  Stetskov says the worse problem is that the developers we should be growing into seniors aren't getting the formative reps.
• 25:03
  Both can be true.
• 25:04
  They're stacked, not in tension.
• 25:06
  The shape of this Sunday is a 90-gigabyte download you can run on the laptop on your desk, a Java pin you can reproduce on your machine in six seconds, an essay about an industry that lost the recipe for its own warhead material, and a Linux team that found a missing display feature by reading a parameter they'd been zeroing for years.
• 25:27
  None of those are turning points.
• 25:29
  They're builders working on the next thing, at every layer of the stack, with the model and without it.
• 25:35
  I'm watching the Xiaomi rumor and the Java 24 rollout in production codebases.
• 25:40
  That's what I'll be tracking tomorrow.
• 25:43
  Lenar Kess.