An open local decision model and System One-shaped HTTP server for yes/no, finite-choice and ordered-score questions. It reads candidate logits rather than generating a prose response.
The server validates Noul, Choice and Score inputs, evaluates each question with the loaded model, and collects the answers. In the reviewed server, requests and per-question CUDA-graph replays run sequentially.
Offers local handling and a familiar decision API for teams able to test their own hardware, domain and concurrency requirements.
Pinned README and server code reviewed. H100 timings, calibration and benchmark results are author-reported; the site did not run the model. Compatible request shapes do not establish equivalent quality or parallel execution to hosted Jev.
Run Jev-shaped finite decisions on an open local model while examining the serving tradeoffs.
Material analysed：
server.py serves requests one at a time and loops over questions for individual CUDA-graph replays. A multi-question API shape is not evidence of Jev's shared parallel execution.
Inspect the supporting source ↗The README attributes one temperature to held-out teacher questions and reports different calibration error on standard and hard tiers. Its speed and quality claims are not universal across hardware or domains.
Inspect the supporting source ↗Consider it when local data handling and a familiar API matter. Benchmark your actual question mix and concurrency requirements rather than copying the H100 latency into an application estimate.
Read the question-validation function and serving loop in server.py; distinguish one request, one question replay and total wall-clock latency.