Skip to content
MrJev

jeff

Self-hosted implementation of Jev's System One API on the 400M-parameter GLiFormer model. The official SDK works after changing the base URL.

View on GitHub →

Hands-on review

A self-hosted server that speaks Jev's API on a 400M-parameter GLiFormer model and runs on a plain CPU. TypeSafe's SDK works against it almost unchanged.

Good for

  • Self-hosting Jev-style classification on ordinary hardware, even without a GPU
  • Testing code written for Jev against a local server by changing the base URL
  • High-volume, simple labeling where a small model is good enough

Watch out for

  • Listens on all network interfaces with no API key unless you set JEFF_API_KEYS
  • Pinned Jev model names like jev-1.13.0 are rejected until you add them as aliases
  • A small encoder model; its README says it's less accurate than Jev on reasoning-heavy tasks

Tested Sep 19, 2026 at 230d85d29e5d · Python 3.12 in Docker on a 4-core CPU with gliformer-large-v1; called with typesafe-sdk 0.7.0

What it does

jeff, by Logan Markewich of LlamaIndex, implements Jev’s System One API (POST /v1/systemone with Choice, Score, and Noul questions) on top of GLiFormer, a 400M-parameter encoder built for zero-shot classification. Instead of a large language model, it scores every label against the state in one pass, so it’s cheap to run and can serve on a CPU. The official typesafe-sdk works against it by changing the base URL.

The README is candid: it’s cheaper to self-host but less accurate than Jev on reasoning-heavy tasks. The repository includes the author’s comparison with Jev across eight datasets. Consistent with our policy, we don’t reproduce the Jev figures here.

Setup

uv sync --extra dev
uv run hf download knowledgator/gliformer-large-v1 --local-dir models/gliformer-large-v1
JEFF_API_KEYS=devkey uv run jeff    # http://localhost:8000

The model download is about 2.2 GB. It picks CUDA, then Apple’s MPS, then CPU, and there’s an ONNX backend and Modal deployment scripts for GPU or CPU serving. Almost everything is configurable through JEFF_* variables: request limits, batching, rate limits, temperature, and how Noul questions are asked.

Using it

We ran it in Docker on a four-core CPU with no GPU, with an API key set, and called it through TypeSafe’s official Python SDK (0.7.0) using the same compatibility checks we run on every Jev reproduction.

  • The offline tests pass. 22 passed; 6 were skipped because they need a second, smaller checkpoint we didn’t download.
  • It passed 11 of our 12 compatibility checks. All three question types, chat-message and JSON state, SDK response_model parsing, Noul criteria, Choice options without descriptions, a 64-option Choice, questions without instructions (optional in Jev’s schema, and accepted here), the model list, and rejecting a wrong key with the SDK’s authentication error.
  • One difference. Requests for a pinned Jev version such as jev-1.13.0 were rejected with “Unknown model”. Only the names in JEFF_MODEL_ALIASES (by default jev-latest and jev) are accepted, so add your pinned names there if your code uses them.
  • The response names the real model. Answers report gliformer-large-v1 in the model field, not the alias you sent, so logs show what actually answered. That matches how Jev reports the versioned model.
  • It runs on a CPU. It served every request on our machine without a GPU.

Permissions and data

  • Your data stays on your server. Requests go to jeff and nowhere else, apart from the one-time model download from Hugging Face.
  • Lock it down before exposing it. By default jeff listens on 0.0.0.0 and authentication is off (JEFF_API_KEYS empty), so anyone who can reach the port can use it. Set JEFF_API_KEYS, bind to 127.0.0.1 with JEFF_HOST for local use, and consider JEFF_RATE_LIMIT_RPS, which is also off by default.
  • Request limits are on by default. Up to 64 questions, 64 labels, and 20,000 characters of state, with a queue limit that returns HTTP 529 when full.

Maintenance

Seven commits, published on September 19, MIT licensed, with a test suite, a benchmark folder, and deployment scripts. No issues have been filed yet. It’s new, but the code and documentation are tidy.

Verdict

Of the Jev-compatible servers we’ve tested, jeff is the only one that runs on a plain CPU, the official SDK needs only a new base URL, and it handled every request shape we sent except pinned Jev names. The trade-off is quality: its README says it’s less accurate than Jev on reasoning-heavy tasks. Use it for high-volume, clear-cut classification, measure it on your own labeled data, and set an API key before it listens beyond your machine.

For larger open reproductions, see openjev-sglang and SemIf. Our Jev alternatives guide compares the approaches.

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

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

More in Open Models & Reproductions

Laya

★ 21k▲ 6.4k

NandhaKishorM/laya

Non-autoregressive decision engine over 100+ languages: three checkpoints and a router that detects the script and dispatches per request. Its benchmarks end with a limits section naming the datasets it does not generalise to and the headline figure that came from a training split.

PythonReviewed

kev

★ 6.3k▲ 5.9k

jaredpalmer/kev

Jev-style decision models from 0.5B to 8B, built as LoRA adapters on Qwen and served behind a Jev-compatible /v1/systemone API.

PythonReviewed

SemIf

★ 4.1k▲ 2.3k

TheoLeeCJ/SemIf-OpenJev

Jev-style decisions from a frozen 4B model on a single RTX 3090, with a browser demo. Formerly OpenJev.

PythonReviewed

Get new Jev projects every week

New Jev releases, pricing changes, and the best new projects, once a week. No spam; unsubscribe anytime.

Powered by Buttondown. See our privacy policy.