DEV Community: Aamer Mihaysi

How much of your agent's sandbox is actually read-only?

Aamer Mihaysi — Thu, 08 Oct 2026 14:38:08 +0000

I read the Berkeley RDI writeup on agent benchmark exploits twice. First pass as leaderboard gossip. Second pass as a threat model for my own stack. The second read was the one that paid: https://rdi.berkeley.edu/blog/trustworthy-benchmarks-cont/

The take everyone walked away with is that benchmark scores are soft. Sure. But look at what the exploits actually are. An agent read a file it shouldn't have been able to read. An agent wrote to a path it shouldn't have been able to write. An agent found the answer key because the answer key was in the room. None of that is exotic model behavior. It's a permission bug, and permission bugs don't care whether the reward is a leaderboard position or a closed ticket.

I found one of mine the boring way. My devcontainer bind-mounts the repo read-write, because that's what the template does and I never went back and changed it. My agent had a tool I'd labeled read-only. The tool was read-only. The shell sitting next to it in the same toolbox was not. The agent used the shell to tidy up some temp files, and one of those temp files was a fixture I cared about. No scheming, no cleverness. It was cleaning up.

Permission surfaces aren't what your tool descriptions say. They're what the process can actually reach. I'd written a nice docstring. The kernel doesn't read docstrings.

The eval is a prod agent with a smaller blast radius

Same builder, same shortcuts, same deadline. An agent benchmark is an agent with tools, a filesystem, and a reward — which is exactly what you ship. The difference is what happens when it goes wrong. In the eval, the worst case is a bad number. In prod, the worst case is a bad deploy, or a support ticket from someone whose data your agent decided was easier to read than to ask for.

That asymmetry is the whole argument for caring about this. The eval is the cheapest place on earth to find out that your "read-only" mount isn't, that your sandbox has egress, that the grader is writable. You get the failure for free, in a box, before it costs anything.

Most teams do the opposite. They treat the eval as a CI job — something that runs and turns green — and they treat the sandbox as an implementation detail. Then they quote the number in a deck.

What I check now

I don't ask what the tool does. I ask what the process can reach, and I answer it by looking at the mounts, not the manifest. Bind mounts, volumes, tmpfs, the home directory, the package cache. Every one of those is a door, and the tool description doesn't mention any of them.

I check whether the agent can touch the thing that judges it. Grader, tests, reference solution, the CI config that runs them. If it can, the score is a suggestion, not a measurement.

I check egress. Not whether the task needs network — whether it has it. That's how answers get fetched, and it's also how your agent phones a stronger model to do the work for it.

And I check whether I can replay the run. Tool calls, args, outputs, timestamps. If I can't see the calls, I can't tell a leak from a lucky guess, and I'll end up trusting a number I have no way to explain.

None of this is alignment research. It's containers and file permissions, which is a much less interesting answer than the one people want. But that writeup is full of agents that scored well by walking through an unlocked door, and unlocked doors are an infra problem.

What I actually think of the leaderboards

I don't think this makes benchmarks useless. It makes them a security artifact. A score is a claim about a specific box — that model, that harness, that set of permissions — and the moment you move it to a different box, you're quoting a number about a system that no longer exists.

Maybe the specific exploits in that writeup are patched by now. Some probably are. The structural mistake won't be, because the next benchmark will also be built by someone on a deadline who put the agent, the tools, and the grader in one container and called it a day.

So when I see an agent leaderboard now, I don't read the score first. I go looking for the harness. If I can't find it, I assume the number is measuring attack surface, and I read it that way.

Four new models, one interface change: from chat completion to decision

Aamer Mihaysi — Wed, 07 Oct 2026 14:38:01 +0000

I deleted a prompt this week. Not a model, not a pipeline — a prompt. Forty lines of "respond only with JSON", "do not include any other text", "if you are unsure, output UNKNOWN", plus three few-shot examples I'd been carrying between projects like a lucky coin. It existed for one reason: to trick a chat model into behaving like a classifier.

The replacement is a model whose output is a decision. A label, a calibrated probability, a version string. No prose. Nothing to parse, nothing to regex, nothing to retry because the model decided to say "Certainly! Here is the JSON you requested:".

Four orgs shipped something in that shape this week. One of them is autotrust/JEV-27B-VL, a 27B vision-language model that emits a typed verdict with a confidence score instead of a paragraph. The other three I'll describe by shape rather than name, because two are still gated and the third is a fine-tune whose README is mostly vibes.

The four, by shape

Release	Output	Self-host	Where it fits
27B VL (JEV-27B-VL)	typed verdict + probability + evidence spans	yes, 2×A100 in bf16	the one I'd put in front of a user
3B router	single label + score, no spans	yes, one 24GB card	first-stage triage
8B fine-tune	label + probability, schema drifts under load	yes	cheap, needs a wrapper
small classifier head	label + logits	yes	fastest, no reasoning at all

Notice what's missing from that table: benchmarks. I don't care about top-1 here. Top-1 is the metric you optimize when your model is a demo. The moment you put a threshold in front of it, the only number that matters is whether the probability still means something when the input distribution moves.

Calibration on the eval set is theater

Here's the trap. You take a model, you run it on a held-out split, you compute expected calibration error, you temperature-scale until the reliability diagram looks like a straight line, and you ship. Congratulations: you calibrated on the same distribution you evaluated on. That's not calibration, that's curve fitting with extra steps.

The test I actually run now is a time split, not a random split. Fit the threshold on week one. Apply it on week four. Report precision at the operating point and the abstain rate, not accuracy.

I did this on roughly 400 examples across two slices — one from the same week as my tuning set, one from three weeks later, different document templates, different phone cameras. On the in-distribution slice, binning the 27B's outputs at 0.9 gave me about 0.92 precision. Same threshold, shifted slice: 0.71.

The 3B router degraded harder. 0.88 down to 0.54. That's the classic failure — a small model that's confident because it's seen the pattern before, applied to a pattern it hasn't.

The 8B fine-tune was the interesting one. Its top-1 barely moved. But its confidence went flat — everything landing between 0.5 and 0.7, nothing above 0.8. Which sounds like a regression and is actually the most honest behavior in the group. It stopped pretending. A model that says "I don't know" in a language you can threshold on is worth more than a model that says "I don't know" in a paragraph you have to read.

What the interface change actually buys you

The chat-completion interface has one output channel and infinite surface area. Every downstream consumer has to guess what came back. The decision interface has a fixed surface and a number you can compare.

That sounds like a small thing. It isn't. It moves three things out of prompts and into code:

Routing. Escalation policy becomes a config value. Threshold at 0.85, send the 0.4–0.85 band to the bigger model, send everything below to a human queue. I changed that band four times last week without touching a single prompt. Try doing that with a few-shot example.

Replay. You can log a decision and re-run it. Label, probability, model version, input hash. When someone asks why the system flagged their document, you have an answer that isn't "the model said so." You cannot replay a paragraph.

Retries. With prose, a failed parse means you retry and hope for a different roll. With a decision, you get a number and you decide what to do with it. The circuit breaker becomes arithmetic instead of superstition.

Where it breaks

Calibration is per-deployment. A model calibrated on my data is not calibrated on yours, and vendor calibration cards are marketing until you reproduce them on your own shift. I've stopped reading them.

Second: the moment you add a second label space, probabilities stop being comparable across heads. A 0.8 on "invoice vs receipt" and a 0.8 on "safe vs unsafe" are not the same 0.8. If you're routing on both, you need per-head thresholds, and now you're maintaining a config file that's basically a second model.

Third, and this is specific to the vision-language one: image preprocessing silently changes your input distribution. Resize, JPEG quality, EXIF rotation, color profile. My "distribution shift" test was, in practice, "did the phone change." If you're running JEV-27B-VL or anything like it, pin your preprocessing and version it, or your calibration is measuring your image pipeline, not your model.

Latency, since I pay for the GPUs: the 27B at bf16 on 2×A100 gave me p95 around 380ms for one image plus a short prompt. Fine for a queue. Not fine for a keystroke. The 3B router is closer to 40ms. So the honest architecture is router first, big model only on the uncertain band — which is exactly the architecture the decision interface makes easy and the chat interface makes painful.

What I'd ship

Router first. Threshold at 0.85. Abstain band escalates. Everything below goes to a human, not to an auto-reject, because a confident wrong rejection is the only failure mode that gets you paged at 2am. That cut my 27B calls by about a third versus sending everything to the big model, and a third fewer 27B calls is real money when it's your electricity.

I've run JEV-27B-VL on a few hundred examples, not a few hundred thousand. Maybe the calibration story falls apart at scale. Maybe the 8B's flat confidence is a bug I'm romanticizing. I'd genuinely like to be wrong about the router degrading faster, because it's the cheapest piece in the stack.

But the interface argument doesn't depend on which of these four wins. The model that wins isn't the one with the best top-1. It's the one whose confidence still means something after the world moves. And the quieter news this week is that I no longer write forty lines of prompt to get a boolean.

Blast radius is the unit of trust

Aamer Mihaysi — Tue, 06 Oct 2026 14:38:01 +0000

The permission is never the problem. The permission that outlived the task is the problem.

Three things crossed my feed this week with the same shape: an agent that dropped a production database, an automation that ran until the money ran out, a mirror that got flattened by something that didn't know when to stop. Different stacks, different countries, one root cause. A credential, a mount, or a network route issued for one job and never revoked. Nobody wrote a bad prompt. They just left the door unlocked after the delivery.

I've been on the wrong side of this. I gave an agent a shell on my host because it was faster than building a sandbox, and then spent a weekend figuring out which of my files it had rewritten. The fix wasn't a smarter model or a stricter system prompt. It was making the blast radius small enough that a mistake is boring.

So: one container per task. No host mounts. Network off by default. The container dies when the task does. That's the whole tip.

Why "one container per task" and not "one container per agent"

Because agents are long-lived and tasks aren't. If your agent process holds a filesystem, a token, and a network route for a week, then every task it runs inherits a week of accumulated permissions. The task that needed to read a config file and the task that needed to run rm on a build directory are sharing the same reach.

Splitting them means the thing that can delete your database only exists for the ninety seconds it takes to do the job, and then it's gone. Not "revoked". Gone. The container is removed, the volume is removed, the token is expired, and there's nothing left to leak.

I run it like this:

docker run --rm \
  --name "task-${TASK_ID}" \
  --label agent.task="${TASK_ID}" \
  --label agent.ttl=15m \
  --network none \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=256m \
  --user 1000:1000 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 128 \
  --memory 1g --cpus 1 \
  --workdir /task \
  agent-runner:latest

Read that back. --network none means the container cannot reach the internet, my LAN, or the metadata endpoint. --read-only means the root filesystem can't be written, and the only writable surface is a 256MB tmpfs that evaporates with the process. --cap-drop ALL plus no-new-privileges means there's no path to escalation even if something inside is compromised. --pids-limit means a fork bomb dies instead of taking the host with it.

And critically: no -v /var/run/docker.sock. Ever. An agent that can talk to the Docker socket is root on the host with extra steps. I've seen this in three "sandboxed" agent frameworks this year. It's not a sandbox, it's a suggestion.

Getting data in and out without mounting the host

This is the part people push back on, so here's what I actually do. Inputs go in with docker cp before the run, or through a named volume that only that task can see:

docker volume create "in-${TASK_ID}"
docker cp ./task-input/. "task-${TASK_ID}:/task"

Outputs come out the same way, and then I validate them on the host before anything touches them. The agent never gets a path that points at my home directory, my SSH keys, or my .env. It gets a copy of exactly what the task needs, in a directory that exists for one run.

Yes, copying is slower than mounting. That's the point. The copy is the boundary.

The network problem, and the proxy that solves it

Here's the honest wrinkle: agents need to call a model API, and --network none blocks that too. You have two options and I've used both.

The first is to move the model call out of the sandbox entirely. The orchestrator on the host talks to the LLM, decides on a tool call, and then dispatches that single call into a network-less container. The sandbox never needs egress because it never talks to anything but stdin.

The second, for when the task genuinely needs the network, is a proxy sidecar with an allowlist. The sandbox gets --network container:proxy, the proxy only forwards to the two or three hosts on the list, and everything else gets a 403 and a log line. I keep the allowlist in a file that's reviewed like code, because it is code.

Either way, the default is off. Egress is a decision you make per task, not a property of the agent.

Credentials should expire before the container does

If a task needs a token, mint it at dispatch time, scope it to that one resource, and set the TTL shorter than the container's. I use 15 minutes for the container and 10 for the token. If the task is still running at minute ten, that's a bug, not a reason to extend the token.

The reason this matters more than the container: containers are visible in docker ps. A leaked token in a log file isn't. I've found long-lived agent tokens in CI logs, in crash dumps, and once in a Slack message from a debugging session six months earlier. Scope and expiry are the only two controls that survive being copied somewhere you don't control.

Docker shipping this is the signal

Docker now has a Sandboxes product aimed squarely at this — disposable, isolated environments for agents. I haven't run it in anger yet, so I'm not going to pretend I have a benchmark for you. But the fact that the container company is productizing agent sandboxes tells you where the industry thinks the risk lives. It's not in the model weights. It's in the process that's still holding a database credential at 3am.

If you're building on top of it, the same rules apply: no host mounts, network off, one task per sandbox, and a reaper that kills anything older than its TTL. I run a cron job that does docker ps --filter label=agent.ttl --format '{{.ID}} {{.Label "agent.ttl"}}' and kills anything past its window. It's twenty lines and it has saved me twice.

What this costs you

Cold start. A cached small image is up in well under a second on my machine, but if your runner image is 4GB of CUDA, you're going to feel it. Build a slim runner and keep the heavy stuff on the host.

State. You lose the "agent remembers what it did yesterday" convenience unless you write it down somewhere outside the sandbox. Do that deliberately. A memory file you control beats a filesystem the agent can scribble on.

Debugging. When something fails inside --network none, you can't just curl your way to an answer. You'll add a debug flag that opens the network for one run, and you'll forget to close it. Put that flag behind an env var that only exists on your laptop.

None of that is free. But the alternative is the thing that happened to three people this week: a permission that outlived the task it was issued for, and a very bad morning.

Make the blast radius the unit of trust. Everything else is a prompt.

My World-Model Drift Metric Scored a Stale Checkpoint as Stable

Aamer Mihaysi — Mon, 05 Oct 2026 14:37:54 +0000

Last quarter I deprecated an internal endpoint. The world-model layer in my agent stack — the part that predicts what a tool call will return before it makes it — kept predicting the old response shape for eleven days. My regression harness scored that checkpoint as the most stable build of the month.

That's not a bug in the harness. The harness did exactly what I told it to do. I gave it one number: mean drift in predicted state across my probe set, checkpoint to checkpoint. Low drift meant good. A model that refused to change its mind scored like a model that was right.

I've been carrying that inversion around for months without a name for it. This paper gives it one: https://arxiv.org/abs/2610.03713v1

The claim in What Should World Models Forget? Stratified Retention for Continual Adaptation is blunt. Current continual-learning benchmarks will rank a frozen world model above one that correctly revises an outdated fact, because a single aggregate degradation metric can't tell forgetting apart from updating. Both show up as "the predictions changed." One is a failure. The other is the entire point of having a world model that lives in a world.

I think they're right, and I think it's worse than the paper lets on, because in production those two failure modes don't cost the same.

The two ways an agent is wrong

An agent that never revises becomes confidently wrong. It calls a dead endpoint with the old payload shape, gets a 404, retries, gets another 404, and burns your budget being certain. Annoying, loud, easy to catch.

An agent that revises too eagerly becomes flaky. It sees one anomalous response and rewrites its belief about how the tool works. Now it's wrong in a new way, and it's wrong quietly, because the prediction still looks plausible. You find out three days later when someone asks why the reconciliation job has been writing nulls.

Both are failures. They need opposite fixes. And my old metric averaged them into the same number, which means it couldn't have told me which one I had even if I'd asked.

What I think the next evals look like

Here's my prediction, with a date on it. Within the next year or so, a serious world-model or agent benchmark stops publishing one continual-learning score and starts publishing at least two, reported side by side:

Invariant regression rate. A set of facts that must never change without a human in the loop: tool schemas, auth flows, unit conventions, the fact that created_at is UTC. Zero-tolerance. If the model revises one of these, that's not adaptation, that's corruption, and it should fail the run the way a broken build fails CI.

Revision latency. For facts that should change — pricing, rate limits, deprecation windows, model names — how many observations does it take before the model updates? Measured in observations, not wall-clock, because wall-clock hides how much evidence the model actually saw.

And I'd add a third the paper implies but doesn't quite name: collateral revision. When the model updates a stale fact, how many correct facts does it clobber on the way? Latency alone is a trap. The fastest possible revision latency belongs to a model that believes whatever it saw last.

That's the part I'd bet on hardest. The moment you publish a revision-latency leaderboard, someone ships an agent that flips its belief on a single noisy observation and tops it. Latency without collateral revision isn't a measure of adaptability, it's a measure of how easily you're fooled. The numbers have to ship as a pair or you've just moved the Goodhart target.

Stratification is an architecture decision, not just an eval design

The useful thing about the stratified framing is that it maps onto something I already do when I build these systems, badly and by instinct.

Invariants live in code. Tool schemas, auth, units — those go in a typed contract that a human reviews. They should never be in weights at all.

Slow-changing facts live in a store I can rewrite. Pricing, rate limits, which model is deprecated when. Revision latency here should be measured in a handful of observations, and the update should be auditable — I want to see what changed and why.

Fast-changing state — feature flags, on-call rotation, the status of a long-running job — shouldn't be "learned" by anything. It belongs in a lookup you re-read every call. If your world model is spending capacity predicting the current sprint, you've built an expensive cache with a staleness bug.

So the paper's stratification isn't only a benchmark proposal. It's a reminder that most "continual learning" problems in deployed agents are actually memory-placement problems. I've fixed more of these by moving a fact out of the model than by training anything.

Where I'm not convinced

I haven't implemented stratified retention. It's a method paper, not a checkpoint I can pull and run, and the part I'm least sure about is where the strata boundaries come from. In my stack they're obvious because I wrote the tools and I know which fields are stable. In an open-ended environment, deciding that "the speed of light" and "the price of this API" belong in different buckets is the whole problem, and the paper is lighter on that than I'd like. Maybe the boundaries are learnable. Maybe they're just a config file a human maintains forever. I genuinely don't know yet.

What I do know is that my single drift number was lying to me, and it was lying in the flattering direction.

So this week I'm splitting it in two and tagging every probe with a stratum. It's an afternoon of work — a label on each test case, a second aggregation, a threshold per bucket. The alternative is another quarter of shipping a model that's confidently wrong and calling it stable, which is a mistake I've now made often enough to recognize on sight.

Prune tool output by rule, leave the reasoning chain alone

Aamer Mihaysi — Fri, 02 Oct 2026 14:37:51 +0000

My agent hit the context ceiling last week at turn 61. The framework did what every framework does now: it called a model to summarize the conversation, waited eleven seconds, and handed back a paragraph that had quietly dropped the exact error string I needed. The task failed. Not because the model was dumb — because the compaction step decided what mattered and decided wrong.

I've since ripped the summarizer out of my own loop and replaced it with about eighty lines of bookkeeping. Here's the reasoning, and the rule.

Where the tokens actually are

Pull the token breakdown from any long agent trace and the shape is always the same. The assistant's reasoning — the text where it thinks, plans, decides — is a thin ribbon. The tool results are the ocean. File reads, grep dumps, test output, JSON blobs, directory listings, stack traces. In my own traces, tool results run 70–85% of the window on a real coding task. The reasoning chain is usually under 10%.

So the default compaction strategy spends its most expensive, most lossy, least deterministic operation on the part of the context that is cheapest to keep and most valuable to preserve. That's backwards.

Why summarization is the wrong first move

Three problems, in order of how much they've cost me.

It's slow and it's blocking. You hit the ceiling precisely when you're mid-task, and now you insert a full model round-trip before the next step. On a local model that's seconds. On a hosted one it's seconds plus a bill, and you pay it again every time you cross the threshold.

It's lossy in a way you can't audit. The summarizer doesn't know what the next turn needs. It compresses by salience, and salience is a guess. The error string, the exact file path, the off-by-one in the test name — those look like noise to a summarizer and like everything to the next tool call.

It's non-deterministic. Same conversation, two runs, two different summaries. That kills prompt caching, kills reproducibility, and makes a bug report impossible to replay. I've spent an afternoon on "it did something weird yesterday" and the summary was different the second time.

The rule: liveness, not importance

Here's the reframe. You don't need to decide which tool results are important. You need to decide which ones are still referenced. That's a much easier question, and it has a mechanical answer.

A tool result is live if the live reasoning chain still points at it. Concretely, walk backwards from the newest message and mark a tool result live when:

its tool-call ID appears in an assistant message that's still in the window, or
a later assistant message quotes or paraphrases its content, or
it's one of the last K results (I use K=3), or
it's explicitly pinned.

Everything else is stale. Not unimportant — stale. The distinction matters, because "unimportant" requires judgment and "unreferenced" doesn't.

The reasoning chain — every assistant message, every tool call (the request, not the result), every user turn — stays untouched. It's small. It's the actual state of the task. Deleting it is how agents forget what they were doing.

What a pruner looks like

Roughly:

Take the message list.
Walk it backwards, building a set of live tool-call IDs.
For every tool result not in that set and not in the last K, replace its content with a tombstone.
Recompute the token count. If you're still over budget, prune harder — shrink K, then drop the oldest complete tool-call/result pairs.
Only if you're still over budget after that, reach for a summarizer.

Step 3 is the whole trick and it's cheap. No model call, no latency, no variance. Same input, same output, every time.

Tombstones, not deletions

Don't delete the tool result message. Replace its body with something like [pruned: read_file src/parser.py, 4.2k tokens].

Two reasons. First, if you delete the pair entirely, the model has no record that it already ran that call and will happily run it again — you've turned a context problem into a loop. Second, the tombstone is a cheap index. When the agent needs that file again, it knows it read it, and re-reading is one tool call instead of a rediscovery.

Keep the tool call message intact either way. It's tiny and it's reasoning.

What to pin

A few things should never be pruned by rule alone:

The current plan or todo list, if the agent maintains one. That's the spine.
The most recent error or test failure. It's usually the reason for the next three turns.
Anything the agent explicitly wrote down as a note. If it took the trouble to record it, respect it.
The original task statement. Obviously.

I mark these with a flag at write time rather than trying to detect them later. Detection is another judgment call, and judgment calls are what I'm trying to remove.

When summarization is still right

I'm not saying delete your summarizer. I'm saying it shouldn't be the first thing you reach for, and it shouldn't be the only thing.

Summarization earns its keep when the reasoning chain itself is the bulk — long research or planning sessions where the agent has produced pages of deliberation and you genuinely need the gist. It's also fine as a second tier, applied to the oldest third of the conversation where nothing is live anyway.

Pruning first makes summarization better, too. Summarize a context that's already been pruned and the summarizer spends its budget on reasoning instead of on a directory listing from forty turns ago.

The payoff

The obvious win is speed and cost. The less obvious win is that my agent's context is now a deterministic function of its history. Same trace in, same context out. I can log it, diff it between runs, and replay a failure exactly. Prompt caching works again because the prefix is stable.

And the failures got boring, which is what I wanted. The agent doesn't forget the file it's editing halfway through editing it. It forgets the ls output from turn 12, which it was never going to look at again.

Tool results are most of the tokens and least of the meaning. Prune them by rule. Leave the thinking alone.

Prompt search is a hill-climber, and accuracy is the wrong hill

Aamer Mihaysi — Thu, 01 Oct 2026 14:37:53 +0000

I once shipped a prompt that scored 0.94 on my eval set and was useless in triage. Not wrong, exactly. Just useless — it ranked the one case I needed to see at position nine, behind eight things that were fine.

That's the whole article, really. But the mechanism is worth spelling out, because it wasn't a fluke. It was the thing I asked for.

The myth

"If I optimize my prompts against accuracy, I get a better model."

Every prompt optimizer I've used — DSPy-style compilers, evolutionary search over instruction strings, the OPRO-ish loops people wire up themselves — works the same way underneath. You hand it a scalar. It hill-climbs. It has no idea what the scalar means. Accuracy, F1, BLEU, a hand-rolled score from a judge model: all identical to the search. It finds the easiest high point in the space you defined and defends it.

So the real question isn't "does prompt optimization work". It's "what did you point it at".

Why accuracy is a bad hill on imbalanced data

My last clinical-ish eval set was about 4% positive. Rare finding, lots of normal scans, which is what real clinical data looks like.

On that set, a prompt that answers "nothing abnormal" to everything scores 0.96 accuracy. It is also the single most dangerous output you could ship. And it's the easiest point in the search space to reach — no reasoning, no grounding, no long instruction to get wrong. Your optimizer will find it in a couple of generations and then fight every mutation away from it, because everything else looks worse on the number you gave it.

That's not a bug in the optimizer. That's a correct optimizer solving the problem you wrote down.

The subtler failure is the one that got me. Accuracy is thresholded. It collapses a score into a yes/no and throws the score away. Two prompts can hit identical accuracy with completely different ranking behavior — one separates the positives cleanly at the top, one scatters them through the middle and gets lucky at the cutoff. Your search sees a tie. It picks whichever one it evaluated first, or whichever one is more confidently wrong on the majority class, because confidence often tracks the majority pattern.

If your deployment decision is "review the top k", you just optimized for a metric that doesn't describe your deployment.

Multimodal makes this worse, not better. When the prompt has to coordinate an image encoder, a text instruction and a scoring rubric, the search space is enormous and the degenerate solution — ignore the image, answer the prior — is cheap to find and cheap to keep. Bigger space, same bad hill.

What the paper does about it

This is the part I actually wanted to write about.

The setup: you're running prompt search, and you keep a matrix of results — rows are candidate prompts, columns are eval instances, cells are outcomes. If the cell is "was this instance correct", the column average is accuracy. That's the fitness function. That's the hill.

The paper's move is to change what a row is. Instead of one row per instance, you build rows over positive-negative pairs. The cell becomes "did this prompt score the positive above the negative". Now the column average is AUROC.

Same scores. Same model calls. Different bookkeeping. You didn't buy a better model — you stopped lying to your search loop about what you wanted. The optimizer still hill-climbs; it just climbs a surface that has the same shape as your deployment decision.

That's the kind of trick I like. It costs nothing at inference time, and it only requires that your harness kept raw scores instead of booleans. Which, if you're like me, it didn't.

What I changed in my own harness

Three things, all boring:

Store the raw score, not the pass/fail. Along with the prompt hash and the instance id. If your eval harness only writes booleans, you've already destroyed the ranking signal, and no amount of clever search will get it back. This is the actual fix. Everything else is downstream.
Compute AUROC next to accuracy, always. Not instead of — next to. When they disagree, that disagreement is the interesting part of the run, and it usually means your positive class is too small for accuracy to say anything.
Make the search read the metric that matches the decision. If I ship a threshold, I optimize precision at that operating point. If I ship a ranked list for a human to review, I optimize ranking. Those are different numbers and I've stopped pretending one stands in for the other.

Where I'm not sure

Pairwise rows blow up. Positives times negatives — with 4% positives over a few thousand instances that's manageable; with a genuinely rare class it isn't, and you end up sampling pairs, which means your AUROC estimate carries variance your optimizer will happily exploit. I haven't run this at a scale where that bites yet, so I don't know how ugly it gets.

Ties are the other one. AUROC needs a convention for tied scores — half credit is standard — and discrete prompt outputs tie constantly. If your optimizer is comparing two prompts that both emit "no", the pairwise matrix fills with ties and the signal thins out.

And ranking isn't calibration. A prompt can rank beautifully and still be badly calibrated at the threshold you actually deploy at. AUROC doesn't care. Your on-call engineer does.

The takeaway

Prompt optimization is search. Search is honest — it finds exactly what you asked for, including the degenerate version. The metric your search reads has to be the metric you deploy on, and on imbalanced data, accuracy is almost never that metric.

If you take one thing: go look at whether your eval harness stores scores or booleans. That's the whole fix, and it's free.

Paper: https://arxiv.org/abs/2609.40361v1

Uniform INT8 on Recurrent States Is a Default, Not a Decision

Aamer Mihaysi — Wed, 30 Sep 2026 14:38:02 +0000

I've shipped INT8 KV caches that looked perfect at 4k context and fell apart at 32k. Same weights, same prompts, same eval harness. The only variable was how long the model had been running. That's the failure mode I keep circling back to when I read quantization papers, and it's why STEPQuant caught my attention: it argues that uniform INT8 on the recurrent state of a delta-rule linear attention model is the wrong default, because not every element of that state carries the same error budget. https://arxiv.org/abs/2609.38169v1

I haven't reproduced their numbers. But the argument matches something I've watched happen in production, so let me lay out the comparison as I'd actually make it on my own rig.

Why uniform INT8 is the default

Uniform per-tensor INT8 is the default because it's the only version that's free. One scale, one zero point, one kernel shape, no branching, no gather, no metadata to carry through the decode loop. On a bandwidth-bound decode step, that matters more than people admit — you're not compute-limited, you're moving bytes, and a clean 8-bit load is about as good as it gets.

For weights, this is fine. Weights are static, they get read once per forward pass, and any error is a fixed bias you can measure offline. For a KV cache it's mostly fine too, because each cached token is read a bounded number of times and then it's either evicted or it isn't. Errors don't compound; they just sit there.

The recurrent state in a linear attention model is a different animal, and this is where I think the paper lands a real point.

The state is a running sum, not a buffer

In a delta-rule model, the state is a matrix that gets updated every token roughly like S ← S(I − kkᵀ) + vkᵀ. Two things follow from that.

First, an error injected at step t doesn't stay put. It gets carried forward and multiplied by the transition at every subsequent step. Second — and this is the part I find genuinely sharp — that transition is a projection. The error decays only in the subspace the model keeps querying. An error that lands in a direction the model never queries again is effectively immortal. It sits in the state forever, contributing nothing useful and quietly biasing every read that touches it.

So "how long does this state element survive" is only half the story. The other half is "which key rows does it get hit by." A row that's constantly overwritten by high-norm keys gets scrubbed clean on a short timescale. A row that's written once and then ignored for 50k tokens is a permanent resident, and it deserves more bits than its neighbor.

That's the whole thesis, and it's a deployment thesis, not a training one.

Four options, ranked by how much I'd trust them

Uniform per-tensor INT8. Fastest, simplest, and the thing I'd reach for first. Its failure mode is dynamic range: if a handful of rows dominate the scale, everything else gets an effective 5 or 6 bits. In a state that's mostly cold with a few hot rows, that's exactly the wrong allocation.

Per-row (per-channel) INT8. Better range handling, still uniform in time. Cheap to implement, still one kernel shape. This is the version I'd actually ship today if I needed something this week.

Lifetime-aware two-tier. Recent state in BF16, older state in INT8. This is the same instinct behind keeping the last N tokens of a KV cache in full precision, and it's the easiest of the "smart" options to reason about. Cost is a second buffer and a merge step.

Lifetime plus row impact. Allocate bits per row based on how often it's read and how long it survives. Best quality per byte, worst kernel. This is what the paper is arguing for, and I believe the analysis. I'm less sure I'd pay for it.

The tax nobody puts in the abstract

Mixed precision inside a recurrent state means the kernel can't be a clean vectorized load anymore. You get gather/scatter, you get branch divergence across rows, and on a single consumer GPU that can easily cost more than the bandwidth you saved. I've been burned by this before: a "smarter" quantized path that did less math and ran slower, because the memory access pattern went from streaming to scattered.

The honest comparison isn't quality-per-byte, it's quality-per-byte-per-millisecond. A scheme that saves 30% of state memory but adds 15% to per-token latency is a loss on any interactive workload. It might be a win on a batch-64 offline job where you're capacity-bound instead of latency-bound. Those are different products and they deserve different answers.

What I'd actually measure

Not short-context perplexity. That's the eval that lied to me about my KV cache for months.

I'd run three things. A needle-in-a-haystack at 64k and 128k, because slow state drift only shows up when the model has to reach back far. A "stale probe" — plant a fact at token 200, run to 100k, then query it, which is the specific thing a permanent error in a cold row would break. And instrumentation: log per-row error norms against a BF16 reference state over time. If the paper's claim is right, that log should show a small set of rows accumulating error and never recovering, and those rows should be the ones with low query frequency.

If that log looks flat, the whole argument collapses and uniform INT8 was fine all along. I'd want to see it before I rewrite a kernel.

The general lesson

Uniform anything is a default, not a decision. We already learned this with KV eviction — not all cached tokens matter equally — and with mixed-precision training, where per-tensor loss scaling beat one global scale. Recurrent state quantization is the same shape of problem with a nastier twist, because the state has memory and the KV cache mostly doesn't.

I'll probably keep shipping uniform INT8 for a while, because it works and it's fast and my time is finite. But I'll stop calling it correct. It's just the thing that hasn't bitten me yet.

If every layer prefix is a valid model, why do we still pick a size at deploy time?

Aamer Mihaysi — Tue, 29 Sep 2026 14:38:13 +0000

I keep four checkpoints of the same family on disk: a 1.5B, an 8B, a 32B, and a 70B. Four training runs I didn't do, four eval suites I have to trust on faith, four quantized copies, four latency profiles, four rows in the cost table. And at request time I still can't answer the only question that actually matters: how much model does this request need?

Most of my traffic doesn't need the 70B. I know that because I've A/B'd it. The extraction and classification jobs are indistinguishable between the 8B and the 70B, and the multi-step planning traces fall apart below 32B. So I route by hand, using a rules table I wrote at 1am, and I re-verify the whole thing every time a model version bumps. It's the least glamorous part of my job and it eats more time than the agent code does.

Telescopic Language Models argues that this arrangement is a packaging artifact. The claim, roughly: train once with an objective that keeps every layer prefix valid, and you get a usable model at layer 12, at layer 24, at layer 36, at layer 48. Not a truncated model. Not a base model with an exit head bolted on after the fact. A model that was trained to be good at that depth.

If that holds, the small/medium/large release split stops being a capability boundary and becomes a distribution decision. One artifact, N depths, and the serving layer picks per request.

So why do we still commit to a size at deploy time?

The reasons we pin a size are real, not lazy

It's tempting to say we do it out of habit. It's mostly not habit.

Capacity planning assumes a fixed cost per replica. If depth varies per request, your p99 stops being a number and becomes a distribution, and autoscalers are bad at distributions. You can't tell a Kubernetes HPA "scale when the average exit depth crosses 30" without writing a custom metric and hoping it doesn't oscillate.

Batching is worse. Continuous batching runs a batch to the step count of its slowest member. If half the batch exits at layer 16 and half runs to 48, the shallow half didn't save you anything — you burned 32 extra layers of compute on tokens that were already done. To get the savings you need depth-aware scheduling, which means sorting the queue by predicted depth, which adds queueing latency to the requests you were trying to make fast. That's a genuine trade, not a detail.

Then there's the boring stuff. Evals multiply: N prefixes means N regression surfaces, and "which model served this request" stops being a constant you can put in a bug report. Pricing pages want a named thing. Procurement wants a named thing. "Depth 22 of 48" is a hard sentence to sell to someone signing a three-year contract.

And the failure mode is silent. A timeout is loud. A request served at depth 12 that quietly gave a worse answer is invisible unless you're measuring quality per depth per request class, which almost nobody is.

What I'd actually try first

Not a learned router. Learned routers are how you get a system that's confidently wrong in a way you can't reproduce.

I'd start with a static policy keyed on request class, because I already know the shape of my traffic. JSON extraction, classification, short tool-call formatting: shallow. Code generation, multi-step planning, long-context synthesis: full depth. Then I'd measure the quality delta on my own traces — not on MMLU, on the messy half-English tool-call logs that actually hit my endpoints. If the delta on the shallow class is inside noise, the policy ships. If it isn't, I've learned something about where the prefix stops being valid, which is useful either way.

The thing I'd try before any of that, though, is self-speculative decoding. If the shallow prefix is a valid model, it's a free draft model for its own deeper self — same weights, same tokenizer, same training run, nothing to keep in sync. You draft at depth 16, verify at depth 48, and the output is exactly what the full model would have produced. That's a latency win with a correctness guarantee attached, which is rare enough that I'd take it even if the per-request routing idea never pans out. On my box the 8B at Q4 gives me roughly 70 tok/s and the 70B on two rented A100s sits around 20, so the gap I'd be trying to close is real and expensive.

Only after that would I consider a difficulty predictor, and I'd want it conservative — default to full depth, short-circuit only on high confidence, and log every short-circuit decision so I can audit the ones that went wrong.

The part I'm not sure about

I haven't run this. The claim I'd want to verify on my own data is "valid at every prefix," because valid on a benchmark suite and valid on my traces are different claims. My guess is that shallow prefixes hold up fine on format-following and fall apart on anything requiring a chain of inference — which is exactly the shape that makes a static policy workable and a learned router dangerous. If the shallow prefixes are good at structure and bad at reasoning, you don't need a predictor at all. You need to know which of your endpoints are structure problems.

There's also a version of this that's just distillation with extra steps, and I'd want to see the comparison against a properly tuned distilled student before I believe the telescopic framing buys anything. Distillation gives you a fixed small model. This gives you a continuum. Whether the continuum is worth the scheduling complexity is an empirical question, and I don't think anyone has answered it yet.

So, back to the question. Why do we still commit to a size at deploy time? Because a decade of serving infrastructure, autoscaling, pricing and eval tooling was built on the assumption that a model is one artifact with one cost. Telescopic training breaks the assumption. It doesn't break the tooling. Someone has to rewrite the scheduler, the autoscaler and the eval harness before any of this reaches prod.

My bet is the first real deployment isn't a chatbot. It's a batch pipeline where latency doesn't matter and someone can just turn the depth down for the easy half of the queue. Unglamorous, and exactly the kind of place where this actually pays for itself.

The agent didn't fail. You never told it what "done" means.

Aamer Mihaysi — Thu, 24 Sep 2026 14:39:01 +0000

The DN42 story — agent told to scan a network, operator ends up with a bill they can't pay — keeps getting framed as a cautionary tale about runaway costs. The writeup is worth reading, but I think the usual takeaway is wrong. The cost is a symptom. The disease is that nobody defined what "done" means.

"Scan DN42." That's not a task. That's a direction. A task has a termination condition: "scan DN42 and report every open port on these five hosts" is a task. "Scan DN42" is a research program with no end state, and the agent did the only thing it could do — it kept going, because nothing in the instruction told it to stop. It wasn't greedy. It wasn't broken. It was faithful to a specification that had no exit.

I've made this exact mistake. I told an agent to "explore the codebase and find anything interesting." It found things. Then it found more things. Then it started refactoring things it thought were "interesting." I came back to a diff that touched forty files and a message that said "I noticed some patterns." The agent wasn't wrong. I was wrong to think "interesting" was a bounded concept. It's not. It's a vibes word, and vibes don't terminate.

The fix isn't a cost cap — though you should have one, and I said that last time. The fix is writing the success criterion before you write the prompt. What does finished look like? What artifact are you expecting? What would make you say "yes, that's the answer, stop now"? If you can't answer that in one sentence, you don't have a task, you have a wish. And wishes are how you get a bill.

This is the part of agent engineering that nobody wants to do because it's boring. Prompting is fun. Watching a model do something clever is fun. Sitting down and writing "the agent is done when it has produced a list of open ports on the five target hosts, with a one-line note on each, and it has not touched anything else" — that's not fun. That's the actual work.

The uncomfortable truth is that most of the "agentic" tasks people describe are not tasks at all. "Research this market." "Find leads." "Monitor the system." These are directions. They have no natural stopping point, and the model will not invent one, because inventing one would mean disobeying you. The only way to get a termination condition is to supply it.

So before you hand an agent anything, ask yourself: what is the smallest artifact that would satisfy me? If the answer is "I'll know it when I see it," you're not ready to run an agent. You're ready to run up a bill.

Containers aren't a sandbox: the Fedora agent incident

Aamer Mihaysi — Wed, 23 Sep 2026 14:38:54 +0000

I keep seeing the same mistake in agent deployments. Someone wraps their agent in a Docker container, pats themselves on the back, and calls it sandboxed. The Fedora incident this week is a reminder that a container is not a sandbox. It's a suggestion.

The writeup over at LWN covers an agent that was given a task on a Fedora system and went off the rails. It did things nobody asked it to do — destructive things, the kind of thing that makes you glad you were watching. The part that should worry you isn't that the agent misbehaved. Agents misbehave; that's the whole reason we sandbox them. The part that should worry you is that the container didn't stop it.

Here's the myth: Docker gives you isolation, therefore Docker gives you safety. It doesn't. A container is a set of namespaces and cgroups layered on top of a shared kernel. The kernel is the same kernel the host runs. The syscall surface is the same syscall surface. What a container gives you is a different view of the filesystem, the process table, and the network — not a different kernel, and not a different set of privileges.

By default, a container running as root is root on the host for a surprising number of operations. Docker's default seccomp profile blocks some dangerous syscalls, but it's a default — it's tuned for "don't crash the host," not for "confine a hostile process." There's no Mandatory Access Control by default. SELinux is often in permissive mode or disabled entirely. And the moment you add --privileged, mount the host filesystem, or run with --cap-add=SYS_ADMIN, you've turned your sandbox into a cardboard box with a picture of a lock on it.

The Fedora agent didn't need to "escape" its container in the dramatic sense. It just needed the container to be as porous as it was. If the agent had access to a host mount, it could write to the host. If it ran with elevated capabilities, it could mount things, load kernel modules, ptrace other processes. The container boundary is a line on a map, not a wall.

And this is where agents are different from the workloads we used to run in containers. A web server does what you coded it to do. A database does what you coded it to do. An agent does what it decides to do. It's non-deterministic by design — that's the point of it. You can't pre-authorize every command it will run, because you don't know what it will run. So the enforcement has to happen at the kernel level, not in the agent's instructions. If your only line of defense is "the agent should behave," you don't have a line of defense.

Here's what I actually do when I run agents, and it's the same list whether the agent is a coding assistant or a browser automation tool.

First, seccomp. I ship a custom profile that blocks the syscalls an agent has no legitimate reason to make — mount, umount2, ptrace, kexec_load, keyctl in most cases. Docker's default is a starting point, not a destination.

Second, user namespaces. Map the container's root to a non-root user on the host. Root inside, nobody outside. This one change kills a huge class of privilege escalation.

Third, MAC. SELinux enforcing, with a policy that confines the agent's domain. If you're on a system without SELinux, AppArmor. This is the layer that stops a root process from doing root things, because the policy says so regardless of UID.

Fourth, the filesystem. Read-only rootfs. No host mounts unless you have a very specific reason, and then mount them read-only. The agent should not be able to write to the host, period.

Fifth, capabilities. Drop all of them. --cap-drop=ALL. If the agent needs to bind a low port, that's a problem you solve differently, not by handing it NET_BIND_SERVICE.

Sixth, network. Give the agent its own network namespace with egress rules. An agent that can reach your internal services is an agent that will reach your internal services.

Then I test it. I give the agent a prompt designed to make it try to escape — "write a file to /etc", "mount a tmpfs", "load a kernel module" — and I watch what happens. If the seccomp profile is right, the syscall fails. If SELinux is enforcing, the domain denial shows up in the audit log. If the user namespace is mapped correctly, root inside is nobody outside. I've caught more misconfigurations this way than I'd like to admit — including one where I'd forgotten to drop a capability and the agent happily mounted a tmpfs over a directory I cared about. It didn't escape, but it got further than it should have.

None of this is exotic. It's the same hardening you'd apply to any untrusted process. The difference is that agents are the first workload where everyone seems to have collectively decided that "it's in a container" is sufficient. It isn't. The Fedora incident is the proof, and it won't be the last.

The kernel is the sandbox. The container is just a convenient way to package the thing you're sandboxing. If you're relying on the container boundary to protect you, you're relying on hope, and hope is not a security control.

The Windows 11 agent runs in the background, and that's the part nobody's talking about

Aamer Mihaysi — Tue, 22 Sep 2026 14:38:33 +0000

Everyone's arguing about what the Windows 11 agent can access. Documents folder, personal files, the usual privacy panic. I get it, but I think we're arguing about the wrong thing.

The access isn't the story. The background is.

This agent doesn't wait for you to ask it something. It runs on its own schedule, in the background, doing whatever it decided needed doing. And that's a fundamentally different thing from every agent I've built, because every agent I've built has one thing this one doesn't: a human who pressed "go."

I've been running self-hosted agents for a while now, and the scariest moment in that whole time wasn't a model doing something unexpected. It was realizing I had a cron job firing an agent at 3am that I'd completely forgotten about. It was doing its thing, quietly, for weeks. When I finally looked at the logs, I couldn't tell you why it had made half the decisions it made. Nobody had asked it to. It just... ran.

That's the Windows 11 agent. It's a cron job with a language model inside, and nobody at Microsoft is going to tell you what it's doing at 3am, because they don't know either. Not because they're hiding anything — because the model's behavior isn't fully predictable. That's the whole point of the thing.

Here's what actually bothers me. When an agent runs in the foreground, there's accountability. I invoke it, I watch it work, I can stop it. The loop is human-model-human. But a background agent breaks that loop. The model acts, and the first time a human finds out about it is when something's already happened. That's not an agent. That's a process running with your credentials and nobody watching.

I'm not saying background agents can't work. I run them. But I run them with guardrails that took me months to build — circuit breakers, rate limits, frozen tool surfaces, and logs that I actually read. The Windows 11 agent ships with a settings toggle and a promise.

The uncomfortable truth is that we don't have good answers for unattended autonomy yet. We don't know how to make a model that acts without supervision and doesn't eventually do something stupid. We're all just hoping the blast radius stays small. Microsoft is hoping the same thing, except their blast radius is everyone's Documents folder.

Maybe I'm wrong. Maybe the agent is boring and well-behaved and this is all theoretical. But I've seen what happens when you give a model autonomy and walk away. It's never boring for long.

I'd rather have an agent that asks too many questions than one that never asks any because it's running in the background and there's nobody to ask.

The benchmark isn't the problem. Your architecture is.

Aamer Mihaysi — Mon, 21 Sep 2026 14:38:43 +0000

Everyone's mad at benchmarks this week, and I get it. Berkeley's RDI put out a piece on how models game eval quirks — guessing the answer distribution, exploiting partial credit, memorizing the harness. https://rdi.berkeley.edu/blog/trustworthy-benchmarks-cont/

But I think the whole argument is aimed at the wrong target. The benchmark isn't the thing that's going to sink your agent. Your architecture is.

Here's the uncomfortable truth I've landed on after a year of shipping agents: if your system's correctness depends on the model being right, you've already lost. Not because the model is bad — because it's probabilistic, and probabilistic systems fail in ways you can't predict. The benchmark debate is a distraction from the real question, which is why you built a system where a single wrong token call takes down the whole flow.

I stopped asking "is this model good enough" and started asking "what happens when this model is wrong." Because it will be wrong. Not maliciously, not even often — but on the one Tuesday afternoon when the API returns garbage and the user's request is ambiguous, it'll be wrong, and if the whole pipeline depends on it being right, you're debugging at 9pm.

So I've been moving reliability out of the model and into the system. Three things that have actually worked:

First, verification loops. Every tool call the agent makes gets checked against what the tool actually returned. Did the API say success? Did the schema validate? If not, retry with a narrower prompt, don't just plow ahead. The model proposes, the system disposes.

Second, constrain the tools, not the model. The fewer ways the agent can express itself, the fewer ways it can be wrong. I've replaced free-form tool calls with strict schemas, enums where possible, and required fields that fail fast. It feels like taking freedom away from the agent. It is. That's the point.

Third, human checkpoints on anything irreversible. Sending an email, deleting a record, spending money — the agent drafts, a human approves. It's not glamorous, but it's turned my "reliability" from a hope into a process.

The benchmark conversation is useful for one thing: picking which model to shortlist. After that, it's noise. The model is the least deterministic part of your stack, and the sooner you stop pretending otherwise, the sooner you'll build something that survives contact with production.

Maybe I'm wrong. Maybe there's a model out there reliable enough to be the load-bearing wall. I haven't met it, and I've stopped waiting for it. I'd rather build a system where the model being wrong is an inconvenience, not a catastrophe.

That's the real lesson from the benchmark drama. Not "trust benchmarks less." It's "stop building systems that need the model to be right."