Jev explained and the rise of the decision layer

A browser agent runs a Google Flights search in about seven seconds. Look at the division of labour behind that number. In the browser-use/jev-ultrafast project, the authors report a 7.073-second run. Their loop gives each component a specific job. Code observes the page, a small text model writes only when a field needs typed text, and a new kind of model picks the next operation and its target. That third thing is Jev.

Jev is TypeSafe AI's typed decision model: you hand it a state and a narrow question, it returns a structured judgment, and it is cheap enough to ask thousands of times. It is not a coding model and it does not run your agent. The opportunity it opens is not "twenty new tools" or a universal coding speedup — it is decision density: how many small, bounded, useful judgments a workflow can now afford. That is my bet: the advantage will come from how well a team defines its decisions and prepares the evidence for them.

What Jev actually is: a typed decision model, not a coding LLM

Jev arrived on 15 September 2026 as what TypeSafe founder Diogo Almeida described as the company's first "System One" model — trained with a method he calls RLCD, Reinforcement Learning for Calibrated Decisions, and named after the economist William Stanley Jevons. It is priced at $0.042 per million input tokens, with output free at that direct rate. The launch headline — 193.6x faster, 444.6x cheaper — compares Jev's outputs against averaged reference probabilities from Astra and Fable across four workflows TypeSafe's own team authored, and the company frames those as upper-end expected gains, not production throughput. I've already argued why that number prices agreement, not correctness, so I won't relitigate the benchmark here.

The shape matters more than the multiplier. TypeSafe's documentation describes Jev as reading a state and answering typed questions with structured output, instead of generating an answer token by token. A general model can already return structured output against a schema; that is not the distinction. The distinction is that Jev is built to make a calibrated choice, cheaply, over and over, as its whole job.

Choice, Score and Noul: three questions over one shared state

There are three primitives, and they are worth naming precisely because most confusion about Jev is a confusion about which one a task needs. Choice selects among options you supply. Score rates the state against descriptive, ordered rubric levels and returns a score with a probability distribution. Noul returns an estimated probability, from 0 to 1, that an answer is yes. You can mix several independent questions into one request, and they all read the same state — but each question has to be narrow.

The catch is in the state itself: it supplies the evidence the model sees, which means collecting and normalising that evidence is your job, not the model's. Jev judges what you put in front of it and nothing more. The fan-out pattern lets independent or speculative questions ride along in a single state request, with your code choosing afterwards which answers apply. But an answer from one question does not become the input to another within the same call. Dependent steps still need orchestration you write.

Why the economics feel different — and where the feeling misleads

At $0.042 per million input tokens, a judgment that used to cost a frontier-model round-trip becomes affordable at many more points in a workflow. That is the shift worth testing. As an illustration I'll own: labelling 10,000 records at roughly 1,000 input tokens each is 10 million tokens, about $0.42 of Jev inference at the cited direct price. That number is small — but it is only the inference. It excludes collecting the records, any transcription or vision step, browser or API time, retries, repeated instructions, and the human review that grades the output. That calculation tells us nothing about the cost of the surrounding work.

There is a second trap worth naming with arithmetic. Suppose a workflow's decision-making is 80% of the elapsed work and you speed that part up 30x. Amdahl's law gives a total speedup of 1 / (0.2 + 0.8/30) ≈ 4.4x, not 30x. That is an illustration, not a measurement — but it is why "make the judgments 400x cheaper" and "make the workflow 400x faster" are different sentences that marketing likes to blur.

The clip below is a silent, AI-assisted animation of that same loop — a diagram in motion, not a recording of a live Jev run and not a measured result.

Confidence deserves the same care. TypeSafe's confidence guidance says the confidence attached to Choice and Score is computed from the shape of the model's distribution — it is not an independent guarantee of correctness, and not directly the chance a business action will succeed. Noul carries no separate confidence field at all. Thresholds have to be calibrated on your own outcomes. This is the same contract I drew for temperature zero: name what the number actually promises before you build on it.

The 7.1-second browser run, read honestly

Back to that browser agent, because it is the clearest picture of the pattern. In jev-ultrafast, deterministic code holds the structured controls: it observes the DOM, checks the target's freshness and whether it is occluded, and only calls the small text model when an operation is literally TYPE_TEXT. Jev's job is narrow — pick the operation and the element to act on. The reported 7.073-second Google Flights task has a specific scope: initial navigation and a fresh, independent verification after the run sit outside the clock.

The project's own performance notes include a matched comparison with only three pairs — a median of 9.450 versus 7.092 seconds, about 25% less time — and, crucially, the same Jev-plus-text-model pairing runs in both arms. So the improvement there is runtime engineering, not Jev beating a frontier model on a bench. I have not reproduced any of it. What I take from it is a design to study: separate repeated choosing from open-ended writing, then measure the complete loop.

What Jev changes inside a coding harness

TypeSafe is explicit that Jev is not a drop-in coding model: it doesn't write code and it doesn't converse. There is an agent skill that teaches a coding agent to call the TypeSafe API, and an MCP server that exposes judgment calls to MCP clients. Neither one hands Jev native control of a full coding harness — they wire judgment into a harness someone else drives.

The circulating 12-page Jev engineering note is useful, with one provenance correction: its first and last pages describe an independent synthesis, unaffiliated with TypeSafe. The compiler attributes the ideas to Almeida's notes; the PDF itself is not a founder-authored product announcement. I read it as an architectural proposal.

The organising question is productive: how would you build a coding agent if there were no KV cache to preserve? A model's cached attention state makes reusing a prompt prefix cheaper than repeatedly processing it from scratch. The thought experiment asks what we would design if an ever-growing conversation were no longer the default container for everything the agent knows.

The proposal stores information as addressable chunks. For the current question, Jev chooses whether each chunk should be hidden, shown briefly, shown at length, or included in full. Another mechanism supplies any summary. In a hypothetical billing fix, I want the relevant refund rule and failing test in full; yesterday's CSS search can stay retrievable without occupying the next prompt. Deleting the only copy would defeat the point.

Tools get similar treatment: short capability descriptions first, the selected schema when needed, detailed documentation for the particular query. Conditional instructions attach to the work—editing a component brings back its style rules; touching billing brings back its gotchas. Mandatory constraints need deterministic pinning or reloading, so a relevance decision cannot quietly discard them.

Routing also has a return journey. The note assumes expensive-model input/output prices of $5/$25 per million tokens and cheaper-model prices of $3/$15. With 0.65 million existing context tokens, 0.12 million generated tokens and 0.23 million additional reads, its example costs $4.15 staying on the expensive model versus $6.19 switching down and back. Those are illustrative assumptions, not current quotes or measured invoices. The extra context load and return processing can consume the saving; actual prefix reuse, cache expiry and handoff size determine your bill.

The same state design can support shared retrieval for read-only reviewers, explanation writers and evaluation builders. My addition is to make retrieval a versioned snapshot: reviewers should know which files and diff they examined, especially while another agent keeps editing. Sharing stale evidence cheaply would be the wrong saving.

Finally, provider policy has to apply before data leaves the system, including data sent to Jev itself. A relevance or sensitivity score can help triage; it cannot grant a provider permission to receive secrets. Likewise, reading a script before approving it can add evidence, but execution permissions, sandboxing and network controls still need enforcement in code.

rendering diagram…

Seven marketing jobs for a decision layer

Marketing operations are a good stress test, because they are full of repeated, bounded judgments over messy exports. The trick in every case is the same: separate the decision Jev makes from the pipeline around it, and remember Jev 1.13 reads text and structured state — no direct image or video understanding — so image, audio or video evidence needs a separate extraction step before Jev can judge it. TypeSafe documents that input boundary. What follows is illustrative engineering, not a result I measured.

Tag the ad library. Your code collects the available records through an appropriate export or access method. Jev can label each record against explicit hook, format and offer categories. The useful output is a consistent research table; completeness still depends on what the collection method exposes.

Find patterns in long-running ads. Code computes age and survival from observations over time; Jev helps group the creative patterns. An ad still live after sixty days deserves investigation, but duration alone cannot establish profitability. Without spend and conversion data, I would use this to choose hypotheses to test—not declare winners.

Score briefs before production. Let the LLM draft alternatives, then ask separate questions about hook clarity, brand fit and whether the offer is supported. Keep the dimensions visible instead of collapsing everything into one mysterious number. A creative rubric becomes a claim about survival odds only after outcomes validate that relationship.

Sort search terms. Jev can distinguish likely buying, research, support and job-seeking intent against the product context. A research query can still lead to a sale, so I would queue ambiguous negatives and compare them with conversion evidence before applying exclusions. The label is an input to account management, not automatic permission to change it.

Investigate fatigue. Code calculates frequency, CTR trends, spend and sample sizes; Jev reads that evidence to suggest refresh, replace or hold. Audience changes, budget changes and tracking faults can produce similar signals. Preserve the alternative explanations and test the intervention.

Check the ad against its landing page. Compare the extracted promise, price, conditions and intended audience with the actual destination. A mismatch can become a specific review item: the ad promises a free trial, for example, while the page only describes a paid demo. Whether fixing it improves conversion still needs measurement.

Score leads. Use appropriate, consented data to assess fit, expressed intent and readiness against explicit criteria. A 0–100 score is a rubric output, not a purchase probability. Grade it against downstream qualified sales before feeding signals back through approved ad-platform integrations.

The common architecture is more useful than any one example. Acquisition supplies evidence, Jev makes narrow judgments, software applies the policy, and business outcomes tell us whether those judgments helped.

Twenty projects show where Jev fits

Within days there was a small constellation of projects. They are not twenty interchangeable "skills" to install — they are apps, libraries, wrappers, and experiments with very different maturity, and the table lists documented purpose, not a tested recommendation.

Project	Documented role and limits
jev-ultrafast	Browser agent: Jev selects operation and target; a text model types.
jev-review	Structured judgments across diff and codebase review stages.
killmyidea	Startup-idea rubric scores combined in code; not market-demand evidence.
Canny	Coding evidence ledger; Jev is optional and advisory, facts govern blocking.
agent-desktop	General desktop observation and execution; current README does not document Jev integration.
fast-jev-compaction	Removes or truncates selected old tool exchanges; retained text stays verbatim.
winnow	Filters tool output, preserves uncertain/error blocks and provides restoration keys.
blink	Semantic filesystem walkers that score candidate paths.
semdecide	Semantic predicates, routing and scoring for Unix streams and CI.
jev-curate	Training-data filtering and rubric scoring; published mock throughput is not live inference performance.
json-render	Generative UI framework; Jev composition is experimental and unreleased in the inspected README.
typesafe-mcp	Judgment bridge for MCP clients, also available through a CLI.
jev-mcp	Focused verification, screening, ranking and review tools over MCP.
jev-codex-router	Per-call model and effort routing; historical simulations do not establish current quota savings.
typesafe-mario	Experimental NES controller choices from parsed telemetry and RAM.
OneVOneJev	Browser FPS decisions from structured game state, with heuristic fallback.
jev-drone	MuJoCo drone simulation; Jev advises, deterministic control owns safety.
jev-trader	Market-making experiment; mock-model and dry-run defaults, not profitability evidence.
prism	Solana liquidity agent with paper trading; current README does not document Jev integration.
neo4jev	Neo4j hop selection and goal checks; explicitly labelled stand-ins when API access is absent.

Three are worth pausing on. jev-ultrafast is the reference for the whole pattern — judgment on the hot path, determinism around it. qkal/Canny is the one I'd study first for real work: it keeps an evidence ledger where deterministic facts do the blocking and Jev's judgment is explicitly advisory, which is the right default when the wrong call is expensive. And RomanSlack/jev-drone makes the boundary especially clear — a simulated quadrotor where computer vision turns camera data into symbolic state, Jev offers tactical advice at roughly 2.5Hz, and deterministic guidance and control own safety. That documents a simulation, not a physical-drone deployment. The separation of tactical judgment from time-critical control is the useful part.

How I'd run an adoption trial

I have not run a Jev deployment or reproduced these benchmarks. My adoption rule is an editorial judgment: start where a mistaken decision is observable and recoverable. The first thing I'd reject is any whole-workflow "30x faster and under $3" pitch with no trace: no denominator, no included collection, transcription, browser, API, or review costs, no outcomes, no sample size, no baseline. That is the same discipline that applies whenever generated output shifts the bottleneck downstream instead of removing it.

Then I'd respect the model's known jaggedness. TypeSafe's Jev 1.13 notes describe literal reading, weak precise arithmetic and date handling, trouble with indirection, degradation from irrelevant state, and susceptibility to adversarial text in the state. So keep arithmetic and date comparisons in code, not in the judgment. Remember a typed answer can fit the schema and still be confidently wrong. And never mistake a semantic guardrail for a sandbox or an allowlist — the boundary that stops a bad action has to be real code, not a rubric.

For a first trial, I would run search-term classification in shadow mode: the model labels the export, but changes no account settings. Compare its proposed exclusions with a reviewed sample containing ambiguous and valuable queries. Keep a separate holdout to check the threshold after tuning; reusing the examples that shaped the rubric would flatter the result.

Compare against the current rules or a simpler classifier as well as the expensive-model baseline. Log the state, question version, model version, answer, fallback and eventual outcome. Measure harmful exclusions, review workload, completed-workflow latency and total cost at the same acceptable error rate. If the simpler method wins, use it.

That is the adoption test I care about. More decisions only count as progress when they improve the work that reaches the other end.

What's in it for you

• Point Jev at one bounded, high-frequency judgment you already make by hand, and price the whole pipeline — not just the advertised token rate.
• Keep arithmetic, dates, and the actual safety boundary in code; let Jev choose, let your code enforce.
• Calibrate every threshold on your own outcomes before you trust the confidence number, and always fund the fallback path.

Jev makes judgment cheap; decision density — and the measured outcomes that grade it — is what turns cheap judgment into an advantage.