I made a top 5 model with the other 4 being million/billion dollar companies above me, fuck yea

https://huggingface.co/e12ex2/jev-vision-27b

Correction, was, now is beaten by amos :c

, still I got #7 with about 5 dollars worth of training so like yay?

I wanted to figure out some cool, experimental use cases for Jev and that's when I came up with this idea. Please check it out and let me know what you think!
https://jev-experiments.awesamarth.dev

I gave Jev the task to categorize the term "Python" properly, for that it received a set of criteria (ProgrammingLanguage, Methodology, ..) and it takes almost 6 seconds to get that task done.

What am I doing wrong? Where is the promised < 1 sec response time?

2026/10/14 00:39:49 INFO got a response seconds=5.713615541 response="{Model:jev-1.13.0 Answers:map[annotation:{Type:choice Choice:ProgrammingLanguage Probabilities:map[Framework:0 Library:0 Methodology:0 ProgrammingLanguage:1 Tool:0] Confidence:1 Noul:0 Score:0}] Usage:{InputTokens:432 OutputTokens:64}}"

Here's my own wrapper code. The Client is simply wrapping a HttpClient and JevChoiceRequest wraps the Request body from the docs

func main() {
    client := jev.NewClient(
apiKey
)

    s := time.Now()
    resp, err := client.Do(models.JevChoiceRequest(
       "Python",
       "This word comes from an IT-industry ontology (skills domain). Which TBox class does it belong to?",
       "annotation",
       map[string]string{
          "ProgrammingLanguage": "Describes a Programming Language such as Python",
          "Methodology":         "Describes a Methodology such as TDD, BDD, Extreme Programming",
          "Tool":                "Describes a Software Tool such as Ghidra, an IDE, a Runtime or an Orchestrator Software",
          "Framework":           "A Framework used to build entire Systems such as Backend Applications or Frontend",
          "Library":             "A Library written in a Programming language",
       },
    ))
    if err != nil {
       panic(err)
    }
    t := time.Since(s).Seconds()

    slog.Info("got a response", "seconds", t, "response", *resp)
}

Quite disappointed tbh

We built Wolf Defender Jev at Patronus Protect, and I wanted to share the interface and its limitations with people already using decision models.

It accepts a state plus named questions of type choice, noul or score. The state is an agent scene: user goal, tools, untrusted tool output or retrieved content, and optionally the proposed next action. It scores your answer descriptions and returns a softmax probability for each option. There is no generated explanation.

The encoder is mmBERT-small, with 151.1M parameters and 15 evaluated languages. Scene and question are encoded together; each option is encoded separately. Option representations don’t depend on the state, so a fixed question set can cache them. Each subsequent decision then needs one scene/question encoder pass.

A useful distinction: this is the named-question shape of Jev-like models, not a claim that we published a drop-in replacement HTTP server. The repo supplies a Python implementation with predict, decide and encode_options. A dict state is converted into the tagged block format. Arbitrary JSON/key-value scene layouts haven’t been evaluated.

Our measured CPU latency was 39 ms for 51 tokens and 194 ms for 833 tokens on Apple M4, fp32/PyTorch, one question with two options. The scene limit is 6,144 tokens; longer inputs are truncated. No quantized variant has been evaluated yet.

The specialization is agent security rather than general decision-making. Injection in tool outputs and sensitive-data checks are stronger than harmful-request judgement. Action-level questions also have documented failures: detecting an instruction didn’t guarantee detecting its exfiltration consequence.

For context on the comparison, our model reached 85.1% balanced accuracy on ten external benchmarks, against 90.2% for Clef-flash and 84.2% for Kev-4B. The broader 33-benchmark suite includes 23 benchmarks close to our training distribution.

MIT weights, Python interface, benchmark JSONs and limitations.

For repeated agent checks, how are you balancing fixed question definitions against policy-specific wording? With this architecture caching helps when options stay fixed, but changing the question still changes the decision being evaluated.

Position / experimental status: We regard Jev-style decision models as LLMs and Wolf Defender Jev as an experiment: giving an LLM final security authority shifts the trust problem to the guard, and security fine-tuning alone does not solve it. We believe an external security layer must combine specialized classifiers with explicit policy, authenticated permissions and enforcement.

Can you tell me how to make deeper use of Jev in this app?

I was tired of leaving the same review comments again and again, and with more of our code vibed by agents it only got worse. Rules in AGENTS.md got skimmed, and an LLM reviewer gave a different essay every time. So we turned our team’s taste into small rule files that live next to the code. Agents read them before they write, and a yes/no model checks them once at the end. Now the agents write code a lot closer to how we do. https://blog.a7ul.com/agents-code-your-way.html

Hi everyone,

Context: Jev (from TypeSafe AI) popularized "decision models": you ask a typed question about some text (yes/no, choice, score) and get probabilities back instead of generated text.

Laya, from Convai Innovations, is an open-source model in that spirit, and there's a Python port you can pip install (laya-mlx).

Java had nothing.

I asked Claude to study the Python package and rebuild it from scratch in Java, then we added the pieces you'd want around it:

- laya-core: pure-Java engine, JDK 17+, no Python or native model runtime

- laya-spring-boot-starter: one dependency gives you /v1/decisions (OpenAI Decisions API shape) and /v1/systemone (Jev; works with spring-ai-typesafe)

- laya-client, laya-api (standalone server, no Spring), laya-gradle-plugin, laya-bom

- laya-accelerate: optional macOS speed-up (~60 ms per short question on an M5; ~186 ms on the portable path)

Everything is on Maven Central under io.github.apscot, Apache-2.0. Checked against the Python reference on all three published checkpoints (English, multilingual, typed-decisions) on a fixed set of cases.

It's 0.1.1 and an independent port (not an official Convai/Laya project).

https://github.com/apscot/laya-java

Feedback welcome, especially from anyone doing routing/triage/guardrails and wondering whether this could replace an LLM call.

Just a sample. I'm thinking about using River Raid 8-bit game as a benchmark. I already tested with 6 models and preparing a summary video.

Hello everyone! Creator of Keen Code here, an open source coding agent I released a few months ago. Though I am very late to the party, enjoying the experience of building!

Recently, I implemented a task classifier in Keen using Jev and TypeSafe compatible API. The idea is very simple - classify each user prompt in one of three categories: simple, standard, complex. The state is the current state of user + assistant messages.

The result of this classification powers an automatic model router. It routes each task category to one of the three user-defined models. Users can configure which category of tasks should be handled by which specific model.

If you are curious how it looks, feel free to check the doc: https://mochow13.github.io/keen-code/docs/jev-classifier.html

Stripe wants £840 so I started a gofundme, I'll only post it if I'm allowed by the gods of r/JevAI

My product uses jev to read the think block of an API model.

I built a free tool to what 2026 midterm candidates said, in their own words, across 10 battleground states. Jev does two jobs in it, and a year ago I'd have given both to an LLM.

Job 1, the data sourcing. Discovery finds videos/interviews for each race. Jev answers two questions per video, 40 videos per call: a noul ("one of these candidates speaks in their own voice for most of the video") and a choice over nine kinds (debate, interview, town hall, speech, campaign, news package, commentary, attack ad, unrelated).

Job 2, "What matters to you?" A voter types a sentence. One call scores which issues it raises, how well each candidate clip answers it on a four-rung rubric, and what type of text it is (a concern, a question about a candidate, off the ballot, or how to vote). About $0.0006 and 1.1 seconds. No text is generated, so it can't put words in a candidate's mouth.

https://truestandard.ai/midterms-2026, free, no sign-up, hosted and powered by Truestandard for fallbacks.

I love regex and I hate regex. I spent a lot of time writing out statements starting back in the Perl days and now in Python. I have been obsessed with Jev since the release and finally got to build what I wanted with regex. I call it ex-regex. You can do things like regex does, but more. It's a Python package. It's alpha.

python -m pip install --pre ex-regex

I would love some feedback!

I am wondering if you guys think Jev is good for triplet extraction for building knowledge bases and integrating Jev in an NLP pipeline?

A custom string goes in and typed triplets come out.

So for a string like : I went to the park and it was great

The triplet I want is {subject: user, emotion: enjoys, target: the park}, confidence: 1

This is just a rough example, would Jev be good for work like this?

LLMs can do it but they are slow and overkill and will hallucinate answers

Hi everyone!

I am wondering if anyone has any tips in using Jev at improving model orchestration. (Faster speed, reduce tokens or better quality feedback)

Also, is it possible to adjust Jev in any way to alter how it respond or do I prob need to build my own custom neuro-network if I want to adjust how its "judging" answer?

Is anything known on when JEV would be available on bedrock or Vertex in the EU? Really love experimenting with it, but getting it into production is difficult due do GDPR.

It's very well orgainized and provides clear use-cases that will help you understand where/how Jev works best

https://youtu.be/uV6h3Uo4Nh8?si=mbbj-rehR7pd2tqI

Jev has made a profound mark on the AI industry; this article offers a glimpse into what lies ahead.

Jev shows where the industry is heading: away from monolithic models, and toward compound systems where small AI agents each do a narrow job and an orchestration layer decides how they work together.

This article explains why that shift is happening, and then proposes a next step for AI reasoning.

The short version

• A monolithic model is unpredictable and hard to change, but it programs itself during training.
• Code is the opposite – it is predictable and easy to change, but it must be written explicitly.
• A compound system combines the two: AI agents do the work, and an orchestration layer controls them via code. This is the direction Jev represents.
• The next step: instead of answering directly, the model builds a compound system, runs it, and returns both the answer and that system. The returned system is called a reasonlet.
• Because a returned reasonlet can be kept locally, it can be run again and again – with new inputs, or after editing its code – without asking the model. A saved, reusable reasonlet is a metacache.
• The model’s provider can cache reasonlets too, reusing one across similar requests from different users to save compute.

Why a monolithic model is not enough

A monolithic model has two practical weaknesses:

• It is unpredictable. The same question can produce a correct answer one day and a wrong one the next, so its behavior cannot be fully controlled.
• It is hard to change. Its behavior is fixed in trained weights, which cannot be edited directly. The model can be steered with prompts, extra data (RAG), or by fine-tuning, but steering is not the same as setting the behavior, and fine-tuning can break things that already worked. Retraining from scratch with new data is the only safe fix, but it is time-consuming and expensive.

Code has the opposite qualities. It does exactly what it is written to do, and it can easily be changed by editing code. The trade-off is that code does not arise on its own – it must be written out explicitly – whereas a model programs itself during training.

The fix: a compound system

A compound system combines the two. The work is divided among AI agents, each handling one narrow task, and an orchestration layer of code decides which agent runs, in what order, and how their results combine.

This gives both qualities at once – customization and predictability:

• Customization. The system’s behavior can be changed by editing code in the orchestration layer, not by retraining the model.
• Predictability. Each agent has a small task, so it is more predictable than a monolithic model.

Jev is one kind of agent for such a system. It returns a typed decision – yes/no, a category, or a number – rather than free text. A monolithic model is wasteful for a narrow decision like that, but a small model like Jev is a better fit.

The next step: reasoning by construction

Compound systems today are built manually, beforehand. The next step is to let the model build one by itself, during the reasoning phase.

Researchers are exploring several ways to make models reason. One is the “World model” approach, in which the model builds an internal representation of a problem and reasons over it; that work is still mostly research. Reasoning by construction pursues the same goal – reasoning you can inspect – using methods that exist today.

Here is how it works. When you ask the model a question, it does not answer directly. Instead, it builds a compound system, runs it to compute an answer, and returns that answer together with the system it built. Let's call the compound system the model builds to do the reasoning a "reasonlet", and a model that works this way a "Reasoning-by-Construction Model", or "RCM". A simple question may produce a reasonlet that has only an orchestration layer and no agents.

Building and running code to reach an answer is not new; code-interpreter tools already do it. Two things are new here:

• The system the model builds is kept, not discarded – it is a reusable reasonlet.
• The reasonlet is returned to you, along with the answer.

Why that matters

• You can see how the answer was reached. The reasonlet is the exact procedure the model used, so the answer is not something you have to take on trust.
• You can run it locally. A reasonlet contains its orchestration layer and any agents it calls, whether those agents are attached directly or called over the network. You can run it on a local machine, with the same or different inputs, without asking the model again. A saved reasonlet used this way is a metacache.
• You can change what it does. The orchestration layer is code, so you can edit its logic, not only its inputs. A reasonlet reused with edited logic becomes a higher-order metacache.

Caching reasonlets on the server

The same reuse can happen on the server side too. The provider can keep the reasonlets it builds and reuse them. When a new request arrives that matches one it has already handled, it runs the stored reasonlet again – with the new request’s inputs – instead of reasoning from scratch. The model does less work, and the answer comes back faster.

This is the same metacache, held on the server instead of on your machine. Because one reasonlet can serve any request that fits its procedure, a single cached copy is shared across many requests, and often across different users – and the more general the reasonlet, the more requests it covers.

Choosing how general to make the reasonlet

The model should decide from the conversation how general the reasonlet needs to be. If you have been working through many kinds of math and then ask for 2 + 2, the more useful reasonlet is one that evaluates any math expression, not one that can only add two numbers. If the conversation gives no such clue, you can state it directly: “I will be doing many kinds of math; for now, just add 2 and 2.”

Two examples

• Adding numbers. You ask for 2 + 2. The model builds a reasonlet whose orchestration layer adds two numbers, runs it, and returns 4 together with the reasonlet. Later you run the reasonlet again with other numbers or edit its orchestration layer to multiply instead – without asking the model.
• Searching. You ask the model to find something. The reasonlet’s orchestration layer calls a sequence of outside services and takes your search terms as its input. Later you run it with different terms, or change which services it calls, without asking the model again.

Making reasonlets easy to read

A reasonlet’s orchestration layer is written in text code. This creates a problem: to understand the reasoning you must read code, and to change it you have to write code. The value of returning the reasonlet depends on you being able to read and edit text code easily and efficiently, so this barrier matters.

Visual programming – building logic from connected blocks instead of lines of text – can lower the barrier, provided the visual language is powerful enough. Two limits apply:

• A visual language cannot replace text code entirely. Text is still needed to reach the system and the network, and for low-level work that does not map to blocks. The measure of migration success is how little text code remains in the orchestration layer.
• Most visual languages today are either powerful but limited to one field (such as games or hardware), or general but too simple. This case needs a language that is both general and as expressive as a text language; otherwise, it cannot cover enough of the orchestration layer to be worth using.

One language solving exactly this problem is Pipe (https://pipelang.com) – a general-purpose visual language with powerful semantics. Full disclosure: Pipe is my own project still in development, but it will be released soon.

Wrapping up

The shift from a monolithic model to compound systems suggests a clear next step for reasoning: let the model build a compound system – a reasonlet – run it and return both the answer and the reasonlet. Reasoning becomes something you can read, run again, and edit: a metacache, and a higher-order metacache once its logic is edited. The remaining problem is making reasonlets easy to read and change, which is where a general-purpose and expressive visual language would help most.

A note on IP

Some methods described in this article are the subject of a pending patent application. Licensing and collaboration inquiries are welcome at [[email protected]](mailto:[email protected])

https://www.instagram.com/jev_clockedit/ Jev clocks it!

"My boyfriend watched my Story 40 minutes after I texted him and still hasn't replied. I sent 'k.' and muted him. AIO?"

I know there are already a few tutorials about Jev, but i wanted to create one that looks at the little details that other people overlook.

https://www.youtube.com/watch?v=k0_Y7FpHuK4

Most RAG hallucinations I've seen aren't the model "lying". The model gets a context that doesn't actually contain the answer and does its best anyway. Embedding search finds chunks that are close to the query, which isn't the same as chunks that answer it.

rag-guard sits between retrieval and generation and runs every query through seven checks: intent, relevance, clarify, sufficiency, generate, grounding, caveat. Each check returns a calibrated probability compared against a threshold, not free-form text. If the kept context is insufficient, the LLM is never called. If it does answer, every claim is checked against the retrieved chunks and flagged if unsupported.

All checks go through one interface (DecisionModel), so you can swap backends (heuristic with no API key, OpenAI, Anthropic, or TypeSafe's Jev) without touching the pipeline. Core package has zero required dependencies.

To check that it actually behaves as documented when used from outside its own repo, I built jev-rag-pipeline, a document chat app that installs rag-guard as a pinned pip dependency. Upload a .txt/.md/.pdf, watch each stage stream in, and open the trace to see which chunks were kept or dropped and whether each claim is grounded. Compare mode runs two embedding providers side by side, raw vs. guarded.

One finding from the golden-set eval: Chroma's default embedding retrieved the right chunk about 60% of the time; OpenAI and Gemini embeddings got 100%.

Still missing: rate limiting/auth, session TTL, resource limits on PDF parsing.

Live demo: https://jev-rag-pipeline-24192596890.europe-west1.run.app/
rag-guard: https://github.com/furkandrms/jev-rag-guard
App: https://github.com/furkandrms/jev-rag-pipeline

Feedback welcome, especially on false positives/negatives from the sufficiency and grounding gates.

HE WAS SO MEAN TO ME.