Openjev — daseinlabs

It is a local Gemma 3 4B behind a compatible endpoint. The server implements the documented System One request and response shape at POST /v1/systemone, including choice, score, and noul answers with probabilities, but the weights are the open Gemma release rather than TypeSafe's. Confidence is one minus normalised entropy, and the README calls that an approximation since TypeSafe does not publish its formula.

Mixed, and the README is candid about it. On the docs' quick-start request the routing answer matches (technical, with probability 1.00), but the judgment calls diverge: frustration scores 2.00 (furious) against TypeSafe's 1.04 (annoyed but polite), and is_urgent returns 0.005 against 0.999. The stated cause is that zero-shot softmaxed next-token likelihoods are not calibrated judgements.

Partly. Scoring, evaluation, benchmarks, correctness checks, and both HTTP scoring endpoints run under PyTorch on Windows and Linux, with --device auto picking CUDA then MPS then CPU. Frozen-feature extraction, head training and evaluation, and the chess LoRA workflow still require MLX on Apple silicon, as do the Doom terminal UI's own platform dependencies.

The base 4B weights need roughly 8 GB just for GPU model weights at 16-bit, plus memory for activations and the option KV caches; CPU runs use float32 and need more RAM, and the docs suggest lowering batch size and context length. Setup also needs Python 3.12+, uv, a Hugging Face login, and the gated google/gemma-3-4b-it download.

The context is prefilled once and that KV cache is expanded across the option batch, then every option is scored in a single padded forward pass with no decoding at all. The score is the log-probability of the option tokens given the context, and a softmax over the option scores gives the probability per option. openjev check verifies that cached batched path against naive re-encoding.

The measured Apple silicon MLX path answers scoring requests in about 90 ms each; PyTorch latency depends on your CPU or GPU. The /score response carries best and best_index plus per-option probability, logprob_sum, n_tokens and timing, and the CLI also has a bench command for a latency benchmark and an eval command for top-1 and top-3 accuracy on JSONL.

Not the training path. openjev decision trains a shared candidate-scoring head on frozen Gemma features with versioned task validation, feature and artifact fingerprints, held-out evaluation against continuation scoring, and candidate-order checks, and it currently requires MLX on Apple silicon. Scoring, evaluation, benchmarks and both HTTP endpoints do run under PyTorch on Windows and Linux.