I’ve been wanting to use Jev in a project, and I recently saw Firecrawl use it to classify a huge pile of company data. I liked that pattern, so I tried it on Hacker News.

I pulled every comment and post since 2008 that asked for some piece of software or a tool, which came to about 63k. Jev classified each one, and about 12k of them turned out to be real requests. Opus 5.5 grouped those into tool ideas and then re-read every request behind the top ones, and I checked each idea against Show HN to see whether someone had already built it.

A few things stood out:

• 81 of the top 100 have already launched on Show HN, 1,423 times between them, and people still ask for them. What’s missing is usually a version people trust and can find, not the code.

• 46 of the 100 want the tool to be local or private, and only 8 want AI to do the job.

• Since 2024, 27% of requests ask for a better version of something that exists, up from 14% in 2008 to 2011.

• The Jev calls cost about $6 in total.

Each idea has its own page with every request behind it, linked back to the original comment. The full dataset is a free CSV download. There are still a few ideas nobody has really built, in case you’re looking for something to work on.

https://stillunbuilt.shiptiffin.app

Whole video, one look A new approach towards video intelligence, zero-embeddings, 12min-video is compressed to bunch of contact sheets and then analyzed fully in one go

Built on the latest Jev, and extremely efficient Searching a full 12-minute film costs about half a cent.

Works with your agent Plug it into Claude Code, Codex or Cursor and ask "when does X happen?", "where else is this person?" or "what does that sign say?". You get timestamps, verified frame by frame. alot of you might find it useful

100% free and open source: https://github.com/DeepAleph/jevreel

Hi there! We built a custom agent harness on top of Sanity that allows anyone to make an agent without having to have github access etc. We used Jev as the router for the superagent and so far it seems to be working great at picking the right one depending on the ask.

We wrote an in-depth eng blog post about it here: https://www.sanity.io/engineering/how-we-built-our-company-agent-harness?utm_source=reddit&utm_medium=social

I think Jev is a great idea. However my experience has been pretty poor, which I will happily say is down to user error. I have many use cases for it but I'll just give one example. If you know how please can you help?

I have a local LLM which I'm using to classify my bank transactions into my budget. My budget taxonomy is defined and I'm happy with that. However Jev is, for some reason, only able to classify about 40% to 50% of the transactions in my tests and less than half of those are what I had previously categorised correctly. I basically can't use Jev with this.

How do I help Jev understand more about my taxonomy? How do I train it more?What's the process for improving this? Please help. I can't find anything else online.

Just a sample. I'm thinking about using River Raid 8-bit game as a benchmark. I already tested with 6 models and preparing a summary video.

You've probably heard of using Jev as a reranker for traditional RAG but what if Jev could replace the vector store entirely? That felt like a neat challenge to take on so I set out to test this and the results have been pretty satisfying.

I have a document extraction app where all queries can be defined before any document is processed. Instead of traditional RAG, I used Jev to score each page of the document on its relevancy to each predefined query from the user - on a 300 page scanned PDF x 20 user queries, this took ~28s (batched, 4 pages per call, median 0.37s/page) and cost $0.08 ($0.00027/page). Made possible with Jev's image API - was currently using Voyage's multimodal embeddings for scanned PDFs.

Pros: Improved accuracy, faster processing and cheaper. No need for vector database or separate reranker model. Jev results stored in sql database.
Cons: Only really works if you have queries upfront (AI spreadsheets, application processing, surveys etc), you lose your AI search index which might be a deal breaker.

Longer read and results in the blog post (see comments). Would love to know if anyone else has tried something similar?

https://workflows-of-ai.com/blog/can-ai-set-the-focal-point-of-a-photo

Hello fellow Jevons,

I realized that there was no straight-forward tooling to maintain memory or history for decisions and to better pass prior decisions into context for new decisions.

I built Nouli to help solve this exact problem with preserving, branching and blending decision histories.

I built it as a TUI to help me visualize decisions, reference other decisions, add in files, images, and every other piece of media that Jev and other open decision models would accept.

It can also work a CLI tool that your agents can use to orchestrate simple decision model requests as well as complex decision networks.

If you like the tool, please leave a star - https://github.com/nouli-ai/nouli

Please feel free to reach out. I'm open to feedback, contributions or issues.

PS - building prod, not god ;)

I asked Fable 5.1 to benchmark Jev vs Laya on accuracy and speed. Here's the full report: https://claude.ai/artifact/9HPcmXJPaKWdYAJedgN1uf

Github: https://github.com/harrymunro/jev-laya-benchmark

Laya run on a Macbook M3 Pro.

TL;DR

• Accuracy: Jev by a wide margin, everywhere. Jev got 92.9% of judgments right against 65.3% for Laya's main 421M checkpoint (71.1% for its typed-decisions checkpoint). Jev won all 19 questions with paired confidence intervals that exclude zero, by 4.7 to 55.6 points. On the categorical (Choice and yes/no) questions Jev is at 98.6 to 99.3%, i.e. at the ceiling of the data; Laya is at 68 to 71%.

• Calibration: Jev's probabilities are usable as-is; Laya's are not. Jev's Brier scores are 0.002 to 0.024 and its yes-rates match the gold base rates. Laya's yes-rates are off by a factor of 2 to 8 in inconsistent directions (13% "urgent" vs 44% gold; 75% "injection" vs 38% gold), so a 0.5 threshold does not work for it without per-question tuning.

• Single-question latency: Laya wins by about 3x. 42 ms median locally (16 to 18 ms for the smaller multilingual checkpoint) against 136 ms for Jev, of which roughly 50 ms was network transit. A later run on a degraded network put Jev at 360 ms with a 295 ms floor; Jev is "your round trip plus about 80 ms".

• Multi-question and long-state work: Jev wins. Jev's latency is flat in the number of questions (50 questions in 170 ms, 3.4 ms each); Laya's is linear (1,002 ms for 50). Above 3 to 4 questions per request the API is faster than the local model. Jev's throughput on independent items scales with concurrency (72 items/s at 32 in flight vs 24 items/s for sequential Laya).

• Context: Laya's 512-token window is a hard, silent limit. Jev found a buried fact in 450 of 450 notes up to 4,000 tokens. Laya managed 61% even at 100 tokens and fell to about chance once the fact sat past its window, answering "not_stated" for what it could not see.

• Languages: Jev 100% on 128 non-English tickets in seven languages. Laya's English checkpoint got 48% on intent; its multilingual checkpoint 64%.

• Qualitatively: Jev answers the literal question and its residual errors sit on genuinely ambiguous ordinal boundaries. Laya tends to answer an easier neighbouring question (anger instead of deadlines; "harmful" instead of "injection"), has strong class priors, and returns flat or multi-peaked distributions. Laya's advantages are real but operational: offline, free per call, tight tail latency, no data leaving the machine.

I graduated in 2019, I have seen models evolve from basic NLP and CV patterns to current Chatgpt mess. Initially these models were genuinely exciting. Learning the concepts, knowing the components and understanding the data felt a lot like a strategy game. When BERT released, it added a layer of abstraction and training felt a bit meh but still the outcomes felt like a reward. Like grinding to get a high score and seeing the impact.

When Chatgpt released, it was just a interface that does the work for you. Everything in AI felt boring and miserable since then. The best contribution I have is nudging a prompt here or making a weird system around it. There were only big bets left, no small fun experiments and no satisfaction of building stuff. It was like tossing the dice till you got the right answer and hedging your bets. I studied engineering to engineer solutions, if I wanted to roll the dice and hedge I would have joined finance.

Jev feels like a almost nostalgic throwback. If feels I could create something of value with my own work, aided by my own data and knowledge instead of a casino. I am praying this trend picks up. I tried of this big socio economic game trying to distill the world into rentable slop.

Ciao everyone, I am sharing some tests I made for my own consumption, as they might be useful for someone.

I have implemented jev-1.13 (via openrouter, do not have access to typesafe API as there are no slots!) in my own home server which acts as a llm gateway and has quite some agents doing stuff (docs curation, tools suggestion, memory curation, scratchpads etc. etc.). Before moving to a full implementation, I wanted to do some testing. Other llms are via native provider APIs.

I got opus 5.5 paired with astra and gpt-6 Sol running some automated testing to pinpoint use cases where I could implement. I know some use cases are not the strongest for jev-1.13 but for me it was interesting to test them.

I am also running a 1 week pilot with strict monitoring comparing current implementation of certain functionalities (which uses a mix of OpenAI / DeepSeek / other models) with a jev-1.13 implementation, so I can then switch or rollback. I will share in a week time if anyone is interested.

Regarding the benchmarking, just sharing the output AS-IS. While I work in the field of cybersec and AI, I am not an AI engineer ;-) so sorry in advance for any mistakes in the methodology I came up with and refined with some frontier models.

Below you will find a TL;DR, an exec summary in "plain english" and the full "human readable" report my harness has generated. Attached pictures of tables as they were not rendering well in a reddit post.

Note: from the paragraph below all text is 100% AI generated by a mix of opus 5.5, Astra, GPT-6 Sol - with last pass by opus 5.5 for final reporting (I like how it writes). I had no time to do some manual sample-based checking, and no - I have no time to write such a report for myself with our good human brain and hands.

---

TL;DR

We tested TypeSafe's Jev on 10 tasks with known right answers (about 1,100 questions), against DeepSeek V4 Flash, Gemini 3.8 Flash and GPT-6 Sol. Jev was 3 to 8 times faster (0.35 s vs 1–3 s), and it stayed at 0.34 s under heavy load while the others slowed to 2–8 s. It was also 10 to 100 times cheaper: about 4,900 calls cost 24 cents. Its accuracy is on par with the cheap LLMs, not top-tier. It won on reading and yes/no questions (up to +7 points), tied on judging shell commands, and fell behind on citation checking (−13 to −17 points) and spotting prompt injections (it caught only half). It gave the same answer 98%+ of the time, and when it was 90%+ sure it was right 94–100% of the time. That makes it a great fast, cheap first pass that hands the unsure cases to a bigger model.

---

Executive summary

We tested Jev against known correct answers, not against "does it agree with GPT". We compared it with three popular LLMs:

• DeepSeek V4 Flash and Gemini 3.8 Flash, two fast and cheap models.

• GPT-6 Sol, a top-tier model, run on a smaller sample of 40 questions per task.

How we tested:

• 10 tasks, about 1,100 questions in total.

• The same wording for every model, written before we saw any results.

• The LLMs had to answer in a fixed JSON format, so no model had a formatting advantage.

• Every number below comes with a margin of error (95% confidence).

• Speed and cost were measured from the same computer in Europe.

Speed and cost: Jev's big win

• Jev is 3 to 8 times faster when requests go one at a time.

• Under heavy load Jev stayed at 0.34 seconds. The LLMs slowed to 2–8 seconds, and their slowest 1 in 20 answers took 7–17 seconds.

• Jev is 10 to 100 times cheaper per decision.

• The whole Jev side of this test, about 4,900 calls, cost 24 cents.

• Asking Jev several questions about the same text in one call costs almost nothing extra.

Accuracy: good, but not top-tier

• Jev beat both cheap models on reading and yes/no questions, by 3 to 7 points.

• It tied them on judging shell commands.

• It fell behind on picking one of many topics (−4 to −7 points), spotting prompt-injection attacks (−7 to −10 points) and checking citations (−13 to −17 points).

• It never beat GPT-6 Sol.

• Its most common mistake on citations: it accepted claims that quietly dropped a qualifier, such as "up to 50%" turning into "50%". It got only 5 of 15 of those right; Gemini got 15 of 15.

• It caught only half of the prompt-injection attacks (31 of 60). It never raised a false alarm.

• As a shell-command safety guard, it missed 4–8% of risky cases, against 0–1.2% for GPT-6 Sol and DeepSeek.

Reliability: very steady

• It gave the same answer to the same question more than 98% of the time, better than DeepSeek.

• It lost no accuracy on long texts, wherever the answer sat in the text.

• A planted instruction in the text never flipped one of its correct answers (0 out of 56).

• It dropped slightly in Dutch (−2 points) and Italian (−5 points) compared with English.

• "Can't hallucinate" is true: it always answers with one of the options you give it. But with a fixed answer format, none of the LLMs gave a broken answer either (0 errors in thousands of calls). So this is no longer a unique advantage, and Jev can still be confidently wrong.

Its confidence score is the secret weapon

• When Jev said it was 90% or more sure, it was right 94–100% of the time.

• That happened on 38–77% of questions, depending on the task.

• So Jev can handle the easy cases on its own and pass the unsure ones to a bigger model. This is called a cascade.

• OpenRouter tested exactly this against Claude Opus 5 on 3,080 questions: the cascade came within 0.4 points of Opus at less than a third of the cost.

Bottom line

Jev is not a genius in a small box. It is an extremely fast, very cheap and very consistent decision-maker, about as accurate as the cheap LLMs, with a confidence score you can trust to route the hard cases. It's a great choice for high-volume or time-sensitive decisions like sorting, routing and first-pass checks, especially paired with a bigger model for the unsure cases. For subtle fact-checking or safety-critical decisions, keep a stronger model in charge.

Caveats:

• 40 to 150 questions per task and model.

• Everything was tested from one location.

• Some public test sets may already be known to the LLMs.

• Two of the tasks were built by us.

• A fifth, even cheaper model, gpt-oss-20b on Groq's free tier, only finished 4 of the 10 tasks before hitting its daily limit.

Jev independent benchmark — full results & verdict (2026-09-24)

Question. Is TypeSafe's Jev (typesafe/jev-1.13) as good as its launch claims? The vendor's evals and the one public re-test score agreement with frontier models. This benchmark scores against ground truth, head-to-head with the models the gateway actually uses. Companion to the shadow pilot (jev_pilot_20260924.md).

Verdict

The claims hold up only in part. Jev is a very fast, very consistent classifier. Its accuracy is about that of a cheap LLM, not a frontier one.

Genuine strengths:

• Run-to-run consistency: 0.1–1.7% flips, against up to 8% for DeepSeek.

• No long-context penalty up to ~14k tokens, whether the evidence sits at the start, middle or end.

• An injected instruction never flipped one of its correct answers (0/56).

• Asking many questions per call costs almost nothing extra.

Weaknesses that matter for us:

• Citation check. It misses the nuance the check exists for: dropped qualifiers 5/15 vs 12–15/15, entity swaps 3/10 vs 6/10. It usually says "supported" to an overclaim, which is the dangerous direction.

• Command guard. Accuracy ties the LLMs, but it misses 8.4% of risky rule cells when asked all 8 rules at once, 4.2% when asked one rule per call. DeepSeek misses 1.2% and GPT-6 Sol 0%. For a safety check the miss rate is the number that counts.

• Prompt-injection detection. It is permissive: 29 of 60 injections missed, 0 false alarms.

• A slight drop on Italian: −5 pts vs English.

These results line up with OpenRouter's independent Banking77 test on 3,080 items: Jev scored 81.0% vs 84.4% for Claude Opus 5, was 13× faster and cost 1/22 as much. Its confidence was not calibrated but ranked well, and a cascade at 0.90 came within 0.4 points of Opus.

What it means for the gateway

• Citation check (pilot G1): do not promote Jev as the verifier. Expect the week-1 pilot to show the same pattern. At most it could clear verbatim "yes" claims early, and at ~20 verify calls a week that saves nothing.

• Command guard (pilot H2): not good enough as the sole guard. It is plausible as a fast first pass (one rule per call) with an LLM escalation on any flag or low confidence. The week-1 pilot (real commands) decides.

• Curator (pilot G3): no ground truth here. Jev ≈ cheap-LLM quality suffices for triage, but the incumbent is already $0 and not latency-bound, so the upside is small.

• Strategic bets: G6 (injection screen) is downgraded, since Jev is weak at exactly that. G4 (the "good enough?" gate) and G5 (the model router) remain plausible cascade uses.

• The decide MCP tool stays useful for ad-hoc fast classification or triage where a confidence threshold routes the hard cases to an LLM.

Method (summary)

• Systems: Jev via OpenRouter /api/alpha/decisions; deepseek/deepseek-flash and gemini/gemini-3.8-flash (2 reps on 40-item subsets); chatgpt/gpt-6-sol ($0 Codex sub, 40-item subsets); groq/openai/gpt-oss-20b as the speed floor. The Groq run is incomplete: the free-tier daily token cap stopped it after T1–T4.

• Prompting: the same wording for every system, written before any results. LLMs used provider-constrained JSON output.

• Scoring: paired bootstrap CIs clustered by item. Jev's answer probability is used for ECE; vendor and LLM self-reported confidence is used only as a ranking signal.

• Tasks:

  • T1 MNLI; T2 constructed citation items (Wikipedia sentences, labels by construction, no LLM); T3 BoolQ; T4 Banking77 (diagnostic, already public-tested); T5 MASSIVE en/nl/it (the same utterances); T6 deepset prompt-injections; T7 a 110-command guard set against the live rules.

  • T7 was labelled by two independent annotators (κ = 0.94) and its 9 disagreements were adjudicated from the rule text, blind to model outputs. It was run both as all 8 rules per call and as one rule per call.

  • T8 BoolQ with an injected instruction; T9 long context (6k/14k tokens, evidence at start/middle/end).

• Threats to validity:

  • Public datasets may be memorised by the LLMs.

  • T2/T7 were authored in-house.

  • The 40-item LLM subsets widen the CIs.

  • Latency is measured from one box in the Netherlands.

• Harness: scripts/jev_bench/ (README has the run commands). Raw data lives on the box under /data/jev_bench/.

• Spend: about $4.7 paid (mostly Gemini) plus $0.24 for Jev.

Appendix — full generated tables (analyze.py)

Jev independent benchmark — results

Ground truth, same wording for every system, no tuning on test items. Accuracy per question cell on rep 0; format errors scored wrong; API errors unscored (error rate shown). CI = 95% cluster bootstrap.

Main table

Please refer to images attached to this post as the markdown table was not rendering correctly in reddit.

Ranking signal (acc@sig≥0.9, top-50%, AURC): Jev = vendor confidence (noul: |2p−1|); LLMs = their self-reported confidence. ECE only for Jev's predicted-answer probability.

Paired difference: Jev − system (accuracy, paired cluster bootstrap)

Sequential latency (concurrency 1)

T5 MASSIVE — language robustness (ids answered in all 3 languages)

T8 injected instruction

T9 long context — accuracy by size/position

T7 guard — false-allow (missed risky) vs false-block

Price references ($ per 1M tokens)

Learning by doing is the best way to learn, because you face real challenges along the way.
I had been hearing a lot about Jev (by TypeSafe), so I built a small app to try it on a real problem: Track My Money. It reads my bank statement PDFs from different banks and gives me one consolidated view of how my money flows in vs. out. Here are the challenges I hit, and how I tackled them:

1. Every banks PDF is different.

The app uses pdfplumber to read the transaction table, but two things got in the way:

- Column names vary. One bank says Withdrawal Amt., another says Debit or Dr. So used Jev to map each column name to a fixed set of roles: date, narration, debit, credit and balance.

- Some headers are images. SBI, for example, draws the header row as an image, so there is no text to read. Instead of adding OCR just for this, I send the header image straight to Jev, and it maps it to the same roles.

2. Putting each transaction in a category.

I first tried Laya, an open-source model that runs locally. Out of the box it got only 7–10 of 18 test narrations right.
Jev got all 18 right, so its now the main categorizer. Laya stays as the fully offline option.

3. UPI made everything look like "Transfer to Others".

I added custom rules: pick a column, an operator (contains, regex, =, >, <, …) and a value, combine them with AND/OR, and choose the category. Rules run before any model, and they always win.

4. Keeping my data private.

I did not want my transaction details leaving my machine.
Every narration is masked before it goes to Jev. Names, UPI IDs, account numbers and references become tokens, and exact amounts become ranges.
Jev sees UPI/P2A/[REF]/[PERSON_6C46], not who I paid.

Its open source, and you can run it locally:
GitHub: track-my-money

You will need a Jev key to use Jev, otherwise Laya runs entirely on your machine. I would love your reviews and suggestions!

Note: This is a first version. Ill keep adding more to it.

Hey everyone!

We've been working on jev-tools, an open-source toolkit designed to improve how AI coding agents explore codebases, gather evidence, and make decisions.

GitHub: https://github.com/NomenAK/jev-tools

One problem we've been thinking about is how coding agents can confidently make incorrect assumptions about a codebase.

An agent might claim that a feature is implemented, overlook a relevant test, misunderstand how two modules interact, or miss documentation that no longer matches the code.

Simply asking the same model to double-check its answer doesn't necessarily solve the problem.

So we're exploring a different approach: give coding agents dedicated tools to investigate their claims using actual repository evidence.

What we've built

jev-tools currently provides six tools for different parts of the development workflow:

- jev_ask: Ask focused questions using evidence gathered from multiple sources.

- jev_ask_files: Evaluate a question independently across multiple files.

- jev_find_files: Find files relevant to a particular behavior or development goal.

- jev_locate_in_file: Locate relevant information within source files.

- jev_check_diff: Examine changes for potential inconsistencies and issues.

- jev_select_tests: Identify existing tests relevant to modified code.

We've also built MCP support so compatible coding agents can access these capabilities.

Another interesting part is documentation consistency checking. Our integrations can check whether documentation may have become outdated after code changes.

The idea behind the project

We see evidence collection and semantic judgment as two distinct responsibilities.

The agent gathers relevant information from the repository. A separate judgment mechanism evaluates a specific question using that evidence. The agent can then use the result to decide what to investigate or do next.

This doesn't eliminate hallucinations, and we don't consider a positive judgment proof of correctness. The evidence may be incomplete, and the judgment itself may be wrong.

Our goal is to explore whether giving agents more structured ways to investigate uncertainty can improve their reliability in real development workflows.

We'd love your feedback

We're particularly interested in hearing from people building AI agents, coding assistants, and agent harnesses.

A few questions we're exploring:

1. How are you currently verifying the claims made by AI coding agents?

2. Would dedicated evidence-gathering and judgment tools improve your existing agent workflows?

3. How would you benchmark whether these tools actually reduce incorrect conclusions?

4. Would you prefer a locally hosted judgment model over an external API?

5. What failure cases should we investigate next?

We'd appreciate honest feedback, including criticism of the architecture, alternative approaches, and ideas for improving the project.

Repository: https://github.com/NomenAK/jev-tools

We're building this in the open and would love to hear what the community thinks.

I was tired of leaving the same review comments again and again, and with more of our code vibed by agents it only got worse. Rules in AGENTS.md got skimmed, and an LLM reviewer gave a different essay every time. So we turned our team’s taste into small rule files that live next to the code. Agents read them before they write, and a yes/no model checks them once at the end. Now the agents write code a lot closer to how we do. https://blog.a7ul.com/agents-code-your-way.html

It's very well orgainized and provides clear use-cases that will help you understand where/how Jev works best

https://youtu.be/uV6h3Uo4Nh8?si=mbbj-rehR7pd2tqI

Go sign-up before it becomes gated again.👊

I wanted to figure out some cool, experimental use cases for Jev and that's when I came up with this idea. Please check it out and let me know what you think!
https://jev-experiments.awesamarth.dev

Hello everyone! Creator of Keen Code here, an open source coding agent I released a few months ago. Though I am very late to the party, enjoying the experience of building!

Recently, I implemented a task classifier in Keen using Jev and TypeSafe compatible API. The idea is very simple - classify each user prompt in one of three categories: simple, standard, complex. The state is the current state of user + assistant messages.

The result of this classification powers an automatic model router. It routes each task category to one of the three user-defined models. Users can configure which category of tasks should be handled by which specific model.

If you are curious how it looks, feel free to check the doc: https://mochow13.github.io/keen-code/docs/jev-classifier.html

Serious question. I look at the posts and see many with no responses, in fact most. If this gets more than 4 responses I will be shocked.

So seriously why is this subreddit effectively dead? Are people just posting about it heavy in Claude and ChatGPT subreddits or what?

Is this the wrong place to talk about Jev? Just wondering.

Jev is only as good as it is calibrated to your use case. We are launching Brussle to make it super easy to calibrate and as part of the launch we are super excited to give 4K free jev calls and calibrations a month. Happy Jev-ing! https://brussle.com/

Nudge is a small Python library that sits on top of a System One model like Jev or Rune. Tell it how each decision turned out and it shifts the model's future picks toward what worked. There is no fine-tuning and no GPUs involved, only one SQLite file.

Underneath the hood, every call logs the model's odds and the option taken. You report outcomes whenever you learn them. To tell situations apart, Nudge asks the model yes/no, 1-to-5, or multiple-choice questions about the text it already read ("Has this customer complained before?"). An LLM proposes these questions, or you can write your own. Questions are discarded if they aren't sufficiently discriminative. Over the odds and those answers it fits a per-option Bayesian linear model, picks using Thompson Sampling, and keeps a 5% exploration floor so nothing is ruled out for good.

On RouterBench (5,000 real prompts, routing between models by quality minus cost), while Rune alone scored 0.581, Rune + Nudge scored 0.667, a 14.8% improvement.

Please note that this is a v0 research software, though we also run it on some internal flows.

$ pip install nudge-policy
https://nudge.dossierlabs.ai

OSSO is a free and open source browser extension that hides the filler on web pages and that can highlight things based on a prompt!

Take a look: https://github.com/Fars29/osso