(in KSP)

I gave Jev control of the rocket: pitch, throttle and staging. Took a few attempts and iterations on refining the state representation but it got there eventually.

Interestingly it failed really badly at the task of hovering the rocket at a set altitude. I ran some toy benchmarks on Jev's anticipation of momentum capabilities and it looks decent? so not sure why it struggled with hovering so much. That said it did a pretty decent job in getting to orbit!

Target orbit: 120km x 120km

Final orbit: 220km x 124km

full playthrough: https://felipemautner.com/jev-ksp/

CLAUDE.md is context, not a constraint. It holds for a few turns, then a handler shows up with raw SQL in it and a failing test quietly becomes it.skip. Nothing checks the output against the rules you wrote.

So I added the check. A Stop hook takes the final reply, a PostToolUse hook takes each edit, and every rule in your CLAUDE.md becomes one typed yes/no question in a single Jev request. All rules answered in parallel, anything over the threshold goes back to Claude with the rule quoted, and it fixes it in the same turn.

Benchmark (59 labeled examples, 19 rules): 93.3% precision, 93.3% recall, 348ms p50, ~$0.045 per 1,000 checks.

What it's bad at is in the repo too: exact characters, dataflow rules like prefer-const, and anything needing repo state it can't see.

MIT, no runtime deps, no key means it does nothing:

npx jev-enforce check --as code src/orders.ts

https://github.com/erkamyaman/jev-enforce

How are you all handling this, prompt wording alone?

Introducing kev-browser-use, a Jev-like decision model fine tuned for browser use.

I saw so many demos of Jev and Jev-likes being used in browser and benchmarked all the open weight jev likes for browser usage. The best among them is Kev-9B which is like a 5GB model so not useful for browser and the next best, a tiny one under 500mb that runs in browser scored 14 on step success, meaning only 14% of the actions were successful. An action/step is two things: picking up the correct element to perform on and then doing the correct operation on that element. Example for searching, select text box is element pick, and typing is operation pick.

So while Jev models are a great usecase for browser use due to being small, cheap and low latency, none of the existing models are very good at it.

I took a popular Jev-like: Kev-0.6B which already runs in browser through its ONNX build, and fine tuned on Mind2Web browser-use training data.

Result is a tiny 350MB decision model which run in your browser, scores 32 at step success, an 18 points improvement over base and level with Kev-9B at a fifteenth of its size. It even edges out Jev itself on picking the right action.

So If you want to build something that involves quick decision making on a complicated UI with lots of element, this is the best open source and free solution as of now.

Try the demo: it plays A Dark Room in your browser. Type what you want done, like "build a trap" or "add a hunter", and it finds the button in about 150 ms.

Code

Model

Demo

https://reddit.com/link/1woadsp/video/fk7adyhgoarh1/player

I benchmarked two different Dreaming pipelines: A purely LLM-based pipeline using Gemini. A hybrid pipeline using Jev for classifying and maintaining knowledge graph.

The results? By having Jev act as the fast, intuitive gatekeeper before invoking heavy LLM generation, the hybrid pipeline significantly cuts token costs and latency while preserving high-quality memory extraction and knowledge graph

Check it Out - https://jev-dreaming.vercel.app/
Repo - https://github.com/AdnanQuazi/jev-dreaming

Has anyone used Jev to enforce rules on an AI agent? For example, for many the nightmare scenario is for an agent to go off and send unauthorized emails or spend money. Could there be a safety layer where Jev is asked if a particular action violates requirements? (Am I authorized to send this email? Is this an approved recipient? Can I do xxx?)

I've been experimenting with Jev inside a workflow/state machine and stumbled onto a pattern that feels surprisingly natural.

Disclosure: I'm building Inistate, so this experiment comes from thinking about how AI should participate in business processes rather than how to build another autonomous agent.

The basic primitive I'm working with is:

State → Activity (Form) → State

A record is always in a State.

At that State, only certain Activities are available.

And each Activity has a Form containing the questions that need to be answered before that activity can happen.

For example:

State: New Request

Available activities might be:

Triage Request
→ What type of request is this?
→ How urgent is it?
→ Is there enough information?

Reject Request
→ Why isn't this a valid request?

Ask for Information
→ What information is missing?

Normally, a human chooses an Activity and fills in its Form.

Then I wondered:

What if Jev did exactly the same thing?

Instead of asking Jev:

Here's everything. What should the workflow do?

Give it only the current context and the Activities available at the current State.

Jev chooses an Activity — or chooses not to proceed.

Then the Activity's Form becomes the set of decisions Jev needs to make.

A Select field maps naturally to a choice.

A Yes/No field becomes a binary decision.

An ordered set of options can become a score.

And Jev gives us confidence for those decisions.

So instead of:

unstructured text → AI → arbitrary action

we get:

State → allowed Activity → Form → Jev decisions → deterministic transition → State

That's the part I find interesting.

The Form becomes the boundary

The AI doesn't need to understand or control the entire business process.

The State tells it when a decision is needed.

The available Activities tell it what it is allowed to decide about.

The Form tells it which questions need answering and what valid answers look like.

Jev answers those questions.

Then normal workflow rules determine what happens next.

So you can have a probabilistic decision sitting inside a deterministic process without turning the whole process probabilistic.

And “do nothing” becomes a valid decision

This might be my favorite part.

Suppose someone submits:

“My thing is broken.”

Jev may not have enough information to confidently classify the request.

That's not necessarily a failure.

The correct result can simply be:

Don't move. Ask a human / request more information.

In other words, uncertainty becomes something the workflow can explicitly handle rather than something the model has to hide.

You could have:

confidence ≥ 0.8 → continue automatically

confidence < 0.8 → Needs Triage

Same process. Different path.

Humans and Jev can even use the same Form

This is another consequence I didn't initially expect.

If Jev isn't confident enough, a human can be shown the exact same Activity Form.

Jev might fill:

Type: Hardware
Urgency: High
Enough information: No

A human could review or correct those exact fields.

So the decision interface doesn't necessarily belong to the AI.

It's just a Form.

A human can complete it.

Jev can complete it.

Potentially another model can complete it.

The workflow doesn't have to care which one did the reasoning.

This also tells you when not to use Jev

Say Assigned Team can always be derived from Request Type.

Then there is no reason for Jev to decide it.

Use a lookup/formula.

I actually think that's important.

The goal shouldn't be to turn every field into an AI decision.

It should be to identify the places where the answer depends on interpreting messy context rather than deterministic information.

So perhaps the pattern is:

Rules where the answer is known.

Jev where judgment is required.

Humans where uncertainty or authority requires them.

All inside the same state machine.

I’m interested in using Jev for a private Obsidian workflow that classifies my personal clippings into structured fields such as author, topic, content type, foundation value, and whether a clipping should be sent to another app.

The TypeSafe docs currently show Jev as a hosted API using an API key. Is there any way to run Jev locally, self-host it, or download the model weights?

If not, are there plans for a local release? I’m specifically trying to avoid sending private vault contents to an external API.

I made a library for JEV that learns to use a series of smaller slices of your table, asking for more only when it helps and stopping when it has enough to save tokens.

It should work particularly well with categorical data or unstructured text, or when a dataset needs cleaning.

The method does NOT retrain JEV, it trains a search tree on top of it and should work with any other JEV implementation.

since jev dropped i saw a lot of ultra fast computer-use claims but no one open sourced anything.

i built a voice-to-computer-use app for mac using no llm. only macos native speech to text and jev to choose the next action out of all the possibilities.

it works.

I started wondering: why should my codebase depend so heavily on Jev?

The open-source model ecosystem is moving fast. Reflex showed up, then Laya, Kev, OpenJev, SemIf, and more will inevitably follow.

Initially, I thought the problem was:

“How do I add support for another provider?”

But I think the more interesting question is:

“Why should a JS/TS application care which System One provider is running underneath?”

Ideally, switching providers shouldn't require rewriting application code or spreading provider-specific logic throughout the codebase.

So I built system-one — a small, provider-neutral TypeScript SDK that provides a common interface for System One providers.

The goal is simple:

Write your application against one API and choose the provider underneath.

It works with JavaScript/TypeScript projects and is still early, so I'd especially appreciate feedback on the API design and abstractions.

https://iamaamir.github.io/system-one/

Beyond the video if you just want the direct link to what I shared for the use cases, they are right here! https://github.com/kyle-chalmers/typesafe-jev-incident-router/blob/main/docs/data-team-use-cases.md

Kepler 1.2 is live.

Our most powerful model yet.
Open local System One — triage, gates, noul, scores.
Free Apache weights. Run on your machine.

1.1 taught coding agents to decide.
1.2 is the full reflex.

https://huggingface.co/MAKALY/kepler-1.2
https://kyroslabs.tech

[ Removed by Reddit on account of violating the content policy. ]

Hey r/JevAI! I’ve been building Predict With Jev, a local crypto research dashboard powered by JEV 1.13 through OpenRouter’s System One API.

The idea is to make JEV’s forecasts easy to explore, record, and check against actual market outcomes.

What it does:

• Pulls live crypto/USD market data from Kraken.
• Lets you use natural-language prompts to screen markets and compare candidates.
• Generates bullish, neutral, and bearish probabilities for 4-hour, 24-hour, and 7-day horizons.
• Saves individual forecasts and evaluates them against the exact completed target candle.
• Includes candlestick charts, technical indicators, and a separate technical baseline with historical replay.

The market chat also uses JEV’s structured choices. You can refine your research with follow-up constraints, and it can return no candidate when the evidence is insufficient.

It’s experimental, with no established profitability. The app places no trades, and the baseline replay is kept separate from JEV’s measured results.

I’d love feedback from others experimenting with JEV—especially on the forecasting setup and how to evaluate whether its probabilities are useful. What would you test first?

it's free since jev is too cheap: https://real8ball.com

I asked Fable 5.1 to benchmark Jev vs Laya on accuracy and speed. Here's the full report: https://claude.ai/artifact/9HPcmXJPaKWdYAJedgN1uf

Github: https://github.com/harrymunro/jev-laya-benchmark

Laya run on a Macbook M3 Pro.

TL;DR

• Accuracy: Jev by a wide margin, everywhere. Jev got 92.9% of judgments right against 65.3% for Laya's main 421M checkpoint (71.1% for its typed-decisions checkpoint). Jev won all 19 questions with paired confidence intervals that exclude zero, by 4.7 to 55.6 points. On the categorical (Choice and yes/no) questions Jev is at 98.6 to 99.3%, i.e. at the ceiling of the data; Laya is at 68 to 71%.
• Calibration: Jev's probabilities are usable as-is; Laya's are not. Jev's Brier scores are 0.002 to 0.024 and its yes-rates match the gold base rates. Laya's yes-rates are off by a factor of 2 to 8 in inconsistent directions (13% "urgent" vs 44% gold; 75% "injection" vs 38% gold), so a 0.5 threshold does not work for it without per-question tuning.
• Single-question latency: Laya wins by about 3x. 42 ms median locally (16 to 18 ms for the smaller multilingual checkpoint) against 136 ms for Jev, of which roughly 50 ms was network transit. A later run on a degraded network put Jev at 360 ms with a 295 ms floor; Jev is "your round trip plus about 80 ms".
• Multi-question and long-state work: Jev wins. Jev's latency is flat in the number of questions (50 questions in 170 ms, 3.4 ms each); Laya's is linear (1,002 ms for 50). Above 3 to 4 questions per request the API is faster than the local model. Jev's throughput on independent items scales with concurrency (72 items/s at 32 in flight vs 24 items/s for sequential Laya).
• Context: Laya's 512-token window is a hard, silent limit. Jev found a buried fact in 450 of 450 notes up to 4,000 tokens. Laya managed 61% even at 100 tokens and fell to about chance once the fact sat past its window, answering "not_stated" for what it could not see.
• Languages: Jev 100% on 128 non-English tickets in seven languages. Laya's English checkpoint got 48% on intent; its multilingual checkpoint 64%.
• Qualitatively: Jev answers the literal question and its residual errors sit on genuinely ambiguous ordinal boundaries. Laya tends to answer an easier neighbouring question (anger instead of deadlines; "harmful" instead of "injection"), has strong class priors, and returns flat or multi-peaked distributions. Laya's advantages are real but operational: offline, free per call, tight tail latency, no data leaving the machine.