Subject: Jev, the first System One model from TypeSafe AI (released 2026-09-15) Sources: 14 groups (official blog & docs / platform integrations / 5 open-source implementations / press deep-dives) Scope: This analysis answers four questions: what Jev is, why it's fast, how much of the hype holds up, and how hard it is to reproduce. Every key claim traces back to a specific source in the Chapter 0 evidence map; official numbers and community measurements are labeled separately.
A Chinese version of this document is available.
| Chapter | Route | Weight | Difficulty | Prereq |
|---|---|---|---|---|
| Three-Minute Overview | 🏃🚶🤿 | ★★★ | ▲ | — |
| Ch. 0 Evidence Map | 🚶🤿 | ★★ | ▲ | — |
| Act I The Gap | 🚶🤿 | ★★★ | ▲ | — |
| Act II What Jev Is | 🚶🤿 | ★★★ | ▲▲ | Act I |
| Act III Verification | 🚶🤿 | ★★★ | ▲▲ | §2.1 |
| Act IV Ecosystem | 🚶🤿 | ★★★ | ▲▲ | — |
| Act V Field Guide | 🚶🤿 | ★★★ | ▲ | Act II |
| Key Takeaways | 🏃🚶🤿 | ★★★ | ▲ | — |
- 🏃 Sprint (~10 min): Overview → Key Takeaways
- 🚶 Main (~40 min): Sprint + Ch. 0 → all acts, skipping 🤿-marked subsections
- 🤿 Deep (full text): everything, including reproduction internals
The short version: Jev is a model that generates no text at all. You give it a state (a ticket, an email, a log line, a JSON blob) and a set of typed questions; it returns all answers in a single request, each constrained to a type you defined in advance, each carrying a calibrated probability and a confidence score. By the vendor's own numbers it is 40–200× faster than frontier LLMs at this shape of task, at $0.042 per million input tokens, with output tokens free. The cost: it completely gives up generation, its core training method (RLCD) is undisclosed, and every speed/cost figure comes from the vendor's own evals with no independent audit.
One figure for the whole story:
Figure 1: The five acts. Acts I–IV cover why Jev exists, what it is, how solid the evidence is, and what the community built; Act V is a field guide for practitioners.
What it got right (my judgment, separated from the facts above): For two years, agent workflows have been stuffed with "using a giant generative model for tiny decisions," and developers are tired of it. Jev carved these decisions out of the generation paradigm and priced them separately. The timing, the packaging, and the systems engineering all landed. But "an entirely new species" deserves a discount: it reads more like a clean recombination of classifiers, calibration research, and selective prediction into a runtime interface. I agree with Turing Post's verdict: the recombination itself is the contribution.
The three most important facts:
| # | Fact | Source |
|---|---|---|
| ① | The interface contract: state in, typed probabilistic answers out. Type errors are impossible by construction (not "measured 0%" — mathematically impossible) | Official blog, docs |
| ② | The headline numbers (193.6× faster / 444.6× cheaper) come from the vendor's own workflow evals, which the vendor itself calls the high end of real-world gains | Official blog, verbatim |
| ③ | The community grew a full ecosystem in five days: five platform integrations, five open-source implementations; the best reproduction (NanoJev) reaches roughly 90% of Jev's navigation performance while honestly acknowledging the gap | awesome-jev index, repo measurements |
🚶🤿 ｜ ★★
Four source tiers; claims are cited by ID. Check the reverse-lookup table first to know how much to trust each conclusion:
| Key conclusion | Source | Evidence tier |
|---|---|---|
| Interface contract, three primitives, context & pricing | Official docs | Official, reliable |
| 40–200× faster, $0.042/MTok | Official blog | Vendor-reported, no independent audit |
| 193.6× / 444.6× | Official workflow evals | Vendor eval; methodology in §3.1 |
| Nine failure modes | Official jaggedness doc | Vendor-admitted; high credibility (self-disclosure) |
| NanoJev comparison numbers | NanoJev repo | Community measurement; rigorous protocol, single checkpoint |
| Kev / Nimble head-to-head vs Jev | Their repos | Community measurement; frozen suites, directly comparable |
| "Recombination of old research" framing | Turing Post | Press analysis, opinion |
| RLCD internals | None | No public source exists; everything beyond the contract is speculation |
Source list:
| ID | Source | Tier |
|---|---|---|
| M1 | Launch blog post | Official |
| M2 | Official docs: system-one / primitives / models / confidence / jaggedness / primer | Official |
| M3 | Official workflow evals | Official |
| M4 | Official SDKs & adapter (python / js / adapter / skills) | Official |
| M5 | jev-arena (comment-labeling arena) | Community tool |
| M6 | awesome-jev (index of 102 community projects) | Community index |
| M7 | LangChain blog | Integrator |
| M8 | NanoJev (Qwen3-0.6B reproduction + frozen comparison) | Community reproduction |
| M9 | jevlike (minimal option-attention implementation) | Community reproduction |
| M10 | Press deep-dives: flaviocopes / Turing Post / snehal.ai / orcarouter / atomicbot | Press |
| M11 | open-jev-deberta-v3-large + jev-reproductions-tracker | Community reproduction |
| M11b | Bespoke Nimble 9B (HF; full open recipe) | Community, deployable |
| M11c | Kev (HF family; TypeSafe-SDK-compatible) | Community, deployable |
| M12 | OpenRouter / Cloudflare AI / Vercel AI Gateway / Pydantic AI | Integrator |
🚶🤿 ｜ ★★★
Start with a mismatch everyone has felt: chat models surpassed average humans at conversation years ago. So where is the automation? The launch post opens with exactly this question (M1).
Founder Diogo Almeida's background matters here. At OpenAI he worked on the methods that made language models follow instructions and converse — the InstructGPT line that became ChatGPT (the M2 primer confirms he co-authored the InstructGPT paper and states RLHF was co-invented by him). His later judgment: he once believed chat models would lead to AGI, and found that something essential was missing.
What's missing? Look at the daily life of an agent workflow: should I retrieve again, is this result good enough, which tool next, does this violate a rule, continue or stop. Most of these are yes/no questions, or picking from a few options. Yet we kept answering them with the same giant generative model: assemble a prompt, generate token by token, parse JSON, validate, retry on failure (Turing Post describes this waste best; the LangChain post enters from the same pain point).
When these decisions occur thousands of times across long agent loops, latency and cost compound, and free-form generation adds hallucination and type errors as extra failure modes.
TypeSafe comes from type safety in programming: outputs always land inside the type your software expects. Jev honors the economist William Stanley Jevons, who observed that steam-engine efficiency gains increased coal consumption — the Jevons paradox. The official reading: every order-of-magnitude drop in the cost of intelligence unlocks orders of magnitude more use cases (M1). System One comes from Kahneman's Thinking, Fast and Slow: fast intuitive judgment is System 1, slow deliberate reasoning is System 2. Jev explicitly positions itself as System 1.
The official primer (M2) sharpens the positioning: large-scale automation will be dominated by AI-to-AI and AI-to-software interactions — what they call Machine Native Intelligence, betting on 99% machine-to-machine over 1% human interaction. "Building prod, not God" is a line worth remembering; it explains every design trade-off that follows.
🚶🤿 ｜ ★★★
Jev is a function call: unstructured state in, typed probabilistic decisions out.
Figure 2: The shape of one request. The state is read once, all questions are evaluated in parallel, and answers are always type-valid. (Redrawn from the official primitives docs.)
Take the refund-ticket example from the docs (M2): the state is the customer message, the transaction records, and the refund policy. One request asks three things at once — was a refund requested (Noul), is there evidence of a duplicate charge (Noul), how frustrated is the customer (Score). The answers come back; your code applies deterministic checks and routes to refund, review, or a human.
Compared with LLM structured output, the difference is not "can you get structure" but the whole path:
Figure 3: Two paths for the same judgment. The LLM path retrofits parsing and validation; the Jev path builds the constraint into the construction. (Redrawn from the M1 comparison table.)
Every question takes one of three shapes (M2):
Figure 4: The answer shapes of the three primitives. Choice confidence is derived from how peaked the distribution is (a flat one gets low confidence); Score returns an expected level, not a probability of correctness; Noul is a bare probability with no separate confidence. Example values follow the official docs; the flat-distribution contrast is an illustrative construction, labeled as such in the figure.
The official selection heuristic is practical: when two types both fit, pick the one your code can act on directly. Choice maps to a switch, Score maps to a threshold, Noul maps to an if.
Three semantic traps, emphasized by both the official docs and snehal.ai (M10):
- Score returns an expected level, not a probability of correctness. Levels at 0.1/0.3/0.6 yield score 1.5 — a position on the scale, not "75% confident".
- Noul at 0.5 means genuine uncertainty; a mid-scale Score is just a position, with no uncertainty implied.
- Choice is relative (which option is most like); Noul is absolute (does this hold at all). Both can be low for the same question.
The speed is not magic; it's the removal of autoregressive decoding. An LLM's latency is input processing plus sequential output steps plus serving overhead; Jev's is input processing plus decision readout plus serving overhead (snehal.ai's decomposition is the clearest). No output sequence, no serial waiting. Two honest corrections: the input compute is unchanged — long inputs still dominate; and "no tokens" precisely means no autoregressive answer-token generation, not that requests are free.
Parallelism adds a second layer: all questions over the same state are evaluated at once, so adding questions barely changes latency and costs only a few cheap question tokens. The official cookbook's measured numbers: batching 13 questions into 1 call is 11.5× cheaper and 9.6× faster than 13 separate calls (M2). This enables a counterintuitive pattern, speculative fan-out: ask every question you might need — answers you don't use are simply ignored by your code. "Asking one more question is nearly free."
Figure 5: Vendor-reported speed and cost ranges. Left: end-to-end latency, frontier LLMs 3–329 s vs Jev 70–500 ms. Right: input price, LLM range $0.20–$10/MTok vs Jev $0.042 (output free). Source: the M1 launch-post comparison table; unaudited.
The numbers themselves (M1, M2, M12): end-to-end 70–500 ms; input $0.042/MTok ($42 per billion tokens), output free; context 64k per request (32k for the state plus the longest question); rate limits 250k tokens/s and 1,200 requests/min. All vendor-reported; no independent audit exists.
Everything TypeSafe has publicly said about RLCD (Reinforcement Learning for Calibrated Decisions) amounts to an output contract (M2 primer): the model does not generate text; it returns decisions and probabilities; higher probability should correspond to a higher chance of being right. Calibration is defined at the group level: events assigned 0.2 should occur about 20% of the time.
The official motivation is a critique of RLHF: preference optimization rewards answers people like, which feeds sycophancy and confident hallucinations, and causes mode dropping — the model tilts toward a preferred style and suppresses other outputs.
But a contract is not a recipe. How the loss is constructed, how the reward is defined, what the training data is, which ablations were run — none of it is public (snehal.ai frames this honesty best: the circulating "Qwen + KV cache + vocab logits" architecture diagram is one reproduction's design; whoever drew it has the same information blind spots as the rest of us). The launch post's FAQ lists six questions — why a new training algorithm, where the data comes from, how these results are even possible — and answers none of them in the body. This document's stance on RLCD: treat it as a named class of objective functions, not a reproducible method.
🚶🤿 ｜ ★★★
Hype first, audit second. Four layers: the official eval's methodology and biases, the vendor's own admitted weaknesses, third-party comparisons, and the resulting trust grading.
The core official evidence is not a public benchmark but a new kind of eval (M1, M3): instead of measuring ground-truth classification, assume there is a correct compute graph (a workflow expressed in code), and use the average prediction of the largest, smartest external models as the reference probabilities. Every model gets the same workflow; no harness engineering allowed.
Three biases you must know about, admitted by the vendor in its own nuance notes:
- The reference answer is the average of GPT-6 Astra and Fable 5.1, biasing toward OpenAI/Anthropic answer distributions; the vendor estimates it underestimates its own model and DeepSeek's.
- The workflows were written by their own capabilities team. Not in the training distribution, they say, but selection bias cannot be ruled out.
- The two most viral numbers — 193.6× faster, 444.6× cheaper — come from exactly this eval, and the vendor explicitly says these are expected to be at the high end of real-world gains.
The side-by-side demo compares against GPT-5.6 Terra (the vendor says Terra is the most comparable on average), with a single disagreement on "churn likelihood level" that the vendor itself calls genuinely ambiguous. In the hallucination chart, the LLM numbers come from OpenRouter routing (harder queries likely routed to better models — a bias); the vendor's 0% type-error rate is a construction guarantee, not a measurement.
The jaggedness doc (M2) is the single most valuable page in the entire corpus — failure modes with official workarounds, one by one:
| Failure mode | Official workaround |
|---|---|
| Literal reading: answers what you wrote, not what you meant | Put boundary cases in the criteria |
| Math and numbers: not a calculator; counting is unreliable | Keep arithmetic in code |
| Dates and times: read as text, not ordered quantities | Extraction to the model, comparison to code |
| Indirection: property-of-a-property drops accuracy | Reduce hops |
| Large states full of irrelevant detail act as distractors | Filter first, then ask |
| Adversarial content is not defended against by default | Write precise criteria; test edges before deploy |
| Contradictory instructions and criteria break it | Align the wording of both |
| Structural invariants are not guaranteed | Don't carry thresholds across question types |
| Cannot generate | Use a generative model |
The eighth row carries a genuinely informative example: on the ticket "I'm not happy with the fit, what are my options", asking "is the customer requesting a refund?" as a Noul yields 0.22; as a yes/no Choice, "no" gets 0.99 with confidence 0.97. Both numbers are right and neither transfers, because Choice asks a relative ranking and Noul asks absolute truth. A pair of complementary Nouls (refund / not-refund) sum to 1.19. These are not bugs; they are the semantic edges of a probabilistic interface, and users must understand them.
Two more constraints that matter for non-English users: English is the primary training language; CJK is handled but not equally well — the vendor advises self-testing non-English workloads first (M2 models page). Input is text-only; images and audio must be pre-converted to text or structured fields.
NanoJev (M8) ran a rigorously frozen comparison (240 episodes, greedy and sampling controllers, states and weights hash-pinned):
| System | test completion | OOD completion |
|---|---|---|
| Jev (greedy / sampled) | 100% / 100% | 80% / 95% |
| NanoJev (greedy / sampled) | 90% / 95% | 50% / 90% |
| Untuned Qwen3-0.6B (greedy / sampled) | 30% / 35% | 5% / 15% |
Three readings: a trained 0.6B decision head is a qualitative jump over untuned Qwen — the "decision head route" works; the gap to Jev is stable — the author's own conclusion is "not yet at Jev's efficiency here, and this small navigation suite proves nothing about general capability"; Jev's probabilities went through rounding normalization, honestly labeled as a proxy distribution rather than passed off as server-side probabilities. On the 50×50 maze, Jev took 2,738 steps to escape versus NanoJev's 244 — a counterexample showing Jev wins on final completion, not per-step optimality.
Figure 7 (video): Three systems on the same maze (advanced by the same environment step; the bars under each panel show the four-direction probabilities of the last decision). At this moment NanoJev has reached the goal while Jev and the untuned Qwen are still running; final numbers are in the table above (Jev eventually escapes too, with an order of magnitude more attempts). Source: the NanoJev repo demo page.
Layer the three tiers of evidence and my grading is: interface contract and semantics (official docs — trust directly; it's verifiable API behavior); nine weaknesses (vendor-admitted — high trust); speed and cost order of magnitude (vendor-reported — trust "two orders of magnitude", not the specific multipliers); intelligence parity (the weakest link — the reference answer is an average of other companies' models, a shadow of smart models); RLCD mechanism (no evidence — treat as a name).
One line to take away: type safety is real, the speed is real, the price is a promise, and intelligence parity is an open question.
🚶🤿 ｜ ★★★
The speed of ecosystem formation in the first five days is the most tangible evidence of the hype.
| Integration | Date | Form |
|---|---|---|
| Vercel AI Gateway | Sep 16 | AI SDK experimental evaluate |
| OpenRouter | Sep 18 | typesafe/jev-1.13 listed |
| Cloudflare AI | live | typesafe/jev |
| LangChain | — | TypeSafeClassifier; AutoModeMiddleware (tool-risk gating) |
| Pydantic AI | — | TypeSafeModel: every field of output_type becomes a question |
The LangChain usage explains the positioning best: model routing (cheap model for easy tasks, strong model for hard ones) and tool-risk gating (a bash command passes a judgment before it executes).
Implementation details (🤿): jev-arena (M5) confirmed that Jev on OpenRouter uses a separate /alpha/decisions protocol, not Chat Completions. TypeSafe also ships an adapter (M4) that constrains LLMs into the System One interface for fair comparisons. flaviocopes (M10) notes the official agent skill for Claude Code and Cursor; its recommended first prompt is "explore this project and find places where intelligent judgment can replace fragile parsing."
Figure 6: Platform integrations and open implementations around Jev (compiled from M6, M8, M9, M11 and later additions).
The first two are research reproductions; the last three are deployable models — different animals:
NanoJev (M8): the most complete training reproduction. Qwen3-0.6B backbone with trained decision heads; dynamic Choice (2–255 options), Score (2–10 levels), Boolean; multiple states and questions in one forward pass (measured: 6 states, 18 questions, 44 candidate paths in one forward). Data, training, and evals all open. Comparison results in §3.3.
open-jev (M11): the cleanest academic reproduction. DeBERTa-v3-large encoder; input is a [CLS][STATE] state [Q] question [OPT] option token sequence; each option scored by a three-layer head (question mean; option mean; product), softmax within the question's option group. Public gold data only (banking77, SST5, BoolQ — 18k states, 42k questions); one H100 trains it in 229 seconds for about $0.25. Results: in-domain accuracy 0.854, ECE 0.022; on brand-new instructions and option sets, OOD drops to 0.690, with ordered scales weakest (0.45 against a 0.26 majority baseline). The author is explicit that these numbers are not comparable to Jev's — they measure different things.
Bespoke Nimble 9B: the corporate-grade open recipe. Bespoke Labs (a well-known post-training team) published "Data, Model, Recipe for an open Jev." The recipe covers data curation, a Qwen3.5-9B LoRA (trained on answer tokens only), and dual-platform serving (Mac MLX and NVIDIA CUDA); no distillation from Jev, explicitly to demonstrate the method. On a 324-example holdout: Nimble 90.1%, base 66.4%, Jev 93.2%. Know the constraints: flat schema (enums up to 26 options), 2,048-token prompt cap, only 2,676 training examples — the vendor itself warns against expecting generalization. Built in one day. Apache 2.0.
Kev: the SDK-compatible pragmatist. A four-size family (Qwen 0.5B/0.6B/4B/8B + LoRA + a pointer readout head) that packs the document and all questions into one sequence, using a block-causal mask to achieve true single-prefill parallel questioning (question isolation exact to 4e-6). The key move: it implements TypeSafe's POST /v1/systemone contract directly — the official typesafe-sdk runs against a local Kev with a base_url change. Frozen head-to-head: OOD locked test kev-4b 0.806, kev-8b 0.780, Jev 0.857. kev-4b serves on a 32GB Mac in bf16 at about one second; the 4B/8B recipes train in 40–70 minutes on one H100. Engineering discipline is unusually strong: eval suites are frozen and checksummed, and the pre-declared release bar (unmet) blocks version tags. Apache 2.0.
jevlike (M9): the minimal runnable teaching implementation. One attention pattern: each option becomes a query vector attending over context tokens to get an option-specific context representation; a shared dot product scores options; softmax across options. Byte-level encoder trained from scratch by default (192-byte context, 32-byte options), or a frozen HF encoder with a rank-256 head. The eval has a nice habit: a shuffled-context control (options paired with the wrong context) that a useful model should decisively beat.
Selection guide: to deploy and try today, Kev's SDK compatibility is the cheapest path, and Nimble suits teams with a Mac or CUDA box; to learn how to train one, NanoJev and Nimble's recipes are fully open; to understand the principle in ten minutes, jevlike; for an academic control, open-jev.
Across all implementations, the crux is not the model but three things: how to encode "questions + options" into a parallelizable tensor structure (NanoJev's candidate paths, open-jev's token sequence, jevlike's option attention, and Kev's block-causal packing are four answers); how to construct a loss that calibrates probabilities (open-jev uses cross-entropy plus Brier, Kev plain cross-entropy, Nimble trains a LoRA on answer tokens only); and how to measure OOD honestly (every project singles out "never-seen questions" — a consensus worth more than any single score).
Figure 8: The "Jev Reproductions Tracker" HF Space homepage (accessed 2026-09-20): a dashboard tracking 48 reproduction-related artifacts, with category counts — parallel constrained decoding 17, trained decision heads 16, diffusion models in Jev mode 4, "this already exists" prior-art claims 2, architecture analysis and explainers 9. The category counts are themselves a map of how the community disagrees about what a reproduction even is. Source: huggingface.co/spaces/multimodalart/jev-reproductions-tracker.
🚶🤿 ｜ ★★★
The first four acts covered what Jev is and how much to trust it. This act is the engineering boundary: which judgments fit, which look like they fit but don't, and the one thing to do before going live.
- Judgments that require counting or date comparison ("more than 3 errors in 5 minutes"): arithmetic and dates are vendor-admitted weaknesses; compute in code and feed booleans.
- Adversarial entry points (security alerts, gateable message inlets): not defended by default; an adversary can craft messages to force or suppress wake-ups.
- Carrying thresholds across question types: the Noul-0.22 vs Choice-0.99 same-question divergence is vendor-documented; calibrate each type separately.
- Stuffing a whole repository into the state: past 32k it fails outright, and near the cap distractors drag accuracy — filter first.
- Expecting it to explain or summarize along the way: it generates no text; pair a generative model if you need reasons.
Widening the lens to the engineering lifecycle, "high-frequency small judgments" have plenty of ready landing spots:
| Scenario | Why it fits | Main risk |
|---|---|---|
| CI failure classification (flake / true regression / environment) | English input, closed Choice, rerun-verifiable | Log truncation |
| Alert grading (Score severity) | Score maps naturally to threshold actions | Alert storms hitting the 1,200 req/min limit; batch |
| PR risk pre-screen + reviewer routing | One fan-out, many questions | Large diffs as distractors; split by file |
| MCP tool-call risk gate (à la AutoModeMiddleware) | Read/write-intent is closed and reversible | CJK query intent suffers |
| Dependency-upgrade triage (changelog → breaking-change Noul) | A single Noul suffices | Version comparisons need code preprocessing |
Every judgment above hangs on one unverified variable: how well Jev actually performs on your language and domain. The action is simple: take 200 real samples of the text you will actually judge, label them, and run the self-test — half a day of work that can save you from betting the whole architecture on an unmeasured assumption. If your workload is primarily non-English, the test matters even more; if it fails, the mitigations in order of cost: write criteria in English first (free, try it) → split languages (route non-English to a self-trained model) → restrict Jev to English/code workloads. Do this before any architectural decision.
🏃🚶🤿 ｜ ★★★
- Jev generates no text: state in, typed probabilistic answers out; type errors are impossible by construction.
- Three primitives: Choice (pick), Score (rubric position), Noul (probability of truth); their semantics don't transfer, and neither do thresholds.
- The speed comes from removing autoregressive decoding plus all-question parallelism; input compute is not saved — long inputs still dominate.
- Vendor-reported: 70–500 ms, $0.042/MTok input, output free, 64k context; 193.6×/444.6× are the vendor's own high-end figures, unaudited.
- RLCD has only an output contract in public; loss and data are undisclosed, and so is the architecture.
- Nine vendor-admitted weaknesses: arithmetic, counting, date comparison, indirection, adversarial content, structural invariants, and more — the workaround is always "judgment to the model, computation to code".
- English-first training; CJK is weaker; text-only input.
- Five open implementations, deployable today: Kev (0.5–8B, SDK-compatible, OOD 0.806) and Nimble (9B full recipe, 90.1 vs Jev's 93.2); plus NanoJev, open-jev, and jevlike as research/teaching reproductions.
- OOD is the shared weakness of every reproduction — and the key metric for judging this model class.
- Trust grading: type safety real, speed real, price a promise, intelligence parity open.
Two runnable companions to this analysis (in tools/, zero dependencies, Python 3.10+):
jaggedness_bench.py— turns the nine vendor-documented weaknesses from §3.2 into live probes. Verify them on the model you're actually using — official Jev or a local Kev — before you build on it.jev_probe.py— the 200-sample self-test from Act V, ready to run: accuracy, Brier, ECE, calibration-by-decile, and a confidence-threshold policy simulation, on your own JSONL data.
Both work against the official API (TYPESAFE_API_KEY) and any System-One-compatible server (--base-url), so the same probes also benchmark the open implementations in Act IV.
All figures ship in both Chinese and English (assets/zh/, assets/en/) and can be regenerated or restyled with figs/make_figs.py (python3 make_figs.py --lang both; matplotlib only).
All materials cited in this analysis (Chapter 0, M1–M12) are public. Every number in the tables keeps its original framing; vendor-reported figures are flagged as unaudited.
Community-maintained Jev indexes (this repo focuses on depth; for ecosystem navigation, credit goes to these pioneers):
- cobanov/awesome-jev — source-backed index of 102 community projects
- yibie/awesome-jev — high-signal practice index, 16 domain categories, strict inclusion rules
- Anil-matcha/awesome-jev-by-typesafe — use-case playbook with Python/TS example code
- Promethe-us/awesome-jev — launch-week chronicle (Chinese)
- AnotiaWang/awesome-jev and AbdelStark/awesome-typesafe — broader ecosystem indexes
- awesomejev.com — daily-refreshed searchable directory
Primary sources: launch blog · official docs · official evals
Compiled 2026-09-20 · Evidence tiers in Chapter 0 · Speed and cost figures are vendor-reported and unaudited · No public source exists for RLCD internals; this document fills no gaps with speculation · Reproduction numbers follow each repo's self-reported protocol, see §3.3
CC BY 4.0 — Attribute the source and link this repository when redistributing.