Kahneman used System 1 as a metaphor for fast, intuitive thinking. TypeSafe turned that idea into a new AI product category, and within a week, the Java community was already building frameworks, Spring Boot starters, and debating what to name the interface.
Fair warning: I had way too much fun with this one today, so we’re getting the meme edition 😃. Old good times.
On 15 September TypeSafe AI launched Jev, in early access. Its founder Diogo Almeida calls it the first System One model, “a new class of frontier models built to make fast, structured decisions that software can use directly”.
A word on the other name first, because it briefly shorted my brain. This TypeSafe is not that Typesafe. The old one was the company Martin Odersky and Jonas Bonér founded around Scala and Akka in 2011, which became Lightbend in 2016 and goes by Akka today, a rename I wrote up back in vol. 109. So for a few seconds on 15 September I thought Scala’s old parent company had shipped a decision model.
Start with what it does. Jev does not hold a conversation. There is no streaming, no tool calling, no message history and no text coming back. You send one request containing a 𝚜𝚝𝚊𝚝𝚎, which is any text or nested JSON, and a map of named questions to ask about that state. All the questions get evaluated against the same state in parallel, and you get typed answers back.
There are three question types. A 𝚗𝚘𝚞𝚕 asks a yes/no question and returns the probability that the answer is yes. A 𝚌𝚑𝚘𝚒𝚌𝚎 picks one option from a set you defined up front. A 𝚜𝚌𝚘𝚛𝚎 rates the state against named, ordered levels. Choice and score answers also carry a calibrated confidence, which is a separate number from the probability and is meant to tell you whether to act on the answer at all.
The wire format is one endpoint:
POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/json{
"state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
"model": "jev-latest",
"questions": {
"urgency": {
"type": "noul",
"instructions": "Does this message express urgency?"
}
}
}That request body is lifted from the quickstart, and it is all the API you need for the rest of this issue.
The numbers TypeSafe puts on it: end-to-end response time of 70ms-500ms, input at “$0.042 / MTok ($42 per billion tokens)”, and output priced at “FREE (too cheap to meter)”. The claim the post leans on hardest is a structural one rather than a benchmark: “The model never makes type errors. All answers are accompanied with calibrated probabilities and confidence scores.” You are not asking a model to emit JSON and hoping it honours your schema. The schema is the request.
TLDR for Breaking Bad fans:
or even better for Rick & Morty fans (found on x.com):
If you have ever written the intent classifier at the front of a support queue, or the @𝚅𝚊𝚕𝚒𝚍 guard that decides whether a document goes to a human, this is the shape of thing that is being sold to you. You would previously have done it with a chat model, a carefully worded prompt, structured output mode and a parser that you do not fully trust.
TypeSafe does not hide where “System One” comes from. The concepts page has a note:
The System One name comes from the concept Daniel Kahneman popularized in his book Thinking, Fast and Slow. System 1 thinking is fast and intuitive. System 2 is slower and more deliberate. Here, the emphasis is on fast, focused judgments.
“Popularized” is accurate. Kahneman took the labels from Keith Stanovich and Richard West, who proposed them in 2000, so the name on the invoice is a second-hand borrowing, and it comes with a warning. And now in that crazy AI-driven world it become a product category. Worth knowing before you use the word in a design review.
Okay, let’s put our engineering hats back on and dig into how all of this actually works.
Kahneman’s System 1 runs automatically and fast, with no sense of effort and no experience of having chosen. Answers arrive rather than being computed. Jev behaves the same way from the caller’s side: you get a value back inside the latency TypeSafe advertises, with no reasoning trace and nothing to read.
The analogy breaks down when it comes to confidence. Kahneman’s System 1 makes fast judgments but often overestimates how reliable they are. Jev is designed to avoid this problem. It returns fast, structured answers with calibrated probabilities and a separate confidence score to help your application decide whether to use the result. The goal is to deliver System 1’s speed with measurable reliability.
Calibration measures model performance across many predictions. It does not guarantee that an individual prediction is correct. As TypeSafe’s documentation states, “Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct.” For example, if a well-calibrated model assigns a 90% probability to 1,000 predictions, approximately 900 should be correct. However, you cannot know whether a specific prediction is one of them. Your application must handle this uncertainty before taking action.
This is where System 2 comes in. In Kahneman’s model, System 2 evaluates and checks the results of System 1. In TypeSafe’s architecture, your application takes on this responsibility. Jev provides fast, structured predictions. Your Java application must provide the context, apply business rules, check confidence thresholds, and handle uncertain results. It must also decide whether to accept the prediction, request human review, or reject it. Jev provides input to the decision, but your application remains in control.
TypeSafe is language-agnostic in the most literal sense: if there is no SDK for your language, you can always speak HTTP.
The platform provides first-class SDKs for Python and JavaScript/TypeScript. For Java and Kotlin, the client SDK documentation has a single answer: call the HTTP API directly.
And this is not just a missing convenience wrapper. The documentation contains extensive Python API references and detailed JavaScript documentation, but no Java page, no Kotlin page, and essentially no JVM-specific guidance. For JVM teams, “language agnostic” effectively means “bring your own client.”
And community did - several times over, in parallel.
By the end of Tuesday 22 September, a GitHub repository search for Java projects mentioning Jev and TypeSafe returned twenty-three results, and it went up three times while I was writing this issue. Twenty-two of them were created between 17 and 22 September 2026. The twenty-third is 𝚝𝚒𝚗𝚢𝚜𝚝𝚛𝚞𝚌𝚝, a framework from 2017 that added a TypeSafe SDK module last week.
First out, at 17:03 UTC on 17 September, was sava-software/typesafe-client, a plain Java client for the endpoint. Two and a half hours later came something that is not a client at all, Vicente-MD/jev-resilience, a use case with a client inside it. Standard circuit breakers see 5xx responses, timeouts and connection errors, and they are blind to a 𝟸𝟶𝟶 𝙾𝙺 whose body contains a stack trace or a “system under maintenance” notice. This starter runs each WebFlux response past Jev and turns a suspected silent failure into a 𝚂𝚎𝚖𝚊𝚗𝚝𝚒𝚌𝙵𝚊𝚒𝚕𝚞𝚛𝚎𝙴𝚡𝚌𝚎𝚙𝚝𝚒𝚘𝚗, ordinary enough to register in a Resilience4j 𝙲𝚒𝚛𝚌𝚞𝚒𝚝𝙱𝚛𝚎𝚊𝚔𝚎𝚛. It fails open, so a Jev outage cannot trip your breaker. On JitPack as 𝚌𝚘𝚖.𝚐𝚒𝚝𝚑𝚞𝚋.𝚟𝚒𝚌𝚎𝚗𝚝𝚎-𝚖𝚍:𝚓𝚎𝚟-𝚛𝚎𝚜𝚒𝚕𝚒𝚎𝚗𝚌𝚎:𝟶.𝟷.𝟷.
Over the next two days came Olti1947/jev-java, Premo-Cloud/typesafe-sdk-java and gudcks0305/jev-java, each one an independent take on the same two hundred lines of HTTP plumbing. Among the rest are an MCP server, Ashfaqbs/jev-mcp-spring, a confidence-based API gateway and a Spring Boot bookstore demo.
Sometimes people complain that there are too many AI-generated graphics in this newsletter, so this time you get a 100% human-generated graphic. I used about 110% of my Paint and Canva skills to bring you this masterpiece ⬇️
Then on 20 September the projects got official support.
At 00:54 UTC on 20 September, Dan Vega, Spring Developer Advocate at VMware Tanzu, published jev-spring-boot-starter. Spring Boot 4.0+, Java 17+, Spring MVC, 𝚁𝚎𝚜𝚝𝙲𝚕𝚒𝚎𝚗𝚝, Jackson 3. Add a dependency, set 𝚃𝚈𝙿𝙴𝚂𝙰𝙵𝙴_𝙰𝙿𝙸_𝙺𝙴𝚈, inject a 𝙹𝚎𝚟𝙲𝚕𝚒𝚎𝚗𝚝:
var response = jev.evaluate(message, Map.of(
"team", Question.choice("Which team should handle this?",
"billing", "integrations", "support")));
return response.choice("team").choice();Twelve hours later, Christian Tzolov, Spring AI lead at Broadcom, pushed spring-ai-community/spring-ai-typesafe, and this one is built like something that intends to stay. Four modules and a set of examples: 𝚝𝚢𝚙𝚎𝚜𝚊𝚏𝚎-𝚓𝚊𝚟𝚊-𝚜𝚍𝚔 is the plain client with no Spring AI dependency, 𝚝𝚢𝚙𝚎𝚜𝚊𝚏𝚎-𝚜𝚙𝚛𝚒𝚗𝚐-𝚊𝚒 carries the integrations, 𝚜𝚙𝚛𝚒𝚗𝚐-𝚊𝚒-𝚜𝚝𝚊𝚛𝚝𝚎𝚛-𝚝𝚢𝚙𝚎𝚜𝚊𝚏𝚎 gives you auto-configuration under 𝚜𝚙𝚛𝚒𝚗𝚐.𝚊𝚒.𝚝𝚢𝚙𝚎𝚜𝚊𝚏𝚎.*, and 𝚝𝚢𝚙𝚎𝚜𝚊𝚏𝚎-𝚋𝚘𝚖 holds it together. The middle module wires Jev into Spring AI’s own SPIs as an LLM-as-a-judge, a guardrail, a RAG post-processor and a tool index. The API models the three primitives as types:
SystemOneResponse response = typeSafeClient.systemOne(
"Help! My payouts have been failing for 3 days.",
Map.of(
"is_urgent", Noul.of("Does this convey urgency?"),
"department", Choice.builder()
.instructions("Which team should handle this?")
.option("billing", "Payments, invoicing, refunds")
.option("technical", "Bugs, outages, integrations")
.option("sales", "Pricing, upgrades, new accounts")
.build(),
"frustration", Score.of("How frustrated is the customer?", "Calm", "Frustrated", "Very angry")));All four artifacts went to Maven Central as 𝟶.𝟷.𝟶 on 20 September at 14:22 UTC, under the 𝚘𝚛𝚐.𝚜𝚙𝚛𝚒𝚗𝚐𝚊𝚒𝚌𝚘𝚖𝚖𝚞𝚗𝚒𝚝𝚢 group. Five days after the model was announced, you can put a Jev client on your classpath from a release version, from a repository your build already trusts, with a reference documentation site attached.
To get a sense of how fast this is moving, look at LangChain4j.
On 19 September at 21:48 UTC, Stefano Maestri of Red Hat opened langchain4j#6468: “Proposal: JudgeModel, a core abstraction for typed batch judgments.”
The argument was simple: the existing abstractions do not quite fit. ChatModel gives you one prompt-shaped interaction at a time, with criteria buried in text and no calibrated confidence. ScoringModel gives you essentially scoreAll(texts, query) -> List<Double>: one relevance dimension, no named heterogeneous questions, no confidence. ModerationModel comes with a fixed safety taxonomy.
What Maestri wanted was something else: a typed decision primitive.
And he was explicit that it should not belong to TypeSafe:
“The immediate driver is TypeSafe AI’s System One API and its model Jev, but the abstraction is provider-neutral: judgment APIs can implement it natively, and any ChatModel with structured outputs can emulate it.”
Then things moved at open-source speed.
PR #6469 appeared in the same minute as the issue: 16 files, +1,293 lines.
The companion integration issue, langchain4j-community#796, appeared in that same minute too, proposing a TypeSafeJudgeModel. The provider PR, #797, followed with the delightfully Java-specific implementation detail:
“No official Java SDK exists, so per the contributing guidelines the client is implemented with langchain4j-http-client + Jackson and package-private DTO records.”
So far, so normal. Then Java reached its natural endgame: naming the interface.
Two days later, Max Rydahl Andersen of RedHat arrived with the obvious question:
“Should this not be called a DecisionModel rather than a JudgeModel? Judging is a special case of Decisions.”
And suddenly the interesting problem was no longer how to integrate Jev.
It was whether the thing was a judge, a decision model, a structured decision model, or a System One model.
Andersen’s objection was substantive. Calling it a JudgeModel, he argued, makes it sound like an LLM-as-a-judge: something that reasons through an answer, produces explanations, perhaps exposes traces. Jev is designed almost in the opposite direction. It gives narrow, structured predictions without pretending to be a miniature deliberative agent.
Maestri then walked through the alternatives. StructuredDecisionModel is close to OpenRouter’s terminology. SystemOneModel matches Spring AI, but sounds suspiciously like a product name escaped into an interface. Plain DecisionModel has the opposite problem: it is beautifully generic, and therefore already means several other things, including in OODA-related terminology.
Then Georgios Andrianakis from the Quarkus team dropped in, pointed at the Spring AI implementation, and pulled Dmytro Liubarskyi into the discussion.
Why am I telling you about this discussion? Because there’s a nice bit of irony in it:
Phil Karlton was right - nowadays, there seem to be only two hard things in software.
Wrapping up, if you build to Native Image, the hints are not in the libraries yet. None of the clients ships a 𝚛𝚎𝚏𝚕𝚎𝚌𝚝-𝚌𝚘𝚗𝚏𝚒𝚐.𝚓𝚜𝚘𝚗 or a 𝚁𝚞𝚗𝚝𝚒𝚖𝚎𝙷𝚒𝚗𝚝𝚜𝚁𝚎𝚐𝚒𝚜𝚝𝚛𝚊𝚛, which in libraries this young is less a scandal than the next item on the list. What exists instead is a worked example. On 21 September Alina Yurenko 🇺🇦 , developer advocate for GraalVM at Oracle, published jev-graalvm, a weather app that asks Jev one 𝙲𝚑𝚘𝚒𝚌𝚎, one 𝙽𝚘𝚞𝚕 and one 𝚂𝚌𝚘𝚛𝚎 about whether you should go outside. It sits on Open-Meteo and on Tzolov’s 𝚘𝚛𝚐.𝚜𝚙𝚛𝚒𝚗𝚐𝚊𝚒𝚌𝚘𝚖𝚖𝚞𝚗𝚒𝚝𝚢 artifacts.
I have not seen the JVM move like this before. Not for a language release, not for a framework, not for anything I have written up in this newsletter. Twenty-two repositories in six days. Two Spring starters twelve hours apart. Four artifacts on Maven Central five days after the announcement, and an abstraction proposed in LangChain4j before most people had a key. Everybody was racing to be first, and nobody was waiting to find out first at what.
That is the strange part, and it is why I find this fascinating rather than silly. Jev arrived as a solution looking for a problem, and it has been looking in public since day zero. jev-use-cases.com, an independent directory built by QikBuild, already lists 685 of them: 261 agents, 159 search and data, 119 creative and real-time, 82 safety and review, 64 computer use.
The model is still invite only. None of that slowed anybody down.
...kinda. But it’s also cool as hell what’s happening.
Some words from me at the end: I spent this week’s evenings on the other end of this.
kNES is my NES emulator in Kotlin, and the part I actually work on is an agent that plays the games. The emulator steps forward a frame at a time, the agent reads the console’s memory, decides which buttons to hold, and every run can be replayed afterwards. The model driving it is a small one, four billion parameters, running on my own machine.
On 16 September someone published alexdong/typesafe-mario, a Jev harness that plays Super Mario Bros the same way, and its demos play visibly better than mine. So I went to find out why.
And I got some pretty interesting results.
Two things are the same in both and are not the answer: both decide once every eight frames, and both offer the model the same seven canned moves, matching almost name for name. The difference is who does the thinking. Their code does the looking and the timing, and the model only confirms. Jev never sees a screenshot. Their harness reads the console’s memory and turns it into a description: where the ground is, where the next three enemies are and how many frames until they reach Mario, whether the jump he is already in will clear the gap, and how long the round trip to the model actually took. Then the prompt says it outright:
Code has already accounted for inference delay, action cadence, and the frames needed to clear an enemy. If 𝚓𝚞𝚖𝚙_𝚖𝚞𝚜𝚝_𝚜𝚝𝚊𝚛𝚝_𝚝𝚑𝚒𝚜_𝚍𝚎𝚌𝚒𝚜𝚒𝚘𝚗 is true, choose a forward jump now.
The model is not being asked what to do. It is being asked to agree. That is the System 2 half of the bargain from earlier in this issue, written out as a paragraph of prompt.
For me, that’s the lesson here: be careful when a Jev demo looks too good 😉.
But don’t read this as me saying the models aren’t useful. They are essential here. Without them, none of these approaches would be playing the game in the first place. Ask an LLM for a decision and you are asking for text that then has to parse: a retry when the JSON comes back malformed, a fallback when a field is missing, a clamp when it invents a button the controller does not have. Every one of those costs frames. It is why the demos I gave at GeeCON were Final Fantasy and not Mario.
A turn-based RPG waits for you. Mario does not, and by the time a second attempt at valid JSON arrives he has already walked into the Goomba. A typed decision has none of that machinery, because there is nothing to parse and nothing to retry, and that is the whole reason Mario is playable at all now.
Playable well is a separate question. I ran SemIf, the open alternative from earlier, on the same harness, and it did worse than the Jev one. It still plays better than my wife.
And now everyone is already saying that Open Jev means Jev is so yesterday. All the cool kids have moved on to Laya... I heard.
PS2. The consolation is that we can still take them in a fair fight. Brood War Bench, which Benjamin Swerdlow published on 19 September, put nineteen agent configurations into a round-robin of StarCraft: Brood War, 361 matches in total. Codex Astra at xhigh went eighteen and zero. Swerdlow’s own summary of the entire tournament:
A beginner playing photon rush would win every single one of these games.
He adds that “None of the models played beyond a beginner level.” Claude Fable “seemed more interested in actually playing the game than any of the other models”, which I have decided to read as a compliment, and Haiku lost all sixteen of its matches.
So AI can be still Zerg-rushed... good to know.
PS3. Then there is the other kind of game. Baba Is Bench, which Piotr Migdal and Piotr Grabowski run on the puzzle game Baba Is You, tells the opposite story. Baba Is You is the one where the rules are blocks lying on the floor and you win by pushing them around to rewrite them, and it is turn-based, so nothing is waiting on a clock. There the models are excellent. Claude Opus 5 passes the intro stages at 100%.
Put the three together and the pattern is not flattering. A real-time platformer is playable only when your code does the thinking and the model just agrees. A real-time strategy game is lost to a beginner with a photon rush. Give them a turn-based puzzle where the rules themselves are the pieces, with as long as they like to think about it, and they are flawless. The only thing keeping us ahead is the clock, and the clock is the part of this that keeps getting cheaper. We are all going to die ;)
PS4: JVM Weekly in strange places - Greetings from the Zurich Airport.
PS5: As I mentioned Brood War, it’s time for “The Last Days of Lordaeron”. Anyone playing?