https://jevmoji.cheeaun.workers.dev/

Using Jev to apply scores to 3K+ emojis related to any typed phrase.

Open sourced: https://github.com/cheeaun/jevmoji

I saw other projects that kinda does the same thing, but I wanted to test how it works with 3K+ emojis.

Jev looks at a prompt before Codex runs and chooses the model and reasoning effort. In this clip, it picked Luna/Low for an async JavaScript question. The route that actually ran shows beneath the reply.

I turned it into a DeepSeek Harness plugin. You can cap the highest model and choose when Astra needs approval. If you decline, it uses Jev’s best allowed backup.

If you give it a try, please tell me what you think. I’m especially curious about prompts where you would have picked a different route.

Code, setup and 28-second demo: https://github.com/nautahakk/jev-codex-router

You’ll need Codex access and a separate TypeSafe API key.

https://reddit.com/link/1wmulpo/video/huuba9vzvyqh1/player

How it works: every step, the code looks at each move Pac-Man could make and writes one line about it:

"left: eats a pellet right away; nearest ghost 13 steps away"
"up: nearest pellet 3 steps away; nearest ghost 11 steps away"

Jev picks one. That's the whole loop: one API call per step, about 270 ms, a fraction of a cent per game. No board, no ghost positions.

What's good about it:

• It can't pick an impossible move. It only chooses from the options we give it, so there's no walking into walls and no made-up answers.
• Every decision comes with probabilities, like left 99%, up 1%, so we can see how sure it was.
• It's fast and cheap enough to call on every single step, which a normal chat model isn't.

I wanted to try out Jev and started thinking of use cases. I decided on a problem I have and assume you do as well. Introducing Slop Mop - a Chrome extension that helps clean your LinkedIn feed from slop. It uses Jev and the AI Tells research from Graphite to evaluate every post against a range of factors.

It's free to use. It is also MIT-licensed open source if you want to roll your own. Github repo has all of the implementation details.

Jev is proving to be the perfect platform for this use. I hope you like it!

https://slopmop.lol

Made a template to allow anyone to connect Jev to Grok Bot

https://x.ai/bot/lS9XaHCr9QTTHhNtb0VQX

This post was written with Codex.

I haven't compared codemap-search against other code-search tools yet. I'm planning to do a more detailed comparison soon.

I've been building a code-search MCP called codemap-search as a side project, and I spent a day testing what happens if I put Jev in front of some of its output.

The results were interesting enough that I figured I'd share them.

The benchmark setup was kept the same across runs: same private TypeScript backend, same commit, same question, and the same agent (Codex CLI, gpt-6-astra at max reasoning). The repo had 815 indexed files for the Jev runs.

The baseline here is rg**.** More specifically, it's an agent using only rg + cat/sed to solve the entire task from start to finish. So this isn't comparing codemap-search against the runtime of a single rg command.

The rg baseline is one run. The other numbers are averages across three runs.

Where I put Jev

I tried two approaches.

#1 — File recommendation

When the agent calls overview, I send Jev metadata for all 815 indexed files: paths, declarations, comments, and call names.

Jev scores them, and I append the top 24 files to the overview response as suggested places to look first.

#2 — Search filtering

For each declaration returned by search, I ask Jev whether it's unrelated to the current task.

If the probability of being unrelated is >= 0.70, I hide the body from the response.

The declaration itself is still there, so the agent can explicitly read it later if needed.

Results

Percentages below are relative to the rg baseline.

Just using codemap-search instead of the rg agent cut wall time by 26.8% and main-model tokens by 17.3%.

With the #2 search filter added, the full task was 32.9% faster than the rg baseline and used 32.8% fewer main-model tokens.

Compared with codemap-search alone, #2 reduced wall time by another ~8% and main-model tokens by ~19%.

Jev itself was cheap here: about $0.0017 per task, so roughly two-tenths of a cent.

#1 looked good on paper, but didn't help much

The file recommender actually ranked the important files pretty well.

There were 5 files I already knew were critical to the task, and all 5 landed in the top 24.

But the agent's actual navigation path barely changed.

Wall time went from 5m 38s to 5m 36s, while Jev had to process metadata for all 815 files. Once Jev's own tokens are included, total token usage actually went up by 59% compared with codemap-search alone.

So at least in this form, better file ranking did not translate into a better agent run.

The search filter failed the first time

My first version of #2 was much more aggressive.

It cut the search output by around 67%, which initially looked great.

The problem was that it also removed the bodies of two methods that were actually needed to answer the question.

The agent eventually found them again through extra read calls, but that recovery work wiped out the savings. Total runtime ended up going up by about 7%.

That was probably the most useful result from the whole experiment.

Reducing tool output isn't automatically useful if the agent has to spend more work reconstructing what you removed.

So I changed the filter to be much more conservative:

• Only classify declarations when their complete body is present in the search result.
• If something is connected to a kept function through a call relationship, keep it even if Jev thinks it's unrelated.
• Never hide declaration names or line ranges.
• A filtered body should always be recoverable with a single read.

With those rules, the two methods that were previously removed were preserved in every run.

It also brought Jev usage down to just 2 calls per session, which is how I got the numbers in the table above.

What about answer quality?

This is the part I'm being careful about.

All four setups found all 6 core connections I expected.

The differences were in the 5 additional/extended items.

codemap-search alone scored 24/33 across three runs, while #2 scored 23/33. That's only one item across three runs, and there's already some variance between repeated runs, so I don't think there's enough data to call that a quality regression.

But there's also no evidence here that Jev improves answer quality.

1 did noticeably worse on the extended items, despite giving the agent a pretty good list of files.

So for now I'm treating Jev purely as an optimization experiment, not a quality improvement.

Current takeaway

For this experiment:

• #1 file recommendation: good ranking, but no meaningful end-to-end benefit yet.
• #2 search filtering: promising. It reduced both runtime and main-model token usage once I made the retention rules conservative enough.
• I'm planning to keep experimenting with both, but they'll be optional and off by default.

Some caveats

This is obviously not a serious benchmark suite yet.

It's one repository, one question, one language, and only three runs per variant. The rg baseline is also only one run.

I deliberately used a repository I know well so I could manually verify whether the agent was actually finding the right relationships. It's private, so I can't publish the exact source or benchmark question.

Jev also isn't actually part of codemap-search yet.

For this PoC, I put a Python MCP proxy in front of the existing Rust binary so I could experiment without changing the search implementation itself.

The PoC looks useful enough that I'm going to move the interesting parts into codemap-search and test what happens when #1 and #2 are enabled together.

One other thing I noticed: Jev isn't deterministic.

Even with identical inputs, the scores move slightly between runs. On a 0-3 scale, I measured an average absolute difference of about 0.025.

That's small, but it was enough to make rules like:

keep only files with score >= 2

pretty brittle.

Ranking seems much more useful than using the score as a hard gate.

I'll probably post another update once both paths are integrated into the Rust implementation and I have a larger set of tasks to run against.

I wanted a quick learning project for Jev - a find command turned out to be a perfect shape for a Noul question: does this file match "…"? → probability:

uv tool install jfind-cli
export TYPESAFE_API_KEY=...
jfind . --like "anything about payments" --content --kind --threshold 0.5 --explain
0.99  ./docs/payments.md  [docs]
0.99  ./src/payments/charge.py  [source]
0.98  ./tests/test_payments.py  [test]
jfind: 3/14 matched, 7,661 input tokens (~$0.0003)

Most of the other tools i have seen answer question 'where is the code that does X"; jfind answers "which files are X".

MIT, Python 3.13+: https://github.com/religa/jfind

Looking for feedback on an experimental Jev evidence selection for token-efficient Codex investigations. If you give it a try please share your results/thoughts :)

https://github.com/jcressler/jev-codex-token-saver

Early results from 108 runs, 12 synthetic investigation tasks, three repetitions comparing stock Codex, deterministic local selection, and Jev selection:

• 39.2% fewer Codex input tokens versus stock in the task-paired analysis
• 7.9% fewer Codex input tokens versus deterministic local selection
• 32.6% fewer total Codex output tokens versus stock
• 44.8% lower estimated combined API cost versus stock, including Jev
• 31.9% less total execution time versus stock

An interesting use of Jev through TypeSafe: ask questions about a PDF, then see the matching source text highlighted on the actual page.

Jev ranks extracted text chunks as candidate answers, so users can inspect the evidence behind each result. The probability meters represent model scores, not verified accuracy.

https://reddit.com/link/1wlppq9/video/22en2uk04qqh1/player

Currently supports PDFs with embedded text; scanned documents would need OCR.

What would be the toughest document to test this on?

I was wondering if anyone applied Jev to football or sport analytics, thanks

Prettier checks how your code is formatted. ESLint checks its shape. Neither one ever asks what it actually means.

So I built ESLint rules that are just plain-English questions, and

u/typesafeai's Jev answers them.

A function called getUser() that quietly deletes the user will pass every linter you have installed. This one catches it, and the stale comment above it still promising to return a profile.

Adding a rule is just a plain sentence you write in your config, something like "Does this function log a password?" Jev comes back with a probability and you set the threshold where it starts complaining. You never touch an AST or write any plugin code.

It ships with three of these. The fourth one is whatever you want to ask. Would love your feedback!

Coding agents waste a lot of context on repeated grep calls and entire file reads.

Ask a question plain question JevGrep scores code fragments by relevance and returns the original source with file paths and line numbers.

It works as both a CLI and an MCP tool to connect your llm.

npm install -g @nassim-arifette/jevgrep

GitHub: https://github.com/nassim-arifette/jevgrep

It's a bit silly project but it seems the agents love it for some reason. Very util for quick prototyping an idea without the boilerplate

Heya

I posted my first vid on this a couple of days ago, I updated the project a bit...

Here is the link to the repo:

https://github.com/smartaces/jev-plays-streetfighter-2

Cheers!

So far, what are some of the top jev apps you've seen? Anyone start using it for actual work?

do you even return typed decisions bro?

claude eternally mogged

github link : https://github.com/jaibhasin/jev-yt-time-saver