The catalog contains 176 source-backed Jev projects
Awesome Jev is a directory rather than an SDK or model server. Its 176 entries cover client libraries, integrations, developer tools, research, demos, and other projects built around TypeSafe Jev or a compatible decision schema. Each listing starts as a small JSON file with the exact repository name, a factual sentence, a category, and optional source paths that support the description.
That structure makes the list more useful than a long README edited by feel. The README is generated from the entries, so the machine-readable record is the source of truth. A contributor can point the reviewer at up to 6 evidence paths, while the workflow also searches the README, manifests, filenames, and file sizes for likely integration code. The final decision still belongs to a maintainer.
Four local tests validate the catalog without an API key
Local development requires Node.js 22 or newer. npm run check validates the entry set, npm test runs the supplied Node tests, and npm run build regenerates the README. The package declares no dependencies, which keeps the catalog check separate from the hosted model review. A contributor can verify formatting and generated output without spending model quota or receiving repository secrets.
The live review has its own credential boundary. A repository owner configures a dedicated TYPESAFE_API_KEY, or explicitly enables a Vercel AI Gateway or Cloudflare Workers AI fallback with its credentials. Submitted pull requests never receive those secrets. The privileged workflow runs trusted code from the base branch and reads the proposed entry files as data, reducing the chance that a submission can replace the reviewer before secrets are available.
What happened when we ran it
Our unprivileged Node sandbox with 3 CPUs and 8 GB of RAM installed commit 4dc482a in 7 seconds. Npm installed 0 packages and used 2 MB on disk. The build succeeded in 7 seconds, and the test step finished in 6 seconds with 4 passed and 0 failed. Npm audit reported 0 known vulnerabilities.
The repository contained 194 files but only about 102 lines counted as source by the lab scanner, because most of the project is JSON entries and generated documentation. The checkout occupied 0.1 MB. It had 2 CI workflow files, no Dockerfile, and a tests directory. Those numbers fit the product: the value sits in its records and review policy, not a large runtime.
Our run tested the local catalog mechanics. It did not call Jev, grade a new repository, or measure whether the model accepts and rejects the right submissions. The contribution guide recommends calibrating on human-labeled genuine integrations, keyword false positives, weak evidence, incorrect descriptions, and ambiguous categories. No accuracy rate should be inferred from the 4 passing unit tests.
One review reads at most 10 files and 48,000 characters
For a live submission, Jev first chooses up to 6 likely source files without seeing their contents or the optional hints. A second call reads the chosen files plus supplied evidence, then judges whether the integration is concrete, the description is supported, and setup instructions are usable. It also suggests a category. The report names the reviewed commit, model version, policy hash, probabilities, and evidence links.
The evidence budget is visible: up to 10 files and 48,000 file-content characters. Files are never silently truncated. If one cannot fit, the workflow omits it and adds a warning that requires maintainer review. There is no second retrieval round. That makes a recommendation reproducible enough to inspect, while a large or oddly organized codebase may need the submitter to choose better evidence paths.
The model advises, and a maintainer controls the merge
A recommendation never merges or rejects a pull request. Uncertain categories, missing source support, and conflicting descriptions go to a person. Batch submissions receive separate reviews, and one unresolved entry makes the Action fail while preserving completed sibling reports. Since GitHub merges the whole pull request, the contributor must fix, remove, or split the unresolved entries before a maintainer can accept the batch.
This boundary prevents the directory from laundering a model score into an endorsement. It also means inclusion is narrow evidence: the code appears to use Jev for the described purpose. The review does not install the listed project, run its suite, test its security, or prove its model claims. Initial seed entries were maintained manually, and the guide explicitly forbids saying they passed a live Jev review unless a report is linked.
Review artifacts expire after 14 days
GitHub Actions stores the JSON report for 14 days. The repository has a validation-record area for saved reports, but contributors or maintainers must preserve the artifact before expiry if they want a permanent record. That matters because the report retains selection probabilities, file paths, model identity, usage, hashes, and the policy version behind the recommendation. The README alone cannot reconstruct all of that later.
GitHub showed 220 stars, 55 forks, and 7 open issues and pull requests on October 6, 2026. Six of those were pull requests, and submission activity continued that day after the October 3 push. There is no release tag, which is acceptable for a living directory but weakens snapshot discovery. Use the catalog to find candidates, then follow its own evidence links and inspect the target repository before adopting anything.