M6 Goes 2nm, Jalapeño Beats Blackwell, EVE Leaves Python 2

Good morning. It's Wednesday, August 26, and we're covering Apple's biggest silicon leap since the M1 transition (a 2nm M6 in the Mac mini and a quad-die M5 Ultra in the Mac Studio), OpenAI's Jalapeño inference chip posting per-watt numbers that beat Nvidia's Blackwell and Vera Rubin in verified lab runs, and EVE Online starting its migration off 2.4 million lines of Python 2.7. Plus: JPEG XL goes on by default in Firefox 157.

The Apple announcement thread held 1,147 points with 1,117 comments overnight - the day's biggest developer discussion by far - while the SemiAnalysis Jalapeño deep-dive pulled 491 points with 314 comments within hours. Here is the signal, sourced.

In today's brief:

• M6 is Apple's first 2nm chip with a 12-core CPU and a Dual 16-core Neural Engine; M5 Ultra is a quad-die design with up to 512GB of unified memory and 1.2TB/s of bandwidth
• OpenAI's Jalapeño ASIC beats Blackwell on tokens per megawatt without speculative decoding, and SemiAnalysis says it clears Vera Rubin's published numbers too
• EVE Online's first Python 3 stage just hit production: 95.9 percent of its ~20,000 files already compile under both versions
• Firefox 157 turns JPEG XL decoding on by default on all platforms, and Chromium has sent its own intent to ship

THE BIG ONE

Apple Ships M6 and M5 Ultra: 2nm for the Mini, a Quad-Die Flagship for the Studio

Apple's M6 and M5 Ultra announcement (1,147 points, 1,117 comments) is the fall hardware event compressed into one press release, backed by two more: the new Mac Studio with M5 Max and M5 Ultra (770 points) and the new Mac mini with M6 and M5 Pro (499 points). M6 is Apple's first 2nm chip: a 12-core CPU (2 super cores, 4 performance, 6 efficiency), a 12-core GPU with a Neural Accelerator in every core, and a Dual 16-core Neural Engine rated at up to 2x the peak compute of the previous generation, with up to 32GB of unified memory and 170GB/s of bandwidth. Apple's own line for developers is that CPU-heavy work like compiling code, indexing files, and "running agentic AI workloads" is faster than ever, with the GPU's Neural Accelerators delivering a nearly 30 percent increase in peak GPU compute for AI compared to M5 for "significantly faster prompt processing" with on-device LLMs.

The M5 Ultra is the more interesting engineering story: it is Apple's first quad-die chip, built by fusing two dual-die M5 Max packages with UltraFusion at over 4.4TB/s of inter-die bandwidth. The result is an up-to-36-core CPU, an 80-core GPU with per-core Neural Accelerators (4.5x the peak GPU AI compute of M3 Ultra), a 32-core Neural Engine, and up to 512GB of unified memory with 1.2TB/s of bandwidth, 50 percent more than M3 Ultra. Apple explicitly frames the Studio config as an on-device inference box: "run huge LLMs with hundreds of billions of parameters entirely on device," with Core AI, Core ML, Metal, and Xcode all wired into the new hardware.

The HN thread debates what this actually means for developers. The machine that previously required a dual-GPU workstation for a 100B-parameter class model now fits in a single Mac Studio footprint, and 512GB of unified memory removes the CPU-GPU copy boundary entirely for local model work - LM Studio runs, fine-tuning, and long-context agent loops all get the same pool. The counterpoint in the thread: Apple's benchmark claims are first-party, the M6 sits at 32GB where M-series plus-points matter, and the "world's fastest single-threaded performance" crown gets re-litigated the moment the next x86 and ARM parts ship.

Why it matters: the practical ceiling for a developer's local AI compute just moved, because a single desktop now serves hundreds-of-billions-of-parameter models from one unified memory pool - if you have not re-run your local-model math since the M3 Ultra era, the tokens-per-second and context-window numbers changed again.

MODELS

OpenAI's Jalapeño Beats Blackwell on Tokens per Megawatt, and SemiAnalysis Says Rubin, Too

OpenAI's Broadcom-built Jalapeño inference chip (491 points, 314 comments), announced at Hot Chips this week, went from team hiring to CoWoS tape-out in about 16 months. SemiAnalysis got lab access, ran its InferenceX throughput suite alongside OpenAI engineers, and reports the headline result: Jalapeño beats every Nvidia, AMD, and Google accelerator it has tested on output tokens per megawatt, without speculative decoding and without prefill-decode disaggregation. At concurrency 1 on DeepSeek R1 the A0 stepping delivered over 700 tokens per second per user; Kimi K2.5 ran at roughly 700 and GPT-OSS at about 1,400. The same story is what pushed Bloomberg's report (archive) that OpenAI claims its chips outperform Nvidia processors in tests, and OpenAI published its own first benchmark results alongside.

The architecture explains the numbers. A 700W, reticle-sized compute die on TSMC N3P delivers 13.4 PFLOPs of MXFP4 versus Rubin's 17.5 at 900-1,150W, with the highest HBM bandwidth per watt in the class: 15.4TB/s from HBM4 at 10Gbps pin speeds. The software story matters more. Kernels are written in Gluon, OpenAI's Triton-derived language with a "layout" abstraction based on Linear Layouts algebra, and - per SemiAnalysis - the company's scaled-up internal Codex wrote the working kernels, including an MLA implementation for DeepSeek after it had none, plus demos like Doom at 36 FPS "ported with just Codex prompts." OpenAI keeps a heat-eating simulator accurate to within 5 percent of silicon, which is how bring-up moved this fast.

SemiAnalysis adds caveats worth quoting before anyone buys the headline: the numbers are OpenAI-provided, the benchmark suite was 8k1k rather than the multiturn AgentX suite that stresses runtime serving stacks, and the Blackwell comparison is "somewhat incomplete and unfair" - Jalapeño really competes with Rubin, and it still wins on tokens per MW against Rubin's published July results, but production volume only ramps across 2027, with most output at the end of next year. Even so, the write-up's conclusion is blunt: if leadership inference performance comes from a CoWoS-priced ASIC pair, "the CUDA moat is potentially dead."

Why it matters: datacenters are power-limited, so tokens per megawatt is becoming the pricing metric for inference - if this holds at volume, the unit economics of GPU farms, and therefore API prices, get a third credible competitor to Nvidia's roadmap.

PLATFORMS

EVE Online Starts Dragging 2.4 Million Lines of Python From 2.7 to 3, and It Hit Production Today

EVE Online's The Move to Python 3 Begins is one of the best migration postmortems-in-progress you will read this year, and Simon Willison's write-up is the best summary of it. EVE has run on Stackless Python since 2003 - last upgraded to Stackless 2.7 in 2010, six years after Python 2.7 reached end of life. The server-side codebase is 2.4 million lines across about 20,000 files, much of it written against 2.3/2.5-era standards that modern Python 3 refuses to parse. CCP's first scan surprised them: 95.9 percent of files already compile under both interpreters. The blockers were mechanical, and the post lists them like archaeology: about 1,500 old-style print statements, about 800 123L long literals, about 600 exception clauses in a syntax deprecated "before EVE existed," and 50 uses of <>.

The hard part is stage two: about 20,000 lines that compile under both versions but behave differently, starting with 1 / 2 being 0 in Python 2 and 0.5 in Python 3 - in a codebase where those numbers can be damage, ISK, or coordinates. Each needs a human decision, which is why stage one (the Python-Future/futurize fixers, using the same 2to3 machinery CPython ships) cleared the mechanical debris first, and why EVE Frontier's prior Carbon-engine migration - twelve minor Python versions in one jump - is the proof of concept. The first stage already deployed to the live Tranquility servers with patch 24.01 today. CCP defines success as "completely unnoticeable," and it needs the game to keep running 23.75 hours out of every 24 while the migration runs under it.

Why it matters: this is the largest real-world Stackless migration on record, and it validates the staged approach for any team marooned on an EOL interpreter: measure first, let mechanical tooling clear the syntax debris, and spend human review only on the lines that genuinely changed meaning.

WEB PLATFORM

Firefox 157 Ships JPEG XL by Default, and Chromium Just Filed Its Own Intent to Ship

Mozilla's intent to ship JPEG XL decoding (381 points, 104 comments) turns the format on by default on all platforms in Firefox 157, after two years behind image.jxl.enabled on Nightly and a Firefox Labs checkbox. The decoder is jxl-rs, written in Rust, and the multithreaded decoding work landed in jxl-rs 0.6.0; in Timothy Nikkel's five-format decode benchmark the Firefox stack came out "slightly ahead of Safari," which uses C++ libjxl. Firefox's implementation adds animation and progressive display, which Safari's 2023 JPEG XL support still lacks, and while HDR decodes to SDR like every other format, Firefox's tone mapping for JXL is better than what it does elsewhere. The thread also points forward: Chromium sent its own intent to ship the same day, after years of Chrome shipping the format only behind a flag.

The honest counterbalance is in the same thread. One measurement-heavy comment reports lossless JPEG XL decoding about 30x slower than lossless WebP in a single-threaded test, and Nikkel's own numbers show JXL close to the other decoders on large images but with a bigger gap on small ones. None of the performance concerns blocked the flip, but they are the reason format adoption takes years: JXL's encoding efficiency only pays off if the decode cost is acceptable on laptops and phones, and the largest lossless use case for the web is exactly that geometry.

Why it matters: a third browser is the threshold where a format becomes shippable, and Firefox plus a Chromium intent-to-ship plus Safari's 2023 support means the "can I use" answer for JPEG XL flips from "no" to "yes, with care" - worth re-testing your image pipeline's JXL output budget, especially the lossless path.

TOOLS WORTH A LOOK

1. LatticeDB (156 points) - a "SQLite for graph databases" take: a graph DB that embeds like a library, no server to run; Show HN from a team that found graph DBs painful to use locally.
2. TeXbrain (MIT, 98 points) - a browser LaTeX editor that compiles pdfTeX to WebAssembly and runs offline; opens your project folder directly via the File System Access API so git and local TeX tools still work on the same files.
3. Maiao (OSS, 82 points) - a Gerrit-style code review workflow (staged commits, submit queues) that sits on top of GitHub, GitLab, Gitea, and others.

WHAT ELSE IS HAPPENING

• str.lower() is a security vulnerability in Python (132 points): CVE-2026-17084 in the stdlib IDNA 2003 codec - str.lower() uses the interpreter's current Unicode tables (17.0) where StringPrep requires Unicode 3.2.0 case folding, so Cherokee domain names encode differently than the spec demands; fixed by pinning B.2/B.3 behavior per codepoint.
• C2PA cameras do not survive contact with reality (154 points): David Buchanan dismantles Android's C2PA credential implementation step by step - a fitting follow-up to yesterday's Paint watermark reverse-engineering, and the same conclusion: provenance metadata is only as strong as the signing chain under it.
• OpenAI and Anthropic Python SDKs both drop httpx: openai-python 3.x and anthropic-python 1.0 both move to pydantic's httpx2, which broke anything relying on the transitive httpx dependency - Simon Willison's llm ecosystem needed two releases to absorb it; check your lockfiles if you pin SDK internals.
• Agentic context management as an architecture problem (paper, 55 points): a new arxiv survey treats agent memory and context cost as first-class architecture decisions - cache, compaction, and tool-result retention - rather than runtime details.
• Python's pre-declared constants are kinda weird (176 points): a deep dive on the surprising ways CPython's built-in names (True, Ellipsis, __debug__) interact with assignment and scoping rules.
• "The end of programming": Paul Dix argues an agent writing 1M lines and refining them over months is the real output of code-generation, via Simon Willison's quote post - the verification-loop argument restated for immutable rewrites.

---

Every link above goes to a primary source or our sourced coverage. Tomorrow's brief lands when the news does - subscribe to get it by email.