Jev AI Decision Model, A Guide for Teams Building Agents

Jev launched publicly on September 15, 2026. Within three days it had shipped integrations on Vercel AI Gateway and Cloudflare Workers AI, gone live on OpenRouter, and drawn enough developer traction to make “Jev AI” a live search topic. Our clients started asking inside 48 hours whether to adopt it.

Our AI architecture practice spent the week reviewing the public benchmark evidence, modeling the cost stack against four LLM baselines, auditing the integration paths, and running a founder provenance check. This is what we found and how we would advise a product team looking at Jev today.

If you are new to the agent stack question this piece assumes, our primer on what an AI agent actually is is the shortest way in.

What Jev AI actually is

Jev is a decision model from TypesafeAI. It does not generate text. You send it application state plus a typed question and it returns JSON in one of three shapes.

• Choice. Pick one option from N candidates.
• Score. A numeric rating on a bounded scale.
• Noul. A probability from 0 to 1 that a yes or no statement is true.

The full API contract lives at POST https://api.typesafe.ai/v1/systemone. OpenRouter lists the same model as typesafe/jev-1.13; confirm the request shape in your account docs before implementation.

Fig 1 – Decision Model Request Flow

Application state and typed questions flow into Jev, then return Choice, Score, and Noul shaped outputs that the app can route to an automated action or human review.

Decision models as a category

The category matters more than any single model in it. Decision models occupy the middle of a three tier AI stack.

• Embedding retrievers sit below. Cheap and fast. They answer “which of these is most similar” well.
• Decision models sit in the middle. They handle typed classification at millisecond latency.
• LLMs sit above. Capable of any task, with unpredictable latency, output cost, and structured output failures.

Decision models handle the classification work that LLMs are overqualified for. Latency lands in milliseconds. Output shape is deterministic. Cost scales with input tokens alone.

Fig 2 – Three Tier AI Stack

Embedding retrievers handle search and recall, decision models handle routing and classification, and LLMs handle generation, reasoning, and explanation. Jev sits in the decision model tier.

Architecture under the hood

TypeSafe describes Jev’s architecture in their own words. New model architecture. Parallel sampler for efficient serving. New training method they call Reinforcement Learning for Calibrated Decisions (RLCD). They do not publish the base model or weights. Zero shot classifier work in the open source world (GLiNER, GLiClass, and mmBERT) predates Jev and sits in similar problem space, without confirming Jev’s exact internals.

RLCD is designed to calibrate probabilities across many decisions. When Jev reports 82 percent across a group of similar decisions, the option wins about 82 percent of the time. Individual answers can still miss. Calibration is a statistical property across the group, not a guarantee for one call.

The parallel sampler is what makes throughput work. In plain terms, Jev can answer several typed questions inside a single request without paying the full cost of each one. One API call can carry a bundle of related questions (pick a tool, rate the confidence, decide whether to hand off to a human) at close to the cost of a single question.

That combination, calibrated typed output and cheap parallelism per request, is why the pricing math in the next section works out the way it does.

Our Jev AI cost model against four LLM baselines

TypeSafe’s launch post claims 193.6x faster and 444.6x cheaper on its own workflow evaluations, and launch coverage rounded that to a “100x cheaper” headline. Neither figure holds up against the models teams actually use for classification work. We built the cost model against four baselines using published prices and a 750 input token routing call as the reference workload.

Workload assumed for the cost per 1,000 decisions column is 750 input tokens and 12 output tokens per decision. Jev returns typed JSON with no billed output tokens. Pricing uses published standard API rates available at time of writing, not discounted batch, cached input, promotional, regional, or priority or fast mode rates.

Jev output is priced at zero on OpenRouter. That is the change that matters for classification workloads. When output pricing goes to zero, you stop paying the LLM tax on structured decisions. A Claude Haiku 4.5 call returning a 12 token JSON payload spends about $0.06 per 1,000 decisions on the output side alone.

Fig 3 – TypeSafe Workflow Accuracy Versus Cost Benchmark

TypeSafe’s published workflow benchmark plots Jev against LLM baselines on average workflow accuracy versus cost. Treat this as useful vendor evidence, not proof for your workload. Clixlogix is running a separate shadow test before making production accuracy claims.

A production example

Consider a mid size SaaS running 10 million agent routing calls per month.

• At the Claude Haiku 4.5 rate, monthly bill of $8,100
• At the Gemini 3.5 Flash Lite rate, $2,550
• At the GPT-5.6 Luna rate, $1,640
• At the Jev rate, $320

Over 12 months, the delta between Haiku and Jev is $93,360. Against Flash Lite the delta is $26,760. Against GPT-5.6 Luna it is $15,840. All three are worth the switch. The integration cost is the same in either case. Roughly one engineer week to swap a routing call for a typed decision call, plus a week of shadow traffic to validate accuracy.

• Payback against Haiku is under two weeks
• Payback against Flash Lite is closer to two months

Even the 130x gap in our own table requires comparing against GPT-5.6 Sol, which no serious team runs at classification volume anyway.

The tool earns its slot in the routing step at the honest 5x to 26x cost gap. The headline cost multiples do not match the workloads teams actually run.

The third cost worth naming

LLM structured output failures. Structured output retries should be measured in your proof, because retries affect both latency and cost.

Jev returns typed output by construction. The reliability property has a cost side effect. It shows up in production telemetry as fewer null pointer exceptions in the routing step.

Fair baselines beyond LLMs

Comparing Jev only against LLMs flatters Jev. For any classification workload, the honest set of alternatives is wider.

• Rules and regex. Fastest and cheapest. Works when the taxonomy is well bounded. Nuance, drift, and edge cases push it toward failure.
• Embedding retrieval with cosine matching. Cheap and fast. Works for finding the closest match among a fixed set of items. Grows brittle as the taxonomy grows.
• Fine tuned classifiers on your own data. BERT family or similar, trained on 5,000 to 50,000 labeled examples from your workload. Beats zero shot approaches on the specific task once you own the training pipeline and dataset upkeep.
• Small local models. GLiClass, GLiNER, mmBERT, or a small Qwen variant running on your infrastructure. No API cost, no data egress, similar order of magnitude latency to Jev.
• Jev or a competing decision model. Best when you want managed infrastructure, wide coverage generalisation, and calibrated probabilities without owning training pipelines.
• Frontier LLM. Best when the task requires open reasoning, synthesis, or explanation.

Any credible Jev proof runs against at least two of these baselines. Start with rules and regex. If they win the whole architecture question changes.

Where Jev AI works, agent routing and content moderation

Three use case families show up consistently across public benchmark repos, vendor docs, and integration writeups.

AI agent routing

The public benchmark at github.com/iammrduncan/typesafe-ai-benchmark ran 480 Jev dispatches and 476 Qwen 3.8 27B dispatches on Cerebras across seven synthetic workloads including smart home command interpretation, tool selection under ambiguous state, approval flows, and multi step orchestration.

Why p95 matters more than p50 for agent products. In any agent framework, the routing decision sits on the critical path between the user’s input and the first visible response. A 452 ms p95 routing call means 5 percent of users wait longer than 452 ms just for the router to decide what to do. Chain three or four such calls in a longer agent flow and the tail latency compounds into a slow experience.

Dropping p95 from 452 ms to 336 ms across the routing step removes 116 ms of tail from every long tail interaction. For a chat product where the perceived speed target is 1000 ms to first token, that is 12 percent of the entire budget freed. Teams already thinking about agentic strategy on existing systems recognize this budget pressure.

AI content moderation

The progression to test in a proof.

1. Teams start with a small fast LLM for moderation classification.
2. It handles the easy cases and misses subtle policy violations.
3. Teams graduate to a larger LLM for accuracy.
4. Accuracy improves and per decision latency climbs, which breaks user flows where publish latency matters.
5. Whether Jev returns accuracy comparable to a larger LLM classifier while keeping latency in the smaller LLM range is the hypothesis to test in the proof.

One documented production case comes from Ryan Vogel, profiled in LangChain’s engineering writeup on Jev as running it for email triage at scale. Email triage runs on the same classification shape as review moderation. Both are bounded typed decisions at high throughput with a hard latency budget.

For an e commerce review workflow, the two questions to test in a proof are whether Jev’s accuracy holds against the site’s actual policy taxonomy and whether the queue clears at peak reviewer volume. Getting either wrong is one of the failure modes in our writeup on why most agentic AI in ecommerce fails.

Tool selection inside agent frameworks

Kyle Jeong at Browserbase is another of the developers LangChain profiles, running Jev to power browser use agents at a fraction of the previous per decision cost. Browser use agents are the canonical tool selection workload, with typed decisions replacing an LLM router inside a live agent framework.

On a Vercel AI SDK or LangGraph workflow the sequence runs like this.

1. User message arrives.
2. The router LLM classifies intent and picks a tool.
3. The tool runs.
4. The response LLM generates the reply.

The router step can become visible in latency budgets, especially when repeated across multi step flows. It runs a full LLM completion for a classification problem. Replacing the router LLM with a typed Jev call collapses that step from 800 ms to 200 ms. The tool implementation and the response LLM stay unchanged.

On a chat product measuring time to first token, that swap is often the largest single latency reduction available.

Where Jev AI fails by design

Four task shapes where a decision model is the wrong tool by design. Each points at when to reach for a full LLM, an embedding retrieval, or a specialised engine.

Games and long horizon planning

Chess is the clean example. A good chess move depends on evaluating what happens three or four moves ahead. Jev only sees the current board and returns a probability drawn from its training data. It has no engine that plays out the future. Any decision model built this way will play chess badly by design. The same reasoning applies to any workload that requires simulating what comes next. Strategy games, multi step planning, and open ended agents that need to think several turns forward all sit in the same category.

The rule. If the correct answer requires simulating the future, do not use a decision model for it.

Trading and any time triggered loop

A decision model answers the question you send it. If you send the same question every thirty seconds against a market that changes on a much slower cadence, most answers arrive at states that have barely moved since the last call. The model does not know the market is still. It answers anyway. Over hundreds of calls, most of them are noise plus transaction fees. The problem lives in the harness. The model behaves as designed. The same failure shows up in any workflow that fires on a clock schedule when the underlying data changes on a slower schedule.

The rule. Bounded decisions inside a loop that fires faster than the state changes produce noise. Match your decision cadence to the rate of change in the underlying data, or gate the decision on an event signal.

Rich judgment across many dimensions

Scoring a company across fifteen dimensions with weighting depends on reasoning that trades off signals against each other. A decision model returns a typed answer to one bounded question at a time. Narrow scoring against a fixed rubric (does this comment violate rule four, yes or no, score the severity from zero to four) fits that architecture cleanly. Rich synthesised judgment (rank these stocks across quality, momentum, and management) needs a full LLM behind it.

The rule. A full LLM handles reasoning across dimensions and synthesised judgment. A decision model handles classification against a fixed rubric.

One prompt lineage tests

Attempting to determine a model’s base or training lineage from a single loaded question is not evidence. Any probability output on a politically or factually sensitive prompt can be explained by many training paths, RLHF choices, or system prompt effects. A single output cannot distinguish between them.

The rule. Testing model behaviour on sensitive topics needs multiple matched probes with controls. Any single output is a data point, not a lineage claim.

The mental model behind all four

A decision model answers “given this state, which of these options is correct” cheaply and quickly.

It does not answer these three questions.

• “What should the state be next”
• “What reasoning explains this decision”
• “How should I weigh these competing considerations”

If the question requires search, generation, or explanation, reach past the decision model.

Do not use Jev AI when

Compact summary of the failure modes.

Fig 4 – Use Jev And Do Not Use Jev Matrix

Strong decision model fits are bounded classification and scoring tasks. Poor fits require long horizon planning, open ended generation, or complex judgment across many dimensions.

Open source decision model alternatives to Jev AI

Jev is one implementation of an architecture that has been in the open for over a year. Our review of the prior art follows.

Laya

Open sourced by Nandakishor Mohan at github.com/NandhaKishorM/laya, with an accompanying engineering writeup on Dev.to. Similar typed decision interface and problem framing.

Fig 5 – Laya Project Benchmark Summary

The Laya project presents latency, task family accuracy, and selective automation results against TypeSafe Jev. Treat this as open source project evidence, not Clixlogix validation. The right comparison for a buyer is to run Laya, Jev, and an LLM baseline on the same workload.

• Latency runs 32 to 39 ms per decision on a single NVIDIA T4.
• Cost on a single T4 class deployment can be materially cheaper than a hosted API at sustained volume, depending on utilisation.
• Network hop is none. Faster than Jev’s hosted p50 by construction.

If your product already runs GPU inference for other models, Laya uses a modest amount of VRAM and a few hundred milliseconds of cold start.

Decider

Mapika’s Apache licensed reproduction at github.com/Mapika/decider. Public Bespoke benchmark suite.

Mixed results. Decider comes in 2B and 35B variants.

• 2B runs on a consumer GPU with 12 GB VRAM
• 35B needs a B300 class card or hosted equivalent

OpenJev, DIY-Jev, recast

Working reimplementations by AlexWortega, VakeDomen, and closuretxt that predate or match the TypesafeAI launch. Reference implementations for engineers who want to understand the decision model architecture before committing to a vendor.

vLLM upstream support

Worth tracking. Open PR #57250 on the vLLM project adds a DiffusionGemma structured generation mode with a prototype /v1/systemone server. If merged, decision model serving becomes a first class vLLM feature. Any team already running vLLM for LLM inference gets a decision model for free with no new infrastructure.

That is a six to twelve month horizon change. Once merged, hosted decision model APIs lose most of their value premium.

The buying question this raises

• Teams with infrastructure and a small ML platform team should self host Laya or Decider today. The answer gets stronger inside six months.
• Teams without that capability should use Jev’s hosted API for the next 12 to 18 months while the open stack matures.

Do not commit to either as a permanent architectural bet. Both are early.

Jev AI integration paths on OpenRouter, Vercel, and Cloudflare

Four viable routes today. All shipped, none private betas. Which fits depends on where your team already lives.

Model IDs to pin.

Fig 6 – Model IDs To Pin

Provider specific model IDs differ across direct TypeSafe access, OpenRouter, Vercel, and Cloudflare. Pin the exact route before shadow traffic so telemetry stays comparable.

Vercel AI Gateway

The Vercel model listing exposes typesafe-ai/jev with experimental_evaluate in the AI SDK. Promotional pricing runs through September 25, 2026. Do not use promotional rates for long term cost modelling.

Best fit for teams already on Vercel with Next.js frontends. Zero new vendor to onboard. The SDK adds observability without extra work.

Cloudflare Workers AI

The Cloudflare model page exposes typesafe/jev through env.AI.run in Workers, and REST at /ai/run. Dashboard priced.

Best fit for teams running edge compute or with Cloudflare already in the path. Colocation on the same edge network as Workers suggests low latency, though Cloudflare has not published Jev specific percentiles. Matters for latency sensitive agent flows.

OpenRouter

The OpenRouter listing carries typesafe/jev-1.13 as a standard integration. Priced at $0.042 per million input tokens with zero output.

Best fit for teams already routing multiple models through OpenRouter for testing or fallback. Adds one gateway hop which typically costs 20 to 40 ms. OpenRouter lists the model but the exact decision endpoint contract should be verified in your account docs before wiring it up. The direct TypeSafe surface and the OpenRouter surface may differ on how state and questions are shaped.

Direct API

POST https://api.typesafe.ai/v1/systemone with a bearer token.

Best fit for teams that want the shortest network path and are comfortable managing a direct vendor relationship for observability and support. TypeSafe direct pricing is public. Public SLA, rate limits, data retention terms, and enterprise support terms were not found at time of writing.

No joint press release exists between TypesafeAI and either gateway. These are catalog additions on both platforms. All four paths are available enough to pilot this quarter.

Our default recommendation for a new integration is OpenRouter. It gives you a single interface to swap Jev for Laya, Decider, or a competing decision model as the market evolves.

Decision model procurement checklist

A decision model sits inside your customer facing flow. It sees every prompt, every state, and every routing call your product makes. That turns the vendor into a load bearing dependency the team cannot easily rip out later. The questions below decide whether the vendor is safe to depend on. Ask them in writing, before signing, and file the answers with legal and security.

• Data retention. How long do you store prompt and response data, and can we request zero data retention?
• No training terms. Will you commit in writing that our prompt data will not train your models or any downstream models?
• SOC 2 Type II. Can you share your most recent SOC 2 Type II report under NDA, and are any findings still open?
• DPA. Do you offer a standard Data Processing Agreement with a published sub processor list and cross border transfer terms?
• HIPAA BAA. Do you offer a Business Associate Agreement if we handle protected health information?
• Region control. Can we pin inference to a specific region (US, EU) and prevent processing elsewhere?
• ZDR mode. Do you offer a zero data retention mode for regulated workloads?
• Audit logs. Do you provide programmatic access to per request logs (prompt hash, response, latency, cost) for compliance and debugging?
• Support SLA. What are your response time commitments, uptime commitments, and credit terms for outages?

TypeSafe has not published answers to most of these publicly at time of writing. Vercel and Cloudflare inherit their parent platform terms, which cover most SOC 2 and DPA needs and leave the Jev specific data path questions for TypeSafe direct. Request the vendor packet before committing to production.

Reliability engineering for a decision model in production

Any provider will have outages. Any model will drift. What to build into the client before shipping.

• Retries – Exponential backoff on 429 and 5xx. Cap at three attempts. Fall through to the fallback path on final failure.
• Fallbacks – A pinned LLM route ready to serve the same schema when Jev is unavailable. Accept the higher cost during outages.
• Model version pinning – Pin jev-1.13 explicitly, never jev-latest. Vendors upgrade default models without notice. A pinned version protects your telemetry.
• Provider outage behaviour – Instrument your own uptime monitoring against the endpoint. Alert on error rates above 1 percent sustained for five consecutive minutes.
• Schema validation – Validate every response against the expected typed shape before acting on it. Drop malformed responses to the fallback path.
• Confidence thresholds – Set thresholds based on the cost of a wrong answer in your workload. Irreversible actions get a stricter threshold. Reversible actions get a looser one. Human review handles decisions below the floor.

TypeSafe AI founder provenance check

Launch coverage describes founder Diogo Almeida as a co creator, co inventor, or inventor of ChatGPT. TypeSafe’s own launch post is more careful. In Almeida’s words, “I helped build the methods that made language models useful at following instructions. That work ended up as the research behind ChatGPT.”

The primary record supports the careful version.

• Fourth author on Training language models to follow instructions with human feedback, the 2022 InstructGPT paper that introduced the instruction following method behind ChatGPT
• Credited by OpenAI on the GPT 4 contributions page

The provenance is genuine and it sits in the area that matters most for this product. Reinforcement learning from human feedback is the same family of technique RLCD extends, so the founder is working on decision calibration from direct experience with the method that made instruction following work.

Worth separating who said what. The stronger claim lives in press headlines, and the vendor’s own wording stayed accurate. Apply that same separation to the benchmark numbers. Read TypeSafe’s published figures as vendor claims, read coverage of those figures as paraphrase, and run your own eval before either becomes a number in your business case.

Our Jev AI decision framework

Workload shapes where the decision model question comes up

Three common workload shapes where teams end up asking whether to slot in a decision model. These are generic examples, not Clixlogix recommendations for production adoption. Every team should run its own eval before making the call.

Shape one – support ticket routing through a mid tier LLM

Common setup – Routing decisions run on a classifier LLM such as Claude Haiku 4.5, Gemini Flash Lite, or GPT-5.6 Luna, often glued into a CRM workflow. Reported problems in this shape include routing accuracy that plateaus below the team’s target because the classifier is not fine tuned to the team’s own tool taxonomy, and p95 routing latency that shows up as delayed first response in SLA reports.

What a proof should test – Whether Jev matches the classifier LLM’s accuracy on the team’s tool taxonomy. Whether the p95 latency reduction survives shadow traffic. Whether the cost delta modeled from published rates holds at production token counts.

Trade off to weigh – Managed API convenience against vendor lock in and the current lack of published SLA or data retention terms.

Shape two – product review or forum moderation

Common setup – A small LLM classifier handles the moderation step. Teams report subtle policy violations slipping through, which forces human moderators to review every borderline case. Moderator time becomes the largest operational cost in the workflow.

What a proof should test – Whether Jev’s accuracy holds against the site’s actual policy taxonomy at real edge case volume. Whether the moderation queue clears at peak reviewer volume. Whether the false positive rate stays inside the site’s tolerance.

Trade off to weigh – Hosted API cost savings against the data path questions of sending user content to a third party vendor.

Shape three – regulated data path forums and knowledge bases

Common setup – Data residency and privacy requirements rule out any hosted API for member content. Common in healthcare, public sector, and legal workflows. That takes Jev, Claude, Gemini, and GPT off the table by construction.

What a proof should test – Whether an open source decision model such as Laya or Decider delivers acceptable accuracy on the team’s own infrastructure. Whether GPU inference cost and operational overhead sit inside budget. Whether the fine tuning cycle is sustainable with the team’s data ops capacity.

Trade off to weigh – Full control and compliance against the engineering effort to stand up and maintain self hosted inference.

Jev AI adoption checklist

Work through all ten before Jev enters a production path.

1. Assemble 100 gold examples hand labeled by two reviewers with adjudication.
2. Assemble 800 evaluation examples stratified across the classes you care about.
3. Run Jev and two baselines on both sets. One frontier LLM baseline, one cheaper option such as an LLM, a fine tuned classifier, or rules.
4. Build a confusion matrix on the evaluation set for each model. Read the class by class breakdown carefully.
5. Compute Expected Calibration Error (ECE) on the confidence scores. Below 0.05 is production ready for most workloads.
6. Measure p50 and p95 latency under expected load. Include network round trip in the measurement.
7. Measure cost per 1,000 decisions at your actual token counts.
8. Set the confidence threshold below which the system defers to human review.
9. Shadow traffic for one week before promoting the model to the primary decision path.
10. Instrument monitoring for accuracy drift, latency drift, and error rate spikes.

Fig 7 – Adoption Checklist

A Jev pilot should move from a small adjudicated gold set to a larger eval, baseline comparison, calibration checks, shadow traffic, and production monitoring before promotion.

Our Jev AI shadow test

Clixlogix is running a two week shadow test across a support ticket routing pipeline and a forum moderation pipeline this quarter. Results, including confusion matrices, ECE numbers, p50 and p95 latency, and cost per 1,000 decisions on real client workloads, will be published here as an update. Expected date is October 2026.

Accuracy claims in this piece will be updated after that shadow test. Until then, production accuracy is a hypothesis to validate, not a settled claim.

What Clixlogix is doing this quarter

We are rolling Jev into two client pipelines this quarter.

1. Support ticket routing on a shape one workload
2. Forum moderation on a shape three workload

Both fit the shape Jev was built for. Bounded typed decisions, high volume, latency budget under one second, and a business case for cost reduction that is easy to measure.

Everywhere else we are holding. Laya sits on the shortlist for any client with on premise or sovereign hosting requirements. We expect the vLLM upstream work to shift the recommendation toward self hosted decision models across most clients by mid 2027.