A reminder today: clever engineering — not just bigger models — is still driving outsized wins. Expect arguments about what “solving” a benchmark actually means, and a practical systems lesson about readahead that matters if you care about latency, throughput, or CPU tradeoffs.

Top Signal

44% on ARC‑AGI‑1 in 67 cents

Why this matters now: The ARC‑AGI‑1 result shows that a solo researcher can push a tiny autoregressive transformer to competitive benchmark performance with very low compute and money, forcing a recheck of what benchmark progress means and how we evaluate sample efficiency.

A solo researcher published a reproducible recipe claiming a ~44% score on the ARC‑AGI‑1 benchmark using a very small autoregressive transformer trained from scratch, with the whole training run reported as roughly 1.5 hours on an RTX 5090 and a cost around "$0.67" according to the post — code and analysis are open for inspection. The headline is not a new Larger‑Is‑Better story: most gains come from engineering choices (SwiGlu, RMSNorm, flash attention, variable‑length training), stronger data shuffling/augmentations, and representational tweaks like 3D RoPE plus per‑task embeddings that let the model specialize per puzzle.

The developer also switched the objective to a supervised one that trains only on output tokens and relies on cheap test‑time training (a metalearning/transductive style): the model sees test inputs at adaptation time and optimizes per‑task embeddings. The post has the telling line:

"This approach is now supervised. What’s weird is that the test loss is now worse, yet it scores better!"

That sentence captures the odd trade: worse global loss but better per‑task performance after targeted adaptation. The community split quickly — many praised the reproducibility and low cost, while critics argued the method is effectively bench‑maxxing via transductive tricks and questioned whether that generalizes beyond ARC’s format (the classic "frame problem" critique). Others pointed out that using test inputs at adaptation is a legitimate metalearning technique in some research contexts, but it does change what "generalization" means for the benchmark.

Practical takeaway: this is a strong reminder that sample efficiency and per‑task adaptation still have huge upside, and that small models with smart training protocols can outperform expectations on puzzle‑style tasks. But also: if a method depends on observing the test input at adaptation, treat claims of "bench solved" with a grain of salt until cross‑dataset, non‑transductive evaluations are shown. Read the original post for the code, ablations, and the discussion thread.

AI & Agents

Saab Enters Collaborative Combat Aircraft Race with High‑End Concept

Why this matters now: Saab’s A3 concept and near‑term demonstrators signal a shift in European defense: higher‑performance “loyal wingman” designs and embedded autonomy could reshape procurement and prototyping timetables for crewed/uncrewed mix.

Saab unveiled a tailless, double‑delta, supersonic unmanned concept (A3) intended to team with the Gripen E, and laid out a near roadmap of demonstrators: an F414‑powered A1 to fly in about 15 months, then an A2 with an internal weapon bay. Saab frames these not as throwaway swarm drones but as survivable, capable platforms that require certification and integration into current air ecosystems. Autonomy and software get heavy emphasis — their in‑house "fighter pilot academy" will train behavior profiles from aggressive to collaborative.

On Hacker News the reaction mixed optimism about faster, cheaper prototyping and skepticism about whether high‑end loyal wingmen are the right strategic bet compared with cheaper attritable swarms. The program is notable because it pushes the conversation beyond "cheap drone numbers" to software, certification, and how autonomy gets trained and validated in a manned‑unmanned team.

Source: Aviation Week.

Markets

Low‑cost, high‑sample‑efficiency wins like the ARC result matter to markets because they compress the barrier to entry for specialized model applications. If a single engineer can iterate to a strong benchmark score with a consumer GPU and clever adaptation, then niche startups and labs can prototype targeted capabilities without cloud spend or large model infra. That changes where venture dollars and hiring bandwidth flow: toward teams that can combine model craft with smart evaluation, not only those who own massive compute.

(See the ARC‑AGI‑1 post for the reproducible recipe that sparked this discussion.)

World

EFF to Governor Newsom: Veto California's AB 1709

Why this matters now: California’s A.B. 1709 would ban key social features for users under 16 and likely force invasive age verification; the EFF warns it would create privacy and free‑speech harms that could outlast the law if enacted.

A.B. 1709 aims to remove "addictive features" (including recommendation rankers and basic social signals like likes/follows) for users under 16. The Electronic Frontier Foundation urged Governor Newsom to veto, arguing the law would push platforms toward invasive age verification—government ID or biometric gates—that centralize sensitive data and harm marginalized youth who rely on online communities for support. Critics also fear blunt bans will drive activity underground or to less regulated services.

The debate neatly captures a policy tension: curb algorithmic harms without creating surveillance or cutting off legitimate social support. The EFF frames the bill as a "privacy and free speech nightmare," and the spread of fixes suggested on public forums ranges from stronger parental controls to platform design changes. The stakes are high because California often sets de facto national norms for tech regulation.

Source: EFF letter to Governor Newsom.

Dev & Open Source

tmp.0ut Volume 5

Why this matters now: tmp.0ut Volume 5 revives knife‑edge systems craftsmanship and anti‑forensics thinking, useful reading for engineers who want to see the fundamentals exercised at byte scale.

The throwback hacker zine released an ASCII‑styled volume with a Doug McIlroy interview and tight pieces like a 57‑byte ELF teardown and a 440‑byte metamorphic ELF‑64 virus exploration. It’s less mainstream news and more a concentrated festival of system craft — reverse engineering, minimal executables, and packing tricks — that teaches fundamentals by example and sparks nostalgia among systems and security engineers.

Source: tmp.0ut Volume 5.

Io_uring Without Readahead (deep dive)

Why this matters now: If you use io_uring with O_DIRECT (common in high‑performance storage paths), you must think about readahead at the application level — otherwise you lose request merging and can cripple device throughput.

A small PR and follow‑up measurements made a clear, practical point about how io_uring + O_DIRECT interacts with kernel readahead. When files are opened O_DIRECT, the kernel’s automatic readahead is disabled; as the post puts it:

"O_DIRECT takes away kernel readahead, so getting it back means implementing it in the application."

Without readahead the io_uring path kept one outstanding read at a time, preventing the block layer and device from merging adjacent requests — device I/O exploded into many small requests. Adding a simple 32‑page application readahead window caused the block layer to merge reads into much fewer, larger device requests (device requests dropped from ~196k to ~16k), which boosted throughput despite fetching some pages the application never used.

The tradeoffs are concrete: with O_DIRECT you avoid kernel copies but you lose warmed CPU cache lines, so cache miss rates go up. Using sqpoll (a kernel polling thread) can reduce syscall latency but consumes CPU — a net win only if you have spare cores. The author and commenters suggest alternatives—buffered I/O with RWF_DONTCACHE, using preadv/preadv for contiguous readahead, or mmap‑based strategies—but the central lesson is actionable: pick the readahead and I/O model to match your workload’s concurrency and your priorities between merged device requests and CPU/cache cost.

Source: Io_uring Without Readahead.

RotaryCell: Rotary phone over LTE

Why this matters now: RotaryCell shows a practical, non‑destructive path to modernize vintage phones with LTE using an ESP32‑S3 and SLIC hardware — a solid blueprint for makers, plus real safety considerations.

RotaryCell integrates a LilyGO T‑A7670G‑S3 (ESP32‑S3 + A7670 modem), a Silvertel AG1171 SLIC to drive the handset and bell, a protected 21700 battery, and OTA firmware updates while preserving the handset, dial and ringer. The repo is a working engineering archive — hand‑wired prototypes and BOMs are included — but reviewers flagged safety notes (don’t accept 5 V over RJ‑11; design should tolerate accidental live wiring) and audio tradeoffs from old handset speakers.

Source: RotaryCell repo.

The Bottom Line

Small, clever changes still move the needle: ARC’s sub‑dollar experiment and the io_uring measurements both show that protocol and systems choices can unlock performance and cost savings that raw scale misses. At the same time, policy and design choices (from AB 1709 to aircraft autonomy) are where technical capability and public consequence collide — those debates deserve technical literacy and careful weighing of tradeoffs.

Sources