Two hundred fifty entries make this a field guide, not a shortlist
The current README contains 250 community projects across 7 categories, plus official resources, runnable examples, and design advice. It covers client libraries, agent tools, browser agents, applications, games, evaluations, and field notes. A searchable GitHub Pages site turns those entries into dedicated project pages, while resources.json gives agents and scripts a machine-readable view.
Breadth is both the attraction and the cost. You can move from the official SDK to local Jev-style models, see integrations, and find independent failure reports in one place. You cannot infer that all 250 projects are equally maintained or safe. The directory says inclusion is not an endorsement, and each project remains responsible for its own code, service terms, data handling, and evidence.
Curation requires evidence and a material limitation
The contribution guide asks each source project to be public, usable or inspectable, licensed when code is involved, safe about credentials, and explicit about data leaving the machine. A listing should name one material limitation. Evaluation submissions need a method, model version, task data, raw results or useful aggregates, and caveats. Empty repositories and private claims are rejected.
That policy produces unusually useful one-sentence entries. Many say exactly what gets sent to TypeSafe, where a threshold lives in application code, or which platform was actually tested. Contributors must disclose affiliation. Maintainers regenerate the derived pages before merge rather than asking first-time contributors to edit generated assets. The rules do not independently reproduce every claim, but they make weak evidence easier for a reader to spot.
What happened when we ran it
Our measurement setup cloned commit af429b4 into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Installation took 9 seconds, added 35 packages, and occupied 37 MB. The build passed in 2 seconds. Pip-audit reported 0 known vulnerabilities in the installed environment.
Pytest completed in 5 seconds with 2 passed and 0 failed. The tests cover the bounded GitHub discovery sweep, including pagination and removal of README-only search hits. The checkout had 571 files, about 2,710 source lines, 2 CI workflows, and a tests directory. It had no Dockerfile, which fits a Pages site and export scripts rather than a hosted application server.
Our run validates repository mechanics, not the 250 linked projects. It did not call Jev, reproduce an external benchmark, check every live demo, or review the security of a listed integration. The separate links workflow is useful for reachability, while a working URL can still lead to changed behavior. Treat the date, model version, and source attached to each claim as part of the claim.
README is the source for every generated page
Contributors edit one alphabetized README entry in one category. The export script derives resources.json, project pages, category pages, social cards, the site index, and supporting assets from that source. CI then checks that committed output matches. Structural validation also rejects tracking parameters, duplicate curated URLs, broken table-of-contents anchors, malformed entry sentences, and missing site files.
The current check script requires at least 20 community entries, although the live README has 250. It verifies shape and consistency rather than editorial truth. A fabricated claim could satisfy the parser if a maintainer failed to challenge its source. Human review therefore remains the main quality control, with automation protecting the catalog from formatting drift and stale generated output.
Examples keep the model answer separate from policy
The opening tutorial explains three typed outputs. Noul returns a probability for a yes-or-no claim, Choice selects among named options with probabilities, and Score maps context onto an ordered rubric. The sample routing code uses a 0.9 threshold but labels it illustrative. Application code validates the answer, chooses the threshold, and performs any side effect.
That separation is the guide's best editorial choice. The independent evaluation table then shows why it matters: different studies report abstention behavior, cascade costs, routing bounds, ranking failures, and action-gate errors under different conditions. Awesome Jev does not blend those results into one score. Readers get links to the underlying reports and warnings to test their own labeled cases.
The renamed repository is active, while claims still age quickly
GitHub now identifies the project as AbdelStark/awesome-typesafe-jev; the old AbdelStark/awesome-typesafe URL redirects there. The repository was pushed on October 2, 2026, and GitHub listed 3 open issues and pull requests on October 5. The latest release is a September 21 ecosystem snapshot containing 129 projects, while the current README has grown to 250.
That jump shows active curation and explains why dated snapshots matter. It also raises the maintenance burden for links, descriptions, licenses, and evaluation details. Awesome Jev is the most useful starting point we found for this narrow ecosystem because it pairs discovery with visible limits. The final decision still belongs in the linked source, current provider documentation, and your own test cases.