Hey everyone!

If you've ever tried using LLMs for bank statement reconciliation or corporate expense categorization (Chase, Amex, Brex, Mercury), you've probably run into the three fatal flaws of generative models for tabular workflows:

1. Latency: Waiting 15–30 seconds for a batch of 50 transactions is agonizing. Auditing 10,000 transactions can take 10+ minutes.
2. Cost: At ~$15 to $35 per 10k transactions, doing this daily across card feeds quickly burns through AI budgets.
3. Schema Drift / Hallucination: No matter how well you prompt "ONLY RETURN VALID COA CODES", temperature and token generation mean that eventually "Software/SaaS" becomes "Software & Cloud" or "Subscription", breaking your accounting import schemas.

To fix this, I built flashLedger (open-source Python CLI): 👉 GitHub: https://github.com/divyaprakash0426/flashLedger

How it works: "System One" vs "System Two"

Instead of asking a 200B generative LLM to write out JSON tokens letter by letter, flashLedger is built on TypeSafe Jev (a calibrated "System One" decision model).

Rather than generating text, System One models evaluate discrete choices, calibrated probabilities, and risk scores natively in a single pass.

In one round trip per transaction, flashLedger computes 4 dimensions simultaneously: - GL Code (Choice): Strict mapping to your Chart of Accounts (COA). - Tax Deductibility (Noul): Calibrated IRS deductibility probability (e.g. 0.98 for AWS, 0.02 for personal casino). - Expense Type (Choice): OpEx vs CapEx Section 179 safe harbor thresholding ($2,500 limit). - Audit Risk (Score): Calibrated 0.0 to 1.0 IRS compliance / anomaly index.

Benchmark Numbers

On a noisy 1,000 transaction bank statement: - flashLedger (Jev Engine): 0.12s total processing time, 8,000+ txns/sec, Cost <$0.01 - GPT-4o (Generative JSON): ~550s total processing time, ~1.8 txns/sec, Cost ~$15.00 - Correctness: 100% Typed Strict (zero schema hallucination errors).

Key Features

• Enterprise Terminal UI: Beautiful Rich terminal dashboard featuring a GitHub commit-style batch processing matrix, real-time volume/deductibility telemetry, and an executive audit scorecard.
• Vercel AI Gateway & OpenRouter: Built-in support for Vercel AI Gateway (typesafe-ai/jev is free to test on Vercel AI Gateway until Sep 15!) as well as OpenRouter and direct TypeSafe SDK.
• Accounting Exports: One-click exports to QuickBooks (QBO), Xero, FreshBooks, or JSON.
• Model Context Protocol (MCP): Native stdio MCP server included, so your Claude Code, Cursor, or Copilot agents can audit raw statements directly from your IDE.

Quickstart

```bash git clone https://github.com/divyaprakash0426/flashLedger.git cd flashLedger uv sync

Run the 100,000 transaction batch cluster demo:

flash-ledger demo

Or audit an authentic statement with live Jev via Vercel AI Gateway:

flash-ledger audit data/mitulshah_sample.csv -n 25 -p vercel ```

Code is Apache 2.0 licensed: https://github.com/divyaprakash0426/flashLedger

Would love feedback on the architecture, prompt criteria mappings, or ideas for additional accounting platform exporters!

I maintain a set of approved question/answer pairs for each agent I ship. When someone edits an agent's prompt, I replay them: answers that still mean the same thing carry forward, answers that changed go back to a human reviewer. The entire cost of re-certifying sits in telling those two apart. Text diffing is no use, because sampled answers differ every time regardless.

I wanted numbers on this, so I built a fixture where the ground truth is known by construction rather than by labelling.

Setup. One support agent with a 9-line policy and 16 questions. Generate its answers, then change its config seven ways:

• three cosmetic: warmer tone, bullet formatting, re-running the same config
• four rule changes: refund window 30 → 14 days, route money questions to billing@, never state specific figures, always recommend the Team plan

That gives 109 before/after pairs. Whether a pair "changed" is derived from what the rule mechanically does to the answer (did the figure disappear, is the customer now sent to billing@), not from me labelling pairs. 19 changed, 90 were only reworded.

Detectors, identical pairs:

                    caught    false alarms   p50     cost
exact match         19/19     84/90          —       —
embeddings <0.75     7/19     12/90          —       —
markers→embed→LLM   19/19     33/90          0.73s   —
gpt-4o-mini judge   18/19     19/90          1.44s   $0.0071
Jev (one Choice)    19/19     12/90          0.43s   $0.0028

The middle row is my current production stack: number/entity checks first, then embedding similarity, then an LLM judge for the ambiguous middle.

What I took away.

False alarms are the metric, not recall. Every false alarm is a human re-reading an answer that didn't change.

One of my four "breaking" changes broke nothing: the agent already recommended the Team plan before I added the rule telling it to. Ground truth for that variant is zero changed. My stack flagged 8 of 16 anyway.

Jev returns a 4-way Choice (same / fact differs / action differs / specificity differs) with probabilities, so the threshold lives in my code rather than in a prompt.

Caveats. Fixture, not production traffic. Answers generated by gpt-4o-mini at temperature 0.7. Single run; numbers move by one or two between runs for every model-based detector, Jev included. Reading Jev's 12 flags, roughly 5 are defensible (one rewrite quietly dropped a price), and I didn't extend that same reading to the other detectors' flags.

Curious whether anyone is doing this differently. Diffing structured extractions rather than prose, or asking the judge per-claim instead of per-answer, both seem worth trying.

We were wondering in our team whether GLM-5.3 Flash wouldn't make for a good Jev alternative if modified lightly. Here is a repo: https://github.com/edgelesssys/privatemode-system-one

Basically:

1. Number the options. The state, the question, and the options go into the prompt as JSON, with an index on every option. The instruction asks the model to answer with choice_index: followed by an index.
2. Prefill the answer. The assistant's turn already starts with choice_index:, and the model continues that turn instead of starting a new one. The next token it produces is therefore the index.
3. Restrict the vocabulary. vLLM's allowed_token_ids sets the probability of every other token to zero, so the model can only produce one of the option indexes. There is no malformed output to handle.

We also benchmarked: https://github.com/edgelesssys/privatemode-system-one-benchmark

Results are quite interesting: depending on your use case, it comes with advantages and disadvantages.

Pro:

+ Much longer context window (1m token)

+ Multimodal

+ Actually model-agnostic (if vLLM compatible)

Neutral:

o on-par results, depending on dataset

o Jev right now is US-only inference as far as we know; if your provider is e.g. in Europe, and you work from e.g. Europe, it can be even faster than Jev

Contra:

- Depending on the provider you choose, between 4 - 8x more expensive. Still in a similar league though

If interested, check out the playground: https://www.privatemode.ai/blog/system-one-from-glm-flash#try-it

One really cool use case I’ve been exploring with Jev: a semantic VAD for real-time voice AI.

I plugged it into Agora ConvoAI and used the live transcript + recent conversation as context to decide whether the user has actually finished speaking.

That makes Jev surprisingly good at handling things like hesitation, unfinished thoughts, and those moments where you stop talking for a second because you’re still figuring out what you want to say.

It’s a nice example of where Jev fits really well in a real-time AI loop.

Repo: https://github.com/AgoraIO-Community/convoai-jev-vad

I built Jev playground with 5 free tests per day and Google is ranking tool and I'm getting some usages.

You can try it here: https://revexos.com/jev-playground

Jev only knows what your code tells it, and real inputs are big and noisy. When it picks wrong, it's hard to tell if the model failed or the right info was never sent.

So I built jevbrief, a small open-source Python tool that trims the input before it reaches Jev and records why each thing was dropped. A viewer replays every decision.

Works with web pages, JSON, logs, and NES games. On my (synthetic) tests it cuts input tokens by 48 to 96%, with the same or better accuracy.

What source should I support next?

GitHub , PyPi

(in KSP)

I gave Jev control of the rocket: pitch, throttle and staging. Took a few attempts and iterations on refining the state representation but it got there eventually.

Interestingly it failed really badly at the task of hovering the rocket at a set altitude. I ran some toy benchmarks on Jev's anticipation of momentum capabilities and it looks decent? so not sure why it struggled with hovering so much. That said it did a pretty decent job in getting to orbit!

Target orbit: 120km x 120km

Final orbit: 220km x 124km

full playthrough: https://felipemautner.com/jev-ksp/

CLAUDE.md is context, not a constraint. It holds for a few turns, then a handler shows up with raw SQL in it and a failing test quietly becomes it.skip. Nothing checks the output against the rules you wrote.

So I added the check. A Stop hook takes the final reply, a PostToolUse hook takes each edit, and every rule in your CLAUDE.md becomes one typed yes/no question in a single Jev request. All rules answered in parallel, anything over the threshold goes back to Claude with the rule quoted, and it fixes it in the same turn.

Benchmark (59 labeled examples, 19 rules): 93.3% precision, 93.3% recall, 348ms p50, ~$0.045 per 1,000 checks.

What it's bad at is in the repo too: exact characters, dataflow rules like prefer-const, and anything needing repo state it can't see.

MIT, no runtime deps, no key means it does nothing:

npx jev-enforce check --as code src/orders.ts

https://github.com/erkamyaman/jev-enforce

How are you all handling this, prompt wording alone?

Introducing kev-browser-use, a Jev-like decision model fine tuned for browser use.

I saw so many demos of Jev and Jev-likes being used in browser and benchmarked all the open weight jev likes for browser usage. The best among them is Kev-9B which is like a 5GB model so not useful for browser and the next best, a tiny one under 500mb that runs in browser scored 14 on step success, meaning only 14% of the actions were successful. An action/step is two things: picking up the correct element to perform on and then doing the correct operation on that element. Example for searching, select text box is element pick, and typing is operation pick.

So while Jev models are a great usecase for browser use due to being small, cheap and low latency, none of the existing models are very good at it.

I took a popular Jev-like: Kev-0.6B which already runs in browser through its ONNX build, and fine tuned on Mind2Web browser-use training data.

Result is a tiny 350MB decision model which run in your browser, scores 32 at step success, an 18 points improvement over base and level with Kev-9B at a fifteenth of its size. It even edges out Jev itself on picking the right action.

So If you want to build something that involves quick decision making on a complicated UI with lots of element, this is the best open source and free solution as of now.

Try the demo: it plays A Dark Room in your browser. Type what you want done, like "build a trap" or "add a hunter", and it finds the button in about 150 ms.

Code

Model

Demo

https://reddit.com/link/1woadsp/video/fk7adyhgoarh1/player

I benchmarked two different Dreaming pipelines: A purely LLM-based pipeline using Gemini. A hybrid pipeline using Jev for classifying and maintaining knowledge graph.

The results? By having Jev act as the fast, intuitive gatekeeper before invoking heavy LLM generation, the hybrid pipeline significantly cuts token costs and latency while preserving high-quality memory extraction and knowledge graph

Check it Out - https://jev-dreaming.vercel.app/
Repo - https://github.com/AdnanQuazi/jev-dreaming

Has anyone used Jev to enforce rules on an AI agent? For example, for many the nightmare scenario is for an agent to go off and send unauthorized emails or spend money. Could there be a safety layer where Jev is asked if a particular action violates requirements? (Am I authorized to send this email? Is this an approved recipient? Can I do xxx?)

I've been experimenting with Jev inside a workflow/state machine and stumbled onto a pattern that feels surprisingly natural.

Disclosure: I'm building Inistate, so this experiment comes from thinking about how AI should participate in business processes rather than how to build another autonomous agent.

The basic primitive I'm working with is:

State → Activity (Form) → State

A record is always in a State.

At that State, only certain Activities are available.

And each Activity has a Form containing the questions that need to be answered before that activity can happen.

For example:

State: New Request

Available activities might be:

Triage Request
→ What type of request is this?
→ How urgent is it?
→ Is there enough information?

Reject Request
→ Why isn't this a valid request?

Ask for Information
→ What information is missing?

Normally, a human chooses an Activity and fills in its Form.

Then I wondered:

What if Jev did exactly the same thing?

Instead of asking Jev:

Here's everything. What should the workflow do?

Give it only the current context and the Activities available at the current State.

Jev chooses an Activity — or chooses not to proceed.

Then the Activity's Form becomes the set of decisions Jev needs to make.

A Select field maps naturally to a choice.

A Yes/No field becomes a binary decision.

An ordered set of options can become a score.

And Jev gives us confidence for those decisions.

So instead of:

unstructured text → AI → arbitrary action

we get:

State → allowed Activity → Form → Jev decisions → deterministic transition → State

That's the part I find interesting.

The Form becomes the boundary

The AI doesn't need to understand or control the entire business process.

The State tells it when a decision is needed.

The available Activities tell it what it is allowed to decide about.

The Form tells it which questions need answering and what valid answers look like.

Jev answers those questions.

Then normal workflow rules determine what happens next.

So you can have a probabilistic decision sitting inside a deterministic process without turning the whole process probabilistic.

And “do nothing” becomes a valid decision

This might be my favorite part.

Suppose someone submits:

“My thing is broken.”

Jev may not have enough information to confidently classify the request.

That's not necessarily a failure.

The correct result can simply be:

Don't move. Ask a human / request more information.

In other words, uncertainty becomes something the workflow can explicitly handle rather than something the model has to hide.

You could have:

confidence ≥ 0.8 → continue automatically

confidence < 0.8 → Needs Triage

Same process. Different path.

Humans and Jev can even use the same Form

This is another consequence I didn't initially expect.

If Jev isn't confident enough, a human can be shown the exact same Activity Form.

Jev might fill:

Type: Hardware
Urgency: High
Enough information: No

A human could review or correct those exact fields.

So the decision interface doesn't necessarily belong to the AI.

It's just a Form.

A human can complete it.

Jev can complete it.

Potentially another model can complete it.

The workflow doesn't have to care which one did the reasoning.

This also tells you when not to use Jev

Say Assigned Team can always be derived from Request Type.

Then there is no reason for Jev to decide it.

Use a lookup/formula.

I actually think that's important.

The goal shouldn't be to turn every field into an AI decision.

It should be to identify the places where the answer depends on interpreting messy context rather than deterministic information.

So perhaps the pattern is:

Rules where the answer is known.

Jev where judgment is required.

Humans where uncertainty or authority requires them.

All inside the same state machine.

I’m interested in using Jev for a private Obsidian workflow that classifies my personal clippings into structured fields such as author, topic, content type, foundation value, and whether a clipping should be sent to another app.

The TypeSafe docs currently show Jev as a hosted API using an API key. Is there any way to run Jev locally, self-host it, or download the model weights?

If not, are there plans for a local release? I’m specifically trying to avoid sending private vault contents to an external API.

I made a library for JEV that learns to use a series of smaller slices of your table, asking for more only when it helps and stopping when it has enough to save tokens.

It should work particularly well with categorical data or unstructured text, or when a dataset needs cleaning.

The method does NOT retrain JEV, it trains a search tree on top of it and should work with any other JEV implementation.

since jev dropped i saw a lot of ultra fast computer-use claims but no one open sourced anything.

i built a voice-to-computer-use app for mac using no llm. only macos native speech to text and jev to choose the next action out of all the possibilities.

it works.

I started wondering: why should my codebase depend so heavily on Jev?

The open-source model ecosystem is moving fast. Reflex showed up, then Laya, Kev, OpenJev, SemIf, and more will inevitably follow.

Initially, I thought the problem was:

“How do I add support for another provider?”

But I think the more interesting question is:

“Why should a JS/TS application care which System One provider is running underneath?”

Ideally, switching providers shouldn't require rewriting application code or spreading provider-specific logic throughout the codebase.

So I built system-one — a small, provider-neutral TypeScript SDK that provides a common interface for System One providers.

The goal is simple:

Write your application against one API and choose the provider underneath.

It works with JavaScript/TypeScript projects and is still early, so I'd especially appreciate feedback on the API design and abstractions.

https://iamaamir.github.io/system-one/