The Jev ecosystem has a discovery problem that looks like a richness problem. There are hundreds of repositories, dozens of “awesome” lists, several benchmark sites, and a steady stream of launch posts. The hard part is not finding a project. It is telling a maintained project from a weekend scaffold, and a benchmark from a marketing page.
This is a map of the community infrastructure, with the caveats that make each layer useful.
The awesome lists are the entry point
awesome-jev is the most complete community list. Its October 2026 crawl lists 481 GitHub repositories and about 640 external links, generated from per-category files. It groups by direct Jev application domain and includes a “Related Practices / Discussions” section for interviews and threads. Its own warning is the most important part: a listing is not an endorsement, and it calls out same-day bulk submissions with thin commit histories.
awesome-typesafe is a field guide rather than a catalog. It separates official documentation from community projects, includes a “choose the right tool” table that routes explicit rules to code, bounded judgments to Jev, and prose to a text LLM, and ships a resources.json plus a SKILL.md so an agent can read the whole directory. It states plainly that inclusion is not TypeSafe approval.
The other lists (Awesome System One Models, Awesome Open System One, Awesome Decision Models, and Awesome Jev Lab) overlap heavily. That is normal for an ecosystem this young. Use one as your primary index and the others as a cross-check.
The companion sites add structure
jevbest.com is a searchable companion to one awesome list: 962 GitHub projects with stars, languages, and one-line decision summaries. It says “verified repositories,” but the page publishes no verification method, reviewer, or inclusion criteria, so treat “verified” as display copy rather than an audit. Its own caveat is the right one: star counts and repo lists change.
jev.info and the community hubs are useful for discovery, but they are not evidence. The TypeSafe Discord is where launch-week discussion happens; the agent skill is the official way to give a coding agent the directory's context.
The benchmark layer is separate
The community lists tell you what exists. They do not tell you what works. The benchmark layer is where the evidence lives:
- JEV Decision Index Results and the encoder index for leaderboard rankings.
- JevBench and JevBench metamorphic for task-level evaluation.
- TypedBench for calibration, framing sensitivity, and cost.
- Workflow evals for end-to-end workflows.
- Jev vs Laya and Jev News compare for head-to-head comparisons.
The caveat is consistent across the layer: most numbers are self-reported, and the independent evaluations often cover one model version or one task family. The measuring Jev article covers how to read them.
The repo layer is where the maintenance signal is
A repository's README is not a quality signal. The maintenance signal is in the commit history, the issue tracker, the release cadence, and whether the project calls the Jev API or only mentions it.
A useful triage:
| Signal | What it tells you |
|---|---|
| Calls the API in code | It is a Jev project, not a mention |
| Has a runnable check | Someone verified it works |
| Publishes numbers with a source | The claim is traceable |
| Has a license | You can use it |
| Has recent commits | It is maintained |
| Has an issue tracker with responses | Someone is accountable |
The awesome-jev checklist is close to this: whether the code calls the Jev API, whether a runnable check exists, whether numbers have a source, and whether a license exists. Use it before you install anything.
The community layer is a signal, not a source
X threads, Reddit posts, and Discord messages are where you learn what people are trying. They are not where you learn what is true. The launch reception article documents the gap between the Product Hunt reception, the Hacker News skepticism, and the r/LocalLLaMA backlash. The weekend builds article covers the first wave of projects and the claims behind them.
The healthy pattern is: discover on a list, verify in the repo, measure with a benchmark, and test on your own data. The community layer is the first step, not the last.
Where to start if you are new
Start with the awesome-typesafe field guide for the concepts, then use awesome-jev or jevbest to find a project in your domain. Pick one repository, read its README and its last twenty commits, and run its example. Do not install five projects in parallel; the ecosystem is large enough that the bottleneck is verification, not choice.
Once you have a candidate, check it against one benchmark and one independent evaluation. If the project publishes a number, reproduce it on a small sample. That is more work than reading a list, and it is the only way to know whether the listing means anything.
A short checklist
- Pick one awesome list as your primary index.
- Check the repo for a real API call, a runnable check, a license, and recent commits.
- Treat “verified” and star counts as display values.
- Use the benchmark layer for evidence, not the list layer.
- Read caveats on every benchmark; most are self-reported.
- Cross-check a project's claims against an independent eval.
- Test the candidate on your own labels before adopting it.
The ecosystem is rich enough that discovery is no longer the bottleneck. Verification is. The map above is designed to make that second step faster.
