# Jev and the era of model Tetris > Source: > Published: 2026-11-12 09:00:00+00:00 This spring, in an interview after a keynote, I said we were all playing LLM Tetris now. The days of using the same LLM for every agent problem were over. Some decisions needed to come back in milliseconds, and some could take three minutes. Some needed generative output, and some needed logical decisions where an open-weight model might do. Fit the model to the use case. I still believe that. But I was only half right, because I was still picturing every piece as an LLM. Bigger or smaller, pricier or cheaper, faster or slower, but all the same shape: text in, text out. On September 15, a model shipped that doesn’t write anything. Within three weeks, more than a dozen others followed, from OpenAI, Cloudflare and Perplexity to open-source projects you can run on a laptop. Then on October 27, we got yet another class of model from Liquid AI, small enough to run on a phone. The game I described in the spring is real. It just has more piece shapes than I expected, and it isn’t only an LLM game anymore. It’s model Tetris now. The model is called Jev, from a startup called TypeSafe AI. Its founder, Diogo Almeida, [says he helped build](https://typesafe.ai/blog/introducing-system-one-models-and-jev) the instruction-following research at OpenAI that became ChatGPT. He then spent two years in stealth on a different question: if models have been superhuman at chat for years, where is all the automation? His answer borrows from [Daniel Kahneman’s](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow) [*Thinking, Fast and Slow*](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow). System Two is slow and deliberate. System One is fast and intuitive. Today’s frontier LLMs, with their reasoning traces and multi-second responses, live in System Two. But a lot of the decisions software makes all day are System One decisions: route this ticket, score this risk, take this branch. A System One model doesn’t generate text. You hand it a piece of state and a set of typed questions, and it returns structured answers with calibrated probabilities. There are three question types: a **Choice** among options you define, a **Score** on a rubric you write and a yes-or-no probability TypeSafe calls a **Noul**. TypeSafe calls it a frontier-intelligence function call. I think of it as a smart if-statement. The launch numbers are aggressive: $0.042 per million input tokens, output free and responses in 70 to 500 milliseconds. One claim needs precision. TypeSafe says Jev can’t hallucinate. What that means is it can’t return an answer outside your schema. It can still pick the wrong answer from inside it, and it will tell you how confident it was when it did. Then there’s the detail I enjoyed most. TypeSafe named Jev after William Stanley Jevons, because it expects machine intelligence to follow coal’s path: every drop in the cost of intelligence unlocks more uses for it. Longtime readers know I’ve leaned on Jevons Paradox to explain [why bank tellers multiplied after ATMs](https://www.cio.com/article/4148168/agi-skepticism-tellers-vs-toll-booth-workers.html) and [why AI coding agents haven’t emptied out engineering teams](https://www.cio.com/article/4166029/the-570k-canary-what-ai-coding-agents-reveal-about-enterprise-ais-real-gaps.html). Now somebody has named a model after it. One model is a product. What happened next made it a category. At its DevDay in late September, OpenAI [previewed a Decisions API](https://thenewstack.io/openai-decision-api-luna/) built on GPT-6 Luna. On October 6, it [opened it to all developers in public beta](https://www.unite.ai/?p=480717) at $0.10 per million input tokens, with output free, and says it decides roughly ten times faster than the same model through its regular API. On October 1, Cloudflare [released Clef](https://blog.cloudflare.com/clef-decision-models/), open-weight decision models whose smaller version returns a median decision in under 40 milliseconds. Perplexity [opened its own Decisions API](https://docs.perplexity.ai/docs/decisions/quickstart) the same day, also on open weights, and claimed a narrow win over Jev on its own benchmark panel. Amazon’s Strands Labs [reportedly shipped](https://aiweekly.co/alerts/cloudflare-open-sources-clef-beats-jev-latency-on-edge-gpus) an open-source decider that day too, and Liquid AI’s [d1](https://systemonemodels.org/models/d1/) and Upstage’s [Solar Decide](https://systemonemodels.org/models/solar-decide/) joined a growing list of open-source projects. On October 2, llama.cpp, the engine behind a lot of local model serving, [added an endpoint](https://github.com/ggml-org/llama.cpp/pull/29818) that speaks the same request format [Jev introduced](https://typesafe.ai/blog/introducing-system-one-models-and-jev). Cloudflare’s Clef speaks it too. Two things stand out for CIOs. First, the interface standardized before the market did. That’s how containers made runtimes interchangeable, how MCP made tools accessible for agents, and it matters for what I’ll argue below. Second, published prices range from $0.02 to $0.24 per million input tokens across vendors. When prices for the same kind of thing span an order of magnitude, nobody knows what it really costs yet. TypeSafe itself says it can’t prove its pricing isn’t subsidized and the pricing tier here will be something to keep an eye on. I don’t know of any customers running System One models in production yet. The category is barely two months old. So, I did what I’d tell any CIO to do with a new piece: I tried it. And I tried it with a use case that seems like a toy until you think about it a little bit. I’m building agents to play Pac-Man. Why? That’s a use case that requires good decisions made quickly, where broader context and planning matter and everybody understands success metrics. You clear the board or you don’t. You score points or you get eaten by a ghost. What I wanted to learn wasn’t only which model knew the most, which is a knowledge question. What I wanted to test was: is a quick decision that might not be optimal worth more than a better one that takes longer? You can’t answer that on paper, because it depends on how fast the world changes underneath the decision. I had to try it to find out. So do you. First I built the harness. Using Claude Code, I wired up MAME, the arcade emulator, so a program could play, and started with an agent that picked a random direction at every intersection. That agent was useless at Pac-Man and invaluable for everything else. It let me get observability right and settle on an ASCII version of the board as the agent’s input before any model was involved. Build the harness first, and trying three models becomes cheap. It’s the lesson I took from software engineering [in July](https://www.cio.com/article/4193951/the-ai-roi-gap-isnt-a-model-problem-its-a-workflow-problem.html): the scaffolding is what makes testing possible. The game sends a new board state roughly every 17 milliseconds. Even a local open-weight model on my M4 Mac couldn’t weigh tactics and strategy in one shot at that pace. So, I split the work into two loops, last month’s micro-agent pattern in miniature. A tactical loop decides which way to turn, given the current goal. A planning loop picks the goal from 11 options: clear a quadrant, go for one of the energizers, hunt, escape or finish the level. Then I built three planners on the same tactical loop. code-planner picks a goal with a proximity analysis of the board, in plain code. jev-planner sends the board to Jev. haiku-planner sends it to Claude Haiku through Anthropic’s API. Both hosted models answered faster than the local open-weight options I tried. I ran each one 100 times: | **Planner** | **Mean score** | **Best score** | **Cleared level 1** | **Bonus lives earned** | **Median frames missed per decision** | | code-planner | 5,100 | 15,640 | 51% | 4 | 0 | | jev-planner | 4,499 | 9,480 | 27% | 0 | 21 | | haiku-planner | 3,406 | 9,090 | 10% | 0 | 59 | Look at the last column. The outcomes rank exactly with latency. Code-planner missed no frames, jev-planner missed about a third of a second’s worth, and haiku-planner missed close to a full second. Scores fell in the same order. I don’t think Jev beat Haiku because it was smarter. I think it beat Haiku because it answered sooner. [Watching the runs side by side](https://www.linkedin.com/feed/update/urn:li:activity:7513214612725489664/), the losses look alike: a planner sticks with a quadrant too long, or switches to escape a beat too late. In one run, both model-driven planners got within a handful of dots of clearing the board and died chasing the last stranded pockets, while code-planner was already on level two. A correct answer delivered after the window closes is a wrong answer. Pac-Man makes the window visible because it’s measured in frames and the penalty is a life. Enterprises have the same windows; they’re just harder to see. A card authorization has to clear in a fraction of a second. An ad bid expires. A guardrail sits in front of every request. A tool dispatch inside an agent loop gets paid for at every hop, which is the compounding I described [in June](https://www.cio.com/article/4180868/your-ai-cloud-strategy-isnt-about-cost-its-about-gravity.html). The latency budget belongs on the list of criteria for choosing a model, right next to accuracy and cost. Most teams leave it off. The ordering that falls out of this is simple. If the rules are known and stable, write code. If the answer is one of a known set of options but the rules are too fuzzy to write by hand, use a System One model. If the answer has to be written, or the reasoning has to be explained, use an LLM and accept the wait. It’s too early to provide guidance on the new Liquid AI models, but this emerging class of smaller compute footprint cousins to the GPU-hungry LLMs may earn a place in a decision matrix as well. One size does not fit all. Adapt to what best fits your use case, which is almost certainly different from my toy Pac-Man experiment. To sort any given decision, ask four questions: Run last month’s five-agent software delivery chain through those questions and the board fills in. Turning a business request into a technical issue needs an LLM. Point poker estimation is a Score. A merge gate is a yes-or-no probability. Test failure triage is a Choice. And some of it, honestly, is an if-statement. Now the part that matters most: don’t limit your options. As an industry, we’ve been building databases for about 60 years. We’ve been building agents for about 18 months. System One models didn’t exist two months ago. Nobody should be confident that today’s model usage pattern will still be the right one 18 months from now. Tetris makes the point better than I can. You only get a short preview of the next piece. A board built so it only works if the long straight piece shows up is a board that loses. In practice, that means keeping the model choice behind an interface you control. My Pac-Man harness does this by design: three planners plug into the same tactical loop, and swapping one touches nothing else. The market is helping, too, since a dozen vendors converged on one decision API in three weeks. This is the deployment flexibility gap I described [in May](https://www.cio.com/article/4166029/the-570k-canary-what-ai-coding-agents-reveal-about-enterprise-ais-real-gaps.html) and the portability question from June. Lock-in used to be denominated in egress fees. Now it’s denominated in model usage patterns. Whatever pieces you play, one thing doesn’t change: every model is only as good as the state you hand it. A System One model given the wrong context returns a calibrated, confident, wrong answer. Because it’s cheap, it can do that at enormous volume. Cloudflare’s hosted Clef currently reads only about the first 2,000 tokens of text state. [In September](https://www.cio.com/article/4226223/the-wrong-million-tokens.html) I argued that the real question is which 200K tokens of a possible million earn their place. At 2K, that question gets much sharper. The relationship runs both ways. Decision models are good at retrieval’s own hardest jobs: reranking candidates, filtering passages and checking whether a source actually supports a claim. Two of the retrieval practices from that September piece, reranking and knowing when to stop, are a Choice and a yes-or-no question. The new piece can help you play the rest of the board. Here’s where Jevons comes back. When a decision costs a fraction of a cent and returns in milliseconds, enterprises won’t make the same decisions more cheaply. They’ll make far more of them. Every ticket, every retrieved chunk, every agent step gets scored, because now it can. More decisions mean more state to assemble, and retrieval quality at low operational and developer cost becomes the bottleneck. That’s the next test for my Pac-Man agents. I’m adding memory, including retrieving board states from past deaths when the current board looks similar. If the right memories make a fast planner smarter without making it slower, that’s the retrieval argument with a score attached. “Isn’t keeping every option open just model sprawl with a better name?” Not if the flexibility lives in the interface. Running every model at once is sprawl. Being able to swap one in an afternoon is flexibility. “Isn’t this just a zero-shot classifier?” Partly. What’s new is calibrated confidence at near-frontier accuracy, behind a standard API, at a price low enough to run on every row of a table. “A video game isn’t an enterprise workload.” Agreed. It’s a workload with a visible deadline. Plenty of enterprise workloads have deadlines too; they just don’t flash GAME OVER when they miss one. Nearly every benchmark in this category so far is vendor-reported, and TypeSafe’s own launch post notes its workflow evaluations were written by its own team. The pricing may be subsidized. A probability with no rationale is a real audit problem in regulated work, so expect System One models to route and screen rather than decide alone wherever someone has to explain why. And where a decision has no deadline, like a contract review or a quarterly forecast, three minutes is fine and the better answer should win. Fast doesn’t beat smart. Fast beats late. In the spring I said we were all playing LLM Tetris. The game turned out to be bigger than that. There are more piece shapes, they’re arriving faster and the board speeds up the longer you play. It’s broader, model Tetris now. The teams that win won’t be the ones who found the perfect piece. They’ll be the ones who know the shape of each decision, put a latency budget next to accuracy and cost, feed every piece the right state, and keep the board flexible enough for whatever comes next. And sometimes, as my code-planner keeps reminding me, the best piece on the board is an if-statement.