What people are building with Jev: a look through nine awesome lists

I went looking for what people had built with Jev. Browser demos were easy to find. So were lists of lists. Getting a sense of the rest took more work.

I collected the repository links from nine Jev directory READMEs. After removing repeated URLs and other directory listings, I had 1,186 different repository addresses. That isn't a count of finished apps. It includes experiments, libraries, integrations, and alternative implementations. A renamed repository can also appear under more than one address.

There was enough there to do more than pick a dozen favourites. Here's the shape of the lists, followed by some projects that make the different uses easier to picture.

First, what does Jev actually do here?

Think about sorting an inbox. Writing a reply is one job. Deciding which messages deserve a reply is another.

The projects below give Jev those smaller decisions: choose a button, score how relevant a document is, or decide which model should handle a request. The surrounding software still has to do something with the answer. If a notification needs writing, a text-generating model can handle that part.

That division of work is a useful way to read these projects. The TypeSafe documentation describes the model interface.

How much do the lists overlap?

The nine READMEs contain 2,108 list memberships: a repository appearing in three lists contributes three to that number. Counting each owner/repository address once brings it down to 1,186.

757 addresses, or 63.8%, appear in only one list. Another 213 appear in two. Just three appear in all nine.

So choosing a directory changes what you see. The largest README in this collection has 785 entries; another has 13 eligible repository addresses in its visible showcase. Some maintainers link to much bigger catalogues elsewhere. Those linked catalogues aren't included in these numbers.

This also puts a limit on what the overlap tells us. Several lists may find projects from the same places. Appearing five times doesn't mean five people tested the software, and appearing once doesn't make a project unimportant.

What are people using it for?

Combining the categories turned out to be trickier than combining the URLs. One list's “SDKs and clients” section even includes a Snake game and an email app. Adding those labels together would give a neat chart with a muddled meaning.

For the category chart, I used all 358 entries in logicrw's directory, which assigns each entry to one of 17 categories. I grouped those into eight broader headings below. This covers 30.2% of the 1,186 addresses; the other 828 remain outside this category analysis. These are the directory's classifications, not my independent audit of every project.

The biggest group is the software around Jev: connections to existing tools, libraries, and frameworks. That's 90 of 358 entries, or 25.1%. Another 72, or 20.1%, deal with assigning work and managing an assistant's history.

Browser and computer control account for 27 entries, or 7.5%, in this particular directory. The browser demos caught my eye first, but they describe only part of what's listed.

Below are examples worth opening from several of these areas. The examples are a reading guide, not a second statistical sample. I checked their documentation. Apart from my OpenPoke fork, I haven't independently run them. The illustrated scenarios below explain the workflows; they aren't screenshots or recorded outputs.

Deciding which emails need attention

An assistant receives a message asking you to confirm a meeting time. Before writing a notification, it has to decide whether that message needs your attention at all.

openpoke-meets-jev is my fork of Shlok Khemani's OpenPoke. Jev handles email screening; a language model can still write the notification afterwards. Uncertain screening decisions can fall back to the original classifier.

In my small test, average screening latency went from 2,452 ms with Sonnet 4 to 424 ms with Jev. That measures the screening call, not the whole assistant. The earlier write-up covers the test and a filtering-policy mistake it exposed. The message in the diagram is just an example to explain the flow.

Start with the repository's A/B results and the screening path. Running the fork takes more setup than reading a report, and enabling Jev sends email bodies to TypeSafe for classification.

Clicking through a website

Imagine asking an assistant to find a flight. At one point, all it needs to do is select the destination field. The illustration below isolates that one step.

Jev Ultrafast turns a page into a numbered set of controls. Jev chooses what to do and which control to use. A separate text model supplies words when something needs typing.

The flight-search example gives you a concrete task to follow. It's also worth reading the author's results on longer tasks, which were much weaker. A quick successful search doesn't settle whether an agent can finish a long errand.

jev-browser takes a similar split in a different direction. A larger model gives it a small goal and any text it needs; Jev handles decisions inside that step. The caller gets a result back, including when the browser is stuck or needs confirmation.

Deciding where the work goes

Suppose an app can call several AI models. It needs to choose where each request goes before any answer is written.

jev-router sits between an app and several AI models. It asks which available model should handle the request. A short question and a difficult coding task don't necessarily need the same destination.

I like that it includes a simple comparison: without a Jev key, it chooses the cheapest eligible model. That makes the extra decision something you can test against a basic rule. The project is experimental; choosing well is the part to measure.

Keeping a long-running assistant on track

After an hour of work, an assistant may be carrying old search results, current instructions and failed test output. Which pieces will it still need?

fast-jev-compaction tackles a different kind of overhead. As an assistant works, its history fills with old tool calls and results. This project asks which pieces are still useful, then removes or shortens the rest.

The useful question is whether the assistant can still finish its task afterwards. A shorter history alone doesn't answer that. Also, the README's animation is a scripted illustration, not a live API run.

Finding the information worth reading

You want to change something in an unfamiliar codebase, but don't know the filename. It helps to ask what the code does rather than guess what the author called it.

every lets you ask a question about code and ranks functions by how likely the answer is yes. For example, you could look for places where unchecked input reaches a database query.

Each piece of code is judged against the question. That makes it an interesting way to find where to start reading, though a high score isn't proof of a bug. It sends the scanned source to TypeSafe, so a public repository is a sensible first test.

Checking something before it happens

Someone submits a project to a directory. Before reading every line, a maintainer wants a first pass against the submission rules.

jev-guard checks actions an agent proposes to take. It combines ordinary checks, such as boundaries around file access, with Jev's assessment of the operation.

Its audit mode records decisions without blocking actions. That gives you a way to see what it flags before putting those judgments in charge. The project's checks, settings, and handling of errors all matter here.

Jev Review Action brings the idea back to these directories. It can check a submitted project against a maintainer's criteria: does it belong here, and is there enough evidence?

Jev supplies decisions, and a fixed template produces the comment. One of the lists I used is therefore also an example of using Jev to help maintain a list.

Arranging an interface from existing parts

An app already has a heading, a list of items and an allowed action. The remaining question is how to put those pieces on screen.

json-render's Jev experiment starts with a set of interface components, their data, and allowed actions. Jev chooses what to include and how to arrange it.

The supplied choices do a lot of the work. The text has to come from somewhere; Jev doesn't invent missing copy in this setup. The documentation labels this an experimental, unreleased interface.

Choosing the next move in a game

TypeSafe Mario gives Jev information from the game's memory: where Mario is, what's nearby, and what happened recently. It then chooses a controller action. It isn't looking at screenshots.

Even without running the game, the documented state-demo lets you inspect the information used for those choices. That was the interesting part for me: deciding what the model gets to see is a large part of building the demo.

Trying alternatives and measuring mistakes

LocalJev provides a compatible interface backed by a locally running model. It offers a way to explore the same style of requests with a different setup.

Compatible requests don't guarantee equivalent answers. Its README explains that the model generates probability values, which differs from obtaining them directly from the model's internal scores. Whether the results are useful needs its own test.

jev-spam-eval compares email classification approaches, including Jev and conventional text classifiers. It also explores how results change when an email comes with more context.

This project separates legitimate mail, spam, and phishing. Its datasets and saved reports are useful reading before spending time building another email filter. Start with the saved results; rerunning the experiments requires API access.

Keep this table for the next time you need an example

The links go to the project or its guide. “Start here” means a useful place to inspect, not a claim that every project runs without setup.

What I'd take from this

The directories gave me more ideas than another fast browser clip would have. A lot of the work is happening in small decisions inside larger applications: what to keep, what to skip, what to read next.

Before adding a model call, I would write down the decision it is supposed to improve and the simplest rule it has to beat. That gives the demo a useful test: does the whole task get better?

If you've built something that doesn't fit these examples, I'd like to see it. A repo link and a sentence about the decision Jev makes would be useful.

How I counted

Snapshot: September 21, 2026. I counted the primary GitHub repository links in the selected project sections of nine README files. I excluded other awesome lists, badges, supporting evidence links, and the generic my-stars-atlas catalogue tool. Articles and demos without a GitHub repository link aren't represented.

I normalised owner/repository addresses to lowercase, removed .git, and counted an address once per directory. Forks remain separate, and renamed addresses aren't merged unless their normalised paths already match. This is a census of those README sections, not a survey of every Jev project. No claims about user numbers, growth, or market share follow from it. Repository stars aren't Jev usage: an established framework may have accumulated most of its stars before adding an integration.

The public research appendix includes all 1,186 extracted repository addresses, the counting rules, snapshot hashes and the category mapping. The 17 original category counts are retained so the broader groups can be checked.

Sources: fatwang2, logicrw, yzfly, walidboulanouar, daftAI2026, BeatAPI, RadRebelSam, yangzhou-chaofan, and evan87863.

I'm Shin, a Japanese indie hacker. Previously CTO at a US startup and CPO at a Japanese startup. You can find what I'm building on GitHub.

AI assisted with research, drafting, and illustrations. The OpenPoke implementation and experiments linked above are my own. The charts count directory entries; the other diagrams show simplified workflows.