← AI Hacker Daily

Edition

06

picks

GPT-6 Sol lasted seven days before GPT-6.1 Sol replaced it.

GPT-6 Sol lasted seven days before GPT-6.1 Sol replaced it. Artificial Analysis scores the new one 4 points higher on its index at the same $2/$10 per million tokens, and the HN thread (974 points, 851 comments) is mostly people deciding whether to switch. Whichever model you pick, the vendor will change it on the vendor's schedule. Livenerf, which reached 680 points on the same front page on Tuesday, exists to notice when that happens. Each of today's picks keeps a reference you control and checks the moving part against it. Livenerf keeps a launch-day baseline for Opus 5.5 and pins every variable except the model. Jevstiller keeps a local copy of a hosted classifier's answers and keeps auditing it against the original. SelfJev keeps the weights, so nothing changes until you change it. Corral and NSL apply the same idea to your own machine. Corral checks that nothing an agent's command started is still running, and NSL keeps the host as you installed it while dependencies come and go inside separate machines.

01

Livenerf — a launch-day baseline for Opus 5.5, with everything except the model pinned

Livenerf (Python, no license file, 609 stars, 39 commits, one author, created September 22, the day Opus 5.5 shipped, no releases) is a daily benchmark for one question: does a model get worse after launch? It runs through headless Claude Code on a Max subscription and is built on the UK AI Security Institute's Inspect framework. Sampling can't be fixed, so it fixes everything else: frozen prompts, exact graders, raw logs kept forever, and a pinned Claude Code CLI. The runner refuses to start if claude --version stops matching the recorded version, because "a changed harness looks exactly like a changed model." The panel is 78 questions from GPQA Diamond, MMLU-Pro, competition math and AIME, chosen from 2,336 because Opus 5.5 gets them right only some of the time; a question it always or never gets right cannot show a change. Days 1–10 are the baseline, followed by 10-day windows, and a change has to clear a pre-registered 99% threshold in two consecutive windows. The first possible verdict is around October 24. Output tokens per sample are a second signal, because lower effort shows up there before it shows up in accuracy.

The README is specific about what the instrument cannot see. In validation, dropping effort to low cut output tokens by 62% and accuracy by 8.3 points (+/- 4.5), which it detects. Swapping in Opus 5 could not be distinguished from Opus 5.5 at 99% (a 3.8-point drop, +/- 6.3), so a same-family swap of that size may get through. An audit of the panel found 8 answer keys that look wrong and 30 ambiguous questions. They stay in, with a pre-registered rerun that leaves them out. The HN thread (680 points, 268 comments) raised two objections that matter. First, a public benchmark that runs on a fixed schedule is easy for a provider to recognize and treat differently, and the author agrees that nobody outside the provider can rule this out. Second, it measures the subscription path through Claude Code, and several commenters argue that path behaves differently from the API. Other trackers exist, including Nerf Bench and MarginLab's Claude Code tracker. What this one adds is the pre-registration and a start date of launch day.

Reach for it if your team argues about whether the model got worse and nobody has numbers. You can watch the public series, or fork the method for the model you actually depend on. Delete the Slack thread titled "is it just me or is Opus worse today." Tradeoffs: no verdict until late October; no license file, so you can read the code but have no stated right to reuse it; by its own estimate the daily run uses about 3.6% of a weekly Max plan; and it tracks one model, through one harness, on reasoning questions rather than coding tasks.

→ github.com/ninjahawk/livenerfdiscussion ↗

02

Jevstiller — a local copy of Jev's answers, with a stated limit on how often it disagrees

Jevstiller (Apache-2.0, Python, 39 stars, 71 commits, one author, created September 21, v0.4.0 on Sunday) is a proxy that sits in front of a repeated call to TypeSafe's Jev classifier. Run the Docker container and point TYPESAFE_BASE_URL at it; your code does not change. At first every request goes to Jev. Jevstiller uses Jev's answers, with their full probability distributions, to train a small local model: a logistic-regression head, about 80 lines of numpy, on frozen bge-small embeddings. Once the model qualifies, it answers the confident requests itself in about 15 ms on a CPU, against about 300 ms for Jev. Uncertain or unfamiliar inputs still go to Jev, and so does a permanent 2% random audit slice. If audit agreement breaks, all traffic goes back to Jev and the model retrains.

The new part is how the confidence threshold is chosen. You set one number, such as 98%, and Jevstiller picks the cutoff using an exact Clopper-Pearson bound at 95% confidence over held-out calibration rows, instead of the usual point estimate. The write-up shows the difference. On random splits, the point-estimate rule went over a 2% budget on 6–12 of 20 splits per task, and the bound went over once in 100. How much traffic it takes over depends on how consistent Jev is, not on how hard the task is. It answered 71.9% of Banking77 locally at 99.50% agreement, but only 22–24% on the two TweetEval tasks, where Jev's answers match the dataset's labels only 64–74% of the time.

Reach for it if the same Jev question runs thousands of times in a loop and the 300 ms round trip or the 1,200-requests-per-minute limit is your bottleneck. Delete the retry-and-backoff wrapper around your classification calls. Tradeoffs: agreement is not accuracy, so it copies Jev's mistakes along with its answers; the budget is per request, not per class, so a rare class can go over it; the bound assumes the calibration rows look like future traffic; it only helps with questions that repeat, which one commenter in the Show HN thread called "the least interesting possible use of Jev"; and another commenter asked whether training on Jev's outputs violates TypeSafe's terms. The terms of use on TypeSafe's website say nothing about training on outputs, but that page is not the API agreement, so read yours before you put this in production.

→ github.com/tomerglick57/Jevstillerdiscussion ↗

03

SelfJev — a Jev-compatible 4B model you host, so the weights change only when you change them

SelfJev (Apache-2.0, Python, 54 stars, 50 commits, one author, created September 23, launched on Product Hunt on Monday) is a LoRA adapter on a pinned Qwen3.5-4B base, plus a server that speaks Jev's API. pip install "selfjev[serve,gpu]" then selfjev serve downloads the 230 MB adapter. Set TYPESAFE_BASE_URL and TYPESAFE_API_KEY to point at your server, and code written for TypeSafe's SDK runs unchanged, with requests for jev-latest answered by selfjev-4b. It reads the text once, reuses that work for every question and answer option, and scores the choices directly without generating any text. It also adds two things Jev lacks: a select-all Multi question type and image input.

The README's comparison table is candid about its own evidence. On the project's 1,991-question text-decision suite, SelfJev scores 95.7% against Jev's 97.2%. On AI response review it scores 93.1% against 92.5%. The README also says the labels in those two suites were written and checked by an AI and influenced research decisions, that the third benchmark was reused during development, and that "a fresh independent holdout remains necessary." The end-to-end report from one run on an L40S passed 14 of 14 checks, which shows the deploy works, not how accurate the model is.

Reach for it if your inputs can't leave your network, or if you want a decision model that stays the same until you swap the adapter; it replaces the hosted endpoint with one you pin. Delete the waitlist email. Tradeoffs: the suggested starting hardware is a 24 GB NVIDIA GPU, and the fast kernels need Linux with CUDA; the accuracy numbers are the author's own, measured on AI-written labels; having jev-latest answered by a different model is convenient but will confuse the next person who reads your logs; and the repo is one week old, from one author.

→ github.com/Jwuthri/SelfJev

04

Corral — runs an agent's shell command and checks that nothing it started is still alive

Corral (MIT, C++, 6 stars, 34 commits, one author, v0.1.0 on Monday) runs a command with a time limit and guarantees one thing: when Corral returns, no process the command started is still running. If it cannot confirm that, it exits with code 120. The author built it after watching an agent leave tail -f and background jobs running, and found open Claude Code issues about the same problem. The README names three cases that ordinary runners miss. A daemon that forks twice and calls setsid() leaves the process group, so the signal never reaches it. A background process that holds stdout open makes the runner hang after the command exits. And a process that ignores SIGTERM keeps running. In enforced mode, Corral puts the command in its own cgroup v2 group, where one write to cgroup.kill ends every process, and --mem and --pids set limits. Without a cgroup, Corral registers as a child subreaper so that orphaned processes become its children, finds the rest through /proc, and signals them through pidfds. Either way, the run ends when the command exits, not when the pipes close.

The one substantive question in the Show HN thread was why not use timeout, and nobody answered it there. The README answers it indirectly: timeout signals its own process group, which is exactly what a setsid() daemon has left, and it offers no check afterward. --json PATH writes a record of each run for your logs.

Reach for it if your agent runner or CI job hangs after a command finishes, or if the next run fails because a port is still bound. Delete the pkill -f cleanup step at the end of your job. Tradeoffs: Linux 5.11 or later only (5.14 for enforced mode), and enforced mode needs a delegated cgroup, which scripts/corral-enforced gets through systemd-run; the prebuilt binary is x86-64 with glibc 2.36 or later; it is "not a security sandbox" and does not limit file access, network access or privileges; it has 12 points on HN and no outside reports; and the author says it was partly a way to learn about Linux processes and signals.

→ github.com/Cardinal44/corral

05

NSL — the WSL workflow on Linux, so dependencies land in a machine instead of on your host

NSL (MIT, Go, 63 stars, 87 commits, one author, created Saturday, three releases on Tuesday ending at v0.6.1) gives an atomic Linux host what WSL gives Windows: persistent machines where you can apt install a project's dependencies without touching the host. nsl create debian --distro debian:13 verifies and caches a signed image. nsl opens a login shell in the current directory, and nsl run make test runs one command and returns its exit status. There are seven distros, rebuilt weekly. Underneath is one small VM started by systemd-vmspawn, running systemd-nspawn containers. Ports inside a machine show up on the host's 127.0.0.1, Wayland apps open windows on your desktop, and nsl ssh-config gives your editor a host alias. NSL runs as your user with no daemon and installs no packages on the host.

The HN thread (140 points, 84 comments) spent most of its time on "why not distrobox?" The author's answer is the useful part. Distrobox mounts your $HOME at $HOME, so a tool that edits your dotfiles or PATH edits the host's copy. NSL mounts host files at /mnt/host instead, so those edits stay in the machine. That protects the host from clutter, but it is not isolation. The README says an ordinary machine "is trusted as you" and can read and write your home directory, keys included. --isolated puts a machine in its own VM with no host files, and that is the mode for agent-written code you have not read.

Reach for it if you run an atomic distro, or any distro you are tired of reinstalling after a -dev package broke something. Delete the libwhatever-dev you installed on the host for one build. Tradeoffs: it is pre-release, and everything before v0.4.0 was a retired prototype; it needs x86-64 with KVM, systemd-vmspawn, QEMU with UEFI firmware and virtiofsd, and the only tested host is Snow Linux 13; edits made to host files produce no inotify events inside machines, so file watchers miss them; idle machines stop even when a service inside them is busy; and several commenters complained that the docs read as machine-written.

→ github.com/frostyard/nsldiscussion ↗

06

Also on the desk. Earendil's "You Said No MCP" (146 points) explains why the Pi agent harness now ships MCP after the team spent months dismissing it. The protocol changed, and running tools through a JavaScript sandbox on the harness side fixed the composability problems they had objected to. "The first thing to remember is that the world is not static" works as a caption for this whole edition.

Verification notes: star, commit, contributor and release data are from the GitHub API on 2026-09-30; commit totals use the per_page=1 Link-header last-page count, and contributor counts exclude bots and co-author accounts. GPT-6.1 Sol's index, pricing and replacement timing are from Artificial Analysis; OpenAI's own post returned 403 to our fetch, so this edition makes no claim about GPT-6 Sol's deprecation schedule. Livenerf's design, validation, question audit, budget and status are from its README (progress as of 2026-09-29); the benchmarkability and API-versus-subscription objections and the other trackers are from HN item 49901736. Jevstiller's mechanism, benchmark table and limits are from its README and its "the guarantee" post; the head's size and the ToS and "least interesting" comments are from HN item 49891769; the ToS check covered typesafe.ai/terms only. SelfJev's install, compatibility and accuracy table are from its README, and the L40S run is from its site and e2e report; all of its numbers are the author's own. Corral's cases, modes and requirements are from its README, and the author's motivation and the timeout question are from HN item 49886422. NSL's features, trust model and limits are from its README; the distrobox comparison is the author's reply in HN item 49894351. HN points are from the Algolia API (items 49896586, 49901736, 49891769, 49886422, 49894351, 49906637). Pipeline health: today's pool held 87 rows, against the ~280 the compose prompt assumes. github:trending returned zero rows across all feeds, and Reddit returned zero again, 144 days since its last nonzero day on May 9.

→

One of these,
every weekday.

Free. One-click unsubscribe in every email. No tracking pixels in the email.