Arbiter

Mostly. It implements POST /v1/systemone with /v1/predict as an alias, and a Jev client ignores the extra routing, latency, confidence and action keys. Health, ready, models and metrics endpoints are additions.

The model field selects English, multilingual or typed-decisions, or leaves it to the router. Left alone it reads script: non-Latin and non-English Latin go multilingual, the rest go English.

Python 3.12 with the NVIDIA or Apple recipe, about 5 GB of GPU memory and a 2.3 GB checkpoint download. Single and fifty-question calls stay in tens to hundreds of milliseconds in the reported runs.

No. Snake, hopper, crossing, paddle, mines and dungeon crawl show one-call typed answers per tick against random and hand-written baselines, with tables noting wins and losses.

Python 3.12 or newer, then ./run.sh setup, which picks the NVIDIA or Apple lane from uname, creates the venv and installs torch, the deps and the three checkpoints at 2.3 GB. ./run.sh serve listens on http://localhost:8010. On Apple Silicon there is an opt-in third engine, ARBITER_ENGINE=laya_mlx, running the community MLX port: a quarter off a single question and a two-second cold load instead of ninety.

GET /healthz for liveness, GET /readyz for checkpoints loaded and warm, which is the one to gate traffic on, GET /v1/models with the three checkpoints and their aliases in OpenAI style, and GET /metrics with Prometheus text for requests, questions, latency, batch size and queue depth. Question types are Jev's: noul, choice up to 255 options, score 2 to 10 ordered levels, and violations return 422.

Set ARBITER_API_KEY and the server requires an Authorization bearer header, answering 401 otherwise, and more question rows in flight than ARBITER_MAX_QUEUE returns 529. The playground page is one self-contained file served from the same origin as the API, so it needs no configuration and the server needs no CORS headers.