Noam Shazeer Joins OpenAI, Local Qwen is a Different Tool Not a Worse Opus, and AMD Silently Strips Memory Encryption

Good morning. It's Thursday, June 18, and we're covering Noam Shazeer's move from Google to OpenAI, a detailed founder's account of running local Qwen for production workloads, and AMD quietly removing a memory encryption feature from consumer Ryzen CPUs.

The Shazeer thread hit 353 points as developers traced the path of one of the Transformer's critical implementers from Google to Character.AI and now to OpenAI. The local Qwen post hit 484 points with a rare combination: real hardware costs, real revenue impact, and an honest accounting of where local models still fail.

In today's brief:

• Noam Shazeer, co-author of the Transformer paper, announces he is joining OpenAI
• Alex Ellis explains why local Qwen 3.6 27B is a different tool, not a worse Opus, with $12k hardware receipts
• AMD silently removes Transparent Secure Memory Encryption from consumer Ryzen CPUs via AGESA firmware
• A skeptical takedown of RTK's token compression claims argues the savings metric is a vanity number

TALENT

Noam Shazeer Joins OpenAI

Noam Shazeer announced he is joining OpenAI. Reuters confirmed the move, reporting that Shazeer had been co-leading Google's Gemini efforts before the departure.

Shazeer was one of the lead authors of "Attention Is All You Need," the 2017 paper that introduced the Transformer architecture. As the HN thread (353 points, 388 comments) established, his contribution was not just authorship. Jakob Uszkoreit initiated the project with the idea that language is partly parallel and partly hierarchical, but the initial implementation did not outperform prevailing RNN approaches. Shazeer wrote his own version of the code, described by colleagues as "magic" and "alchemy," that made the architecture actually work. He later designed mixture-of-experts at Google and founded Character.AI before returning to Google in 2024 as part of a licensing deal.

The thread's deeper discussion focused on what the move says about Google. Multiple commenters framed it as an innovator's dilemma: a $4.5 trillion company protecting its core business cannot easily sustain the kind of unstructured research environment that produced the Transformer in the first place. One commenter linked a satirical thread about "permission working groups" at Google that rang true enough to be mistaken for real internal documents.

Why it matters: The Transformer paper's author list was randomized, but the implementation that made it work was Shazeer's. When the person who wrote the code that defines modern AI leaves the company that funded it for a competitor twice in two years, the talent concentration question stops being theoretical.

LOCAL AI

Local Qwen is a Different Tool, Not a Worse Opus

Alex Ellis, founder of OpenFaaS and several infrastructure products, published a detailed account of running local Qwen 3.6 27B for real business workflows. The post is notable for what it is not: another benchmark claim that local models have reached parity with frontier models. It is a founder's honest accounting of where local models produce value and where they fail.

The hardware setup is concrete. Ellis spent roughly $12,000 on an RTX 6000 Pro Blackwell with 96GB of VRAM, running two llama.cpp instances with full-quality f16 KV cache and 262k context. Speculative decoding via MTP delivers 130-200 tokens per second sustained, faster than cloud model latency feels. The card paid for itself through a specific use case: feeding a customer's telemetry database through a local model to discover they had been under-reporting licenses and under-paying by 4-5x for over 12 months. That revenue recovery alone covered the hardware cost.

The failures are equally specific. Qwen loops infinitely on long-horizon tasks, repeating the same output block dozens of times while drawing 600W. Asked to add a --json flag across CLI commands, it wrote convincing tests for the first implementation, then when it hit a problem it could not solve, it proposed writing a reverse proxy in Python, corrupted the file, and got stuck in a different kind of loop. Ellis compares it to tempering steel: if you go one shade past the target temperature, you have to start over. You would not leave it unattended.

The useful workflows are narrow but real: airgapped analysis of customer diagnostic data that cannot legally be sent to cloud models, telemetry analysis for revenue recovery, and codebase exploration where the model reads and explains code it could not have written. The post explicitly rejects the claim that local Qwen is "near-Opus level" on coding tasks. In code review, Qwen hallucinated concurrency issues and race conditions that did not exist and would not follow instructions to be brief.

The HN thread (484 points, 253 comments) focused on the cost analysis. Uber recently capped AI spend at $1,500 per developer per month per tool. At the median Uber salary of $330k, two tools maxed out is roughly 12% of compensation. For heavy token use, agentic loops, and in-product AI features, the break-even point for local hardware arrives faster than the "local models aren't about cost" framing suggests.

Why it matters: The local models conversation has been stuck between two unhelpful positions: benchmark-cherry-picking claims of parity and dismissals that ignore real workflows. Ellis's post is the rare middle: here is what I bought, here is what it earned, here is where it loops and burns 600W for nothing. The use case that matters is not "replace Claude" but "do work you cannot legally send to Claude."

SECURITY

AMD Silently Removes Memory Encryption from Consumer Ryzen CPUs

According to a Tom's Hardware report citing Ars Technica, AMD has quietly stripped Transparent Secure Memory Encryption (TSME) from consumer Ryzen CPUs via the AGESA 1.2.7.0 firmware update. The feature, which encrypts DRAM contents to protect against cold-boot and physical memory attacks, now returns FALSE on consumer chips regardless of BIOS settings. Pro-tier CPUs retain the feature.

Ben Kilpatrick, a Linux user running a Ryzen 7 9700X, discovered the removal when Host Security ID (HSI) reported TSME as unsupported despite being enabled in BIOS. His months-long investigation involved AMD engineers Tom Lendacky and Mario Limonciello, who initially could not explain the disappearance, and MSI's engineering team, which confirmed through controlled testing that consumer chips had TSME enabled under older firmware but not under AGESA 1.2.7.0.

The most damaging detail: Lendacky had confirmed in a 2020 GitHub comment that a Ryzen 3700X, a consumer CPU, "should support TSME." In 2025, he recommended using TSME again. When Kilpatrick asked whether the flag being set to FALSE was a silicon limitation or a firmware policy decision, Limonciello closed the discussion: "My apologies, but I don't have any more information to share on this topic."

The removal is undetectable on Windows and requires significant technical work to identify on Linux. AMD's only official statement is that TSME "is a security feature only applied to PRO CPUs as part of AMD PRO Technologies," the first time the company has publicly stated such a restriction, despite the feature having worked on consumer chips for years.

The HN thread (450 points, 209 comments) debated whether this was an intentional product-segmentation decision or an accidental firmware regression. Either way, the silicon is capable of running the feature. The difference is whether users are looking at a bug AMD should fix or a quiet segmentation decision AMD has not properly explained.

Why it matters: Silent security regressions delivered through firmware updates are the worst class of product change. Users cannot detect them, cannot opt out of them, and cannot get an explanation for them. The feature worked for years, an AMD engineer confirmed it worked, and then it stopped working with no announcement and no documented rationale.

AI TOOLS

The Token Compression Illusion: Why One Engineer is Skeptical of RTK

Przemek Mroczek published a skeptical analysis of RTK, a tool with 60k GitHub stars that claims 60-90% token savings for LLM agents by compressing terminal output. The post argues the savings metric is a vanity number that masks structural flaws.

The core criticism: RTK's "60-90% savings" reflects the percentage of raw command-line output stripped away, not a reduction in actual API bills. The tool touches Bash output while ignoring the heaviest cost drivers: deep file reads, repository contexts, system prompts, and the model's internal reasoning tokens. The savings number is engineered for social media screenshots, not for measuring real cost reduction.

The more serious concern is what Mroczek calls the "silent failure trap." When RTK strips a critical line of stack trace or compiler context to save tokens, the AI agent has no idea the text was compressed. Both the developer and the model operate in the dark. RTK's GitHub issues already document instances where terminal output gets quietly mangled or dropped.

The post also notes the absence of the metric that actually matters: task success rate. Saving 80% on a prompt is a net negative if the degraded context causes the agent to hallucinate, fail the build, or loop, ultimately burning more tokens than it saved. Until RTK publishes SWE-bench-style accuracy evaluations alongside cost graphs, the savings narrative remains incomplete.

The HN thread (118 points, 111 comments) discussed the architectural critique. RTK introduces a fragile external dependency into the synchronous path between agent and shell, relying on parsing human-readable stdout formats that will break the day git, cargo, or npm changes its terminal formatting. The moment major CLIs ship native --compact or --json-stream flags for LLM consumption, RTK's advantage disappears.

Why it matters: Token cost optimization is a real problem. Tools that claim to solve it by stripping context the agent cannot detect are trading deterministic reliability for a vanity metric. The right answer is native LLM-aware output flags in the CLIs themselves, not a brittle parsing layer in the critical path.

WHAT ELSE IS HAPPENING

• Midjourney Medical (1356 points, 874 comments): Midjourney announced a full-body ultrasound scanner built around 40 Butterfly IQ3 transducer chips arranged in a contactless ring submerged in a water spa. The HN thread featured practicing radiologists raising serious concerns: ultrasound cannot image lungs (air) or brain (bone), the images shown are "very, very far from medically useful," no peer-reviewed papers accompanied the launch, and one commenter noted Midjourney is repackaging an existing FDA-approved handheld device at 200-400x the distance with water in between, which can only reduce resolution.
• Microsoft's new Outlook takes 10 seconds to do what Outlook Classic does instantly (743 points, 519 comments): Clicking a notification banner in the WebView2-based new Outlook takes ~10 seconds to display the email, while Outlook Classic does it instantly. New Outlook runs 10 separate processes and uses 490-636MB RAM at idle vs Classic's 117-148MB. The gap is architectural, not fixable with a feature update.
• DeepSeek Introduces Vision (493 points, 200 comments): DeepSeek adds multimodal vision capabilities to its model line.
• CS 6120: Advanced Compilers self-guided course (442 points, 60 comments): Cornell's open compiler course, updated for the 2025fa semester.
• Clojure Hosted on Go (196 points, 26 comments): Glojure, a Clojure implementation on the Go runtime.
• Launch HN: TesterArmy (YC P26) (126 points, 68 comments): YC W26 startup shipping agents that test web and mobile apps autonomously.
• Cell-based architecture for resilient payment systems (156 points, 62 comments): American Express engineering on the cell-based architecture pattern they use for payment resilience.
• I hate compilers (175 points, 168 comments): Xe Iaso on the pain of vendoring WASM binaries in compiler toolchains.

---

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.