One call, ten agents, and the answer moves

The framing going around is tidy. An agent reaches a fork: a state, several possible actions, one route that has to win. Sending that fork to a frontier model costs seconds and cents, so make decisions their own engineering layer. The loop becomes LLM → reason, Jev → decide, tools → execute, state → update, Jev → decide again. Once decisions are a layer you can benchmark them, batch them, and verify them on their own terms.

I think that is basically right. I also think the number stapled to it — "up to 193x faster and 444x cheaper in our tests" — is doing the argument active harm, and this site has already done the arithmetic, so I am not going to do it twice.

Two things come out of that, and the second is the one nobody states. The batching is real and measured: ten questions against one shared arena cost about the time of one. And the batch is not answer-preserving — the same rows measured grouped and alone move jev_score by about 0.29 rubric levels on a 0–3 scale, while jev_choice agrees 269 times out of 270, because argmax survives a shift that a probability-weighted mean does not. Both sections are below; if you only read one, read the second.

The layering argument does not need the number it is quoting

Take the corrected pair and put it back into the pitch. A decision layer that is 4.57x faster and 336x cheaper per call than a frontier model on the same bounded question is a good reason to build one. It is a better reason than 193x, because 4.57x is a number a reader can imagine surviving their own workload, and 336x is large enough that nothing about the case rests on the speed figure at all.

The inflated multiplier buys nothing the argument wanted. Notice what it would take to be true: a baseline spending over two minutes per decision. Quote it and you have conceded, in the same breath, that your comparison ran against a system doing the exact thing your architecture says to stop doing. The honest single-digit latency number and the honest three-figure cost number point at the same design; the three-figure latency number points at a straw man. Every reader who checks it — and this ecosystem has repeatedly checked, in public, within days — will discount the whole post, including the parts that hold.

So the layering claim survives the correction. It survives it more comfortably without the number.

What the layer still cannot do, and what that costs you

The part of the pitch I would push back on is not the multiplier but the silence. Three limits are now documented well enough that shipping without them in view is a choice.

It cannot write a string. The type signature is state → one of k known options, with a probability attached. That is the whole product. Any deployment that needs an argument value, a message body, or a file path needs a second model beside the decision layer. WindTunnel's board is the clean instance: Jev picks the tool, Mercury 2.5 writes the arguments, 49 of 49 tasks solved, and the cheap fast model that writes the strings is 78% of the bill. Two models, one of which is the one the pitch says you were replacing.

It cannot plan. A layer that answers a bounded question about the current state has no horizon. Every roster entry in the nine-day ecosystem census rebuilt the option menu from scratch on every step, because that is the only shape the layer supports. The Jev Engineering guide states it as principle three — "rebuild the options at every step" — which is a sensible rule and also an admission: the plan is the loop your code writes, not something the model holds.

It cannot compare two options to each other. This is the sharp one. Jev scores 0 of 100 on relational choice — questions where the content of one option decides another — on a suite where the same model scores 100% on rule judgment and 98% on ARC-Challenge. Not low. Zero, across a hundred attempts, far below guessing. It is the signature of a structural constraint: the options never share a context. That last reading is now contested — permuting a 77-option list moves the hosted model's answers on 12 of 100 items, which a strict per-option scorer cannot do at all — but the measured 0 of 100 stands whichever way that resolves, and so does its consequence for a swarm.

That last one is where the swarm variant gets interesting, because a swarm is nothing but options that need to be compared.

The swarm variant's real argument is the batch

Here is the definition that is actually circulating, and it is a precise one:

A decision is (state, typed question, options) → a probability distribution over exactly those options. A swarm is a set of agents that all decide against one shared state in one batched call.

Credit where it is due: that second sentence is a genuinely new claim, and it is not a restatement of the single-agent pitch. The single-agent framing sells latency and price per decision. The swarm framing sells something structural — the state is the expensive half of a decision request, and N agents looking at one world means N questions against one copy of it.

aeluyo8-blip/jev-swarm is the cleanest instance I found and it publishes its own counters. Ten cooperative snakes share one 30×30 arena; every tick sends a single request carrying all ten snakes' questions; the model returns a full distribution per snake. Its README states the batching result plainly and modestly:

Parallelism is real. A 10-question request costs ~0.37 s p50 / ~1.24 s p95 — the model answers ten judgments in roughly the time of one.

The repository's own framing of what it is for is better than most launch posts manage, and it is the right question to have asked:

How much intelligence does one small model contribute to a multi-agent system — and how much comes from the code around it?

expand

Intentions stay private, so the negotiation happens in code

Now read the swarm's own design rule, because it is the relational-choice result restated by someone who has clearly never seen it:

Positions are public physics (each snake sees its own body and every other snake's head); intentions stay private — no question may see another question's answer.

That is not a privacy preference. It is the constraint. Ten agents batched into one request do not become a team; they become ten isolated questions that happen to share an envelope. Two snakes can each be confidently right about their own best move and jointly wrong, and no amount of batching fixes it, because the thing batching shares is the state, not the answers.

So the swarm builds the relation the only place it can: in deterministic code. The Joint Action Resolver enumerates joint actions, drops the ones that violate a hard constraint, and keeps the one maximising the sum of log probabilities. The README is exact about the cost of that — 3¹⁰ enumeration with pruning is about 0.5 ms, and beam search for twenty agents about 22 ms — which is cheap, and is also the whole point: the coordination is a 0.5 ms program, not a model call.

This is the same shape the three-tier piece found in Stanley and in an xArm7 harness: deterministic code builds the relation, then hands it down as an independent question. A swarm is that pattern with N questions instead of one. The layer got wider; it did not get smarter.

The project knows this, which is the best thing about it. Its headline diagnostic is the override rate — how often the resolver rewrites what the model picked — and the README names it as the Go/No-Go gate: "if the resolver rewrites most decisions, the code is playing the game — not the model." In the published run it is 2.2%: fourteen overrides, which at that rate implies roughly 640 individual decisions across the run's 176 ticks. That is a real result in the model's favour, published by someone who set up the measurement so it could have gone the other way.

expand

That feature table is the honest accounting of a swarm decision. Food distance, reachable cells, head distance, dead-end risk, conflict candidates, wall distance: all of it computed deterministically, per action, before anything is asked. The model picks among three options that code has already described in full. That is the architecture working exactly as advertised, and it is also why the parameter count of the decision model is not the interesting number in the system.

The batch is not answer-preserving

Here is the part the swarm framing does not mention, and it comes with measurements.

colliber/duckdb-jev exposes Jev as DuckDB scalar functions, and someone opened issue #4 with a title that is the whole finding: "A shared state changes the answers: propose jev_*_each and jev_*_all instead of silent batching." The measurements:

Same API, same call, two different answers about whether batching is safe.

The mechanism is the readout. Choice reports which option won; a distribution that shifts without reordering is invisible to it. Score reports where the probability mass sits across an ordered rubric, so the identical shift lands directly in the output. Batching is answer-preserving for the readout that throws information away and not for the one that keeps it — which means the cheap sanity check ("we batched and the answers matched") is run on precisely the readout that cannot detect the problem.

And it is worse for a swarm than for a SQL function, because the swarm has no un-batched baseline to compare against. duckdb-jev could run each row alone and diff. A tick that asks ten questions of one arena has no single-agent control unless you build one, and the efficiency argument is the reason nobody does.

The issue's proposed fix is the right one and it is an API fix, not a model fix: stop batching silently. Name the three shapes separately — jev_choice for one row and one state, jev_choice_each for many rows sharing a state with an answer per row, jev_choice_all for many rows sharing a state with one answer about the group — so that grouping is something the caller wrote down rather than something the runtime did for speed.

The other swarm, and what a closed PR is worth

The second place this framing shows up with code behind it is acyclic-labs/sdk#110, which adds acyclic-jev and an arena that judges competing forks of a repository: render each fork's diff into one shared state, ask which fork wins. Its demo is a three-model race on one feature task, and the numbers are the good kind — specific, cheap to falsify, and unflattering to somebody:

DeepSeek V4 Flash won the verdict at 0.92 with tests passing for $0.003; Sonnet broke the tests for $0.12. Judge cost $0.00009.

A judge that costs 0.075% of the cheapest contestant is the decision-layer argument in one line, and it is the same argument this site has now watched fifteen-odd projects make. But the PR carries ten blocking review findings — symlink following that leaks host files to an external endpoint, failed workers promoting broken edits, cleanup failures leaving stale fork mounts — and it was closed without addressing them. The decision layer was the easy part. The thing around it, which had to mount untrusted repository forks and run them, was not. That asymmetry is the recurring lesson of this whole family: moving the decision down a tier moves the hard work into the code you now have to write, and that code is where the security review lands.

What I would actually take from the swarm framing

Three things, in order of how confident I am.

Batch against one state when the state is expensive. That is the real win, and it is structural rather than incidental. A 30×30 arena with per-action features for ten snakes is a couple of thousand tokens; each additional question is around a hundred. The saving is not "the model is fast," it is "you stopped re-sending the world." Ten questions against one arena run in about the time of one. The guide's own worked example puts a 13-question batch at roughly an order of magnitude on both axes — though it states that pair twice on the same page, once as "10x faster and 12.2x cheaper" and once as "11.5 times cheaper and 9.6 times faster," which is a small thing and also exactly the kind of small thing that makes a reader check the big ones.

Then measure whether the batch changed the answers, on the readout that can show it. Group a held-out set, run it ungrouped, and diff the Score values, not the Choice labels. If you only have Choice, diff the probability vectors rather than the argmax. A tenth of a rubric level is invisible until it sits under a threshold, and every one of these systems is a threshold on a number.

Do not call what the resolver does "collective intelligence." The batching is an efficiency property of the request. The coordination is a program you wrote, and in the one published run it rewrote the model 2.2% of the time, which is the number that makes the model look good and is also the number that only exists because somebody instrumented the override path. Ship the override rate. It is the only honest way to say which half of the system is playing the game.

Sources: the swarm definition and the seven working principles are quoted from madewithjev.com/what-is-jev-engineering. Measurements and design rules attributed to jev-swarm are from that repository's own README and the two screenshots reproduced above; the counters in Figure 1 are the running app's, not mine. The grouped-vs-solo numbers are from colliber/duckdb-jev issue #4 as reported there. The corrected 4.57x / 336x pair is from The middle tier is not in the middle, which recomputed it from a published xArm7 seed-0 trial; I have not re-derived it here. The batching, resolver and shifted-distribution interactives are my own illustrations of the mechanism — the resolver's two-agent case is drawn to make the rule visible and is not a recorded tick.