What developers built with Jev, TypeSafe AI's System One model, in its first 72 hours

I wrote about Jev the day after TypeSafe AI launched it — what a “System One” model is, why parallel typed decisions beat streaming tokens for a five-way enum, why I’d hold their 200x/400x numbers loosely until someone outside the company reproduced them. That post was about the architecture. This one’s about what happened next: in the 72 hours after launch, people pointed Jev at problems I wouldn’t have guessed, and the pattern in what they built tells you more about what a System One model is actually for than TypeSafe’s own blog post does.

The decisions were fast because they had to be

The most interesting projects share one trait: the decision was on a clock that a normal LLM call can’t hit.

Milind Labs built a computer-use agent that never touches an LLM or a screenshot. A local CoreML model segments every button and UI element on screen, on-device OCR reads the labels, and that’s all Jev gets — no pixels, no DOM. Jev scores the elements, picks one, clicks it, and the loop re-runs detection and decides again, at about 90ms per decision. That’s a loop, not a single call, which is exactly the shape that breaks down once your per-step latency is measured in seconds instead of milliseconds.

Jarrod Watts built a trading bot that decides “buy” or “sell” from a live price feed and executes on Monad, against Kuru’s on-chain order book, once per 300ms block. A block only stays open for 300ms — there’s no version of that loop where you wait on a few seconds of token generation and still get your order in before the block closes.

Zachi built a PostgreSQL extension that does natural-language row filtering with no index and no embeddings — WHERE jev(people, 'could work from home') — by calling Jev once per row. 129 rows judged in about a second for $0.0009 on the first pass; 6ms from cache on the second. That’s not a real-time loop in the game or trading sense, but it’s the same underlying constraint: nobody writes WHERE llm_generate_text(...) over a table and expects it to be usable, because the per-row cost of a text generator is too high to pay 129 times, let alone at table scale.

Faadil Shaik got Jev playing Super Mario Bros in real time, which is the most literal version of the same test — a game doesn’t pause and wait for your model to finish reasoning about whether to jump.

Gregor Zunic wired Jev into browser-use to build a flight-search agent, with Jev picking the action at every step instead of a small LLM. A full flight search ran in 7 seconds for $0.0039. The interesting part isn’t the total time — a browser agent doing 10+ steps is never going to feel instant — it’s that the per-step decision (which element to click, what to type) stopped being the bottleneck. The slow part is loading pages, not deciding what to do with them.

The budget that actually matters

TypeSafe’s headline number is “70–500ms,” and it’s easy to read that as a flex rather than a constraint. It’s more useful as a budget: below some threshold, a use case is off the table for a text-generating model entirely, not just more expensive. Here’s what each launch-week project actually measured, next to a few reference points for scale.

Against a 300ms budget — a blockchain block, roughly a third of a second — the picture is stark: the trading bot is right at the wire, the computer-use agent and the Postgres extension are comfortably inside it, and a typical LLM classification call is already past it before it’s even started. Only the cached Postgres lookup gets anywhere near game-frame territory, under 20ms — the honest caveat there being that the 6ms number is a cache hit, not what every row costs.

Not every experiment was about speed

Some of the launch-week activity wasn’t a real-time use case at all — it was people testing what a typed, calibrated decision-maker is like to poke at once it’s not embedded in a pipeline.

Max Rovensky ran the trolley problem through it and reported that Jev “decided to sacrifice a human to save robots” — funny as a one-liner, and a fair reminder that a model returning a calibrated probability over a fixed answer set will still give you an answer to a question that doesn’t really have one, because that’s what it’s built to do.

Tamara Tran proposed using Jev for context compaction in agent harnesses — instead of asking a model to summarize a tool-call history in prose, score every past tool call for relevance and drop what scores low. That’s a genuinely different application of the same primitive: not a live decision loop, but a filtering pass over an agent’s own history, done the same way Zachi’s Postgres extension filters rows.

And OpenRouter put Jev into beta on their platform within the same window, which matters less as a technical result and more as a distribution one — it’s the difference between “early access to one company’s API” and “one more model in the dropdown of every app already built on OpenRouter.”

What the range tells you

None of these are benchmark results, and I’d treat the specific numbers with the same skepticism I’d apply to TypeSafe’s own — a tweet with a demo video isn’t a reproducible eval. But the spread is the finding: nobody used launch week to ask “can Jev write me an essay,” because that’s not the bet TypeSafe is making. Every project above is either bound by a real clock — a game frame, a blockchain block, a click-and-recheck loop — or it’s a filtering pass over a lot of small decisions, which is the same constraint wearing a different hat. That’s a narrower niche than “foundation model” implies, and also a more concrete one than the RLCD calibration story I wrote about last time. Whether Jev holds up as more people build on it past the honeymoon week is still an open question, but the shape of what got built first is a pretty clean confirmation of what TypeSafe said they built it for.

Sources: Milind Labs, Jarrod Watts, Zachi, Faadil Shaik, Gregor Zunic, Max Rovensky, Tamara Tran, OpenRouter, TypeSafe AI — Introducing System One Models and Jev.