Models · System One
The Floor Costs More Than the Questions
Every network call has a fixed price you pay before any work happens. Usually it is small enough to ignore. With a model that answers in tens of milliseconds, it stops being small and starts being most of the bill.
A pre-registered independent evaluation of Jev, published on September 20, 2026, measured that floor and then tested what happens when you fill a single call. The numbers argue for a specific shape of system, and it is not the shape most people build first. Ciyo does not run Jev — it generates no image and no video — so this is a read of published measurements rather than a product note.
What was measured
The evaluation collected 5,721 calls across 21 experiments, with 50 predictions timestamped before data collection began. It ran `typesafe/jev-1.13-20260917` through OpenRouter from Western Europe, and it published its raw data.
Two findings drive everything else. There is a fixed cost of roughly 430 milliseconds per call. And 800 typed judgements placed in a single call completed in 985 milliseconds, at a cost of $0.00075.
Put those together and the arithmetic is stark. The first judgement costs about 430 milliseconds. The next 799 cost about 555 milliseconds between them, which is roughly seven tenths of a millisecond each.
The authors' own caveat, which matters here
They say plainly that they cannot separate model latency from gateway latency. The 430 milliseconds is measured; the claim that it is a property of the model rather than of the route is a hypothesis, and they say so. Anyone with native API access can settle it quickly.
That caveat does not weaken the design advice. Whatever the floor is made of, you pay it once per call, so filling the call is the lever either way. It does mean you should measure your own floor from your own region before building a latency budget on somebody else's number.
It is also one location on one day, against one model version. Treat it as the shape of the thing rather than as a specification.
What this argues for
Do not build the loop that sends one state and one question, waits, then sends the next. That design spends almost all of its time paying the floor over and over.
Two better shapes fall out of the same measurement. Fan out the questions: send the state once with every question you might want answered, including ones you will probably discard, because the marginal question is nearly free. And batch the states: if you are classifying a backlog rather than reacting to a live event, put many items into one call rather than many calls into one minute.
The second shape has a limit that is not about latency: a call carrying 800 judgements carries 800 judgements' worth of state, and you have to be able to attribute every answer back to its row. Keep your question ids meaningful and your mapping explicit.
Posted 2026-09-21. A developer working through an email-triage design notes that the primitives can be used in parallel, that Score with thresholds and Choice do not behave identically on the same task, and that the documented patterns favour asking many questions — even speculative ones — in a single call. That last point is the same conclusion this article reaches from the latency data.
Concurrency, and where it stops helping
The same run looked at parallelism across calls rather than within them. It found eight concurrent requests to be the best operating point and throughput saturating at around eleven requests per second.
That is a small number, and it is worth knowing before you design a fan-out worker pool. Beyond eight in flight, the run got no more work done; it simply had more requests waiting. The 5,721 calls took about 25 minutes at that setting, and cost $0.176 in total.
If you need more than roughly eleven requests per second of this, the answer from these numbers is not more workers. It is fewer, fuller calls.
A budget you can actually write down
Take the shape of these numbers and apply it to a real workload rather than to a benchmark. Say you want to evaluate every step of every agent run, and you have 50,000 steps a day with four questions per step.
As one call per step, that is 50,000 calls, about six hours of wall-clock time at the measured floor and concurrency, and a lot of scheduling. As batched calls of, say, 200 steps each, it is 250 calls. The token cost is the same either way, because you are sending the same state; what collapses is the time spent paying the floor.
That is the whole design lesson. With this class of model, the question you should be asking is not “how fast is one call” but “how much can I fit in one”.
| Design | Calls per day | Floor paid per day |
|---|---|---|
| One call per step | 50,000 | about 6 hours of fixed cost |
| 200 steps batched per call | 250 | under 2 minutes of fixed cost |
| The same tokens either way | — | the state is what you pay for |
What to measure before you commit
Your floor, from your region, on your route. It is one script and twenty minutes, and it is the number your budget rests on.
Your ceiling per call. Push the judgement count up until the response time or the error rate turns, and stay below it.
Your attribution. A batched call is only useful if every answer finds its way back to the right row, and that is a bug class worth a test rather than a hope.
And your own accuracy, because none of the speed matters if the judgements are wrong. Speed is the reason to use a model like this; agreement with your own labels is the reason to keep it.
Throughput questions
How many judgements fit in one call?
The documentation publishes no cap on questions per request. One independent run placed 800 in a single call, which completed in 985 milliseconds for $0.00075.
Is the 430 ms floor the model or the network?
Unknown. The authors measured the floor and say explicitly that they cannot separate model latency from gateway latency on their route.
How many requests can I run at once?
In that run, eight concurrent requests was the best operating point and throughput saturated near eleven per second. Measure your own before sizing a worker pool.
Does batching change the token cost?
No. You pay for the state you send. Batching collapses the fixed per-call cost, not the tokens.
Keep reading
Ciyo writes about the models behind creative and agent tooling, and tests the ones it can run.