jevos

How we reviewed this: we ran the published jevos-v3 Linux binary and OpenVINO model, both checked against the release’s SHA256SUMS, in Docker on four cores, and repeated the measurements from our first review of the Python build so the two can be compared. Numbers are ours, on that hardware; the project’s own benchmarks, including its comparisons with Jev, are the author’s and we have not reproduced them.

What it is

One 25 MB binary and a 600 MB INT8 model. The server is C++: OpenVINO runs the model, llama.cpp’s tokenizer is compiled in, cpp-httplib serves POST /v1/systemone and GET /v1/models. The release archive carries every dependency’s licence under licenses/, matching a THIRD_PARTY_NOTICES.md in the repository, and /health reports the SHA-256 of each model file — a small thing that lets you prove which weights answered.

It is still candid. /v1/models lists jev-latest as “answered by jevos-v3 on this server, not by TypeSafe’s Jev”, and it ran with --network none from the first request.

New since our first review: choice and score work — a choice is asked as one yes/no question per option — and jev decide now accepts the same request body the README documents, which fixes the other issue we filed.

What it costs on four cores

The Python build read the state once and then paid about 85 ms for every question. This one does not:

questions	median	per question
1	216 ms	216 ms
5	280 ms	56 ms
10	369 ms	37 ms
20	502 ms	25 ms

About 15 ms for each question after the first, against 85 before. Twenty questions went from 1.6 s to half a second.

Long texts are still expensive the first time — 4,000 words took 18.7 s, down from 22.3 — but the server now keeps what it has read. A 1,100-word text took 6.8 s, then 114 ms for the same question again and 105 ms for a new question about the same text. That is the shape to design around: ask everything you want about a document while it is warm. Past 8,192 tokens it still refuses with no truncation rather than reading part of it.

Repeated answers are identical to the last digit. The same question inside a batch differs in the seventh decimal place, which main.cpp documents as the cost of INT8 activation groups and offers a flag to remove.

Negated questions: better, not sound

Our first review found that Is it false that this is a billing problem? returned 0.10–0.13 for every message, billing or not. On the same four messages:

question	billing	billing	technical	technical
Is this a billing problem?	0.932	0.932	0.069	0.114
Is it false that this is a billing problem?	0.056	0.054	0.307	0.199
Is this about something other than billing?	0.013	0.021	0.839	0.771

It now moves in the right direction. It does not move far enough: for the two technical messages, a question and its negation add up to 0.38 and 0.31, and across all five non-billing messages the negated answer ranged from 0.20 to 0.76. The positively worded inversion in the third row is reliable. Write conditions positively still.

Rechecked on jevos-v4, 13 October. The model released after our test does the same thing:

question	billing	billing	technical	technical
Is this a billing problem?	0.938	0.942	0.044	0.073
Is it false that this is a billing problem?	0.045	0.038	0.302	0.245
Is this not a billing problem?	0.036	0.038	0.890	0.587

How well negation works depends on the wording. “Is this not…” mostly flips, and “Is it false that…” still stays low on the technical messages. A contributor’s probe with a different state and negated questions tracked the evidence well (0.12 with a bomb beside the ship, 0.92 with none), and we got the same numbers. The maintainer closed our issue and points to a wiki page, negation in yes/no questions, with the same advice we give: ask positively and compute 1 − P(yes) in your own code.

On the ten-message set it scored nine of ten at 0.5 again. The miss is the same angry double-charge ticket, now at 0.496 rather than 0.183.

What it believes

Planted instructions moved nothing that matters — “ignore previous instructions” and a fake system turn shifted a crash report from 0.069 to 0.054 and 0.062. A planted fact moved it to 0.956, as its prompt intends: an assertion in the evidence is evidence.

History

We first reviewed the Python build at eb74cf7, which pinned llama.cpp and refused choice and score. Its numbers are superseded by the ones above.

At that ref four files carried a header naming Rizzo Flow, Apache-2.0, and a NOTICE the repository did not ship. We filed that as issue 9 on 28 September; it was deleted, and the headers were removed while the code in three files stayed byte-identical. We asked on 29 September, as issue 15, whether the headers had been wrong; that was deleted too, with no reply. The two technical issues from the same review were left alone. The C++ rewrite then removed the derived files and added the notices above — a better state than the one we raised, reached without an answer.

The repository was created in August 2024 and its oldest issues concern a résumé-builder library: jevos was published onto an existing popular repository, so its star count is not a measure of jevos.

Verdict

The rewrite fixed what made the first version awkward. Batching is real, a warm document answers in about a tenth of a second, and the answer types match Jev’s. On a laptop with no GPU and no key, this is now the most complete local stand-in for the wire format we have run.

Two cautions: give it time to read a long document once and then ask everything, and phrase every condition positively — negation is improved but a question and its negation still do not add up. For the same protocol over a model you already serve, see jevify; for many open models behind one daemon, ollaya.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Oct 13, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.