Study Notes / 2026 ・ No.03
Jev Field Notes
A model that writes nothing — where it fits and how to call it
Published
The questions this note answers
The short answer to Q1: yes — and that is the shape of the model, not a limitation
In September 2026, TypeSafe AI released a model called Jev.
What makes it different from everything before it: it does not write.
First what that means, then the three questions above.
A model that writes nothing
Jev does not generate text. It returns one of the choices, scores or yes/no answers you defined in advance, with probabilities attached. Its makers call it a “System One” model — intuition rather than reasoning.
It comes from TypeSafe AI, founded by Diogo Almeida, formerly of OpenAI and a co-author of the InstructGPT paper — the origin of the RLHF in No.01, chapter III. His own description of Jev: “think of it as a smart if statement”.
the same input, and what comes back has a completely different shape
Ask an LLM to classify a ticket and you get prose. Ask for JSON and the length and shape are still the model’s to choose, so you validate the result every time. Jev has no ability to emit a string at all. What comes back always fits the type you defined.
You will see “zero hallucinations”. Precisely, that is a guarantee that the schema holds: no answer outside your options. It is not a guarantee that the chosen answer is right, and the 0% figure is not an empirical measurement.
Why it is fast and cheap
An LLM writes one word at a time (No.01, chapter I): a hundred words means a hundred passes. Jev writes nothing, so that loop is absent. The output is not merely short; the mechanism producing it is different.
| Item | Published figure |
|---|---|
| Latency | 70–500ms end to end |
| Price | $0.042 per million input tokens. Output is free |
| Context | 32,000 tokens |
| Input | Text only (no images, audio or video) |
| Training | Synthetic data only. RLCD, reinforcement learning for calibrated decisions |
Output tokens are free because there is not enough output to bill for: a handful of probabilities and a confidence value. It is the same reason the price is quoted per billion rather than per million.
You will also see “193.6× faster and 444.6× cheaper”. Those come from TypeSafe’s own evaluations against comparison models they chose. The order of magnitude looks real enough, but treat it as something to re-measure on your own data.
state and questions — the answer to Q1
Yes. Without a state and a set of options it does nothing. But that is less a constraint than the way the model is used: writing down what it should look at and what it is being asked is what using Jev consists of.
Two things go in
The API takes state (what to look at) and questions (what to ask about it).
state is whatever you want the model to look at: a string, an object or an array, and structured data can go in as is. The example passes a subject, a body and a plan tier.
Three kinds of question
| Type | What comes back | Limits |
|---|---|---|
| Noul | probability of yes, from 0 to 1 | — |
| Choice | the chosen option, every option’s probability, a confidence | up to 255 options |
| Score | a probability-weighted value over levels, plus per-level probabilities and a confidence | 2–10 levels |
Every type takes instructions — what is being asked. criteria is optional and explains what each option or level means. Names differ across SDKs: Vercel’s AI SDK calls the yes/no type boolean.
What comes back
This is the real difference from an LLM. The probabilities of the options that were not chosen come back too, and confidence arrives separately. So “probably billing, but not sure” is a state your own code can read.
the “smart if statement” is this branch
High confidence, handle it automatically; low confidence, hand it to an LLM or a person. The threshold lives in your code; the model only supplies the material for it. That division of labour is the design.
Using it to test a web page — the answer to Q2
Start with the premise: Jev does not drive the browser. Playwright or equivalent does the acting; Jev looks at the current screen and judges what to do next and whether the step passed.
your code acts, Jev judges, and the loop repeats
What goes into state
This is the heart of the question. Do not hand it raw HTML. The context window is 32,000 tokens and a real page’s DOM passes that quickly. What goes in is a summarised screen.
- goal and expected — what is being verified. Without it there is nothing to judge pass or fail against
- step and history — which step this is and what has happened. This is how a loop gets detected
- page — URL, title, the visible text, and the wording of any alert or toast
- actions — the clickable elements. This list is the set of options
Pass the accessibility tree or visible text rather than the DOM. Asking yourself what you would say if you had to describe this screen to someone over the phone gets the level about right.
Shaping the questions
| Question | Type | Purpose |
|---|---|---|
| nextAction | Choice | which of actions to click |
| expectedMet | Noul | did this step do what was expected |
| stuck | Noul | are we going in circles (when to give up) |
| severity | Score | how bad the deviation is, on a rubric you define |
nextAction allows at most 255 options, so a page with more clickable elements than that needs narrowing in code first.
Assertions you can write in code should stay in code. “Does the button exist” and “is the status 200” need no model. Jev earns its place on the judgements that are tedious to write down: “would a user understand this error”, “does this look like the checkout page”.
Screenshots cannot be passed (text only). If appearance itself is the thing under test, have a model that reads images describe it first, and put that description into state — two stages rather than one.
Can it trade stocks — the answer to Q3
Technically yes, and examples appeared within days of release. But Jev carries only a small part of the whole; what decides the outcome is usually the code around it.
Within a week there were bots judging order-book state roughly every 300ms, designs holding separate positions per instrument, and paper-trading variants. Calmer uses were reported too: direction prediction on Hong Kong equities, and banking-intent classification at 92.4% accuracy.
the shape the examples share — everything either side of Jev is code you wrote
What they have in common: a state compressed to around 400 tokens, and a policy in your own code that acts on the returned probabilities. Jev does not go and look at the market. Which features to build and how to compress them is entirely your work.
What to watch
- Calibration is not accuracy — a calibrated 0.7 means about 70% right on the distribution it was trained on. Markets are non-stationary and adversarial. That is outside the distribution
- 70–500ms is fast for a model — and far too slow for anything that competes on speed
- Text only, 32,000 tokens — no chart images, and history cannot be poured in without limit
- It is probabilistic — the same input need not give the same answer. Loss limits and position caps are rules that belong in code, not in a model
- The benchmarks are vendor-run — measure the speed and cost claims in your own setup before relying on them
We are not in a position to give investment advice. What is written here is about the mechanism, not about whether to buy or sell. That most of the published examples default to dry runs and paper trading is telling.
Choosing between the options
Jev is not a replacement for an LLM. The difference in No.02, chapter I — what the model was asked to predict — is exactly the difference in what each is good for.
| Approach | Training data | Speed | Same answer twice | Free-form prose |
|---|---|---|---|---|
| Rules | none | fast | always | no |
| Classical ML | required | fast | near always | no |
| Jev | none | fast | varies | no |
| LLM | none | slow | varies | yes |
One more promising use is Jev as a watcher over an LLM: before an agent calls a tool, have Jev judge whether that call is risky and block it if so. That looks like a practical answer to the compounding-reliability problem from No.01, chapter VI.
Where to start
The easiest thing to swap is a place where an LLM is already doing nothing but classification. The inputs and the expected outputs are already on hand, so you can run both over the same data and compare. Checking the speed and cost claims on your own ground is a good first move.
§ One page summary
- Jev writes nothing. It returns choices, scores or yes/no answers you defined, with probabilities.
- Hence the speed and the price (70–500ms, $0.042 per million input tokens, output free).
- Q1: yes — writing the state and the options is what using it consists of.
- Q2: a summarised screen, not the DOM. Goal, step, visible text, clickable elements — and those elements are the options.
- Q3: technically possible, but the features and the risk limits are your code, and calibration is not accuracy.
- “Zero hallucinations” means the schema holds, not that the answer is right.
- Rules, classical ML, Jev and LLMs do not compete. Watching over an LLM is a large use in itself.
References
- TypeSafe AI — API reference (the state / questions schema)
- TechCrunch — A new kind of AI model from a ChatGPT inventor
- ITmedia AI+ — what Jev is (Japanese)
- MarkTechPost — TypeSafe AI Releases Jev (notes on the benchmarks)
- Vercel — How to classify, route, and score with Jev and AI SDK
- Cloudflare AI docs — Jev (context length)
Jev Field Notes — six chapters / 2026.09