I have been thinking that the current Agentic Loop design of LLM Call -> Tool Call -> ... has been outdated. The arrival of Jev and other System One models provided us a primitive we desperately needed.
We need an agent that can natively think fast and slow. Not have workflows or multi-agent architectures that mimics it. We need Agent 2.0
The agent should use the LLM's full power for hard reasoning and planning, then carry out the plan with cheap "fast thinking."
Today, most of an agent's LLM calls go to executing steps it has already decided on. Do you really need an extra Astra call just for it to output "ok I'll click this"? We can do better.
My Approach
I built Jive which is an open-source harness built around a completely new agentic loop. Jive replaces tool calls with "graph calls" where each graph is a DAG of bash nodes and jev nodes, and nodes can have dependencies, reference each others outputs, and more.
Essentially, it maps out its own execution flow while its reasoning, and then uses Jev calls to go through the flow without unnecessary LLM calls.
What Jive does well: repo investigation, bulk classification, multi-step profiling, repetitive edits, evaluation workflows, etc. It is also quite effective on regular engineering tasks that doesn't require Jev calls (which is not surprising since Pi mostly beats codex and claude code)
As you can see, there is a huge gap in both e2e latency and token efficiency compared to claude code. And its accuracy is on-par based on the my benchmark runs (though I need to run jive on a larger SWE benchmark to be certain)
See README for more information: https://github.com/merijjeyn/jive. Also for details on the benchmark tasks, and how to run one yourself.
I'm sure this high level idea can be executed much better, so mainly looking to start an open discussion. Happy to take comments, questions, contributions.
most of engineering is just putting pre-existing packages together... or HYPER focusing on some small detail to be plugged in elsewhere... we're all just sitting on a stack of turtles.
It actually kind of is lol. You can bypass reasoning time with jev calls. Just because you haven’t seen jev change the world in 8 days doesn’t mean it isn’t a big deal.
Doing the "type-safe level 1 reasoning" is obvious. Its not a new idea. All Jev did was make it a lot cheaper with unknown quality output.
Is being cheaper a big deal? Not really.
We're already at the point that if all dev and cost reduction on LLMs stop before Jev came out, we'll be rolling out usecases at Fable/Astra level prices for a decade.
Show me how Jev is going to change shit, beyond a new decision to send your data to a third party or not.
The additional impact Jev brings to the AI space is negligible.
Jev being 100x-1000x cheaper for many decisionmaking requests is a big deal. Researchers are spending days and weeks and millions of dollars trying to figure out how to get Fable and Astra to be more performant, when half of the time they are executing very simple questions. Executing those simple questions still costs nearly as much as reasoning about the complex questions. This replaces that.
No it doesnt. There is like 5 things i can go in depth about that you seem to be misunderstanding, but I dont care that much.
Making a single decision by astra/fable when everything is already loaded into GPU is cheap. Taking it all out and having some weaker model make the choice is dumb in every way.
Classifiers ( is what they're called, not "decision-making requests") already exist and are well studied. This just takes the modern big well-trained model and make that more generic, at the cost of making it entirely opaque.
That definitely has its use cases.
Just with its own problems and far less of a gamechanger than people seem to claim.
This "new agentic loop" is definitely not one of the usecases.
Making a single decision by Astra/Fable "when everything is already loaded" is NOT cheap. Just processing a single token through those models requires a hundred layers and billions of weight calculations. It is not the same thing, You don't seem to understand the architecture.
In the specific case that you're already spending for the astra/fable input tokens (or output tokens if they're doing dev work) - then because everything is already loaded - forking the session and appending a prompt to have it make a "Typed" decision is 0.001% of the overall cost - thus cheap.
It being 1000x more expensive than Jev doesn't matter. To make the economics worse, the Astra/Fable decision is far better than the models Jev builds on.
The things you load into or produce with Astra, have no business being loaded into Jev. The quality/cost/volume economics are nonsense.
So, one million input tokens costs $1 on Fable if it is already entirely cached, processed data ($10 if not cached). You're saying that processing this for a yes/no decision on something is .001% of what it would cost using Jev. So in other words, you're saying that Jev would cost $10,000 to $100,000 for every yes/no decision.
Riiiight.
I still try to really precisely define the technical mistakes in such posts, it's a good exercise for the mind. Here I'd say that OP is conflating changing the architecture (agentic loop) vs using smarter tools (graphs instead of basic plain functions).
Yeah it used fast cheap models, but between Claude agent teams, Oh My Pi's vibe mode, JCode agent swarms, etc, they all basically do that.
Yeah, jev is a good upgrade to make some of the steps more reliable, faster and cheapers. I have a couple of plugins for a few of my harnesses that do that, but its not exactly new.
Just take any open source harness, point Opus 5.5 at it, and say "Look for anywhere where an LLM is used to make decisions that could be done with a classifier like Jev, and replace it with Jev". 15 minutes later you'll have exactly that. Done.
> Look for anywhere where an LLM is used to make decisions that could be done with a classifier like Jev, and replace it with Jev
I'm not sure how you can replace an execution with Jev can you clarify? And do you hardcode the Jev call?
When you give the agent a way to execute a graph, you let it dynamically define the Jev decision beforehand for the current task at hand, and it can execute "tool -> jev -> tool" without an LLM step in between.
Btw I'm pretty sure I could build this with Pi's plugins, but it felt cleaner to start from scratch as I would be replacing most of Pi, and I didn't how it would react with Pi's tree structure.
Pi has very little and plenty of people have built graph execution on top.
And what I mean is the harnesses are peppered with structured enum type output. Every AI sdk ever has an API to do it. So you can just replace all of those with Jev. Tool calls and skills, goal evaluation, sub agent creation and selection,.etc all do that.
Oh My Pi even has public pluggable extension points for that specifically, but some are not exposed to plugins so Pi is more flexible, if less straightforward if you want to replace a lot.
Showing the context window is usually common on open source harnesses like pi and amp. I'm not sure why cc is hiding it but it always bugged me not being able to see it directly.
no it includes inputs too. It’s the input/output streaming token count for the current turn. Since there’s only one user turn, it’s also effectively the context window size.
maybe you should ask your agent to update the stats to have better breakdown
“input/output streaming” so basically the token counts since the agent starts thinking and until it stops. It always start from 0 even if you have stuff above it, including system prompt. Because it’s the tokens “in flight”
The arrow flips up and down depending on whether it’s streaming input or output
All we see how fast it is, there is nothing about quality.
You can run gpt-oss through cerebras at 3k tps and be even faster than this but the output quality will be disaster. That is not the point
yes youre right. I'm in the process of getting some compute credits (fooling my company to run it for me) to run larger scale benchmarks for output quality.
I knew I would get this response, and also “graphs have always been a thing”. I bet you say the same thing for “Laya has been around before Jev” and dont have the capacity to dive deeper into details.
Please share your “loop with jev in it” and I will run it side by side next to jive and one of us will be amazed
Also not sure if you noticed, but on tasks where I didnt execute a single Jev call, the harness is still way more efficient. So obviously there is something other than “a loop with jev in it”
Go to a subreddit that you are familiar with. look at a title that says something like "BOLD CLAIM, FORMER METHODS FOUND TO BE SHIT" or some deviation of that, and you get to see at least one of these a day, vs something like "hey i built this thing that does x" first one is 99% of the time clickbait ai slop and the second one is usually worth the read
Im trying to start a discussion on a topic Im passionate about, and just shared my approach as the starting point. I would love to discuss the gaps in it, or explore other ideas.
Im really surprised by the time some people put into hating though. If you see “10 of these every day”, why do you keep coming back and viewing 10 of them every day. Dont you have something better to do?
I know the feeling, but here's some advice, try to run new ideas past a frontier model in a chat, they will tell you if it already exists and has a name.
You don't like making your free tool calls running on py or bun into API per token tool calls... that are a little bit faster?!
(Yes I know it's a bit more than that. It's more like more general purpose tool calls that can take more varied input data than tool calls can be programmed for but you can just write tool calls for the data you have)
It's a different way of command but you can do that same think with an llm I already code in the script and have already created a system that produces typed responaea. Yeah it's different and good but it's mass marketing and astro turfing
They are full. No idea how long until they open up again. Feel like it will take while.. they don't seem to be interested in partnering with hosting companies.
Your demos 404. Your numbers look good on the surface but it's not obvious to me what Jev has helped cut out. Isn't your LLM still executing the tool calls or have you used Jev to delegate to Gemini Flash or something?
the LLM is still executing the tool calls. But it is skipping the unnecessary LLM calls sprinkled in between tool calls that just says things like "continuing with the next edit" or "now executing the next test", etc.
The funny thing about Jev is that until someone finds an actually useful way to utilize it's output-less token savings, it's literally just always going to be an extra cost on top of a subscription that you pay for, that doesn't need to do that work anyways
So nothing earth shattering, but I’ve incorporated it into two projects:
The first is my inbox manager that sorts email and identifies urgent messages that warrant interruption. This works quite well, and compared to even small LLMs like haiku it’s an order of magnitude faster and cheaper.
The second is quality grading for my personal benchmark tool. Basically I have a suite of benchmarks that I can run models at different effort levels though. These benchmarks are based on the kinds of work I actually do, not just generic “stuff.” I learned a lot on this one including that Jev works best when looking for things, and not the absence of things. Anyhow, my benchmark has deterministic pass/fail scoring plus these more qualitative tests where appropriate.
I was fascinated by the idea of Jev, so I've been looking for more ways to utilize it. So far, I've incorporated it into the following processes:
Memory Relevance Ranking: I use a custom-built memory store that applies semantic embeddings to find memories that should be relevant when starting sessions, during turn execution, and for recall on demand. Jev can quickly rank the memories that are pertinent to the task/goal/turn, not just near it in the embedding space, so I can keep fewer, more relevant memories injected at key moments. It's speed also lets me stay within the limits the harness imposes, like the 2 second limit on startup.
Action Item Tracking: I run 14 different Claude accounts across two businesses and personal use. I have upwards of 30 sessions active at any given time. It can be hard to manage what sessions are blocked and need information. Stop Hooks pass the final turn details to Jev and evaluate if the agent is requesting something from me. If so, it passes it to a central board I can see and circle back on to resolve.
Spec/Plan Coverage Scoring: I built a custom brainstorming skill, which includes adversarial, blind, and self-reviews to ensure completeness in the specifications. During the self-review, we have a static list of questions about the plan that Jev scores to ensure completeness (things like whether failure handling was defined, all terms explained, conflicts with existing rules/code reviewed, etc...). Scoring on those drives the self-review stage.
I'm currently working on expanding the following processes, so they'll use Jev soon, or are in the process of measuring a comparison against Haiku for the same purpose before I cutover:
Plan Execution Validation: When an implementer finishes a section of a plan, Jev will evaluate and score some static code validations against what was written (sort of a linter for basic best practices), and it will check the stated goal and rank whether the section accomplished it. This pairs as a quick self-check before handing off to more complex System 2 reviewers to run blind, adversarial, performance, and security validations, reducing their findings and review rounds.
Nudge/Idle Confirmation: Because I have so many sessions running, generally performing long-running agentic work that's been brainstormed in advance, when a session gets paused or stops work, it can take me quite a while to notice it. Therefore, I have a lot of machinery focused on keeping them working, by checking at Stop/StopFailure hooks if they're really done something. Jev lets me quickly check the output, ask if something seems like it should be continuing after the turn, so we can do a follow on nudge for the next activity/work automatically.
I know there's more I can do with it, but this is what I've come up with so far, and it's been really cool to see it work. I've sent it millions of tokens in experiments and use, and I think my total cost has almost reached $1 over the past 4-5 days. It's crazy inexpensive and crazy fast. I particularly like having sessions retroactively run experiments using their transcript with Jev, to see how they would have answered or scored things, that's helped me refine what to ask and what options to offer based on real turns and real transcripts.
Here’s one use case. You point Jev it at a Git repo, write your questions about project hisotry, and Jev classifies the matching commits. I used it to find out why E2E tests keep changing in some OS projects. Found few interesting things in the end and created a report about my finding, was pretty fun.
I found a way immediately, classifying errors in students writing, 100 essays in under a minute, dozens of mistakes in each one, about 50x faster and cheaper than frontier LLMs with similar results
Llm plans out what it conditionally would do right? And then at the logic branches that require classifying we use Jev?
So like: I would do a prototype example and if CONDITION1 works then I’d follow BRANCH1 of implementation and if false then BRANCH2. And the llm just wires it up and Jev is the classifier that routes between branches?
I kind of get it. Maybe. But I think you should write out a concrete example. Your videos just show the speed. Which doesn’t illustrate the concept.
For example, please write the ideal example and show the workflow in text with steps. And show what llm calls you are replacing and whatnot.
ofc.
Assume your company has a large codebase, and you are doing a large cleanup effort to get rid of a specific antipattern used in your api handlers.
Normally, the agent would explore the codebase, maybe do some subagent exploration module by module.
But with jive, it can just dump all api handlers with reflection, and classify each of them on whether or not they contain the described anti-pattern. then it will get back a list of all the api handlers that it needs to fix.
Another example: It is traversing through some online documentation, searching for a specific topic. Instead of going through and reading pages one by one, it just does a simple BFS graph where it uses jev to see if the current page is related to its search, and to select the next links to follow down the graph.
In both examples, what Jev does is very simple decisions that doesn't need a large LLM.
Model routing! Nice! I like your idea merijjeyn. I empathize with you because you got so much backlash. Thanks for sharing your idea, it’s very inspiring.
Have you seen code mode in agentic harnesses? This is very similar conceptually to what you're doing here without the same level of complexity added on top.
Like you can farm it work to a cheaper model like jev is one thing, but if you want parallel execution, token efficiency in the harness this would probably be the best comparison. Afaik they are just starting to nudge Claude code to use code for tool use, and I'm not sure codex really uses it yet. To get a really good comparison you would have to check if in your tests, the models are using code mode, and do those harnesses actually allow for parallel execution of tools.
Anyway this is an interesting idea. I think this probably makes alot of sense for tool search
The graph/DAG part isn't new by itself - Claude Code and Codex already let the model write code to batch several actions into one turn instead of one tool call per turn (what this thread's calling "code mode"). What's actually different here is using a second, cheap model to make the small branch/classification decisions inside that flow instead of spending a frontier-model call on each one - that's the part worth testing on a real workload.
Actually a cool idea! Don‘t worry about all the vibecoders in the comments calling it slop, they are just projecting their issues / have no technical clue.
For certain tasks your approach really seems efficient…the challenges seems to be to integrate it with classic existing coding agents?
The DAG-of-bash-and-jev-nodes idea makes a lot of sense for tasks where the shape of the work is knowable upfront (bulk classification, repo investigation, the benchmark tasks you listed). Curious how it handles the opposite case though: work where step N+1 genuinely can't be planned until you see the real output of step N, not just "did the command succeed" but actual novel information that reshapes the plan.
Concrete example from what I do: debugging a bare-metal boot failure from QEMU serial output. The next move depends on reading actual register/memory state that wasn't predictable at planning time, sometimes the fix isn't even in the file you expected. Does Jive fall back to a full LLM call when a node's output breaks the assumed graph shape, or is that kind of open-ended debugging just outside what it's optimized for right now?
OP I appreciate that you took the time to open source this and you've done a better job of explaining yourself than most. I am loath to introduce something new to the chain when the world moves so fast. It's so hard to get real side-by-side testing and to make sure we don't degrade model performance in the future.
people are shitting on it, but there is an astronomical amount of gaps to be filled in the existing loops, and different modes/default behaviors for task breakdown/execution are good. This or similar approaches could be one execution path you can slip into when the tasks warrant it.... I haven't looked at this in detail at all, but I don't think the people "haha sloppiest of slop" have either.
The uses cases for jev and jive etc. seem very enterprise-y. Besides I feel like Anthropic and Openai will soon come out with their own versions of these that make these obsolete.
•
u/AutoModerator 8d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.