Chapter 1. The novelist who sorted mail
Imagine hiring a brilliant novelist to sort your mail. She is wonderful. She reads every letter with full attention, notices the trembling in the handwriting, and composes a thoughtful paragraph about each one. It is beautiful work. It is also not what you needed. You wanted two piles. Urgent over here, junk over there, and lunch before noon.
That small domestic scene is, strangely, the story of artificial intelligence in business over the last few years. Companies bought the novelist. They put her inside their software and asked her to judge things thousands of times a day, and she answered in essays. Every essay then had to be parsed, checked and forgiven by a patient engineer. It worked, sort of. It was also slow, expensive and just a little absurd.
On September 15, 2026, a young company called TypeSafe AI released a model that simply refuses to write the essay. It is called Jev, and it is the first public example of what the company calls a System One Model. Jev reads the letter. It tells you, in numbers, how urgent it thinks the letter is. Then it stops. This article is a long walk through what that refusal means: where the idea came from, what Jev is and what it very deliberately is not, how to actually use it in your own code, where it shines, where it stumbles, and what its arrival might change. Everything here is drawn from TypeSafe's launch post and documentation, from press coverage in TechCrunch, InfoWorld, InfoQ and the Wall Street Journal, from independent reviews, and from the wonderfully argumentative threads on Hacker News, and it reflects what was publicly known in the first days of October 2026.
Chapter 2. A broken heart at OpenAI
Every good technology story has a person at the center, and this one has Diogo Almeida. He worked at OpenAI on the methods that made language models follow instructions and talk pleasantly with people, research that fed directly into ChatGPT. By any normal standard that is a career peak. Yet he told TechCrunch something startling: "We have lightning in a bottle, and yet it is not useful." He described battling that feeling for years before reaching a conclusion. The industry had spent four years optimizing for human language, and human language is the wrong target, because computers speak a different language. Computers want a value they can branch on.
So two years ago he left and founded TypeSafe AI, along with co-founders Erik Gafni and Sasha Sheng, whose photo graced the TechCrunch piece. The company spent two years in stealth and emerged with 40 million USD in seed funding, a new architecture, a new training method, and a launch that briefly knocked their own API over because demand was so high. There is something almost old-fashioned about the pitch. No talk of digital gods. Almeida told TechCrunch that the main product of frontier labs is fear or hype, and that he would like his main product to be intelligence instead.
Even the names are doing quiet philosophical work. "System One" comes from Daniel Kahneman's Thinking, Fast and Slow, which divides our minds into the fast, intuitive System 1 and the slow, deliberate System 2. TypeSafe's argument is that chat models are System 2 machines, general and flexible and best with a human watching, while the inside of software needs System 1: fast, focused judgment. And "Jev" honors William Stanley Jevons, the nineteenth-century economist famous for the paradox that when a resource becomes cheaper, we do not use less of it. We use vastly more. Almeida expects intelligence to follow coal: every order-of-magnitude drop in cost unlocks orders of magnitude more uses. He told TechCrunch he imagines smart software everywhere, "much more like the early internet than the mega apps people are trying to build right now." Whether or not you buy the vision, you have to admire a founder who names his product after an economist's paradox about demand.
Chapter 3. What Jev is not, and why that is the point
It is worth spending a moment on the negatives, because most of the confusion about Jev comes from expecting it to be something else. Jev is not a chatbot. The documentation says plainly that System One models do not write replies, do not produce code, and do not generate explanations of their reasoning. Jev is not a smaller or cheaper LLM squeezed into a box; the company's own FAQ raises that question directly, though I will be honest that the answer text was not visible in the version of the page I could read. Jev currently accepts text only, which the docs define as strings, JSON objects and arrays of text. No images, no audio, no video. Not yet, as the docs put it, with the "yet" doing hopeful work. And Jev is not an oracle. It answers the questions you define. If you frame the wrong question, it will faithfully judge the wrong question.
Here is the part that takes a moment to sink in: every one of those absences is a feature. Because Jev never produces free text, it can never produce malformed free text. Because the possible answers are defined before the call, the answer after the call is guaranteed to be one of them. The launch post puts it in one clean line: think of Jev as a frontier-intelligence function call. Unstructured state in, typed probabilistic decisions out.
Chapter 4. State in, decisions out: how it actually works
The whole programming model fits in two words: state and questions. The state is whatever you want judged, a customer email, a transaction record, a description of a game board. The questions are what you want to know about it, written by you, in advance, in a fixed schema. The LangChain team published the cleanest example I found, and I will show it here as plain text rather than anything fancier:
POST /v1/systemone { "model": "jev-latest", "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.", "questions": { "is_urgent": { "type": "noul", "instructions": "The message conveys urgency or time-sensitivity" } } }
Look at what is missing. There is no prompt engineering, no "you are a helpful assistant", no pleading with the model to answer only in JSON. There is a piece of text and a question. What comes back is a probability that the message is urgent. Your code receives a number. Nobody parses prose at midnight.
The question types have names that deserve a small tour, because they are the entire vocabulary of the system. The first is the noul, TypeSafe's own coinage, which the CEO explained on Hacker News is short for Bernoulli: a yes-or-no quantity with a probability attached, such as "Does this message request a refund?" coming back as 0.95. The second is the choice, which picks among options you define, like routing a ticket to billing, technical or account, with a probability on each. The third is the score, which places the input on a scale you describe, such as 0 for calm, 1 for frustrated, 2 for very frustrated, possibly returning 1.4. The docs stress these are illustrative configurations, and the primitive pages hold the full details, several of which I could not fully read, so I will not invent fields.
The same CEO offered the most beautiful mental map of the whole thing, and I want to hand it to you exactly as he framed it. A choice corresponds to a match statement. A score corresponds to sorting. A noul corresponds to an if-statement. Sit with that for a second. Jev is not trying to be your program. It is trying to be the fuzzy little judgment inside your program, the one place where an if-statement used to give up because the world refuses to be an enum.
A fuller example, taken from a Hacker News comment quoting the Python SDK docs, asks three kinds of question about one message:
response = client.system_one(
state={"document": "I was charged twice. Please fix this ASAP."},
questions={
"billing": Noul(instructions="Is this ticket about billing?"),
"tone": Choice( instructions="What is the customer's tone?", criteria={"calm": None, "frustrated": None, "angry": None},
),
"urgency": Score( instructions="How urgent is this ticket?", criteria=["can wait", "this week", "today"],
),
},
)
print(response.nouls["billing"].noul)
print(response.choices["tone"].choice)
print(response.scores["urgency"].score)
Read it slowly and the design philosophy reveals itself. Three independent questions go out in a single call. The answers come back already sorted by type, each one a plain value ready for an if-statement, a routing table or a sort key. Notice where your effort goes as a developer: into the instructions and the criteria. Those few lines of description are the model's only picture of what you mean. Writing them well is the new prompt engineering, and we will come back to that craft later.
Chapter 5. The physics of cheap: speed, cost and calibration
Why is this fast? The answer is the most technically interesting part of the story, and it is worth understanding rather than just admiring. An LLM writes its answer one token at a time, each token conditioned on all the ones before it, like a speaker who cannot plan the sentence until each word has left their mouth. Long answers therefore take long times, and the launch post cites third-party measurements of 3 to 329 seconds for frontier models. Jev does not write. It evaluates. All of its outputs arrive in one parallel pass, in roughly 70 to 500 milliseconds end to end.
The cost follows the same shape. Jev charges 0.042 USD per million input tokens, which the company also states as 42 USD per billion, and output is free, "too cheap to meter" in their phrase. The comparison in the launch material puts LLM input at 0.20 to 10 USD per million tokens, with output around five times more expensive. Let us do the arithmetic together on a human scale, because this is where the idea stops being abstract. Suppose a support email plus your instructions comes to about 1,000 tokens. Triaging one email with Jev costs about 0.000042 USD. Triaging a million emails costs about 42 USD. A commenter on Hacker News spotted a subtler benefit: since output is free, you only ever have to estimate your input, so the bill is predictable in a way that LLM bills, with their variable output lengths and unpredictable reasoning, simply are not. One engineer inside TypeSafe worried during the Doom demo that making ten queries a second would be expensive. It worked out to roughly 7 USD an hour. The team reportedly concluded this was lower than expected, which tells you something about the new economics they think they are opening.
The third pillar is calibration, and it is the least flashy and the most important. Jev is trained with a method TypeSafe calls Reinforcement Learning for Calibrated Decisions, or RLCD, instead of the RLHF that powers chat models. The goal is that when Jev says 90 percent, it is right about 90 percent of the time. The docs are careful here: calibration is measured across groups of predictions and does not guarantee any individual answer. That honesty matters, because a calibrated probability is the raw material of automation. A model that does a task 95 percent of the time but never tells you which 5 percent it is unsure about cannot automate anything. A model that says "I am only 50 percent on this one" hands you the steering wheel back at exactly the right moment.
Chapter 6. Eight ways people are actually using it
Enough theory. Let us walk through the patterns, from the humble to the delightful.
The first and most common is ticket triage. Every message to a shared inbox gets asked the same small battery of questions: is it about billing, is the customer threatening to leave, how urgent is it on your defined scale. Then ordinary code takes over. High billing probability plus high urgency goes to the top of the billing queue. Everything murky goes to a human. The model never decides what happens; it reports what it sees, and your code decides, which keeps the whole system's behavior inspectable when something goes wrong at 3 a.m.
The second is the refund workflow, which is TypeSafe's own documented example and the clearest display of the core craft. The application builds a state containing the customer's message, the relevant transactions and the refund policy. It then asks three independent questions together: whether a refund was requested, whether the evidence suggests a duplicate charge, and whether the policy supports a refund. Deterministic code combines the answers and routes the case to action or review. Notice the move: instead of asking one enormous question, "Should we refund this person?", you ask three small ones, each easy to answer and each individually testable. Decomposition is the whole game. TypeSafe's launch post observes that reliable real-world workflows tend to have many independent, decomposed questions whose probabilities eventually feed a discrete branch. In my own sketch of the final step, the code refunds automatically when the duplicate-charge and policy probabilities both clear thresholds you chose, and escalates otherwise. You tune those thresholds against real outcomes. That tuning is engineering, and it is the kind of engineering TypeSafe believes the industry will now do a lot more of.
Pattern three is built on confidence, and Armin Ronacher, CTO of Earendil, described its psychology perfectly in TechCrunch: the design "delegates the hallucination problem a little bit to the user." A 50 percent answer is a coin toss; disregard it. A 95 percent answer is something you can act on. This is both a feature and a burden, and it deserves both words. A feature, because the uncertainty is finally visible instead of hidden inside confident prose. A burden, because someone has to choose the thresholds and the escalation path, and that someone is you. The docs suggest exactly the ladder you would expect: act when confident, escalate to a person or a reasoning model when not. Think of a hospital triage desk. The quick assessment handles the obvious cases and sends the ambiguous ones to the specialist. Nobody asks the triage nurse to perform surgery.
The fourth pattern is guarding another AI, and it comes with a real deployment story. Vercel engineer Pranit Sharma reported that Vercel had been using OpenAI's Luna 5.6 to run a classifier reviewing commands for safety; after swapping in Jev, results came back five to 18 times faster with greater accuracy, a story TechCrunch relayed. The logic writes itself. Before an agent executes a proposed shell command, ask Jev whether the command is destructive, whether it touches files outside the project, whether it matches the task at hand. That check costs a fraction of a cent and a fraction of a second. Almeida himself argues that using LLM agents to watch other LLM agents gets expensive fast, while Jev makes the watching affordable, including watching agent traces and catching jailbreak attempts. There is something quietly funny about the arrangement: the expensive, eloquent model does the work, and the cheap, silent one holds the leash.
Routing is covered by pattern is pattern five. Modern applications often choose between a cheap model and an expensive one, and the choice itself needs a little intelligence. Ronacher pointed out that asking an LLM to make that call on every request is too expensive to be practical, while Jev's speed makes it trivially affordable. The analysts quoted by InfoWorld generalized the same thought: Jev sits beside the general-purpose models, which keep the open-ended reasoning, summarization and conversation, while Jev handles the frequent structured decisions, routing, scoring, verification and policy checks. One analyst offered a simile I cannot improve on: using a general LLM for a yes-or-no routing question is like using a full enterprise service bus for it.
In pattern six things get playful, and it shows Jev as a real-time decision maker. A Hacker News user built a browser agent in which the available actions are a menu of ten to forty clickable elements from the page's accessibility tree, and Jev picks one element per step. On six benchmark cards it made 21 to 23 decisions, all correct by the author's report, at a total cost of about 0.001 USD. The one thing it could not do was write the text for an input field, so a small language model handles typing whenever Jev chooses "type". That division of labor is the architecture in miniature: Jev picks, a generator writes, each doing the job it is shaped for. Another user built a chess opponent where the backend lists every legal move and Jev scores them in one pass, roughly 300 milliseconds and 0.00004 USD per move. The legal moves come from ordinary code, so the model can never suggest an illegal one. That is type safety earning its keep.
TypeSafe's own demos push the same idea to theater. In the Wikirace demo, the bot hops between Wikipedia pages by choosing among hundreds or thousands of links per step. The launch post mentions a cardinality limit of up to 255 options per question, so bigger menus use a two-stage system, scoring candidates independently and then making an explicit choice, which explains an occasional slowdown. The Doom demo has Jev playing the game in real time from a structured text description of the game state. The company is candid about the fine print: the input is structured state, not pixels, and a purpose-built non-AI bot would play better. Critics on Hacker News added that the state hands Jev information, like enemy coordinates, that a human player never gets. Fair enough. The demo proves latency and cost, not vision. It is a sports car on a test track, not a cross-country road trip.
The seventh pattern is counterintuitive: using Jev to decide what another model should see. TypeSafe engineers described on Hacker News the opportunity in context management, asking "do we really need to pass all these tokens to the agent?", and in semantic linting, scoring a change against the rules in an AGENTS.md file. A cheap, fast judge filters which context deserves the expensive model's attention. One caution comes from DigitalOcean's explainer: for coding-agent context compaction, Jev can undercut savings that prompt caching already gives you. The honest advice is boring and correct. Do the arithmetic on your own traffic before assuming the win.
Last but not least, the eighth pattern is bulk thinking. The launch post mentions map-reducing over big data, and the picture is vivid: a million product reviews, each asked whether it mentions a defect, which part it concerns, and how angry the writer is, producing a table of numbers you can actually chart. Hacker News commenters sketched lighter versions, ranking a thousand articles to surface the five most relevant, or stripping content that regional privacy laws forbid. These are sketches, not shipped products, but they show the direction of people's imaginations, and imagination has a way of becoming roadmap.
Chapter 7. Getting your hands on it
If you want to try it yourself, the doors are these. Early access runs through console.typesafe.ai, where the launch post says developers are being pulled off the waitlist as fast as possible. The eesel review notes you can call it through Cloudflare Workers AI under the model id typesafe/jev, and DigitalOcean lists it in its model catalog. LangChain users get a tidy integration, importing Noul and TypeSafeClassifier from langchain_typesafe, calling classifier.invoke with a state and questions, and reading the probability back off the response. TypeSafe also published an open source adapter that wraps ordinary LLMs to return decisions in the same format, which is how they ran their comparison models, and one of their engineers posted a DSPy fork that automatically routes suitable calls to TypeSafe. One Hacker News commenter observed that the API shape differs from the familiar OpenAI chat interface, so it will not drop into an existing chat client unchanged. That friction is real, and it is also the point: this is a different instrument, and it asks you to hold it differently.
As for the craft of writing good questions, the documentation's advice, quoted approvingly even by a critic on Hacker News, is to keep each score to one dimension. If a description says "punctual and smart and experienced", you are measuring three things at once; confidence drops and the score means less, so split it into one score per quality and combine them in code. The same spirit applies everywhere: make choice options mutually exclusive where you can, describe them as you would to a smart stranger, and keep the state focused on what matters. And here is my favorite pragmatic suggestion, offered by a Hacker News commenter and blessed with an "exactly right!" from the CEO: use a chat LLM interactively to help design and refine your Jev configuration, then let Jev run that configuration in production. The novelist designs the filing system. The sorter works the mail room. Everybody is doing what they are actually good at.
Chapter 8. The arguments against, taken seriously
Now the part where we take the skeptics seriously, because they earned it.
Start with the loudest claim: Jev "can't hallucinate." The narrow version is true and guaranteed by construction, since the output must match your schema and can never be a malformed type. The broad version is not true, and the critics were quick and correct: the model can still return a wrong value that is perfectly valid, and as one commenter put it, type safety is not factual correctness. The eesel review called the claim half true and oversold. Even TypeSafe's defenders framed it more carefully, arguing that a whole category of failures, the ones born from long sequential generation, is structurally removed, which is different from the answers always being right. To its credit, TypeSafe's own hallucination chart marks its 0 percent figure as not empirical, guaranteed by schema rather than measured, and notes that the LLM comparison figures came from OpenRouter data that almost certainly carries its own bias.
The second concern is the evidence itself. The homepage numbers, 193.6 times faster and 444.6 times cheaper, come from TypeSafe's own workflow evaluations, and the company says it expects them to be on the higher end of real-world gains. The evaluation method uses the average predictions of two top models, GPT-6 Astra and Fable 5.1, as the reference answer, which measures agreement with the strongest models rather than agreement with truth, a subtlety that baffled at least one Hacker News reader. The workflows were built by TypeSafe's own capabilities team, and the post admits bias could exist. The speed runs were measured from laptops on the US West Coast, where the service lives. Independent, third-party benchmarking, as DigitalOcean's explainer puts it, is still emerging. One commenter was openly wary of a company reluctant to publish on public benchmarks, and the FAQ entry on that question was not readable in the version I retrieved, so I genuinely do not know TypeSafe's answer. I would rather tell you that than guess.
The third concern is scope. Jev cannot write, and much of what people love about LLMs is the writing. A commenter compared it to a calculator: faster and cheaper for the tasks you confine it to, but the comparison to LLMs misleads if it implies equal generality. The original Hacker News submission title, which crowed about a new frontier model, drew enough complaints that it was changed. A user who tried to coax Jev into completing a Lisp function reported it was not capable enough. A participant in a code-review thread called it a low-level classifier and advised against using it for code review. This all rhymes with the design. If a task needs patient multi-step thought, that is what reasoning models are for. The InfoWorld analysts added two enterprise-flavored worries: specifying questions, outputs, thresholds and escalation paths in advance is real work, and the service currently runs hosted in a single region, which matters for data residency and for latency far from that region.
The fourth concern is the black box. Almeida is tight-lipped about the architecture; TechCrunch reports that outside observers suspect it is built on top of an open-weight LLM, while Almeida says it is trained exclusively on synthetic data, a bet he called better than the launch itself. I cannot confirm either claim, and no architecture paper has been published that I could find. One Hacker News commenter who had built similar classifiers on a 4-billion-parameter open model asked whether Jev is essentially a transformer with a learned readout over predefined options and no decoding. It is a plausible guess, and I do not know if it is right. The pricing carries its own asterisk too: TypeSafe says it cannot prove the prices are not subsidized, expects them to fall rather than rise, and has no standalone pricing page or tiers yet.
The fifth concern is the most interesting, because it is philosophical. Is any of this new? One thread argued that Jev is a generic classifier, a descendant of the random forests and logistic regressions of fifteen years ago, and that a custom-trained model would beat it on any specific task. That is probably true when you have labeled data and a fixed problem. The reply was equally true: many teams have a dozen different judgment calls, no training data, contractual bars on training with customer data, and no time. For them, a zero-shot model with broad world knowledge is not a worse classifier; it is the only classifier they will ever actually deploy. And as another commenter noted, TypeSafe never claimed to be the only humans interested in schema-guided classification. The claim is narrower and more interesting: a training method that gets far higher general intelligence into this shape, at far lower cost. Whether that claim fully holds is exactly what the coming months of independent tests will decide.
Chapter 9. The copycats, and the shape of what comes next
The market voted with unusual speed. Within days of launch, an open source model called Laya appeared, described in a Medium write-up as a 421-million-parameter ModernBERT-large encoder with a typed decision head; a Regolo analysis lists variants from 322 to 421 million parameters supporting more than 100 languages, while noting that its base checkpoints need task-specific fine-tuning to cure out-of-the-box overconfidence. The same analysis lists OpenJev, a diffusion language model with 4 billion active parameters that can act as a drop-in Jev API proxy. DataCamp counted seven open alternatives by early October: Laya, Nimble, Kev, SemIf, Rizzo Flow, Von and NanoJev. A Reddit post claims Von beats Jev on some tests while running on a CPU, a self-reported result nobody has independently checked. History runs deeper than the launch, too: commenters noted an earlier project behind Laya going back about a year, with a 2025 research paper linked as prior art. On October 2, the Wall Street Journal framed the whole moment as Jev sparking copycats and talk of LLM alternatives. The open versions answer a complaint worth hearing: a product whose entire selling point is speed sits awkwardly behind a network call, and local execution removes that tension.
So what comes next? TechCrunch reports TypeSafe is building more versions of the model, in new modalities, and Ronacher expects competitors to multiply now that the utility is visible. His explanation for why nobody did this sooner is the kind of line that lingers: LLMs are so cheap and subsidized that you often do not have to be creative yet. Commenters sketched hybrid futures where a Jev-like model acts as a fast nervous system, escalating hard cases to slower, deeper thinkers, and the InfoWorld analysts expect enterprises to start with internal automation where gains are measurable and risk is contained. My own modest prediction, and I mark it clearly as mine: the lasting legacy will not be the brand but the interface, the idea that software asks models typed questions and receives calibrated probabilities as naturally as it receives rows from a database. One commenter wondered whether TypeSafe's API shape might become a standard the way OpenAI's once did. That is speculation, and I cannot say.
A few honest confessions before we close. I do not know what Jev is built on, nor exactly how its parallel sampler works. I do not know how it performs on independent benchmarks across many languages, whether a self-hosted version is planned, how long free output and current prices will last, or the full response schema for a choice distribution. And one correction to my earlier telling deserves the light: the sources say a single choice question supports up to 255 options, while I previously wrote that up to 255 questions could be asked in one call, which the sources do not firmly support. The 32,000-token context window comes from the eesel review and a Hacker News comment rather than from a TypeSafe page I read directly.
Epilogue. The sorter and the novelist
If you remember one piece of practical advice, let it be this. Use Jev where you have a frequent, bounded decision that a person would make with a glance. Write small, sharp questions. Let ordinary code own everything that must be exact. Treat the probabilities as the real product, set thresholds from your own data, and send the uncertain cases up the ladder. And run your own head-to-head against whatever you use today before believing any speedup figure, including, perhaps especially, the ones from the people selling the sorter.
The novelist is not fired. She was never meant to sort mail. She writes the letters, the sorter flies through the trays, and for the first time the mail room runs on something honest: a machine that tells you, in numbers, exactly how sure it is.
No comments:
Post a Comment