Dagens Vibes — 15. juli 2026

Latent.Space@latentspacepod

Did... Codex just overtake Claude Code? 24.5 hours ago Tibo announced 6M active users. this means Codex usage jumped 1M in ~ONE DAY. the last user number we heard from Claude Code was 2M in Feb: https://t.co/jghFZlpjEq more analysis within, but this is very big if true. https://t.co/cMw1QUyj9C

Anshu@anshuc

This is my "feel the AGI" moment: I used GPT-5.6 Sol to train my own autocorrect model that outperforms GPT-5.6 Sol (wtf??) I have no ML background. I have no idea what I'm doing. I just kept pushing Sol until it spat out a SOTA model. And I spent $0. The motivation: Years of talking to AI have made me terrible at typing. Rather than fix my skill issue, I decided to throw more AI at it. My idea was: instead of autocorrect that interrupts my flow, I want to type fast with mistakes and have AI clean it up after. I wanted the smallest local model possible, for speed, for battery life, for science! So I decided to train my own. Inspired by @karpathy’s autoresearch, I ran Codex /goal with this setup: pick an experiment, try it, record the results to a doc, throw it out if it fails, and plan the next experiment without repeating failures. I gave a few examples that had to pass, tight latency targets, and let it run. Sol did some amazing things. First, it scanned benchmarks and shortlisted base models: Qwen 3.5, Gemma 4, Liquid LFM 2.5. It found a dataset on HuggingFace for typed text. Then it built a simulator for fingers striking a Mac keyboard, modeling the physical layout with a Gaussian distribution around each key. It simulated striking the wrong key, wrong order, fat-fingering, etc. With the models + data + simulator, it fine-tuned using MLX right on my MacBook. It had a working prototype within an hour! But accuracy was pretty poor. — Problem 1: Tokenization Sol read papers, ran tests, and identified that the tokenizer was the bottleneck. Tokenization makes typos hard for the model to see, so it memorizes mappings instead of using its language priors. Sol tried ByT5, Google’s tokenizer-free byte-level LLM. This made a big improvement, but the model is old and lacked the knowledge needed to reach Sol performance. Sol dug deeper and realized a tokenizer-free model isn’t needed; instead, it used T5Gemma, an encoder-decoder model. This can understand the input deeply before producing output, and furthermore, Sol could post-train the encoder to improve performance. This gave a much higher ceiling. — Problem 2: Loss function Now the model was correcting some typos perfectly, but ignoring most. Sol realized that standard cross-entropy loss was teaching the model to avoid edits, because the vast majority of characters in the training data were left unmodified. The fix was wild: Sol wrote a custom loss function that byte-aligns the source and target strings, uses a dynamic programming algorithm to compute the minimum edits between the two, then weights correct edits much higher than copies. After a lot of tuning, this dramatically improved accuracy. — Problem 3: Autoregression One failure mode remained: if the model made a mistake, it couldn’t backtrack. It could only predict the next token. Teaching it to “think” like a reasoning model would solve this, but would be far too slow. Sol found a beautiful solution: instead of greedily predicting the next token, beam search over all possibilities. This parallelizes the exploration instead of one linear chain-of-thought. At the end, choose the path with highest cumulative log probability. This worked great, but made the experience worse, since the user wouldn’t see progress until the whole search was done. To fix this, Sol made a clever observation: after each search step, the longest common prefix among surviving branches is guaranteed to appear in the final result, so it can be displayed immediately. As the search progresses, weaker paths are dropped and the prefix grows, so the user sees continuous progress. Sol built all this as a custom MLX pipeline that does the parallel decoding on the MacBook GPU, with just ~40ms TTFT. It’s crazy fast and entirely local. — Final eval (error reduction rate, higher is better): - Apple autocorrect: 49.66% - GPT-5.6 Luna: 82.47% - GPT-5.6 Terra: 87.64% - GPT-5.6 Sol: 90.56% - Our model (1.7B): 91.02% Final cost: - 1 quota reset (thanks @thsottiaux) - $0 (And yes, I verified there's no cheating. In fact, we test words scrubbed from the training data to prove the model isn’t memorizing) There were a ton more details and tangents I could write about: contrastive learning, GRPO, DPO, dynamic masking, and more. Sol is a fascinating and creative model. It blew my mind so many times. Don’t let a lack of experience stop you: Sol makes AI experiments accessible to anyone!

Feross@feross

🚨 Active supply chain attack on AsyncAPI. Five malicious @asyncapi packages were published to npm today, shipped through the project's own GitHub Actions trusted publishing pipeline after an attacker poisoned a commit on the next branch. Affected versions: @asyncapi/generator@3.3.1 @asyncapi/generator-helpers@1.1.1 @asyncapi/generator-components@0.7.1 @asyncapi/specs@6.11.2 @asyncapi/specs@6.11.2-alpha.1 The first three were published within a six-second window at 07:10 UTC. AsyncAPI tooling runs on developer machines and CI runners, so the implant executes directly in build environments. Socket AI Scanner flagged all five releases as confirmed malware. This is a multi-stage botnet loader: • On load, an obfuscated implant spawns a detached, hidden Node.js child process • The child downloads an 8.25 MB encrypted payload (sync.js) from IPFS into a fake "NodeJS" data directory on Windows, macOS, or Linux • HKDF-SHA256 key derivation and AES-256-GCM decryption unpack the final stage • That final stage is Miasma, a 3.09 MB command framework with REST-based C2 plus fallback channels over Nostr, IPFS, Ethereum RPC, and BitTorrent DHT • 12 command types, including ShellExec, file get/put/delete, payload updates, and self-destruct • Persists on Linux via a systemd user service (miasma-monitor.service) The campaign config is labeled "miasma-train-p1" and contains dormant modules for PyPI, RubyGems, and Cargo. npm appears to be phase one. If you installed any affected version, treat the host as potentially compromised. Check for detached Node.js processes with ignored stdio, connections to 85[.]137[.]53[.]71, fake NodeJS directories, and the miasma-monitor service. Pin to known-good versions and audit lockfiles before your next install. Full analysis: https://t.co/Md6AkAABI2 Developing story...

Saoud Rizwan@sdrzn

TIL of SlopCodeBench, a benchmark for how coding agents slowly turn codebases into slop. instead of single shot tasks like swe-bench, the agent gets several tasks one after another so eg bad architectural decisions early on lead to worse results for the later tasks. compared to 473 human written python repos, agent code is: - 2.3x more verbose (redundant) - 2x more eroded - degrades 5-7x faster per change than humans do across their git history we are now anti slop engineers

PrismML@PrismML

Today, we’re announcing Bonsai 27B: the first 27B-class model to run on a phone. Bonsai 27B is the new multimodal flagship of the Bonsai family. Based on Qwen3.6 27B, it brings a new capability tier to local AI: multi-step reasoning, structured tool use, long-context workflows, and coherent agentic loops. Until now, models in this class have been impractical to deploy locally. A 27B model occupies roughly 54 GB in 16-bit precision, and even a strong 4-bit build is around 18GB - too large for a phone and for most laptops. Bonsai 27B changes that. It comes in two variants: • Ternary Bonsai 27B: 5.9 GB, 1.71 effective bits per weight, optimized for laptop-class quality. • 1-bit Bonsai 27B: 3.9 GB, 1.125 effective bits per weight, optimized for phone-class footprint. Everything is open-sourced today under the Apache 2.0 license.

joel ⛈️@joelhooks

This is a fun project Lakedbed, Herdr, Pi, Effect, XState prototyping a looping autonomous agent that monitors issues and clears its own backlog. The project is dogfooding an issue tracker into a durable agent that is building the issue tracker its looping over. It's an imperfect demo and the result isn't polished, but I think there's a lot fo interesting ideas to explore and expand on. The goal here is to demo a stack of tools that have been giving me consistently reliable results. Herdr and Pi make a KILLER combo for building a bespoke custom harness around your work. Lakebed is really nice to work with. Plenty of other opinions in the workshop lol - Pi as the agent harness — a minimal loop you own instead of rent, running GPT-5.5 through a Codex subscription inside a Docker workshop container - Planning before prompting: TLDraw sketches, a grilling session with Matt Pocock's Wayfinder skill, and a VISION.md to act as guardrails for the looping agent - Event sourcing with Effect v4 and Effect Schema, ports-and-adapters so the JSONL issue store can become GitHub Issues or Linear or whatever later - Multi-agent orchestration in herdr: an operator pane and an agent-loop pane, where one Pi session literally types prompts into another (fuckin LOVE this) - Enforcement that actually bites: OxLint with Ultracite, Lefthook hooks, and an agent that tries to eslint-disable its way past a complexity rule before fixing it properly 🤡 - A live issue tracker UI on Lakebed, built by the loop it tracks Workshop repo: https://t.co/cyTymyueCv The repo has a docker container to fire it up as a sandbox. Chapters: 0:00 Intro: Loopcraft and the workshop setup 2:25 Starting Pi inside the Docker container 4:31 Designing the looping issue resolver 10:16 Choosing XState v5 and Effect v4, prompting the starter 15:17 Why Pi: a minimal harness you own 19:35 Reviewing the generated scaffold 24:53 Architecture summary page with Lakebed 30:43 Matt Pocock skills and the vision.md concept 36:37 Grilling session: defining the vision 46:54 Daemon architecture and spec/ticket skills 55:38 Agent loop pane: one agent prompting another 1:01:22 Watching the build: compaction, tests, lint enforcement 1:07:59 Building the Loopcraft Pi extension and monitor 1:15:32 Lakebed issue tracker UI 1:21:07 Kanban board live: running the loop end to end 1:31:49 Wrap-up: bugs, next steps, takeaways

Mitchell Hashimoto@mitchellh

A ChatGPT automation just found ~$45K in erroneous invoices across 3 years of billing history that I've confirmed and already had resolved. My lifetime history for ChatGPT is ~$1,800, so it just paid for itself 25x over. I setup an automation with read-only access to my email, and tasked this one specifically with analyzing construction invoices. It has access to prior construction invoices, emails, meeting notes, etc. It produces a report and emails it to me (the only email its allowed to send, enforced by API token) whenever I receive a construction invoice. Across 3 years of construction projects, it found about $45K in issues. Some were wrong amounts, some were duplicate invoices, some were invoices addressed to the wrong person. I manually verified, emailed my GCs, and got refunded/credited. I get multiple construction bills each month and each bill is ~50 pages in a PDF of low-quality scanned paper. I do manually review each bill but its pretty hard to be right all the time. I do believe these were genuine mistakes and not done out of ill will just based on what the mistakes were. I don't want to share my full construction costs across the past few years, but $45K is a very small percentage of overall billed amounts. Pretty sweet.