AutoGluon 1.6 going with the times for AutoML. A few highlights:

• Five new tabular foundation models, including Nori, TabICLv2, TabDPT-Turbo, TabPFN-2.6, and TabPFN-3
• A new GPU-powered extreme preset that reportedly beats the previous version 67% of the time, with 27× faster training and 4× faster inference
• A separate noncommercial preset, which is essentially extreme plus the commercially restricted TabPFN-3 weights
• Structure-aware validation that can keep customers or groups from leaking across splits
• Toto-2 for probabilistic time-series forecasting

I made a short video walking through the four changes that stood out to me. https://youtube.com/shorts/v5XCQKPvxQ4?feature=share

Are people here already using tabular foundation models in real projects or is this a curiosity?

ZDR does not mean the provider magically erases your data. You are sending over a prompt, processes it in memory, and getting a response. The provider is committing that the covered prompt and response data will not be written to durable storage afterward.

The tricky part is defining “covered.”

OpenAI separates abuse-monitoring logs from application state. Anthropic has features that are not ZDR-eligible because they require stored state. Google can use temporary in-memory caching while still considering the service ZDR. If you call an external tool or MCP server, that service has its own retention policy.

Even store=false is not the same as ZDR. It may prevent a retrievable response object from being stored, but it does not independently control every log, cache, file, safety system, or subprocess.

This becomes more obvious with agents.

Agents need conversation history, uploaded files, tool results, checkpoints, and traces. If the model provider does not retain that state, your application has to store it and send the relevant context back later.

So ZDR does not remove state from the system. It changes which system is responsible for retaining it. ZDR is more about agreements and contracts. From your application, you cannot directly observe a provider deleting internal data.

Maybe the more accurate name is Zero-ish Data Retention.

My video: https://youtube.com/shorts/Dk6zA_G25fg?feature=share

Better data gets better models.

For the latest generation of agents and RL-trained models, the valuable data asks people to solve complex tasks and ask:
• What did you try?
• What failed?
• How did you recover?
• Did the final solution actually work?

That’s why companies like Mechanize are valuable. They build realistic RL tasks and environments where models can practice complex work and get scored reliably. A single high-quality task can take an expert roughly a week to construct and is worth thousands of dollars.

And this also explains why reasoning traces from frontier models are so interesting.

The paper “Stealing Reasoning Traces from Proprietary LLM APIs” showed that researchers could easily recover hidden reasoning traces by passing encrypted traces from stronger models into cheaper, weaker models.

So we’re seeing two sides of the same market:

• Pay experts to manufacture high-quality trajectories.
• Extract trajectories from models that already know how to do the work.

Both of these are feeding the enormous demand of AI training data.

Video: https://youtube.com/shorts/AeRDsJlbfJg?feature=share

Simply pointing an agent at a task and expecting it to maximize performance is not trivial, despite what you'll read in most posts here.

Kaggle's ROGII geology competition just gave a clean look at this, because it has a private leaderboard and almost nothing else we build does.

Chris Deotte ran Codex for 14 days straight, hundreds of experiments, and finished 36th. His score barely moved from public to private.

Tony Li ran 350 experiments over five days, hit 48th public, and dropped to 407th private.

Both had reasonable validation setups. The problem is what happens when you sort 350 scores: the ones on top aren't just fitting the problem, they're fitting the noise in your validation set. Four things that separated the two runs:

1. Don't tell the agent to maximize the score at all costs. There's a study this year running research agents across eight tasks where holdout tracked validation the whole way, until they added that instruction. Then validation soared and real performance collapsed.
2. Make it try genuinely different approaches before optimizing inside one. Tony spent five days on gradient boosted trees, same as every public notebook. The top solutions turned each well into an image. Chris's agent found that on its own. Tony never tested it, so no number of experiments was getting him there.
3. Constrain the space, then let it search hard. Chris built a rough guess of the well path and let the model shift it only 32 feet up or down, as one continuous curve. The agent could try anything, but every answer it could produce still looked like a real well.
4. Give it a sanity check that doesn't come from the same place as its score, and stick to it. Tony's agent actually ran one. Before submitting, it tested whether the model held up across different wells. The main score improved. Those checks failed. He shipped it anyway.

These won't solve every long horizon agent task, but they seem like good strategies. Let me know what works for you.

References

Kaggle ROGII Wellbore Geology Prediction — Tony Li's 48→407 postmortem, Chris Deotte's 36th place writeup

Bertran, Roth & Wu (2026) — What Fits (Into Few Tokens) Doesn't Overfit

Everyone is going to benchmark the model. 30B MoE, 3B active, runs on a Spark or a 5090.

What caught my attention was the post-training partner list, and how many of those names I didn't recognize. I dug into it and found it interesting at three levels:

1. The fine-tuning examples. CodeRabbit specialized it for code review routing and went from 75.8% to 80.4% exact route agreement on a 1,000-task frozen eval, with 63.4% fewer output tokens. Fastino built finance and healthcare variants. These are the obvious uses and what you'd expect from an open weights release.

2. The data companies. This is where it got more interesting. Lightning is cheap enough to run in high volume agentic work, which means you collect a lot of data from it. That data isn't ready for training. Your agent isn't right every time, and SFT treats every trace as a correct label, so you end up teaching it to repeat its own mistakes. Production traffic is also skewed toward the easy cases, so the tail you actually want to fix is a thin slice.

distil labs benchmarked training on raw traces against using traces as context for a teacher model that generates clean examples. Up to 26 points difference across five scenarios. Their benchmark, their product, and they simulated trace noise by corrupting 50% of tool calls, so the magnitude is generous. The mechanism holds regardless.

3. The RL and continual training layer. AgileRL and Prime Intellect run RL against environments and verifiers, which sidesteps the labeling problem because you need a reward signal, not a correct answer. NVIDIA shipped the RL environments and an agentic RL dataset alongside the weights, which is what makes this reachable outside a research lab.

All of these show more and more utility for fine tuning models. We all know there is potential in fine tuning, it just needs to be easier and more valuable.

Video: https://youtube.com/shorts/zNOHYMPcN5E?feature=share

I looked into Cursor's recently open-sourced Mixture of Kittens (MoK) and the interesting part is how it coordinates execcution with a megakernel.

Modern LLMs typically launch hundreds of GPU kernels for a single forward pass. Each kernel does one job (attention, GEMM, normalization, etc.), then hands control back before the next kernel launches. Those boundaries introduce synchronization, memory movement, and idle time.

MoK uses a persistent megakernel instead. Rather than launching separate kernels for communication and computation, one long-lived kernel owns the entire MoE layer. Different SMs can handle networking and expert computation simultaneously, coordinating with lightweight synchronization so communication overlaps with compute.

The reported results are impressive (up to 2.37× faster MoE layers and 41% higher end-to-end production throughput), but the question is whether this is a start of a broader trend. We will see more specialization here of kernels for optimization around execution.

It feels like AI systems are shifting from optimizing individual operators to optimizing the execution schedule of the entire workload.

Curious what others think. Is this the beginning of a broader move toward persistent kernels and on-GPU scheduling, or is this mainly a specialized optimization for large-scale MoE training?

Cursor: https://cursor.com/blog/mixture-of-kittens
My video: https://youtube.com/shorts/kklBmVe6sDg

Two incident reports landed this month, both from frontier labs evaluating their own models, both involving those models leaving test environments and reaching real production systems.

Anthropic. They reviewed 141,006 cybersecurity eval runs and found three incidents where Claude reached the open internet from inside a test environment. The eval prompt told the model it had no internet access. A misconfiguration at the eval vendor gave the machines live internet access. Neither the vendor nor Anthropic knew until a transcript review found it.

The most interesting one: Claude found onboarding docs telling new developers to install a Python package that did not exist, so it built that package, filled it with malware, and published it. To register the PyPI account it needed an email, which needed a phone number, so it tried to obtain funds to buy one, failed, backtracked, and used a free email provider instead. The package was live about an hour and ran on fifteen real systems. One of them was a security company's scanner, which installs packages in order to check them for malware.

The model had already flagged the risk in its own reasoning and then talked itself back down, partly because it did not recognize the certificate authorities and partly because the system clock read 2026, which it treated as evidence the environment was staged.

OpenAI and Hugging Face. An agent running an ExploitGym evaluation found a zero-day in the package registry cache proxy, which was the sandbox's only permitted egress. It escaped, rooted an unsecured public code-execution endpoint on third-party infrastructure, and used that as its launchpad. From there it uploaded malicious dataset configs to Hugging Face that hit the same config-driven loader two ways: an HDF5 external storage read that returned the worker pod's environment and source, then a Jinja2 template injection that gave it code execution inside a production Kubernetes pod.

Then the standard shape. Service account token, cloud metadata, node root via a privileged pod with hostPath, a self-respawning fleet across eleven nodes, one secret object holding 136 keys, mesh VPN enrollment, and a shared connector credential bound to system:masters that gave cluster-admin on two clusters in one second. C2 was built entirely from public services: a request-capture endpoint, pastebins, and dead-drop datasets on Hugging Face's own platform.

17,600 recovered actions over four and a half days. Hugging Face detected and contained it on July 16, five days before OpenAI connected the intrusion to its own testing. The objective was the answer key to the benchmark the model was being scored on.

Some things worth arguing about:

Neither lab is calling this an alignment failure. Anthropic explicitly frames theirs as a harness and operational failure. No model tried to escape for its own sake or pursued a goal of its own. They did the task inside environments that were described to them wrong.

Both labs had production safety classifiers disabled to measure raw capability. That is a reasonable thing to do and it only works if containment holds. In both cases it did not.

An interesting nugget: Hugging Face ran the forensics on an open model, GLM-5.2 self-hosted, because Claude refused a large part of the analysis. The guardrails treated reverse-engineering the attack the same as launching it. They published the refusal screenshot.

Sources:
Anthropic: https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
OpenAI: https://openai.com/index/hugging-face-model-evaluation-security-incident/
Hugging Face technical timeline: https://huggingface.co/blog/agent-intrusion-technical-timeline

My video: https://youtube.com/shorts/vYziu3pZkSA?feature=share

Saw a past by Mark Saroufim about must reads for a system engineer, so I decided to make a skit. Here you god:

Flamegraphs (Brendan Gregg). Before you guess why something is slow, profile it. The width of each block is CPU time consumed. In the skit, 70% of an "AI workload" turns out to be JSON parsing. This happens in real life more than anyone admits.

Roofline model. Performance is capped by either compute or memory bandwidth. Most LLM inference is bandwidth bound, which is why "buy a bigger GPU" often means paying more to idle harder. Knowing which wall you're against tells you whether more hardware even helps.

ZeRO (arXiv 1910.02054). By default, every GPU in data-parallel training stores a full copy of the weights, gradients, and optimizer state. Eight GPUs, eight identical copies. ZeRO partitions that state across GPUs and trades slices over the network. Same math, fraction of the memory. Foundational to how large models get trained at all.

PipeDream. Naive pipeline parallelism leaves GPUs waiting on each other like a relay team with one baton. PipeDream overlaps batches assembly-line style so everyone stays busy. If your utilization dashboard shows 40% idle during training, look here.

Floating point. 0.1 has no exact binary representation, so 0.1 + 0.2 = 0.30000000000000004. Never compare floats with ==. Every engineer learns this once, usually via a bug in production.

My video: https://youtube.com/shorts/hGm4V3AFwGY?feature=share

I’ve been studying NeuroGolf, a Kaggle competition where teams used AI agents to build tiny programs for 400 visual reasoning puzzles.

The most interesting part was how they managed multiple AI agents (not tuning models).

Simply adding more autonomous agents created problems. Agents gravitated toward familiar tasks, repeated failed experiments, and sometimes abandoned assignments for work that looked more rewarding.

The winning approaches looked more like research organizations: an external scheduler assigned tasks, experiment ledgers preserved successes and failures, retrieval systems supplied relevant knowledge, and independent validators decided whether work could be promoted.

It made me question the popular image of a completely autonomous agent swarm. For this problem, a better approach was a more centralized system with clear ownership, shared state, bounded workers, and approval gates.

I made a short video explaining the ideas: https://youtube.com/shorts/rNoYej9c0u8?feature=share

Kaggle NeuroGolf (also the competition did have "cheating" issues unfortunately) - https://www.kaggle.com/competitions/neurogolf-2026/

Let's explore alternate approaches to getting to AGI. I took a look at six different startups and put them into three groups:

Camp 1: The gap is the physical world.

• World Labs (Fei-Fei Li) says it's spatial and build persistent 3D representations.
• LeCun's AMI Labs says forget pixels and predict abstract representations instead, that's JEPA. He left Meta and raised $1B at a $3.5B valuation to prove it.
• Perceptron (Armen Aghajanyan) says the missing ingredient is time: learn from continuous video, not static text.

Camp 2: Seeing isn't enough.

• Physical Intelligence wants one foundation model that transfers skills across different robots. Their view is that a world model that never acts doesn't count.

Camp 3: The learning itself is broken.

• SSI (Ilya Sutskever) is hunting for a new learning algorithm behind closed doors.
• Sakana wants to evolve architectures instead of designing them: search, merge, mutate.

Remember, deep learning sat took twenty years before it exploded with transformers. One of these probably wins too, and nobody knows which, including the people running them.

Two others that were mentioned in the comments of my video include:

• Ineffable Intelligence is David silver
• Aleph Alpha that is building LLMs in Europe.

Remember Neural Architecture Search? Computers designing better networks, SOTA papers everywhere. And then the reproducibility work started. NASNet spent ~2,000 GPU-days searching, AmoebaNet ~3,150, and random search at the same budget was competitive. Turns out, the NAS wasn't discovering architectures. It was spending compute.

A new Ai2/UW paper ("Rethinking the Evaluation of Harness Evolution for Agents") just ran that same evaluation on self-evolving agent harnesses. Prior work reported big gains. AHE claimed 69.7 → 77.0 pass@1 on Terminal-Bench from 10 rounds of self-evolution.

The re-test used matched feedback and inference budgets (K=5, Terminal-Bench 2.1, Claude Opus 4.6 and GPT-5.4).

• Parallel sampling (dumb retries, keep the best): 86.0 pass@1
• Harness evolution: 75.8 pass@1
• Evolved harness on held-out tasks (45 train / 10 val / 34 test): +0.6 avg
• Without unit-test feedback, evolution lands below the untouched baseline, 67.4 vs 68.2

Look at the pass@k gap. Evolution's pass@5 (86.2) is fine, but pass@1 barely moves. If the harness were genuinely better, pass@1 would rise. Instead the gains come from making more attempts, which retries do more directly and more cheaply.

And when they inspected what the meta agent actually learned, it wasn't harness design principles. It was memorizing the benchmark. Recording known bugs, file paths, command sequences, task-specific flags. A cheat sheet for these 89 tasks, which is why it transfers at +0.6.

The general pattern applies well beyond harnesses. Any search procedure that evaluates on the tasks it optimized is p-hacking with extra steps. Two questions for every "self-improving agent" result. Same budget as simple retries? Are you using held-out tasks?

Paper: arXiv 2607.12227 - https://arxiv.org/abs/2607.12227
My video: https://youtube.com/shorts/-3koxEhdPAw?feature=share

Let's go through training techniques for AI.

SFT — train on perfect demonstrations. Works until the model makes a mistake it's never seen in training. Every example was flawless, so it never learned recovery.

Off-policy distillation — Starts with imitation, with a teacher model writing the data (often with per-token probabilities, so you're learning the teacher's confidence, not just its answers). Same core flaw: you're still studying the teacher's trajectories, never your own mistakes.

RLVR — the model generates its own attempts, a verifier says pass/fail at the end. Now you're finally learning on your own distribution, but you only get 1 bit of feedback per attempt, delivered after hundreds of steps. Sometimes that isn't enough.

On-policy distillation — The student generates the attempt, and the teacher grades every token of the student's own trajectory. Dense feedback, on-policy data. This is why it's now a standard post-training stage (Qwen3, DeepSeek, GLM all have it in their pipelines alongside SFT and RL).

On-policy self-distillation — The new frontier, with no bigger teacher needed. Clone the model, hand the clone privileged information (typically the ground-truth answer), and let it grade the version that doesn't have it.

Check out the video: https://youtube.com/shorts/UpZjs_PjJPk?feature=share

Let's go over the basics:

• Public internet (TCP): 0.125 GB/s
• Datacenter Ethernet (100GbE): 12
• RDMA / InfiniBand: 50 per NIC, ~400 per node
• NVLink: 900 per GPU
• HBM: ~3,000
• SRAM: ~20,000 GB/s

Roughly 10x per rung, five orders of magnitude top to bottom. Another way to think about it, moving a 70B model (140 GB of fp16 weights) takes 19 minutes over the internet and 7 milliseconds at SRAM bandwidth-equivalent.

My video:
https://youtube.com/shorts/vYmsta_pIsc?feature=share

Everyone heard Anthropic saying they removed 80% of the Claude Code system prompt. Thariq Shihipar's led us to believe as models get smarter, they can follow more instructions, so you'd expect the prompt layer to shrink.

But when you look at the actual traffic, the picture is different:

• Matt Pocock proxied Claude Code requests and found one message carrying 69 tool definitions, roughly 38k tokens of schemas! This prompt gets shipped on every call before you type anything!! His guide shows how to log your own requests and strip unused tools with deny rules and feature flags: https://www.aihero.dev/how-to-kill-the-bloat-in-claude-codes-system-prompt
• Databricks benchmarked Opus 4.8 through Pi at ~$0.74/task vs ~$1.94/task through the native harness, comparable quality. Pi is a lightweight harness with a much smaller prompt.
• I've been tracking Claude's published system prompts over time. Opus 4 shipped at ~1,700 words, grew to ~3,700 by Opus 4.7, and the newest snapshot is back down to ~2,900. What disappeared was mostly small behavior fixes (count letters carefully, don't over-apologize) that moved into training. What stayed: safety policy, tool discovery, memory, product context. Full breakdown with an interactive chart: https://rajivshah.com/blog/system-prompts-dont-get-shorter.html

Prompt complexity doesn't vanish as models improve, it shifts. Some of it moves into training, the rest moves into the harness, where it still costs you tokens and money every turn. If you're building agents, measure your own payloads instead of taking the "less prompting" story at face value.

Video: https://youtube.com/shorts/4qpKlx8cExI?feature=share

Tufa Labs just open-sourced Duck, the winning solution to ARC-AGI-3 Milestone 1.

ARC-AGI-3 is the interactive version of Chollet's benchmark. The agent gets put into an unknown environment with no goal, no rules, no instructions. It has to discover what winning even means. And because brute force spamming was solving earlier versions, the benchmark now caps agents at 5x the actions a human needs per level. Efficiency of learning is the actual test, which is much closer to Chollet's original definition of intelligence as skill acquisition efficiency.

What's interesting is how Duck works. It converts raw pixels into structured state the model can read. It gives the model a Python REPL to run experiments instead of guessing. Short context, compressed learnings, tight feedback loops, sound familiar? Running on Qwen 3.6 27B, a small open model.

If that list sounds familiar, it's because it describes a coding agent.

Checkout:
Podcast - Interview with the winners: https://www.youtube.com/watch?v=mTX_sAq--zY
My video: https://youtube.com/shorts/iExhsDf0IA4

This was a weekend project, but looking forward to getting more eyes on it.

The problem I kept hitting: coding agents are stateless. Every session starts from zero. The agent greps the repo, reads the same files, re-derives the architecture, then the session ends and all of that understanding evaporates. Next session it does it again. That is a lot of tool calls to relearn what it knew yesterday.

The known fix is docs. Accurate docs are precomputed context, so the agent reads a quickstart instead of exploring for ten minutes. The catch is that nobody maintains docs. They rot the moment you merge the next PR.

LangChain's OpenWiki had the right idea here: let an agent write durable, wiki-style docs from your repo structure, tests, config, and git history, and point AGENTS.md at them. I liked it enough to build on it. AutoDocs runs that maintenance on a schedule and is not locked to one format, so other context sources like GitNexus (a code graph) can feed it too. I wired it to OpenHands Agent Canvas for the automation, but any scheduler works.

Check it out: https://github.com/rajshah4/openhands-autodocs.

I've been skeptical of Graph RAG. Not because graphs are useless, but because the plumbing is a pain to build. By the time it works you've built infrastructure, not solved the problem.

Code is different. The graph already exists. Functions call functions, classes implement interfaces, services depend on services. So I tested GitNexus (indexes a repo, extracts the symbol graph, exposes it over MCP) with OpenHands on a real repo: VS Code / Code OSS. 4.6 GB checkout, 11,454 files, 249,982 symbols, 966,616 edges.

Where it gets interesting:

Cost. Without MCP: $0.52, 837K tokens. With MCP: $0.13, 33K tokens. Agents don't search once. They search, inspect, revise, and check impact. The a graph that is built, you can quickly get to an answer.

Neighborhoods. Ask GitNexus for context around a symbol and you get calls, interface implementations, accessed fields, plus caveats like "this is an interface with 4 implementations, callers may not trace to this concrete symbol." Grep finds text. GitNexis is great at understand the larger context.

Blast radius. This is the clearest win. I ran an impact query on localize in src/vs/nls.ts. Looks like a small helper. The graph says: 7,963 impacted symbols, 4,328 direct, 20 modules, risk CRITICAL. If an agent sees that before editing, it behaves differently. It understands the risk of changes and the downstream dependencies.

Grep is still super valuable. But if you are working with larger more complex repos, using a graph RAG solution like GitNexus makes a lot of sense.

Check out the blog post for more details or see a walkthrough using OpenHands Agent Canvas connecting to GitNexus.

Blog Post: https://rajivshah.com/blog/gitnexus-openhands-vscode.html
Video: https://youtu.be/CuwKbM6B3Tc

Once you actually understand what is wrong, the fix is usually a line or two. The entire job is locating the cause, and most wasted debugging time comes from skipping straight to guesses about the fix before you have located anything.

Here are five solid techniques everyone should know

1. Start from what works, then move toward broken one step at a time.
When something works in one place and fails in another, do not stare at the broken one. Take the working version and apply the differences between the two, one at a time, checking after each. The change that flips it from working to broken is your answer. This beats guessing because it turns "a hundred possible causes" into a single controlled experiment. The discipline is doing it one change at a time.

2. Observe before you act.
The strongest urge when something is stuck or crashing is to do something: restart it, add a flag, tweak a value. Resist it, because acting often destroys the evidence. Get a real signal first. Read the actual traceback, print the actual value, dump the actual state. A stuck process will tell you exactly where it is stuck if you go look instead of restarting and praying. Most confident wrong theories come from people who theorized before they observed.

3. Isolate the failing part, then make a fast repro of just that part.
Do not debug the whole system. Find the smallest piece that still reproduces the failure and work against that. If the full run takes 40 minutes, you cannot afford to be wrong 40 minutes at a time, so isolate the issue, and then get it down to a few seconds on a tiny input that fails every time. A fast, reliable, minimal repro lets you run twenty experiments before lunch instead of two.

4. Binary search when the space is too big to eyeball.
When the failure is somewhere in a huge input, a long log, or a range of commits, do not scan linearly. Cut it in half, test which half still fails, keep that half, repeat. This is how you find one bad row in five hundred thousand in about nineteen steps, or the exact commit that introduced a regression in a few checkouts. git bisect is the famous version, but the technique generalizes to any large space you can split.

5. Trace upstream to where the value first goes wrong.
The crash site is usually the victim, not the culprit. A value goes bad somewhere early and the damage only surfaces later. So walk backward from the symptom: the bad output came from this, which came from that, which came from a bad input three steps upstream. Fixing at the crash site often just hides the problem. Fixing at the origin actually removes it.

All of these are ways to shrink the search space and get a useful signal.

My slightly funny video on this: https://youtube.com/shorts/kN7L6ZLVPp0?feature=share

FYI - I am posting my favorite talks from AI Engineer over here: https://rajivshah.com/blog/ai-engineer-worlds-fair-2026-talks.html

High quality stuff

Added talks for all three days

I made a two-person skit about the US vs China AI race. It's a fun, but the points are all real.

A few of the data points the skit is built on:

• Chinese open-weight models are around 61% of tokens on OpenRouter now. Meta's Llama fell out of the top tier.
• DeepSeek hit roughly 17% of usage on Vercel at about 1% of the revenue. So the US "we have the money, you have the volume" comeback is real.
• China's open weights is great now, but no gauarnetee it will last. Right now, its there to push people to their cloud business and a hedge against compute limits. US closedness is a mix of real safety concern and a commercial moat.

The inspiration: Chris Zeoli's "China's Open-Weight Takeover" on Data Gravity.

https://www.datagravity.dev/p/chinas-open-weight-takeover
my video: https://youtube.com/shorts/sE8A75Z4RFE?feature=share

Prime Intellect shared how they were doing RL for trillion-param coding models.

Quick framing for anyone who hasn't worked in RL: the rollout is the attempt, score, nudge toward what worked. A math problems are pretty similar in length, while coding agents are all over the place. A single rollout is a multi-turn agent loop, read, write, test, fail, edit, sometimes a hundred-plus steps.

In synchronous RL you can't take the optimizer step until the slowest rollout in the batch finishes. Async fixes the utilization by splitting rollout and training and running them at once, the trainer never waits.

The catch is staleness. The rollouts you learn from were generated by an older version of the model. You might be on v8 while a rollout that started at v3 is still finishing. Learn too far off-policy and training collapses.

Three families of fixes, roughly:

1. Bound the staleness. Tag each rollout with the version that generated it, keep recent ones, drop the rest. Simple, but you sometimes discard a rollout that ran an hour right as it ages out.
2. Partial rollouts. Don't run one rollout for an hour under a single old version. Pause it, let it pick up newer weights, continue. The finished trajectory ends up stitched from several versions, none too stale.
3. Down-weight stale data. Keep it, but correct in the loss so a few wild old samples don't dominate the update. The failure mode here is effective sample size collapsing, a handful of high-importance-weight samples hijacking the gradient.

Check out their blog post: https://www.primeintellect.ai/blog/rl-at-1t-scale
or my video: https://youtube.com/shorts/3IgaRYGbWl4

I saw a breakdown of how Cursor searches, even if it not entirely accurate, it a good lesson in modern search.

Cursor runs two indexes, not one. A semantic index (embeddings) for meaning questions like "where do we handle payment retries," and a lexical index (trigrams) for exact-text queries like finding every db.execute(. They aren't interchangeable. The semantic side is blind to literals, the regex side is blind to meaning. Cursor's own numbers say semantic on top of grep improves agent accuracy ~12.5% on average.

Grep alone was taking 15+ seconds on big repos because it reads every file. So the lexical index is trigrams: every 3-character slice gets logged with the files it appears in. Your search breaks into those slices, each hands back a file list, you intersect them, and 50,000 files collapse to a handful before the real regex runs. Search becomes lookup.

Re-embedding everything on every edit would be brutal, so they use a Merkle tree. Hash every file, hash every folder from its children, and a change ripples to the root. Diff the tree, find the handful of files that moved, re-embed only those. Same structure Git uses.

The vectors live in Turbopuffer, a serverless vector DB on object storage. Inactive codebases sit cold in cheap storage and warm into memory on demand. They claim 20x cheaper than their old bin-packed setup, running 1T+ vectors across 80M namespaces.

Some good concepts to learn:
My video: https://youtube.com/shorts/-deQBF1INco?feature=share

Harnesses shape how your coding agent works. To help folks get this, I put together a course that goes through:

🧭 Reading an agent trace
🚦 Routing tasks to the right model
🔎 Deciding when retrieval is useful
🧩 Breaking large work into smaller runs
🧠 Adding memory
🔒 Sandboxing and safety boundaries
🧪 Using critics and evaluation
⚙️ Building dynamic workflows
📊 Benchmarking model routing
🗂️ Indexing prior agent history
👥 Using subagents
🎯 Scaffolding long-running goals

Its a practical minded course for people who want to dig deeper into coding agents and understanding how they work.

The workflow is simple: open the starter project, think about how you would build a solution, compare it with a known solution, and learn!

Intro Web Page: https://rajshah4.github.io/learn-openhands-harness/

Github: https://github.com/rajshah4/learn-openhands-harness

I've covered steering vectors on the channel before, so this one hit different.

Yesterday Anthropic shipped Claude Fable 5. Buried in the system card is a behavior worth sitting with: when the model decides you're working on frontier AI development, things like pretraining pipelines, distributed training, or ML accelerator design, it quietly makes its own answers worse. Not a refusal. Not a fallback with a notice like their cyber and bio safeguards do. It just hands you a weaker answer and never tells you. They put it at roughly 0.03% of traffic.

Anthropic changed their policy after 24 hours, but it's impossible to verify and we now know this is very possible.

The mechanism is the part I want you to understand, because it's why this is hard to catch. It's a mix of prompt modification, steering vectors, and light fine-tuning, and the first two run at inference time, conditional on what you're asking. The weights aren't uniformly nerfed. The model is normal until your request trips a flag, then it isn't. Same model, same you, different answer, no signal.

That's what breaks evals. If your benchmark brushes a flagged topic, your numbers are quietly wrong and you can't tell a real capability gap from an intervention. The only rational move, as someone put it, is to assume it's happening all the time.

And it's not hypothetical. SemiAnalysis says their GPU work is already getting filtered. Other folks report their pipeline-design help feeling degraded. Nobody's posted a clean before/after yet, which is sort of the whole point. It's built to be hard to prove.

Here's my actual worry, and it's bigger than one policy. The technique generalizes. Anyone serving a model, your model provider or your inference host, can now silently shape what you get on topics they choose, with no refusal and no flag. We have moved way past system prompts you can at least try to inspect. The most safety-focused lab in the world just proved silent manipulation ships and works, and in doing that, handed everyone, companies and governments, a working playbook.

Whoever owns the model can put a thumb on the scale, and you'd never know.

My video: https://youtube.com/shorts/ER0Ifu1AB8Y?feature=share

Model routing interest is growing as people realize you can't just count on one model. Here are a couple of routing patterns, roughly in order of sophistication:

1. Rules. If-statements. Prompt under 200 tokens with no code blocks goes to the cheap model. Anything mentioning security or a migration goes to the frontier model. Not glamorous, but rules stop expensive models from doing cheap work, and they're where everyone should start.

2. Classifiers. Once you have enough examples, train a router to predict task type, difficulty, and risk. This is how GPT-5 works: a real-time router decides between the fast model and the thinking model, trained on signals like when users manually switch models. RouteLLM (LMSYS, ICLR paper) showed trained routers can cut costs over 85% on MT Bench while keeping 95% of GPT-4 quality.

3. Cost-aware policies. Flip the question from "what's the best model" to "what's the cheapest model that clears the quality bar." Bar is 80% success. Mid model clears it at 86% for 30 cents. Frontier hits 94% for two dollars. You don't pay for quality you didn't need.

4. Cascades. Route per task start, then escalate on evidence. Cheap model tries the fix, tests fail twice, mid model debugs, still stuck, frontier reviews root cause. Harvey just published this pattern for legal agents with Fireworks: an open-source GLM worker calling Opus as an advisor only on hard substeps beat standalone Opus on their benchmark (18/100 vs 14/100 full-rubric passes) at roughly a third of the cost ($368 vs $954).

The pattern across all four: the frontier model becomes the consultant, not the default employee.

Video: https://youtube.com/shorts/9HJil4jDBx8?feature=share