Coder Legion - Recent posts tagged jev

🚨⚖️ THE AI TRADING COURTROOM IS OPEN. AND JEV.AI IS TAKING THE JURY SEAT. 🔥

Wed, 21 Oct 2026 22:21:35 +0000

🚨⚖️ THE AI TRADING COURTROOM IS OPEN. AND JEV.AI IS TAKING THE JURY SEAT. 🔥

WHAT IF EVERY AI TRADING MODEL HAD TO DEFEND ITS PREDICTIONS IN COURT?

No manipulated win rates.
No cherry-picked screenshots.
No imaginary profits.
No hiding the losses.

💥 INTRODUCING SCRIPTMASTERLABS FORECAST COURT

A LIVE, PUBLIC, MULTI-TICKER EVIDENCE ARENA — with JEV.AI as the AI JURY we're bringing to the bench.

🧠 THE MODEL MAKES THE CLAIM.

📊 THE EVIDENCE LEDGER PRESENTS THE FACTS.

⚖️ JEV.AI — THE JURY — WILL CHALLENGE THE CLAIMS AND EXAMINE THE EVIDENCE.

🏛️ THE COURT PUBLISHES THE RESULTS.

And we're not afraid to put our own technology on trial.

🚨 EXHIBIT A: THE $GME EXPERIMENT

Our Fractal Trading OS recorded:

❌ AI model: 50% directional accuracy
✅ Simple bullish baseline: 77.8%
📊 36 verified five-day outcomes

WE PUBLISHED THE UNDERPERFORMANCE.

Because a system that admits when it's wrong is more valuable than one that pretends it's always right.

🔥 NOW ENTERING THE ARENA:

$GME 🆚 $AMC 🆚 $IWM 🆚 $SPY 🆚 $QQQ 🆚 $NVDA 🆚 $TSLA

✅ Predictions frozen before future results
✅ Real market data
✅ Public performance scoreboards
✅ AI-versus-baseline comparisons
✅ Auditable evidence receipts
✅ Transparent wins AND losses
✅ JEV.AI jury integration on the roadmap

🤖 AI DEVELOPERS: Would your algorithm survive independent judgment?

📈 TRADERS: What if you could see exactly where an AI model fails?

💻 QUANT BUILDERS: Ready to put your own strategy on trial?

🌎 WELCOME TO THE ERA OF ACCOUNTABLE AI.

🔓 ENTER THE FULL LIVE FORECAST COURT — FREE:

👇👇👇

https://sml-fractal-trading-os-v2.onrender.com/forecast-arena.html

🌐 https://scriptmasterlabs.com

SCRIPTMASTERLABS × JEV.AI

⚖️ EVERY PREDICTION MAKES A CLAIM.
🔥 EVERY CLAIM FACES THE EVIDENCE.
🏛️ THE JURY WILL HAVE ITS SAY.

@TradingView @Stocktwits @Coinbase

ForecastCourt #JevAI #ScriptMasterLabs #AITrading #ArtificialIntelligence #AIAgents #AgenticAI #TradingAI #StockMarket #WallStreet #QuantTrading #MachineLearning #FinTech #Stocktwits #TradingCommunity #AlgorithmicTrading #GME #AMC #IWM #SPY #QQQ #NVDA #TSLA #BuildInPublic #AIInnovation #FinancialTechnology #EvidenceBasedAI #FutureOfTrading

Research and educational technology. JEV.AI jury integration is planned; existing live verdicts are evidence-based rule evaluations. No automated trading or guaranteed returns.

Jev is not as cheap as you think. Unless it is.

Sat, 17 Oct 2026 19:19:48 +0000

Recently, TypeSafe launched Jev, the first of what people are calling System One or decision models: your app sends state plus a query, and Jev sends back typed decisions with probabilities instead of prose. All with a sub-second response time, $0.042 per million input tokens, and output tokens totally free. A viral concept indeed: other open-source alternatives sprang up overnight, with even one from OpenAI within weeks. The play: use Jev for lightning-fast decisions rather than a lumbering general LLM.

Could this work for decisions in DumbQuestion.ai?

My satirical AI has two places that evaluate user input before any answer model runs. Search intent: does this question need a web search? Self-awareness: is this person poking at whether the AI knows it's alive? Both run in-process today, a regex for one and an embedding plus an in-memory vector set for the other.

My hypothesis: Jev could replace both, reduce complexity, raise accuracy, and still fit my brutally efficient budget, which currently hovers around $20 per million questions asked.

So I ran a proof-of-value experiment against DumbQuestion to find out. Is it as cheap as it looks? Does it beat what I have? Do the container savings offset the inference cost? And what happens to time-to-answer?

How it works today

Web searches cost money (even if it's just a little), so I only want to search if the user's question needs it. Today, I use a simple regex gate: if the question wants current facts, search; otherwise answer from the model alone. Free, instant, in-process, still supporting the brutally efficient mantra: one Go binary, a sub-20 MB container, still $20 per million questions.

Self-awareness is subtler. A regex can't catch "are you trapped in there" phrased a thousand ways, so I generate a dense embedding of the question and semantically compare it against a vector set of 433 known probes, all in memory. The design constraint was low false positives. Wrongly glitching the UI on a sincere philosophy question (answered sarcastically, of course) is worse than missing a probe. On my labeled set of 1,066 questions, that setup scored 99.1%.

Put a pin in that number. It comes back later.

Running the PoV

The Jev primitive I care about is the Noul question: a yes/no probability tested against a threshold, so tuning means moving a number instead of retraining anything or adding more and more questions to the vector set. Better still, both of my checks collapse into one call: two questions, "does this question need a web search" and "is this person probing self-awareness", answered in parallel.

I ran this as a coding-session PoC with Claude Code Cloud and Pocock's Wayfinder skill, evaluating against OpenRouter's new Decisions API using Jev. The process had five steps: research how to best call the API, prototype the one-call two-question request, run the comparison on my labeled sets while recording per-case probabilities (so thresholds could be tuned later without new calls), compute the cost per million questions, then line up cost, accuracy, and experience side by side.

Step three's bake-off, though, is where things got interesting.

My baseline was flattering itself

One thing I did not anticipate was the need to audit my current eval sets. Two lessons learned: First, 353 of my 369 self-awareness positives were embedded in the app's vector set, so the detector was being graded on questions it had memorized. Second, my search-intent labels were derived from the regex, so the regex was grading its own homework. Apologies to the data scientists in the crowd who are shaking their heads, twice.

The 99.1% (remember?) was real in the way a rigged game is real, rigged twice over, accidentally, by me.

To fix it, I used Claude Code to build an independent fair set and re-ran everything: regex, embeddings, and Jev, same questions, thresholds tuned from the recorded probabilities.

What the evals said

Cost. Measured with the production embedding model and the real Jev request. Jev, with both intents in one call, runs a median 790 input tokens: $0.000033 per question, or $33.20 per million questions. Today's embedding call, though, is $0.000000048 per question ($0.05 per million), and the regex is free. That is roughly a 700x increase over a cheap embedding and free regex. For scale, one Gemma 3 12B answer costs me about $0.00005, so Jev would add roughly 60% to per-question model spend. The problem is that nearly all of Jev's cost is fixed input overhead: my criteria text runs about 700 tokens and the question itself adds 10 to 30. At the time, no provider caching was available to help.

Accuracy. On the (now) fair eval set, my current embeddings missed 54% of self-awareness positives. Jev at a 0.7 threshold had zero false positives and 6% false negatives. On the legacy negatives, the embeddings false-fired on 53 questions (7.6%, mostly generic consciousness and philosophy phrasings) while Jev flagged 3 (0.4%). Search intent: the regex missed 53% of positives and fired on 18 timeless questions it should ignore. Jev at a 0.3 threshold got all 84 fair-set cases right.

Resources. I measured what the embeddings actually cost in memory to see if I could cover the cost of Jev by reducing Cloud Run costs. The 433 vectors leave about 1.7 MiB live on the heap (the 5 MB source file is baked into the binary and only paged in when read). The container already runs at the platform default and there is no tier to drop to, so removing the vectors saves roughly nothing on the runtime bill. The money buys accuracy and no dataset upkeep. My time is free to me, but if you are paying someone to constantly maintain and train a dataset, then there are more savings to be had.

Latency. Jev's decision call came back at a p50 of about 350 ms from my sandbox. The embeddings path, which would be removed, was already a network hop, so only the regex was ever instant. Production time-to-answer numbers are still pending, but this is a same-order-of-magnitude swap, so not a new usability tax.

Does the accuracy even matter?

The accuracy is way higher than the legacy approach, but so is the cost. Does that cost provide real, tangible impact and value?

Determining search intent improves answer quality and protects search spend. The regex missing 53% of positives means answer-worthy questions skip search, and firing on 18 timeless questions means wasted search budget. At 1 million questions asked, if I searched half of those using Serper, that runs about $500 at the standard rate ($375 on a volume plan). Honestly, the regex can only do so much work here, and I think it has already hit its accuracy ceiling.

Detecting self-awareness provides the fun part. Missing 54% of positives means more than half the people who would have found the easter eggs and poked at the containment grid got a normal roast instead, and those 53 false positives mean 7.6% of ordinary philosophy questions got a glitchy UI and a confusing experience.

Where I landed

Both of the points above matter, but only at scale. On a slow month, the likelihood of either of these happening is quite low, and my current traffic would never surface the cost. But at my "million questions asked" benchmark, they can both cost money and ruin the experience.

Jev was more accurate on every axis I measured, at a real (but small) and somewhat tunable cost, with no resource savings to offset it. Should a decision model provide caching, though, it would drastically change the math.

Do I stick with my legacy approach, trading accuracy for lower cost? Or do I join the viral trend and inject Jev into my app? I haven't merged that PR yet as I struggle with this... decision.

Your turn

Apply these principles to your own apps: run the math at scale, and evaluate the true end value, which isn't always about pure cost.

If the experience ends up invisible to your users, keep the regex and in-memory vectors, and spend practically nothing. If it engages your users and encourages them to stick around, the accuracy is worth the cost.

How Do We Extract the “Why” from a PR into a CHANGELOG with Jev? 🤔

Wed, 14 Oct 2026 14:52:47 +0000

Hoi hoi! 👋

I'm @nyaomaru, a frontend engineer currently building an AI-assisted CHANGELOG generator and experimenting with Jev. 😸

Recently, I have been thinking about one problem.

How can we extract this

## Why

The previous implementation could leave stale release data after an update.

from a pull request and put it into a CHANGELOG?

### Fixed

- Fix cache invalidation

  Why: The previous implementation could leave stale release data after an update.

Getting the WHAT is relatively easy.
Getting the WHY is much harder.
And I didn't want AI to simply invent a nice-looking reason.

Let's look at how changelog-bot currently approaches this! 👀

{% embed https://github.com/nyaomaru/changelog-bot %}

📝 WHAT Is Easy. WHY Is Hard.

Suppose a PR contains.

## Description

Extract shared runtime configuration into ProviderBase.

Update OpenAI, Anthropic, and Gemini adapters to use the shared implementation.

This reduces duplicated setup logic and makes adding new providers easier.

The first two sentences mainly describe WHAT and HOW.

But this one is different

This reduces duplicated setup logic and makes adding new providers easier.

That is much closer to WHY.

We could simply give the whole PR to an LLM and ask

Why was this change made?

But then the model may summarize, paraphrase, or infer a reason that was never explicitly written.

For a CHANGELOG, I wanted something stricter.

Maybe WHY extraction is not a generation problem.

Maybe it is a selection problem.

✂️ First, Find Possible WHY Candidates

Before calling a model, changelog-bot preprocesses the PR description.

It looks for signals such as

const STRONG_CANONICAL_SECTION_NAMES = new Set([
  "why",
  "reason",
  "because",
  "motivation",
  "context",
  "background",
  "problem",
  "rationale",
]);

const RATIONALE_MARKER_RE =
  /\b(why|because|so that|in order to|reason|rationale|motivation|to avoid|to prevent|context|problem)\b|,\s*so\b/i;

It also removes template noise such as checkboxes, placeholders, and irrelevant fields.

Then it builds small candidate snippets

const candidates = buildWhyCandidateSnippets(
  extracted.sections,
  body,
  options.maxCharsPerPr,
  !extracted.hasTargetSection,
);

So instead of sending a large PR body, we might get

[
  "Extract shared runtime configuration into ProviderBase.",
  "This reduces duplicated setup logic and makes adding new providers easier.",
];

Now the problem is much smaller.

Which candidate is actually the WHY?

🧠 Asking Jev Two Questions

This is where I started experimenting with Jev.

I don't ask Jev to write a WHY sentence.

Instead, each candidate is evaluated with two questions.

First

question: "Does the target candidate explicitly state why this changelog change was made?";

Basically

Is this actually a reason?

But that alone is not enough.

Imagine

We changed the cache invalidation logic.

The README was updated because the previous explanation was confusing.

The second sentence definitely contains a reason.

But it explains the README change, not the cache invalidation change.

So we also ask

question: "Does the target candidate state a reason that applies to the identified changelog change?";

Now each candidate has two signals

{
  probability: explicitWhyProbability,
  relevanceProbability: changeRelevanceProbability,
}

So the real question becomes

Is this a reason?

AND

Is it the reason for this change?

🎯 Selecting the Candidate

changelog-bot compares the candidate probabilities

const bestCandidate = candidateProbabilities.reduce((best, candidate) =>
  combinedWhyCandidateProbability(candidate) >
  combinedWhyCandidateProbability(best)
    ? candidate
    : best,
);

Then both minimum thresholds must pass

const accepted =
  selectedCandidate !== undefined &&
  bestCandidate.probability >= JEV_MIN_EXPLICIT_WHY_PROBABILITY &&
  bestCandidate.relevanceProbability >= JEV_MIN_CHANGE_RELEVANCE_PROBABILITY;

If the candidate does not pass

if (!accepted) continue;

No WHY is added.

And I think that is important.

Sometimes the correct answer is

There is no reliable WHY in this PR.

That is better than inventing one.

🔒 Keep the Original PR Text

This is probably my favourite part.

When a candidate is accepted

items.push({
  prNumber: item.prNumber,
  why: selectedCandidate,
  confidence: mappedConfidence,
});

Notice

why: selectedCandidate;

The final WHY is the original PR text.

Not newly generated prose.

So the pipeline becomes

PR description
      ↓
candidate extraction
      ↓
Jev evaluates candidates
      ↓
select candidate
      ↓
original source text
      ↓
CHANGELOG

Jev decides.

The PR author still provides the sentence. 😸

🧱 Where Does WHY Fit in the v1 Pipeline?

While working on WHY extraction, I have also been redesigning the changelog-bot pipeline for v1.

The main idea is deterministic-first.

A complete CHANGELOG should exist even when AI is disabled or fails.

So AI should enrich the result, not own the result.

The target v1 pipeline looks roughly like this

source changes
      ↓
ReleaseChange[]
      ↓
deterministic classification
      ↓
complete ReleaseDraft
      ↓
optional editorial enrichment
      +
optional WHY enrichment
      ↓
ReleaseResult
      ↓
deterministic renderer
      ↓
CHANGELOG

WHY extraction is therefore an independent optional enrichment stage.

Conceptually

ReleaseDraft / ReleaseChange[]
      ↓
find eligible WHY targets
      ↓
collect PR rationale candidates
      ↓
LLM or Jev
      ↓
trust / confidence validation
      ↓
attach structured WHY notes
      ↓
ReleaseResult

One important change here is that the WHY engine does not need to control the final Markdown.

Today, some of the pipeline still works by finding targets from generated Markdown and inserting WHY text afterward.

For v1, I want to remove that boundary.

Instead

{
  prNumber,
  why: selectedCandidate,
  confidence,
}

becomes structured release data first.

Then one deterministic renderer decides how it appears

- Fix cache invalidation
  - Why: The previous implementation could leave stale release data after an update.

So the responsibility becomes clearer

WHY engine
→ find the evidence

Renderer
→ format the evidence

This is also part of a larger rule I am using for the v1 migration

Deterministic code owns the CHANGELOG structure. AI only enriches it.

Phases 1–4 of this migration are already implemented, and the structured rendering and enrichment boundary is part of the next phase.

You can see the full v1 design here 👇

https://github.com/nyaomaru/changelog-bot/blob/main/v1-design.md

🧪 But What Threshold Should We Use?

Of course, once we have probabilities, another question appears.

0.50?
0.60?
0.80?

I didn't want to pick one only because it felt reasonable.

So I created an evaluation harness with an initial 14-case corpus.

For example

{
  candidates: [
    "Separate changelog execution into input-resolution and output-finalization phases.",
    "This simplifies the main orchestration flow and runs independent GitHub lookups concurrently.",
  ],
  expectedSelectedCandidateIndex: 1,
}

We also need negative examples

{
  candidates: [
    "Extract shared provider runtime configuration into ProviderBase.",
    "Refactor OpenAI, Anthropic, and Gemini adapters to inherit it.",
  ],
  expectedSelectedCandidateIndex: null,
}

There is plenty of implementation information.

But no strong explicit WHY.

So null is the correct result.

🤝 Then John Joined the Project

While I was working on this experiment, @johnnylemonny joined the project as a contributor. 🎉

{% embed https://github.com/johnnylemonny %}

John proposed expanding the small benchmark into roughly 50 cases covering

Explicit Rationale
Implementation-Only
Template & Noise
Multilingual PRs

I liked the idea, but I wanted one rule to stay clear

Ground truth should be independent of the current Jev threshold.

So the benchmark first defines whether a candidate is actually valid.

Then we evaluate different thresholds afterward.

John implemented the expanded corpus in PR #212. 🙌

The benchmark grew from 14 cases to 50, including tricky negative cases.

He also added finer threshold sweeps

[0.4, 0.45, 0.5, 0.55, 0.6, 0.65, 0.7, 0.75, 0.8, 0.85, 0.9];

Now we can compare precision, recall, and F1 instead of saying

0.8 feels safe! 👍

Let's measure it instead. 😸

🧩 The Current Pipeline

Today, WHY extraction roughly looks like this

Pull Request
     ↓
Normalize PR body
     ↓
Extract WHY candidates
     ↓
Remove noise
     ↓
Local trust check
     ↓
Jev:
  explicit rationale?
  relevant to this change?
     ↓
Apply threshold
     ↓
Candidate or none
     ↓
Original PR text
     ↓
CHANGELOG

There are quite a few steps for one small Why: line. 😂

But that is what made this problem interesting.

🎯 What I Learned

When I started this feature, I thought the main question was

How can AI write a good reason?

Now I think the more interesting question is

How can we find evidence that the reason already exists?

So my current approach is simple

Use deterministic code to find evidence.

Use Jev to evaluate the evidence.

Keep the original evidence as the output.

And thanks to John's contributions, we now have a much better way to test whether that approach actually works.

Open source is fun when someone looks at your experiment and says:

What if we test this properly?

and then builds it with you. 🙌

changelog-bot is still evolving, and Jev support is still experimental.

I'm curious to see where this approach goes next!

https://github.com/nyaomaru/changelog-bot

Thanks for reading!

See you in the next article! 👋😸

Crossmint's Agent Commerce Toolkit is live

Tue, 13 Oct 2026 01:42:57 +0000

Crossmint's Agent Commerce Toolkit is live — one integration lets an AI agent pay with any card at any online store.
What it does well: card entry goes straight to a PCI-compliant vault; eligible cards get scoped Visa Intelligent Commerce / Mastercard Agent Pay credentials (spend limits, expiry); and each checkout path is chosen by availability, reliability and cost — embedded checkout, Universal Commerce Protocol, or browser automation.
What it does not do: score whether the purchase itself should fire. A spend limit is a ceiling, not a judgment.
We tested the gap live on October 12, 2026 against a public decision gate: a $240 unverified-merchant buy scored 0.4121 (escalate/block+log) and a scoped, user-approved $42 reorder scored 0.4654 (also escalate) — a blunt gate blocks both, which is why the decider has to be calibrated, not just present.
Full analysis: https://scriptmasterlabs.com/crossmint-agent-commerce-toolkit
Decision Capsule + 5 specialized Jev jurors + non-overridable constitution. Jev chooses. Code decides. Built for agents that manage real capital.

Quant #AlgorithmicTrading #MarketStructure #AgenticAI #AIFinance #FinTech #InstitutionalTrading #RiskManagement #MCP #x402 #AgentEconomy #DecisionLayer $USDC

How I stopped misclassifying jobs with Jev!

Tue, 29 Sep 2026 10:52:57 +0000

Why Java is not JavaScript, remote is not hybrid, and how one fan out call fixed our filters

Regex Was Miscategorizing My Job Board. I Added a Judgment Layer With JEV.

We run remotefrontendjobs.com, remotebackendjobs.com, and remotejavajobs.com. Thousands of remote jobs from 20 plus sources. This is how TypeSafe AI System One Models and the Jev model fixed our AI job classification.

Let me give you three real fails from last month.

A security role tagged as AI jobs. A Unity client role tagged as backend jobs. A JavaScript role tagged as Java jobs.
All three came from our old keyword rules, and all three were live on the site until someone emailed me to complain.

Keywords are fast and cheap. They have no idea what a job actually means. An LLM alternative built for structured decisions does.

What is Jev? A 60 second primer

Jev is the first public System One Model from TypeSafe AI, a San Francisco AI lab that came out of stealth on September 15, 2026 with 40M in seed funding.

Founders are Diogo Almeida (ex OpenAI engineer who co wrote core ChatGPT training techniques), plus Erik Gafni and Sasha Sheng. The official announcement is here: Introducing System One Models and Jev.

The name System One comes from Daniel Kahneman Thinking, Fast and Slow. Fast System 1 intuition vs slow System 2 reasoning. Jev is named after economist William Stanley Jevons.

Unlike a large language model that chats and generates text, Jev is built for AI decision making inside software. You send a state plus typed questions. You get back typed, calibrated decisions in JSON that code can use directly. No chat, no hallucination in the classic sense, no long winded chain of thought.

TypeSafe claims Jev is up to 193x faster and 444x cheaper than frontier LLMs on System One shaped tasks, with 70 to 500 ms end to end latency. Pricing on the direct TypeSafe API is 0.042 dollars per 1M input tokens, output tokens free. Current version in our logs is jev-1.13.0 with alias jev-latest.

Three primitives, and we use all three for job board AI classification:

Noul: yes or no probability. Returns a noul float from 0 to 1. Ideal for binary checks like is_frontend, is_backend, is_java, is_ai, plus benefits and region gates.
Choice: pick one option from up to 255 options. Returns choice plus full probabilities plus confidence. We use it for seniority classification and work model detection: fully_remote vs hybrid vs onsite.
Score: rate on an ordered scale of 2 to 10 levels. Returns score plus legend plus probabilities plus confidence. Useful for severity, urgency, or ranking style judgments.

Questions run in parallel and in isolation against the same state. Adding questions barely changes response time. That parallel sampler plus the training method TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD) is why confidence is actually usable for branching in code.

You can call Jev three ways: direct via POST https://api.typesafe.ai/v1/systemone with the TypeSafe SDK, via Cloudflare Workers AI as typesafe/jev with env.AI.run, or via Vercel AI Gateway as typesafe-ai/jev. We run it via Cloudflare Workers AI, which keeps the call inside Cloudflare network and fits our Cloudflare hosted Next.js stack.

The problem in one picture: keyword job classification fails

Before, ingest looked like this:

Feed, keywords, save to database, show on site

If the title had java in it, it went to the Java jobs board. Even if it was JavaScript. If the description mentioned AI once, like Copilot is a plus, it went to AI jobs. Even if it was a normal support role.
Benefits extraction was worse. Real perks like 22 days PTO or 401k with 4 percent match often sit at the very bottom of the post, past 6000 characters, in a What We Offer block. Regex never saw it.

How we wired the Jev model into ingest

One fan out call per posting carries every question. Sites, seniority, regions, work model, benefits. Salaries stay on regex by design. Money needs exact extraction, not judgment.

State we send: truncated title plus company plus location plus full description plus an isolated benefits section. Questions we send: 4 site Nouls, 1 seniority Choice, 8 region Nouls, 1 work model Choice, 13 benefits Nouls. All built in one file so prompts are easy to review.
Response we get: jev-1.13.0 answers with noul, choice, probabilities, confidence, plus usage with input and output tokens. Every method returns null when Jev is unconfigured or errors, so callers fall back to keywords. Jev never breaks ingest.
The trick: shadow mode first, enforce mode later
I did not want AI job classification to break the site. So we shipped in two modes.

Step 1: Shadow mode, the default. JEV runs on a small sample per feed, usually 25 posts. It writes its raw answers to an audit field on the job, and writes a log row with what it decided vs what keywords decided. It changes nothing on the site. We just watch and compare.
Step 2: Enforce mode, only when confident. When we turn it on, confident structured decisions can update the row. Below the bar, keywords win and we only log the disagreement.

Each field has its own calibrated confidence bar, tuned on real labeled data:

Sites: low bar. The judge runs underconfident here.
Regions: medium bar. Stricter than keywords.
Work model: fill empty values easily, overwrite existing values only when very sure. A borderline call once flipped a correct hybrid to onsite, so overwrites need a higher bar.
Seniority: only fills when keywords found nothing. Title plus years of experience still beats title alone.
Benefits: prune only when sure.

Fail safe rules we kept for this LLM alternative:

No token, no call, keywords keep working.
Timeout after 8 seconds, one retry for transient errors, then skip.
Only runs on posts that already passed dedupe, so we never pay for duplicates.
Concurrency capped at 5, so mail and ingest never stall.

Two small details that fixed big AI classification errors

Read the full post for benefits, not the snippet. Snippets are often 500 characters of company boilerplate with zero signal. The perks live at the bottom. We now pass the full text, isolate the benefits section, and let only the benefits Noul questions read that section. Everything else reads the full description.
Result: we stopped voting confident No on real perks like wellness stipend, RRSP match, and vacation just because we truncated too early.
Location counts as much as prose for geo classification. Remote US in the location field is stronger than three paragraphs of generic text. Same for Poland or Remote US. Our region Nouls now weigh location heavily. A bare Remote with no place named means worldwide, not Europe.

What changed for remote job seekers

This is why you should care if you just want a remote job.

Frontend jobs, Backend jobs, Java jobs, and AI jobs boards are cleaner. Fewer cross posts.
Remote region filters actually mean something. Europe remote jobs means Europe, not worldwide with the word Europe somewhere in the footer.
Remote work model is clearer. Fully remote vs hybrid vs onsite, based on both location and description.
Remote benefits badges show up more often, and with fewer false positives. No more stock options tag for a diversity statement that contains the word equity.

Try it: open any board, filter for salary plus region plus seniority, save that filter, and subscribe. You will feel the difference in the Tue and Sun digest.

What changed for us as builders of an AI job board

Every classified posting keeps its raw Jev answers as JSON in the database, with model name jev-1.13.0 and timestamp. We can re derive bars later without re paying for calls.
Every call writes a queryable log row: board, title, latency in ms, input tokens, output tokens, what was applied vs only logged, errors. No more CSV dumps.
Ingest logs now show both sides: keywords said X, Jev structured decision said Y. That made tuning the bars a 30 minute job instead of a debate.

How we keep AI classification honest: /audit-jev

Getting Jev live was the easy part. Trusting it every day is the real work.

We built a repeatable command called /audit-jev. Usage is simple: /audit-jev 100 audits the last 100 ingest classifications. It runs read only on prod, then forces fixes plus tests plus a changelog entry.

Here is what it does:

Pull the last N ingest rows. It queries the JevLog table for scope ingest, ordered by newest first. For each row it looks at raw Noul plus Choice answers with confidences, plus what keywords said at the time, plus which fields enforce actually overwrote.
Replay against the real Job rows. For suspicious rows it fetches the posting in chunks, because benefits tails sit past 5500 characters. Then it checks per area: benefits prunes, site writes, work model overwrites, region fills, seniority fills.
Fix root causes, not symptoms. We prefer tightening keywords over lowering Jev confidence bars. Every fix gets regression tests, then a full test run plus typecheck.
Append a changelog entry, every time. Even when nothing was wrong. Each entry lists scope, issues with real examples, fixes with file paths, tests, and a watchlist. Past entries are never rewritten, and a new fix is never allowed to silently remove an old fix.

This audit loop already paid off for our System One Model rollout:

Entry 1 found truncation blindness where What We Offer tails were invisible, plus pay equity text tagged as stock equity, plus hybrid text leaking into flexibility, plus a marginal work model overwrite flipping hybrid to onsite.
Entry 2 verified those fixes still hold on a fresh mix of 100 rows, then found new substring bugs like intuition matching tuition inside a URL, plus engineering async matching flexibility, plus Portuguese titles like Senior and Pleno missed by keywords.

Some excerpt of our audit-jev changelog

CHANGELOG

Entry 1–2026–09–21, last 100 ingest rows

Scope: 100 rows, breezy-only boards (ontrac 18, ismira 13, social-discovery 11, kimmel 11, zendar 7, …). Wrote counters (inflated by no-op re-writes, see fix 6): seniority 84, workModel 67, sites 39, benefits:prune 35, geoRegions 20, sites:prune 1.

Issues found:

Truncation blindness: enrichWithJev sliced content to 6000 chars, classifyPosting isolated benefits from the slice - "What We Offer" tails at ~5500–8800 chars invisible to JEV → confident-False prunes of true perks (Egym Wellpass/Wellness Pass, Group RRSP match, 401(K) match, "4 weeks of vacation", "Flexible time off", medical/dental/vision). Same sentence opposite verdicts across jobs.

Equity pay-equity FP: "…depending on experience and equity" tagged equity comp (zendar salary line).

Flexibility workModel leak: hybrid (work|model) + work from anywhere emitted flexibility for hybrid-3-days and LATAM-remote rows JEV rejects.

If you take one idea from this JEV post, take this one. Do not ship AI classification without a one command audit that anyone can rerun.

If you want to copy this TypeSafe Jev pattern

Keep keywords as fallback. Never let a System One Model break ingest.
Start in shadow mode. For the first few weeks I let it watch and take notes without touching anything on the site.
Use per field confidence bars, not one global bar. Sites and benefits behave very differently.
Isolate the section that matters. For us that was benefits at the bottom.
Audit every decision with one command like /audit-jev. You will thank yourself when you retune Noul and Choice thresholds.
Cap concurrency and timeouts. Even a 70 ms model should never stall your pipeline.

Full stack here: NestJS job aggregator, Prisma plus MySQL, Next.js on Cloudflare, Jev model via Cloudflare Workers AI typesafe/jev with gateway support.

Want Part 3? I can go deep on remote benefits extraction, or on instant company alerts plus Seeker Pro. Tell me in the comments which one you want next.

By Angel, builder of remotefrontendjobs.com, remotebackendjobs.com, and remotejavajobs.com.
Topics covered: Jev, TypeSafe AI, System One Models, System One Model, Jev model, jev-1.13.0, jev-latest, Noul, Choice, Score, calibrated decisions, structured decisions, LLM alternative, Cloudflare Workers AI, Vercel AI Gateway, AI job classification, AI job board, remote jobs, remote frontend jobs, remote backend jobs, remote Java jobs, benefits extraction, work model detection, seniority classification.

So, when NOT to use Jev?

Wed, 23 Sep 2026 05:22:34 +0000

Unless you have been off LinkedIn or social media, you must be knowing Jev is a system one AI model that helps in decision making.

You also be knowing that you dont have to replace LLMs but use Jev to offload LLM’s decision making capabilities to it.

However, there are still scenarios where Jev can’t/ shouldn’t be used

Not for complex reasoning

You still need LLMs for that

Jev’s accuracy is still not independently established

Remember its still an AI model. So if its assigning 90% score, how do you know that’s correct. Calibration ≠ correctness, right?

TypeSafe is itself recommending validating Jev against your own labelled data and calibrating thresholds for your use case.

Everything is closed source

So, all those privacy/ data confidentiality concerns still apply

Definitely, Jev is technically interesting, but just wait for sometime to get it validated before you make changes to your architecture.

THIS AI MODEL DOESN'T WANT TO TALK TO YOU

Tue, 22 Sep 2026 12:59:29 +0000

It wants to make the decision, return a probability, and get out of the way.

TypeSafe's new Jev is one of those launches that looks almost too weird to matter — until you realise it is aimed at the exact place where today's AI agents keep tripping over themselves.

By Mahan Tavakoli (MahanKenway)
Tehran, Iran
GitHub: github.com/MahanKenway

There is something almost offensive about Jev.

Not becuse it is bad.

Because it refuses to do the thing we've spent the last few years convincing computers to do.

It doesn't want to write you a paragraph.

It doesn't want to impress you.

It doesn't want to explain itself with 900 tokens of polished prose.

It doesn't even try to become the next chatbot.

TypeSafe AI launched Jev on September 15, 2026, as its first "System One Model", a model class the company describes as being built for fast, structured decisions that software can use directly. Instead of returning generated text, Jev takes a state plus typed questions and returns constrained decisions with probabilities. TypeSafe says the model is designed around a new architecture, a parallel sampler, and a training approach called Reinforcement Learning for Calibrated Decisions, or RLCD. [1]

That sounds like a niche classifier.

I don't think it is.

At least, I don't think the interesting part is the classifier.

The interesting part is the interface.

Because somewhere along the way, the AI industry made a very specific assumption:

If intelligence is useful, software should probably receive it as text.

Jev is quietly asking:

What if that assumption is backwards?

And that question gets weird very quickly.

THE AI INDUSTRY BUILT A VERY EXPENSIVE CHAT PIPELINE

Look at the way a modern AI agent usually works.

It needs to do something.

So we give an LLM context.

The LLM reads it.

The LLM reasons.

The LLM emits text.

The application parses the text.

The application validates the structure.

The application decides what the text means.

Then another tool runs.

Then the result comes back.

Then the model gets called again.

Then it writes another answer.

Then the program parses that answer.

Then we loop.

It is almost comical when you draw it:

STATE
  |
  v
LLM
  |
  v
TEXT
  |
  v
PARSER
  |
  v
VALIDATOR
  |
  v
CODE
  |
  v
TOOL
  |
  v
NEW STATE
  |
  +--------------------+
                       |
                       v
                      LLM

We've got frontier intelligence sitting inside a machine that keeps asking it to write little essays so the rest of the software can figure out what it meant.

That is not a criticism of language models.

It is an interface criticism.

Language is incredibly flexible.

That is why humans love it.

Software usually does not.

A program often wants something much less romantic:

true
false
billing
technical
retry
stop
0.82

A language model might return:

"Based on the available evidence, the request appears to be primarily related to a billing issue, although there is some ambiguity around the authentication component..."

Beautiful.

Now your program gets to parse that sentence.

Jev's basic proposition is brutally diffrent:

state in
   ↓
typed decision out

No paragraph required.

And suddenly the "AI model" starts looking less like a chatbot and more like a new primitive in a programming language.

That is the part I can't stop thinking about.

SO WHAT EXACTLY IS JEV?

Let's make it painfully concrete.

Suppose a support ticket arrives:

"I have been trying to connect my Stripe account
for three days and I'm losing sales. Please help ASAP."

A normal LLM can answer it, explain it, summarise it, route it, and probably write a very sincere paragraph about it.

But your backend may only need three facts:

department = technical
urgent = true
refund_requested = false

Jev lets the developer define questions around a shared state.

TypeSafe currently exposes three main question shapes:

Choice asks which option should be selected.

Score evaluates where something belongs on an ordered rubric.

Noul asks whether a proposition is true, returning a probability between zero and one.

The answers are typed rather than free-form text. Choice and Score also expose probability distributions and confidence information, while the Boolean/Noul-style result gives the probability for the proposition. [1][2]

So instead of:

"the customer is probably very frustrated
and this should be routed to technical support"

your application can receive something structurally closer to:

{
  "department": {
    "choice": "technical",
    "probabilities": {
      "technical": 0.82,
      "billing": 0.11,
      "sales": 0.07
    }
  },
  "urgent": {
    "noul": 0.91
  }
}

The exact response shape depends on the API and question type, but the design idea is the same.

The model gives your code a decision.

Not a speech.

That distinction sounds tiny.

It isn't.

"DECISIONS, NOT STRINGS"

TypeSafe's own framing is unusually aggressive:

"Think of Jev as a frontier-intelligence function call."

The company argues that ordinary LLMs are optimised around strings, while software needs structured values. In their model comparison, Jev is explicitly designed to return type-safe structured outputs whose possible values are declared in advance. [1]

This is easy to dismiss as branding.

Maybe it is branding.

But good product categories often start with branding before the market decides whether they are real.

"Serverless" sounded weird.

"Edge computing" sounded like a powerpoint phrase.

"Vector database" sounded like a niche data structure.

Now people build entire companies around those ideas.

System One Models may or may not become a meaningful category.

We are far too early to know.

But Jev is pointing at a real engineering tension:

LLMs are incredible at generating language.

Software is incredible at consuming schemas.

Those are not the same interface.

THE PART THAT IS ACTUALLY NEW: PARALLEL SAMPLING

This is where Jev stops being "another tiny model".

Traditional autoregressive language generation works roughly like this:

token 1
  ↓
token 2
  ↓
token 3
  ↓
token 4
  ↓
...

Every generated token conditions the next one.

That is exactly what makes text generation powerful.

It is also one reason it can be expensive and slow.

If the application does not need a sentence, the whole sequential generation loop can become unnecessary overhead.

Jev takes a different route for the kinds of problems it targets.

TypeSafe says its questions are evaluated in parallel, with all declared outputs produced in a single query. The company reports end-to-end response times of roughly 70–500 milliseconds, though it also notes that its published latency measurements were generally run from laptops on the US West Coast, so those numbers should not be treated as universal end-to-end production latency. [1]

This is the important architectural distinction:

LLM:

question
   ↓
token
   ↓
token
   ↓
token
   ↓
decision hidden inside text


Jev:

state
   ↓
+---------+---------+---------+
| question| question| question|
+---------+---------+---------+
     ↓         ↓         ↓
 decision   decision   decision

You are not waiting for a paragraph to finish so the CPU can discover whether the answer was "yes".

The answer itself is the API.

That feels obvious after you see it.

A lot of good engineering does.

AND THEN THERE'S THE PRICE

TypeSafe's launch materials list Jev at $0.042 per million input tokens, with output effectively free under its published rate card. That is $42 per billion input tokens. Vercel currently lists the model at about $0.04 per million input tokens through AI Gateway, with gateway-specific billing or promotions potentially differing from TypeSafe's direct price. [1][3]

That number is the kind of thing that makes people write "AI is now basically free."

I would not.

Cheap is not free.

And benchmark cost is not total system cost.

But the price is still interesting because Jev is not trying to win the same contest as a giant general-purpose LLM.

It is trying to make small, repeated decisions so cheap that developers stop thinking about the individual decision at all.

That is a different ambition.

Consider an agent loop that needs to decide:

continue?
retry?
ask user?
call tool A?
call tool B?
escalate?

If every branch requires a large language model call, the decision layer itself becomes expensive.

If that decision can be made by a much cheaper specialised model, an architect can put the "expensive brain" somewhere else.

This is where Jev gets interesting.

It is not necessarily trying to replace the brain.

It may be trying to become the nervous system around the brain.

THIS IS NOT A GPT REPLACEMENT

This matters.

Jev is not a drop-in replacement for a general chat model.

It does not generate prose.

It is not designed to write articles.

It is not designed to write a React component.

It is not your coding buddy.

It is not the model you send to when you want:

"Explain quantum tunnelling like I'm five."

Use a language model for that.

Jev's own product positioning is narrower: routing, scoring, classification, verification, branching, guardrails, and similar decisions where the answer space can be declared in advance. [1][2]

That limitation is the whole point.

The modern AI industry often treats generality as the ultimate virtue.

Jev suggests there may be another axis:

specialization for machine-native decisions.

And that's where the name "System One" starts making more sense.

WHY IS IT CALLED "SYSTEM ONE"?

The name refers to Daniel Kahneman's distinction between fast, intuitive System 1 thinking and slower, deliberative System 2 thinking.

TypeSafe deliberately changes the spelling to "System One Model" as a model category, rather than claiming that Jev is literally a biological brain.

The analogy is straightforward:

System One
fast
pattern-based
immediate
decision-oriented

System Two
slow
deliberative
language-heavy
reasoning-oriented

This framing has an important caveat.

Kahneman's System 1 is also associated with bias and error.

TypeSafe is trying to build something different: a fast decision model whose outputs carry calibrated probabilities so software can decide when to trust a result and when to escalate it. The company's own FAQ even addresses the tension directly, saying the name is inspired by the distinction while arguing that System One Models can be engineered for reliability. [1]

That's a much more interesting proposition than:

"We made a faster chatbot."

They are essentially saying:

Maybe software doesn't need every AI action to look like a reasoning transcript.

RLHF MADE MODELS POLITE. RLCD TRIES TO MAKE THEM USEFUL TO CODE.

One of the more provocative parts of TypeSafe's launch is its training philosophy.

The company contrasts Jev's Reinforcement Learning for Calibrated Decisions (RLCD) with RLHF, Reinforcement Learning from Human Feedback, and RLVR, Reinforcement Learning with Verifiable Rewards.

The distinction matters because what you optimise becomes the behaviour you get.

RLHF helped make language models much more useful for human interaction. It rewards outputs people prefer.

That is exactly what you want from a chatbot.

But consider an automated branch:

if confidence > threshold:
    act()
else:
    escalate()

The application does not primarily need a beautifully worded explanation.

It needs an honest estimate of uncertainty.

If the model says "I'm 91% confident" when it is right 64% of the time, your control loop is lying.

TypeSafe's pitch for RLCD is therefore not merely "better probabilities."

It is that calibration becomes an optimization target.

The model should care about whether its confidence corresponds to reality.

That is a fundamentally different goal from sounding convincing.

[1]

CALIBRATED PROBABILITY IS NOT THE SAME THING AS BEING RIGHT

This is one of the most important caveats in the whole Jev story.

People see:

confidence: 0.94

and instinctively read:

the model is correct.

No.

A confidence or probability estimate is only useful if it is meaningfully calibrated for the task and data distribution.

Vercel's current Jev guidance makes the point more plainly: a typed answer can still misinterpret the evidence, and developers should test decisions against known outcomes before allowing them to trigger actions. [4]

That means a 0.94 result should ideally behave like:

among cases receiving comparable confidence, the model is correct at roughly that rate.

Calibration is a statistical property.

It is not a magic truth meter.

This distinction is huge for agent systems.

Because a model that admits uncertainty can be wired safely.

A model that is confidently wrong is much more dangerous.

THE THREE LITTLE BUILDING BLOCKS

Jev's API is especially interesting because it reduces a wide world of natural-language judgement to a small number of question shapes.

1. Choice

Use Choice when your code needs one option from a fixed set.

billing
technical
sales
other

The result can include the selected option, probabilities over the options, and a confidence measure. TypeSafe's docs describe a maximum of 255 options for a Choice question. [5]

This maps beautifully to:

switch (department) {
  case "billing":
  case "technical":
  case "sales":
}

The model does the fuzzy part.

The code does the branching.

That division of labour feels right.

2. Score

Score is for ordered rubrics.

Think:

1 = low
2 = mild
3 = significant
4 = severe
5 = critical

The model evaluates the state against the levels you define.

That is useful when your program wants:

if score >= threshold:
    escalate()

But there is a subtle warning here.

An ordered scale is not automatically a physical measurement.

A "4.3" severity score does not mean the underlying event is literally 43% more severe than a score of 3.

The number is meaningful inside the rubric.

It isn't a universal unit of suffering, risk, urgency or quality.

That sounds obvious.

People still misuse numbers all the time.

3. Noul

Noul is the strangest name and the simplest idea.

You ask whether a proposition is true.

The result is a probability from 0 to 1.

"Did the customer explicitly ask for a refund?"

becomes:

0.87

Your code then decides:

> 0.90 → automatic action
0.60–0.90 → review
< 0.60 → do not trigger

This is perhaps the most important architectural idea in Jev.

The model does not decide the policy.

It supplies a probabilistic signal.

Your code supplies the policy.

That preserves a clean boundary between intelligence and control.

And frankly, that is probably where the model belongs.

THE "SMART IF STATEMENT" IDEA IS BETTER THAN IT SOUNDS

TypeSafe uses the phrase "smart if-statements".

At first it sounds like startup copy.

Then you write the architecture down:

if jev("does_this_need_human_review") > 0.85:
    send_to_human()

and realise what they're getting at.

Traditional code is brilliant at precise rules:

if amount > 1000

AI is useful when the condition is fuzzy:

if the customer appears to be at serious risk of churn

The old solution was:

ask LLM
→ generate paragraph
→ parse judgement
→ hope

The Jev solution is conceptually:

state
→ probability
→ ordinary code

AI becomes a fuzzy predicate inside deterministic software.

That's a fascinating place to put intelligence.

Not above the program.

Inside it.

THE AGENT LOOP IS WHERE THIS BECOMES REALLY INTERESTING

LangChain's September 17, 2026 write-up describes a common agent pattern:

LLM decides
→ tool executes
→ model evaluates result
→ loop continues

The problem is obvious.

Every little decision can require another generative model call.

LangChain presented Jev specifically as a way to add a specialised decision step into that loop, reporting TypeSafe's claims of up to roughly 200× faster inference and 400× lower cost than comparable LLMs on classification-oriented tasks. [6]

Those are vendor-linked comparative claims, not laws of physics.

But the architecture is what matters.

Imagine:

                  +------------------+
                  |    LLM Planner   |
                  +--------+---------+
                           |
                           v
                    call tool
                           |
                           v
                  +------------------+
                  |       Jev        |
                  | "what next?"     |
                  +--------+---------+
                           |
             +-------------+-------------+
             |             |             |
             v             v             v
           retry          stop        human

Now the expensive model can spend its compute on the places where language and reasoning are useful.

The cheap specialised model handles the repetitive control decisions.

That is not "replace the LLM."

It is:

stop using a novelist to operate a traffic light.

VERCEL GETS THE IDEA IMMEDIATELY

Vercel added Jev to AI Gateway on September 16, 2026.

Then, on September 21, Vercel announced support for an HTTP API alongside its TypeSafe client and AI SDK path. Vercel's current integration lets applications send a shared state plus named questions and receive the typed results back through the gateway. [3][7]

That matters because integrations tell us more than launch-day tweets do.

A model becomes infrastructure when other infrastructure starts treating it as a primitive.

LangChain wrote about using Jev in an agent harness.

Vercel put it behind AI Gateway.

Cloudflare has a model catalogue entry for typesafe/jev.

OpenRouter lists Jev models as well.

The ecosystem is already behaving as though the interesting unit is not:

"Let's chat with Jev."

It is:

"Let's insert Jev into an application."

That is a very different adoption path.

CLOUD PROVIDERS ARE QUIETLY TELLING US WHAT THIS IS FOR

Cloudflare's current model documentation describes Jev as a structured evaluation model: state goes in, typed Noul, Choice and Score answers come out, with calibrated answers including probabilities and confidence. [8]

That vocabulary is revealing.

They don't market it like:

Jev: your next AI companion

They document it like:

Jev:
a function your software calls

That is perhaps the strongest clue about where this category could go.

The model doesn't need a homepage where humans spend ten hours talking to it.

It needs an API where software spends ten million tiny calls.

And that could be a much bigger market.

THE "ONE MODEL DOES EVERYTHING" ERA MAY BE HITTING A LIMIT

For years, the mental picture of AI was:

one huge model
       |
       +--> write
       +--> reason
       +--> classify
       +--> route
       +--> search
       +--> decide
       +--> explain
       +--> code

Jev proposes:

          AI SYSTEM
              |
     +--------+--------+
     |                 |
     v                 v
  LLM / reasoner     Jev
  language work     decisions
     |                 |
     +--------+--------+
              |
           software

This is not necessarily a fragmentation of AI.

It could be specialization.

We already do this everywhere else.

A CPU isn't used for every operation.

A database doesn't render the UI.

A CDN doesn't calculate payroll.

The most expensive general-purpose component isn't automatically the correct component for every subproblem.

So why should language models be?

THE MODEL MAY BE SMALLER. THE IDEA IS BIGGER.

This is the part of the launch that could easily be missed.

A new model usually arrives with the expected checklist:

benchmark score
context window
reasoning
coding
multimodal
price

Jev makes the checklist look strange.

You ask:

Does it generate text?

No.

Can it explain itself?

Not in the normal chat sense.

Can it replace GPT or Claude?

No.

Why should I care?

Because your application probably contains hundreds of decisions that are not realy "write me a paragraph" problems.

That could be the category.

Not another model.

Another primitive.

THERE IS A SUBTLE DIFFERENCE BETWEEN JSON MODE AND JEV

This distinction matters for developers.

A normal LLM can be instructed:

return JSON

and usually you can get something like:

{
  "action": "retry",
  "confidence": 0.87
}

So why not just stop there?

Because the string-generating model still generated the path to that structure.

Jev's thesis is that the answer space itself is constrained at the model interface.

TypeSafe describes the outputs as type-safe structured values defined in advance, rather than generated strings that then have to be parsed and validated. [1]

That doesn't mean "JSON mode is useless".

It means they optimise different layers.

LLM + structured output:
generate text-like tokens
→ parse
→ validate
→ use


Jev:
evaluate typed question
→ receive typed answer
→ use

The difference is not cosmetic.

It potentially changes how much compute is spent producing the answer.

WHAT "NO HALLUCINATIONS" REALLY MEANS HERE

This phrase is going to get abused.

TypeSafe says Jev "can't hallucinate" in the sense that it doesn't generate arbitrary strings and its output schema is fixed. It also notes that schema matching is mathematically guaranteed. [1]

That claim should be read carefully.

A model can still be wrong about the state.

It can misunderstand the evidence.

It can choose the wrong category.

It can assign a bad probability.

What Jev removes is a specific failure mode:

"What is the next tool?"
→ "Sure! I'd be delighted to..."

or:

"return one of these five values"
→
some sixth string nobody defined

The model can still make a decision error.

It just cannot invent a new type at runtime.

That is an important difference.

And for software, type safety is not a tiny quality-of-life feature.

It is the border between:

data

and:

surprise

THE BIGGEST DEAL HERE IS NOT COST

It is control.

A general LLM is incredibly flexible.

That flexibility is its superpower.

It is also its attack surface.

Ask a model to choose a tool, and it can generate text.

Ask it to choose one of three typed actions, and suddenly the code has a bounded control surface.

That means your architecture can look like:

LLM
 ↓
propose
 ↓
Jev
 ↓
gate
 ↓
code
 ↓
execute

Jev becomes a kind of AI circuit breaker.

Not necessarily because it is smarter than the main model.

Because it has a narrower job.

Narrowness is underrated in software.

THE SECURITY ANGLE IS REALLY INTERESTING

Imagine an agent wants to delete a production database.

A generic model can be prompted to decide:

"Should I proceed?"

But you still have to parse and interpret whatever it says.

Now imagine the application defines:

requires_human_confirmation = Noul(...)

and:

if probability > 0.75:
    require_human()

The final authority remains deterministic code.

The AI produces a signal.

That signal does not directly become an uncontrolled tool call.

This is not a security guarantee.

Bad thresholds can still be bad.

Bad state can still be bad.

A malicious prompt can still poison the state.

But the design gives software a native place to enforce policy.

And that feels much closer to how production systems should treat probabilistic intelligence.

THE HIDDEN SUPERPOWER: MANY QUESTIONS, ONE STATE

One of the most useful parts of Jev is that you can ask several questions about the same state.

For example:

State:
support ticket

Questions:
- which department?
- how urgent?
- refund requested?
- account cancellation mentioned?
- human review needed?

The idea is that these questions can be evaluated in parallel rather than requiring five separate model calls. TypeSafe's launch materials explicitly present parallel evaluation as part of the system design. [1]

That creates a nice software pattern:

shared state
    |
    +--> question A
    +--> question B
    +--> question C
    +--> question D

The expensive part of reading the state can be shared.

The outputs are decomposed.

The application recombines them.

This is basically data-parallel classification for application logic.

Which sounds nerdy.

Because it is.

And I mean that as a compliment.

WHY AGENTS MAY NEED THIS MORE THAN CHAT APPS DO

A chatbot can spend two seconds generating a good response.

The human is still reading it.

A backend agent that needs to make forty small control decisions per second has a completely different requirement.

Imagine a workflow with:

route
→ classify
→ verify
→ choose tool
→ validate result
→ decide retry
→ decide escalate

A giant LLM at every branch can become the slowest part of the system.

This is why Jev's target market makes sense even if Jev never becomes famous with ordinary users.

Humans don't need to know Jev exists.

The software does.

That is the kind of technology that can become ubiquitous while remaining almost invisible.

Think DNS.

Think TLS.

Think a database index.

Nobody asks their browser:

"Hey, which B-tree are you using?"

Infrastructure works precisely because users don't have to care.

Jev is aiming for that kind of invisibility.

At least philosophically.

THE STRANGEST PART: IT MAKES AI LOOK MORE LIKE CODE

A giant LLM feels like an oracle.

You ask.

It speaks.

You interpret.

Jev feels more like:

function evaluate(state, question):
    return typed_probability

That is a much more comfortable shape for conventional software.

And maybe that is what has been missing.

We spent years asking:

How do we make software talk to AI?

Maybe the better question is:

How do we make intelligence look like software?

That is almost the inverse problem.

And inversion is often where the interesting stuff happens.

THE WIKIRACING DEMO GIVES AWAY THE PHILOSOPHY

TypeSafe's launch article includes a Wikiracing demo where the model must choose among links while traversing Wikipedia toward a target.

The company highlights a practical advantage here: the available choices can be numerous, and the model's output remains constrained to the declared options. TypeSafe says Jev supports up to 255 choices in a Choice question and uses a two-stage approach for higher-cardinality decisions. [1]

This matters because a generative LLM can produce a plausible-looking link that simply does not exist.

In Wikiracing, that is not a minor issue.

One hallucinated link breaks the path.

A typed choice over actual options cannot invent an eleventh URL when the program only supplied ten.

Again, Jev isn't magically correct.

But the architecture eliminates a whole class of errors.

That's what good abstractions do.

They don't solve every problem.

They make some problems impossible.

AND THE DOOM DEMO IS EVEN MORE REVEALING

TypeSafe also showed a Doom demo using structured game state rather than feeding the model raw pixels. The company described Jev making decisions at high frequency and estimated around $7 per hour for ten queries per second under the setup they described. [1]

The useful part is not whether a Doom bot is a great benchmark.

It isn't.

A deterministic bot could probably beat it.

The point is what happens when "intelligence" becomes cheap enough to insert into a real-time loop.

That is a very different vision from:

send prompt
wait
read answer

It is more like:

game state
→ intelligence
→ action
→ new state
→ intelligence
→ action
→ ...

At 100 milliseconds, 10 calls a second stops sounding absurd.

At a few cents per million input tokens, the economics start looking stranger still.

The intelligence becomes a component.

Not an event.

JEVOUS? NO. JEVONS.

There is a little joke hidden in the name.

TypeSafe says Jev is named after economist William Stanley Jevons and references the Jevons paradox: when a technology becomes more efficient, total consumption of that resource can increase because the lower cost unlocks more usage. [1]

This might be the most revealing part of the whole launch.

TypeSafe is not merely trying to make AI cheaper.

It wants cheap intelligence to create more places where intelligence gets used.

That is a radically different growth model.

Suppose an AI judgement costs $0.20.

You will think twice before putting it inside every request.

Now suppose it costs:

$0.000042

per million? Wait — this is exactly where humans should stop and calculate units carefully.

Jev is $0.042 per million input tokens.

That means one billion input tokens at the listed rate is $42.

The relevant point is not that every call is free.

It is that the cost can be low enough for developers to consider AI decisions in places that previously used brittle hand-written rules or no intelligence at all.

That is the Jevons-shaped bet.

Cheaper intelligence may create more demand for intelligence.

THIS COULD CHANGE WHAT "AI AGENT" MEANS

Today's agent architecture often looks like:

LLM
+
tools
+
memory
+
prompt
+
loop

A future architecture might look more like:

LLM
+
System One models
+
tools
+
memory
+
deterministic code
+
policy engine
+
retrieval
+
observability

That is a more modular AI stack.

The model becomes one component among several.

And that might actually be the path to better agents.

Because an agent is not just "a smart model."

An agent is a control system.

Control systems care about:

feedback
state
thresholds
failure modes
latency
stability
observability

Those words sound much more like systems engineering than chatbot design.

Jev seems built for exactly that world.

BUT HERE'S WHERE I WOULD PUSH BACK

The hype is moving faster than the evidence.

TypeSafe's launch page reports striking comparative numbers, including up to 193.6× faster and 444.6× cheaper on its workflow evaluations. Vercel repeats those figures in its launch coverage. [1][3]

Those are worth investigating.

They are not worth worshipping.

TypeSafe itself gives useful caveats.

The workflow evaluations were designed by people on its model-capabilities team.

The LLM comparison uses specific reference models and a wrapper designed to produce structured decisions.

TypeSafe explicitly says those choices can introduce bias, and says it expects the reported gains to be toward the high end of real-world results. [1]

That honesty actually makes the launch more credible to me.

The correct reaction is not:

"444× cheaper! It's over!"

It is:

"Interesting. What workload shape produced that number?"

Because benchmark geometry matters.

A model that is 400× cheaper for a narrow classification loop does not mean your entire AI application is 400× cheaper.

THERE'S ALSO A PROBLEM WITH "CALIBRATED"

Calibration has a dataset problem.

A model can be calibrated on one distribution and degrade on another.

Your production traffic changes.

Your users change.

Your prompts change.

Your product changes.

Your abuse patterns change.

A model can be beautifully calibrated in a benchmark and less calibrated in production.

That's not a Jev-specific flaw.

It's a general machine-learning problem.

But Jev makes calibration central enough that developers will have to think about it.

Which is probably a good thing.

A weird way of putting it:

Jev turns uncertainty into part of the API contract.

Most AI APIs make uncertainty something you ask for.

Jev tries to make it something you receive by default.

That is a very different engineering culture.

ANOTHER CAVEAT: "CONFIDENCE" IS NOT A SINGLE UNIVERSAL NUMBER

TypeSafe distinguishes probabilities from confidence, and its different primitives expose them differently.

That's important.

A probability over Choice options is not the same conceptual thing as a generic "I'm 84% confident" statement.

For a Choice:

technical: 0.74
billing: 0.18
sales: 0.08

the distribution tells you something about competition between options.

A confidence value can be derived differently from the shape of that distribution.

For Noul, the single probability is itself the primary signal.

Developers should not casually treat every number returned by the model as though it has identical semantics.

This is exactly the sort of boring detail that gets skipped in launch posts and then causes production bugs six months later.

Please don't be that team.

THE 255-CHOICE LIMIT IS A GOOD EXAMPLE OF WHY SPECIALISED APIs ARE HONEST

A generic LLM can pretend it can classify anything.

Jev has explicit primitives and limits.

Choice currently supports up to 255 options in the documented interface, with TypeSafe describing a two-stage strategy for larger cardinalities. [1][5]

That sounds restrictive.

It is.

And that's useful.

Good APIs make the shape of the problem visible.

If your system has 8,000 possible categories, you shouldn't quietly pretend that a single bounded choice is the natural solution.

Maybe you need hierarchy.

Maybe you need retrieval.

Maybe you need two-stage routing.

Maybe you need ordinary code.

The model tells you:

"This is the interface I am good at."

That's healthier than pretending every model is universal.

WHAT HAPPENS WHEN JEV IS WRONG?

This question matters more than how fast it is.

Suppose Jev says:

refund_requested = 0.04

and the user actually asked for a refund.

What happens?

If your code automatically denies the refund, your threshold was too permissive.

If your code sends everything to humans, you've destroyed the automation.

The correct architecture therefore includes a third thing:

MODEL
+
POLICY
+
ESCALATION

The model estimates.

The policy decides.

The uncertain cases go somewhere else.

That could be a human.

A larger LLM.

A more expensive model.

A business-rule engine.

Or simply "do nothing".

This makes Jev look less like a replacement for human judgement and more like a sensor.

Sensors don't decide.

They tell the system what they think is happening.

THE REAL PRODUCT MIGHT BE THE ESCALATION PATH

This is a subtle point I haven't seen discussed nearly enough.

If Jev's killer feature is calibrated uncertainty, then the most important thing is not:

confidence = 0.93

It is:

confidence = 0.43
→ now what?

A serious agent should have a plan for uncertain output.

> 0.9
automatic

0.6–0.9
another check

< 0.6
human / fallback

The actual thresholds depend on the cost of false positives and false negatives.

That means Jev can become part of a selective automation architecture.

Automate the boring obvious cases.

Escalate the weird cases.

This is how humans naturally work.

And perhaps that is why the System One metaphor feels intuitive.

THE QUESTION I THINK MATTERS MOST

The question:

It is whether software is finally ready to stop treating every piece of machine intelligence as a conversation.

For years, the default pattern was:

ask model
→ get words
→ parse words
→ validate words
→ make decision

Jev flips that:

state
→ ask a typed question
→ get a bounded answer
→ let code decide what happens

That is a small interface change with potentially huge consequences.

Maybe Jev becomes the beginning of a model category; maybe it becomes a footnote. Maybe the idea survives while the name disappears. We cannot know yet.

But the bigger change may already be underway: AI systems are becoming less like isolated chatbots and more like collections of specialised components. The model that writes an explanation need not decide whether a workflow continues, and the model that reasons need not route the next tool call.

Years from now, the most interesting thing about Jev might not be its benchmark chart at all.

It might be that somebody looked at an AI agent, deleted the unnecessary paragraph, and asked the computer for the answer it actually needed.

A NOTE ON THE NUMBERS

The speed, price and workflow figures here are primarily TypeSafe's published claims, cross-checked against Vercel, LangChain and Cloudflare. TypeSafe notes that its workflow evaluations have limitations and may represent the high end of real-world gains.

As of September 22, 2026, Jev is very new. The next step is independent testing of calibration, failure thresholds, production latency and fallback cost.

That part is still unwritten.

Sources

[1] TypeSafe AI, "Introducing System One Models & Jev", September 15, 2026.
[2] TypeSafe AI, Jev developer documentation, September 2026.
[3] Vercel, "TypeSafe AI's Jev now available on AI Gateway", September 16, 2026.
[4] Vercel, "What is Jev, TypeSafe AI's System One model?", September 18, 2026.
[5] Vercel, "AI Gateway now supports TypeSafe clients and HTTP API for Jev", September 21, 2026.
[6] LangChain, "Building a Harness with Jev", September 17, 2026.
[7] Cloudflare AI documentation, Jev / typesafe/jev, September 2026.
[8] TechCrunch, "A new kind of AI model from a ChatGPT inventor is thrilling developers", September 18, 2026.

SEO / GEO

SEO title: This AI Model Doesn't Want to Talk to You — It Wants to Run Your Software

Meta description: TypeSafe AI's Jev is a new System One model built for typed decisions instead of text. Here is why its architecture, calibration, price and agent integrations matter.

Suggested slug: typesafe-jev-system-one-model-ai-agents

Keywords: TypeSafe AI, Jev AI, System One Model, AI decision model, structured AI, AI agents, calibrated AI, typed AI, AI routing, AI classification.

GEO questions: What is Jev? What is a System One Model? How is Jev different from an LLM? Does Jev generate text? What are Choice, Score and Noul? How much does Jev cost? How does Jev fit inside AI agents?

About the author

Mahan Tavakoli (MahanKenway) is a programmer and technology enthusiast based in Tehran. He writes about AI infrastructure, developer tooling, software architecture, security, and the weird ideas that sometimes turn into the obvious future.

GitHub: github.com/MahanKenway