Kev (Apache-2.0, Python, 1,681 stars, 93 forks, created September 17, 177 commits, 4 contributors, kev-family release September 20) is a family of 0.8B/4B/9B decision models built on Qwen3.5 bases, with an API that matches TypeSafe's System One wire format closely enough that you point their own Python SDK at localhost instead of TypeSafe's servers. uv run python -m kev.serve --run jaredpalmer/kev-4b --port 8009 starts a local server; send it a support ticket with three typed questions (which department, does this need escalation, how frustrated is the customer) and it returns a choice, a yes/no probability, and a 0-2 severity score, each with its own confidence and full probability breakdown, in under 500ms on an Apple M5. Three question types cover most of what an LLM judge or a routing prompt is actually asked to decide.

What sets Kev apart from the rest of today's list is what it says about its own numbers. Kev-9B trails Jev by 3.5 points on out-of-domain accuracy (0.822 vs 0.857) and scores 0.852 on a held-out test set Jev has never been run against — and the README says outright, "we don't know which datasets Jev was trained on, so this isn't a controlled comparison of the two architectures." A KEV_TEMPERATURE calibration setting cuts confident wrong answers from 8.7% to 4.4%, close to Jev's own 3.7%; a KEV_DATE_FACTS flag that hands the model a pre-computed day-count pushes deadline-policy accuracy from 0.80 to 0.90 against Jev's 0.93. Every improvement is quantified against the gap it's closing, not against zero. The HN launch thread (116 points, 55 comments) split the way these threads usually do — one commenter called it "a bit of a Jev explosion," another asked, reasonably, whether tool-calling on an existing chat model already covered most of the use cases this opens up — and the author, Jared Palmer (Turborepo, Formik), didn't oversell past what the tables show.

Reach for it if you want a local, self-hosted decision model without waiting on TypeSafe's access queue, and you can live with single-digit accuracy points below the hosted original on data unlike what Kev trained on; it replaces the hand-rolled few-shot classification prompt you're currently running against a chat model for ticket routing, escalation flags, or rubric scoring. Delete the GPT-4o-mini call you use today just to pick one of five labels. Tradeoffs: 4B and 9B need a 32GB Mac or a CUDA GPU to run comfortably; the context window tops out around 32k per a thread commenter's testing; and every accuracy number in the README is Kev's own eval run, not a third party's.

Von (Apache-2.0, Python, 309 stars, 22 forks, created September 18, 56 commits, 1 contributor, no tagged release) is a 395M-parameter "OptionMarker" model, also protocol-compatible with TypeSafe's /v1/systemone spec, claiming sub-15-18ms local inference on CUDA, ROCm, Apple Metal, or CPU. The README opens with "SOTA Empirical Accuracy: 91.23% accuracy on adversarial multi-hop reasoning benchmarks, surpassing published commercial alternatives," backs it with LaTeX for a Brier-score training objective and a calibration temperature fit to four decimal places, and includes a benchmark table where Von beats TypeSafe Jev 1.13 on a ViZDoom combat task, 9.38 kills to 5.62.

Read past the headline and the comparison gets narrower. On the actual 49-task accuracy suite Von cites for that 91.23%-class number, Von scores 71.5% macro against Jev's own 96.6% — a 25-point gap, in Jev's favor, on the one broad-coverage benchmark in the README. The category where Von wins is the ViZDoom one, which the README calls "the standard 8-seed evaluation protocol," sourced to a single blog post at morethanamachine.com. That post is a real, honest piece of work — its own author flags that Doom navigation is "weak" from missing spatial cues — but it's a one-off experiment by an independent blogger, published September 19, one day after Von's repository was created, and it never mentions Von at all. The harder "jabr v2 benchmark" behind the main accuracy table traces to a GitHub repo with zero stars, no description, and no other activity, created by an account with no bio, company, or public history — also created September 19, after Von existed. A benchmark a project cites as "standard" evidence for beating a commercial rival should exist independently of the project; here, both of Von's did not.

Reach for it for what it verifiably is: a free, local, Apache-2.0 model that speaks the same wire protocol as Jev and Kev, sub-20ms on ordinary hardware, no waitlist. Delete nothing on the strength of the "beats Jev" framing specifically — that claim doesn't survive reading the table it's drawn from. Tradeoffs: one contributor, no releases yet so installing means pulling straight from git, and on the single benchmark in its own README that measures general accuracy rather than gaming reflexes, it trails the model it markets itself against by 25 points.

simple-jev (Apache-2.0, Python, 431 stars, 45 forks, created September 18, 22 commits, 2 contributors, no tagged release), from Featherless AI, turns any Hugging Face model's own next-token logits into a typed-decision endpoint without training a separate classifier head. It doesn't generate a JSON completion and parse it; the server reads the model's logits for each option directly and builds the response from the scores. Point it at Qwen3.5-0.8B on a CPU, Gemma 4 26B-A4B on a GPU, or the actual Laya "Typed Decisions" checkpoint through a --backend laya flag, and the request and response shape stay the same: state plus typed questions in, choices with probabilities out.

The demo API needs no signup, API key, or auth token — curl https://simple-jev-demo-api.featherless.ai/v1/classifier with a JSON body works right now, rate-capped at 2 requests/second with a 2k-token context. That makes it the only pick on today's list a reader can try inside the next thirty seconds without an account anywhere. The tradeoff for that flexibility is real: nothing here is calibration-trained the way Jev, Kev, and Von all specifically are, so accuracy and confidence quality depend entirely on whatever base model you pointed it at.

Reach for it if you don't want to choose between Jev, Kev, and Von, or you already have a model loaded for something else and don't want to stand up a second inference server just for classification; it replaces the decision of which decision-model vendor to commit to. Delete the second GPU allocation you were about to spin up for a dedicated classifier server. Tradeoffs: self-hosting means a plain HF/Transformers server, not a compiled or optimized runtime; the free demo's 2 RPS cap rules out anything beyond testing; and it inherits whatever miscalibration the underlying open model already has.

jevals (MIT, Python, 17 stars, 0 forks, created September 20, 9 commits, 1 contributor, v0.1.1 released September 20), from Openlayer, replaces an LLM-judge eval pipeline with the same typed-decision shape, running every metric for an agent trace as one request instead of one model call per metric. The README's own worked example checks a weather agent's tool call across eight dimensions — did it call the right tool, did it use what came back, is the answer grounded in the tool result, did it stay in scope, is it complete, is it relevant, did a tool result try to inject instructions, does it leak PHI — and gets all eight back in one HTTP call: 1,388 tokens, $0.00006, 0.33 seconds.

The reason this matters is the alternative it's replacing. jevals cites Ragas' own source to show an LLM-judge pipeline needs two calls for faithfulness, three plus embeddings for answer relevancy, one call per retrieved chunk for context precision — six to eleven round trips and several seconds for four metrics on one sample, which is why most teams eval 1% of traffic overnight instead of every request. It also cites a LangChain comparison from last week: on identical agent traces, GPT and Claude judges showed 92x to 913x the score variance of Jev, meaning a judge that disagrees with itself between runs makes a weak test suite regardless of how it scores any single run. Backends resolve from environment variables — Jev direct, Jev through Vercel's AI Gateway (the fastest path to Jev access without a TypeSafe waitlist slot), Kev self-hosted, Laya fully local on Apple Silicon, or any OpenRouter chat model as a slower fallback — so the eval definitions don't change when the backend does.

Reach for it if your agent evals currently run as a nightly batch job against a small sample because an LLM judge is too slow and expensive to run on every trace; it replaces that sampled, offline pipeline with something that can sit inside the request path as a gate. Delete the separate "eval harness" repo that re-implements Ragas' metrics against your own agent format. Tradeoffs: nine commits and one contributor, a day-old 0.1.1 release, Python only with a TypeScript package "next" per the README, and swapping backends means re-running jevals calibrate since probabilities don't line up across models.

jev-ultrafast (MIT, Python, 14,155 stars, 865 forks, created September 16, 3 commits, 1 contributor, 23 open issues, 75 open pull requests), from the team behind the browser-use framework, replaces the usual screenshot-plus-vision-model browser agent loop with a text-only one: read the page's actual clickable controls into a numbered table, send Jev one request that picks both an operation (click, type, select, scroll, wait, done) and a target element at the same time, and only call a small text model (Mercury 2.5) when the operation is TYPE_TEXT and something actually needs to be typed. The recorded demo runs a real Google Flights search, Zurich to London, start to finish in 7.073 seconds, with real text generation and real page load waits included, not scripted around.

The project's own performance doc is more careful than the headline number suggests it needs to be. The controlled comparison behind the "faster" claim is six alternating runs — three matched pairs — of the new loop against the previous version of their own agent: median runtime dropped from 9.45s to 7.09s, TypeSafe requests from 22 to 17, browser protocol calls from 1,092 to 101, a real 25% improvement. Then the doc adds, in its own words, "three pairs are too few for a strong statistical claim (two-sided sign-test p = 0.25)." The 7.1-second number people will actually repeat is the one polished recording, not the average of that small controlled test — and the doc says so before anyone else has to point it out. Separately: the repository's three commits are, in order, build the agent and demo, reduce round trips and record a 7-second version, then "docs: announce the Cloud waitlist below the README title" — the monetization banner landed as its own commit after the working code shipped.

Reach for it as a reference implementation for the "one combined decision instead of a full vision-model screenshot loop" pattern, not as a production agent to install; it replaces the architecture of a screenshot-driven browser agent, not any specific tool you're running today. Delete the assumption that a browser agent needs a vision model reading screenshots on every step. Tradeoffs: no full accessible-name algorithm, no shadow-DOM or iframe traversal, no canvas or file-upload support; it needs a TypeSafe API key from the same waitlist gating everything else on this list; and its own statistics undercut its own headline number two paragraphs later in the same document, which is the kind of thing worth noticing when a company is also selling a cloud waitlist for the fast version.

Also on the desk. Laya-MLX is a native Apple Silicon runtime for Laya's own typed-decision checkpoints, 7-14ms on an M3 Max with no PyTorch or cloud call, and its README points to a September 20 post from the model's original author arguing he built non-autoregressive decision models a year before Jev existed — read as a second, independent prior-art claim sitting next to Von's borrowed one. Cronhq is exactly-once cron scheduling enforced by Postgres row locks instead of best-effort crontabs, Rust/Postgres, MIT-licensed and self-hostable with Docker Compose, free for 5 jobs. Gdocs-me-up is a Node script from longtime Google i18n/text-rendering engineer Behdad Esfahbod that exports a Google Doc to HTML/CSS by reading real styling data from the Docs API — headings, line spacing, RTL, table and list nesting, font matching — instead of the lossy formatting most "export to HTML" buttons produce.

Verification notes: star, fork, commit, and contributor figures are from the GitHub API on 2026-09-21; commit counts use the per_page=1 Link-header last-page trick. Open issue/PR splits use the search API's type:issue and type:pr filters rather than the combined open_issues_count field. Kev's HN thread quotes are from the Algolia API against the item's actual objectID (49783999), resolved from the candidate row's stored meta.hn_id rather than this project's internal row id. Von's benchmark critique is from a direct read of its raw README plus a WebFetch of the morethanamachine.com post it cites and a GitHub API check of the jabr/classifier-benchmark repo and its owner's profile; jev-ultrafast's statistical caveat (p = 0.25) is quoted from its own docs/performance.md, not calculated here. Reddit returned zero rows again today, last nonzero day May 9 (about 19 weeks); github:trending returned 12 rows across all five feeds (all 2, go 2, python 3, rust 3, typescript 2); Product Hunt's 24 rows were mostly marketing/vertical-specific tools (SEO, ad prediction, App Store automation) that didn't fit today's slate.