Now this is how[0] we get some of the most magical Star Trek technology that eludes us to this day, such as automatic doors. Because if you notice, they work much, much better than real-life ones, because they seem to be doing something like this:
if(within 10 meters of door then) {
if(Jev(
[A] Intends to go through, expects doors to open
[B] Approaches with no intent to pass
[C] Passing by, loiters, or otherwise
[D] Other
) == most definitely A) {
// open doors, +/- identity/security/interlocks check
} else {
// ignore
}
}
Keywords: ambient awareness, understanding of intent.
Most interactive tech on Star Trek is like this - from phasers to consoles to communicators to voice interactions with the ship's computer. The computer seems to be aware of the user and surrounding, and actively infers intent from context, to DWIM ("do what I mean") and when they mean it, instead of doing dumb things[1] on simple triggers.
--
[0] - The direction, not final implementation - surely we can work out how to do it more efficiently than wrapping around final stage of LLM. But the point is, multimodal.
[1] - Obviously it's a fictional show, but in this, both Watsonian and Doylist explanations align near-perfectly: this is/portrays advanced technology, that Just Works and doesn't do stupid shit. Same intent recognition algorithm is there - fictionally in the computer, in reality in the minds of on-set technicians.
The technique i mentioned in the blogpost works with video too. I tested succesfully with Qwen/Qwen3-VL-8B-Instruct. Effecient caching is a little trickier though, but very doable.
"doing dumb things" and "stupid shit" is an odd choice to describe tools that only trigger on explicit activation. Is a windshield being lowered by a switch being held a "dumb thing"?
Dumb things start to happen when you try to build Star Trek interfaces. When you build DWIM interfaces in real life, they are annoying and trigger unwanted and the implementation is without exception, by necessity, a growing ball of spaghetti.
> Dumb things start to happen when you try to build Star Trek interfaces. When you build DWIM interfaces in real life, they are annoying and trigger unwanted and the implementation is without exception, by necessity, a growing ball of spaghetti.
This is what I'm talking about.
"Growing ball of spaghetti" happens because system cannot recognize intent. That problem, itself, was something most engineering teams still seem to fail to recognize.
Automated doors are my favorite example, because the "simple solution" is ubiquitous and wrong and we got used to it, and complex solution is usually leading people the wrong path. In short:
Current doors: if(user triggers proximity detector) { open(); }
Failed attempt at DWIM: if(user triggers proximity detector && this && not that && except when ...) { open(); }
Star Trek: if(user intends to walk through the door) { open(); }
LLMs are the first tool we have that allow us to infer user intent directly, and use that as an input.
And recognizing intent itself cannot be done with a single sensor. It requires both general understanding of how humans behave, and awareness of surrounding and subjects - their movements and behavior, as well as who/what they are, and what they are doing.
Just because you're using an LLM (even a big one) doesn't mean there won't be cases of ambiguous intent or random classification errors.
Automatic doors (as used in the real world) are pretty much always located in areas intended for actively moving foot traffic (not as interior doors for every room). So this feels like adding a lot of complexity and unwelcome probabilistic behavior to something that in most locations does the right thing 99% of the time already.
> Automatic doors (as used in the real world) are pretty much always located in areas intended for actively moving foot traffic (not as interior doors for every room).
Causality reversion. They're located there because they don't work well, and this use case is about the only where current state makes sense.
I predict they'll spread around into many more places once they get better. They are more complex, yes, but also have space[0], accessibility and healthcare advantages.
Similar technology with even larger spread: touch-free operated water faucets, PIR activated lights. Both are something people absolutely do install at home.s
> something that in most locations does the right thing 99% of the time already
No, it doesn't. It sucks and half-asses the right thing maybe 80% of the time, but it's just one of million different tiny annoyances with "value-engineered" technology people just got used to, because it's not like they can do anything about it.
--
[0] - Space is always a strong driver with powerful economical backing. It now makes manually operated sliding doors increasingly popular to install as interior doors in apartments, too.
> Most interactive tech on Star Trek is like this - from phasers to consoles to communicators to voice interactions with the ship's computer.
Almost like the Star Trek mechanisms can infer perfect intent.
Like there’s a hidden script or something.
More seriously, I think there’s real value in an automatic door that behaves consistently rather than one that tries to infer messy human intent. Real life isn’t a TV show and there’s both ambiguity in how people behave and how they even intend to behave. It’s mostly not hard to understand how a proximity sensor door will function. Using a black-box classifier to improve that won’t necessarily make people like it more. And calling up to the cloud for every sensor event, ignoring privacy issues, adds weird latency and a huge failure mode during data center outages.
Spoken like a person who's never had to queue in a shop with an automatic door and then the queue reaches too close to the door and then you're the unfortunate person who keeps on accidentally opening the door while standing at the back of the queue and then everyone else in the queue glares at you.
So now you turn around to check if anyone else is coming in behind you and the door triggers. Or alternatively, you finally get sick of waiting and turn around but the door takes 5 seconds to realize you're not just doing aimless human fidgeting and actually want to leave.
Also .15% of the time the door just randomly opens or stays shut with no rhyme or reason. Bug previously filed with cloud door vendor but told it's within door SLA and sent previously signed copy of agreement that "all neural nets are a black box and inherently probabilistic so errors may occur at any time and not a product defect"
> So now you turn around to check if anyone else is coming in behind you and the door triggers. Or alternatively, you finally get sick of waiting and turn around but the door takes 5 seconds to realize you're not just doing aimless human fidgeting and actually want to leave.
You're literally describing how current automated doors work. That's because they can't infer what you actually want to.
Intuition pump: imagine the doors are actually manually operated by a set technician (like they are on Star Trek sets). Such a person can trivially tell, in split second, whether you're turning around to leave or just to check if someone is behind you, and open the door at the right time. They are inferring intent. This is what I'm saying transformer models are finally allowing us to implement in silico.
> Bug previously filed with cloud door vendor
Who is even talking about cloud here? Giving operational control over hardware to a third party located far away from deployment site is just monumentally stupid in nearly every case.
This is one of the top use cases for local models, because you need video feed processing with sub-second reaction time and real-time guarantees.
> It’s mostly not hard to understand how a proximity sensor door will function. Using a black-box classifier to improve that won’t necessarily make people like it more.
This is fundamentally the same problem as with self-driving cars. There's "dumb and predictable" and there's "DWIM" and the space in between is "mostly useless or dangerous". For DWIM interfaces, you have to reach a level of reliability[0] where you just know what the device will do and trust it to do it. Like, you walk at the doors "on autopilot" while distracted by phone or conversation, and the doors open in time to let you comfortably through.
Note that the currenetly used automated doors rarely meet even basic reliability standards for a dumb, predictable device. Notably:
1. Most don't open fast enough to let a person walk through them at normal pace, forcing people to slow down or stop;
2. Many don't react well, or at all, when you approach from a side.
That 2. is IMO exemplary of the problem: it's typically some tuning to prevent the doors from getting triggered by people passing by or leaving the store through exit doors at 90deg to entry doors - but there is no complete solution here and any attempt just makes things inconvenient for users, because it's trying to solve the wrong problem. It's solving for "open for people approaching, ignore people passing by", whereas the problem that needs to be solved is, "open only for people who clearly intend to go through".
> And calling up to the cloud for every sensor event, ignoring privacy issues, adds weird latency and a huge failure mode during data center outages.
You do not need to call up cloud for this.
In fact, this post inspired me to get the equivalent working off local model to finally get "computer" activation DWIM (no bullshit "hotword recognition", but continuous awareness of conversations, and picking up only on those clearly intended for the "home's computer" -- exactly like Star Trek does it). Turns out, it's totally doable on the humble RTX 4070 Ti (which is like TFA card but only half the memory bandwidth).
Hell, a doors PoC would be too (gonna try this later for triggering lamps via Home Assistant), but since determining intent here requires processing multiple frames, that's gonna be tricky to do with local model in near real-time. Tricky, but not impossible.
--
[0] - Possible interactive reliability, so you're able to negotiate your intended meaning on the spot, without even thinking about it, through a gesture, word, face movement, pose change, etc.
Nice! I would love to use it for images as well.
Then again is using Grammar-Based Decoding with a json response not the same? Is Jev just that with nice caching?
Because then I have been using that already…
A functional difference is the probabilities associated with each option. True, you could use the constrained next-token distribution at the appropriate generation step, but those would not be calibrated by any means, which Jev's claim to be. An empirical analysis would be interesting.
Almost the same. The neat trick here is to ask the model to reply with just 1 letter, which is one token, rather than a long string of json. Its quicker. And just the fact that Jev made a pretty decent API for structuring your questions. And they do the massive parallelization.
Presumably this is much less good than Jev, because the normal LLM models have been trained with RLHF and to be agents. Especially on a large model, I'd expect it to decide in an earlier layer.
I'd hope whatever Jev's Reinforcement Learning for Calibrated Decisions (RLCD) does is better at training the models to give accurate probabilities in the weights.
Jev doesn't support images, so it's hard to compare this directly. But in general this approach beats Jev in its own benchmarks for accuracy and speed and is about the same price.
one day i was about the tell my girlfriend the wonders of ai and how it works underneath. She stopped me about 30 seconds in " so hotdog, not hotdog? " i was like "yep".
What I'd want to see next to accuracy is tail latency. In a real-time use, deciding when a spoken sentence is finished, a general LLM with the same prompt was slower and more hesitant for us than Jev, even though both cost about the same.
I don’t know how this wrapper works, but if it is like any of the classifiers I’ve had Claude build off an LLM in the past, it grabs the probabilities of the tokens you are looking for, and then computes their relative probs against each other.
Even if the LLM thinks it’s made up D is the highest probability, that isn’t part of the set.
You never actually generate the prose, only the first pass, and grab the probabilities. It couldn’t ask for more details even if it wants to. It gets stopped before the first token renders.
I guess “A” by itself would be a seperate token but my point is the model might be trying to say something that begins with that letter rather than actually answering.
You’d need to use an approach that links the output to a closed set.
A is significant in it's own right. But most models follow instructions well enough when you prompt it, "Choose one of the following answers:", it will follow that 90% of the time. Use temperature tuning, and a LoRA, and you are 99% of the way there, just without the speed that Jev has.
Yesterday, just to prove to a friend that Jev isn't that "revolutionary" I extracted some image classification code that Claude had written for my private image organizer that used Qwen3-VL, and stopped the output at a single token, then used the probabilities. Input processing on my GPU was somewhere around 1000ms per image, so not too fast, but each question used the prompt cache, so followups were 100ms-ish.
That was my baseline of an untrained, non-optimized single pass classification. It would connect to my llama-server, and use the logprobs for the choices.
After that, I had Claude remove llama-server from the solution, and write it directly to the transformers, then I kept prompting it to profile and find more speed. Eventually my "Decision Engine" running locally on a trained 1B model got to just under 85% accuracy across my 500 validation prompts (images and text) not used or derived from the training set, and an 8MB image, with 10 questions with 5 choices per question, got down to just under 500ms. Pure text prompts and questions are below 100ms for 300tokens + 10 questions + 5 choices per question (average).
It did better on text than images, just because my training set included 90% text. I'll do more training and validation for images when I get home, but for now, I'm more than happy that I can get a local "decision engine" running in 4GB of VRAM and responding in under 30ms for most use cases I've had.
Jev is rumored to be a 30B model, and it's input price is MUCH cheaper than similarly sized models. The maker is also heavily focused on having a profitable product, so it's unlikely to be subsidizing the cost, especially since they say they have more demand than what they can serve.
Exactly, imo it’s not even that cheap if you look into perspective and consider the fact that providers could subsidize the cost of cached input tokens to virtually zero if they would allow for a more flexible API (e.g. tree of message blocks instead of chain). Most of the cost is the infrastructure around keeping KV caches, estimating their lifetimes, etc. When mist people just want to run one context block with multiple subsequent variants of a second block in parallel. I still stand by my statement.
That's an interesting point, if you send a batch with a shared prefix you basically only end up paying for the sequence length difference effectively.
There is still some minor memory bandwidth issue on outputting more tokens, but the truth is that if you process e.g. 16 messages at once you wont end up being much slower than Jev even though you have to perform several autoregressive passes.
Seems to be slightly higher quality and substantially faster, although this compares remote API vs local deployment.
The prevalent idea of Jev's superiority in price, speed and accuracy seems to come from TypeSafe's marketing and their, I'd say even bad faith, benchmarking. In independent benchmarks the relative numbers tend to be very different.
They can't overturn the economics of attention by restricting themselves to a single token output.
Sure they are no longer memory bandwidth bound thanks to that but someone could add a similar projector to a conventional model, train with a Jev style dataset and call it a day.
Whatever they are doing on inputs must either mean they intentionally chose a Mamba successor or they suffer from the same compute costs as everyone else.
Jev claims 70-500 ms latency, including for the first request. This requires some clever engineering at least, which will take a little to duplicate.
Maybe first request is unbatched, to have fast prefill, and the subsequent ones are batched.
They also don't restrict your prompt. You can have a dumb one, where you put the variable data at the front, and the details on how to process it at the back, thus you bust the user-part of the KV cache every request.
Now this is how[0] we get some of the most magical Star Trek technology that eludes us to this day, such as automatic doors. Because if you notice, they work much, much better than real-life ones, because they seem to be doing something like this:
Keywords: ambient awareness, understanding of intent.Most interactive tech on Star Trek is like this - from phasers to consoles to communicators to voice interactions with the ship's computer. The computer seems to be aware of the user and surrounding, and actively infers intent from context, to DWIM ("do what I mean") and when they mean it, instead of doing dumb things[1] on simple triggers.
--
[0] - The direction, not final implementation - surely we can work out how to do it more efficiently than wrapping around final stage of LLM. But the point is, multimodal.
[1] - Obviously it's a fictional show, but in this, both Watsonian and Doylist explanations align near-perfectly: this is/portrays advanced technology, that Just Works and doesn't do stupid shit. Same intent recognition algorithm is there - fictionally in the computer, in reality in the minds of on-set technicians.
To do this you need video/motion understanding, the intent cannot be judged from still images or state descriptions.
We’ve had the tool to do this since mid 2025, V-JEPA2 [1], Yann Lecun’s last work at Meta.
It runs at several FPS on a macbook and can even be trained locally. Chaining it with Jev for decision-making would probably work great!
[1] https://ai.meta.com/research/vjepa/
The technique i mentioned in the blogpost works with video too. I tested succesfully with Qwen/Qwen3-VL-8B-Instruct. Effecient caching is a little trickier though, but very doable.
"doing dumb things" and "stupid shit" is an odd choice to describe tools that only trigger on explicit activation. Is a windshield being lowered by a switch being held a "dumb thing"?
Dumb things start to happen when you try to build Star Trek interfaces. When you build DWIM interfaces in real life, they are annoying and trigger unwanted and the implementation is without exception, by necessity, a growing ball of spaghetti.
> Dumb things start to happen when you try to build Star Trek interfaces. When you build DWIM interfaces in real life, they are annoying and trigger unwanted and the implementation is without exception, by necessity, a growing ball of spaghetti.
This is what I'm talking about.
"Growing ball of spaghetti" happens because system cannot recognize intent. That problem, itself, was something most engineering teams still seem to fail to recognize.
Automated doors are my favorite example, because the "simple solution" is ubiquitous and wrong and we got used to it, and complex solution is usually leading people the wrong path. In short:
Current doors: if(user triggers proximity detector) { open(); }
Failed attempt at DWIM: if(user triggers proximity detector && this && not that && except when ...) { open(); }
Star Trek: if(user intends to walk through the door) { open(); }
LLMs are the first tool we have that allow us to infer user intent directly, and use that as an input.
And recognizing intent itself cannot be done with a single sensor. It requires both general understanding of how humans behave, and awareness of surrounding and subjects - their movements and behavior, as well as who/what they are, and what they are doing.
Just because you're using an LLM (even a big one) doesn't mean there won't be cases of ambiguous intent or random classification errors.
Automatic doors (as used in the real world) are pretty much always located in areas intended for actively moving foot traffic (not as interior doors for every room). So this feels like adding a lot of complexity and unwelcome probabilistic behavior to something that in most locations does the right thing 99% of the time already.
> Automatic doors (as used in the real world) are pretty much always located in areas intended for actively moving foot traffic (not as interior doors for every room).
Causality reversion. They're located there because they don't work well, and this use case is about the only where current state makes sense.
I predict they'll spread around into many more places once they get better. They are more complex, yes, but also have space[0], accessibility and healthcare advantages.
Similar technology with even larger spread: touch-free operated water faucets, PIR activated lights. Both are something people absolutely do install at home.s
> something that in most locations does the right thing 99% of the time already
No, it doesn't. It sucks and half-asses the right thing maybe 80% of the time, but it's just one of million different tiny annoyances with "value-engineered" technology people just got used to, because it's not like they can do anything about it.
--
[0] - Space is always a strong driver with powerful economical backing. It now makes manually operated sliding doors increasingly popular to install as interior doors in apartments, too.
> Most interactive tech on Star Trek is like this - from phasers to consoles to communicators to voice interactions with the ship's computer.
Almost like the Star Trek mechanisms can infer perfect intent.
Like there’s a hidden script or something.
More seriously, I think there’s real value in an automatic door that behaves consistently rather than one that tries to infer messy human intent. Real life isn’t a TV show and there’s both ambiguity in how people behave and how they even intend to behave. It’s mostly not hard to understand how a proximity sensor door will function. Using a black-box classifier to improve that won’t necessarily make people like it more. And calling up to the cloud for every sensor event, ignoring privacy issues, adds weird latency and a huge failure mode during data center outages.
Spoken like a person who's never had to queue in a shop with an automatic door and then the queue reaches too close to the door and then you're the unfortunate person who keeps on accidentally opening the door while standing at the back of the queue and then everyone else in the queue glares at you.
So now you turn around to check if anyone else is coming in behind you and the door triggers. Or alternatively, you finally get sick of waiting and turn around but the door takes 5 seconds to realize you're not just doing aimless human fidgeting and actually want to leave.
Also .15% of the time the door just randomly opens or stays shut with no rhyme or reason. Bug previously filed with cloud door vendor but told it's within door SLA and sent previously signed copy of agreement that "all neural nets are a black box and inherently probabilistic so errors may occur at any time and not a product defect"
> So now you turn around to check if anyone else is coming in behind you and the door triggers. Or alternatively, you finally get sick of waiting and turn around but the door takes 5 seconds to realize you're not just doing aimless human fidgeting and actually want to leave.
You're literally describing how current automated doors work. That's because they can't infer what you actually want to.
Intuition pump: imagine the doors are actually manually operated by a set technician (like they are on Star Trek sets). Such a person can trivially tell, in split second, whether you're turning around to leave or just to check if someone is behind you, and open the door at the right time. They are inferring intent. This is what I'm saying transformer models are finally allowing us to implement in silico.
> Bug previously filed with cloud door vendor
Who is even talking about cloud here? Giving operational control over hardware to a third party located far away from deployment site is just monumentally stupid in nearly every case.
This is one of the top use cases for local models, because you need video feed processing with sub-second reaction time and real-time guarantees.
> It’s mostly not hard to understand how a proximity sensor door will function. Using a black-box classifier to improve that won’t necessarily make people like it more.
This is fundamentally the same problem as with self-driving cars. There's "dumb and predictable" and there's "DWIM" and the space in between is "mostly useless or dangerous". For DWIM interfaces, you have to reach a level of reliability[0] where you just know what the device will do and trust it to do it. Like, you walk at the doors "on autopilot" while distracted by phone or conversation, and the doors open in time to let you comfortably through.
Note that the currenetly used automated doors rarely meet even basic reliability standards for a dumb, predictable device. Notably:
1. Most don't open fast enough to let a person walk through them at normal pace, forcing people to slow down or stop;
2. Many don't react well, or at all, when you approach from a side.
That 2. is IMO exemplary of the problem: it's typically some tuning to prevent the doors from getting triggered by people passing by or leaving the store through exit doors at 90deg to entry doors - but there is no complete solution here and any attempt just makes things inconvenient for users, because it's trying to solve the wrong problem. It's solving for "open for people approaching, ignore people passing by", whereas the problem that needs to be solved is, "open only for people who clearly intend to go through".
> And calling up to the cloud for every sensor event, ignoring privacy issues, adds weird latency and a huge failure mode during data center outages.
You do not need to call up cloud for this.
In fact, this post inspired me to get the equivalent working off local model to finally get "computer" activation DWIM (no bullshit "hotword recognition", but continuous awareness of conversations, and picking up only on those clearly intended for the "home's computer" -- exactly like Star Trek does it). Turns out, it's totally doable on the humble RTX 4070 Ti (which is like TFA card but only half the memory bandwidth).
Hell, a doors PoC would be too (gonna try this later for triggering lamps via Home Assistant), but since determining intent here requires processing multiple frames, that's gonna be tricky to do with local model in near real-time. Tricky, but not impossible.
--
[0] - Possible interactive reliability, so you're able to negotiate your intended meaning on the spot, without even thinking about it, through a gesture, word, face movement, pose change, etc.
How does the model get context to decide ABCD ?
As described in the blog post – e.g. image via a camera feed.
Nice! I would love to use it for images as well. Then again is using Grammar-Based Decoding with a json response not the same? Is Jev just that with nice caching? Because then I have been using that already…
A functional difference is the probabilities associated with each option. True, you could use the constrained next-token distribution at the appropriate generation step, but those would not be calibrated by any means, which Jev's claim to be. An empirical analysis would be interesting.
Almost the same. The neat trick here is to ask the model to reply with just 1 letter, which is one token, rather than a long string of json. Its quicker. And just the fact that Jev made a pretty decent API for structuring your questions. And they do the massive parallelization.
Yes, that is my question too. Someone knowledgeable can comment
Presumably this is much less good than Jev, because the normal LLM models have been trained with RLHF and to be agents. Especially on a large model, I'd expect it to decide in an earlier layer.
I'd hope whatever Jev's Reinforcement Learning for Calibrated Decisions (RLCD) does is better at training the models to give accurate probabilities in the weights.
Empirically this approach is more accurate, faster and about the same price as Jev.
https://github.com/Mushroom-Systems/lichen
Interesting, thanks! JevBench is a new benchmark - am curious to see how it plays out.
Ah sweet it’s like Jev but several order of magnitude more expensive, and slower too.
Jev doesn't support images, so it's hard to compare this directly. But in general this approach beats Jev in its own benchmarks for accuracy and speed and is about the same price.
https://github.com/Mushroom-Systems/lichen
[A] Hotdog
[B] Not a hotdog
one day i was about the tell my girlfriend the wonders of ai and how it works underneath. She stopped me about 30 seconds in " so hotdog, not hotdog? " i was like "yep".
I never bought that up again.
Much less code https://news.ycombinator.com/item?id=49769618
What I'd want to see next to accuracy is tail latency. In a real-time use, deciding when a spoken sentence is finished, a general LLM with the same prompt was slower and more hesitant for us than Jev, even though both cost about the same.
I've created a Jev wrapper so that it can work via any OpenAI-compatible endpoints https://github.com/zhulinchng/jevper
Likely works even better with fireworks ai since they have proper grammar support
Ah, will try, thanks!
> Answer with the letter of the best option only [A, B, C]
What if it says "D"? What if it tries to say "Additional details needed"?
(Also no calibration, etc.)
I don’t know how this wrapper works, but if it is like any of the classifiers I’ve had Claude build off an LLM in the past, it grabs the probabilities of the tokens you are looking for, and then computes their relative probs against each other.
Even if the LLM thinks it’s made up D is the highest probability, that isn’t part of the set.
You never actually generate the prose, only the first pass, and grab the probabilities. It couldn’t ask for more details even if it wants to. It gets stopped before the first token renders.
I guess “A” by itself would be a seperate token but my point is the model might be trying to say something that begins with that letter rather than actually answering.
You’d need to use an approach that links the output to a closed set.
A is significant in it's own right. But most models follow instructions well enough when you prompt it, "Choose one of the following answers:", it will follow that 90% of the time. Use temperature tuning, and a LoRA, and you are 99% of the way there, just without the speed that Jev has.
Yesterday, just to prove to a friend that Jev isn't that "revolutionary" I extracted some image classification code that Claude had written for my private image organizer that used Qwen3-VL, and stopped the output at a single token, then used the probabilities. Input processing on my GPU was somewhere around 1000ms per image, so not too fast, but each question used the prompt cache, so followups were 100ms-ish.
That was my baseline of an untrained, non-optimized single pass classification. It would connect to my llama-server, and use the logprobs for the choices.
After that, I had Claude remove llama-server from the solution, and write it directly to the transformers, then I kept prompting it to profile and find more speed. Eventually my "Decision Engine" running locally on a trained 1B model got to just under 85% accuracy across my 500 validation prompts (images and text) not used or derived from the training set, and an 8MB image, with 10 questions with 5 choices per question, got down to just under 500ms. Pure text prompts and questions are below 100ms for 300tokens + 10 questions + 5 choices per question (average).
It did better on text than images, just because my training set included 90% text. I'll do more training and validation for images when I get home, but for now, I'm more than happy that I can get a local "decision engine" running in 4GB of VRAM and responding in under 30ms for most use cases I've had.
[flagged]
Of course it works, Jev is nothing but an API breakthrough
Jev is rumored to be a 30B model, and it's input price is MUCH cheaper than similarly sized models. The maker is also heavily focused on having a profitable product, so it's unlikely to be subsidizing the cost, especially since they say they have more demand than what they can serve.
You can get Gemma 4 26B A4B at the exact same token input price of $0.042/M. GPT-5 nano is not much more expensive at $0.05.
https://openrouter.ai/google/gemma-4-26b-a4b-it
Exactly, imo it’s not even that cheap if you look into perspective and consider the fact that providers could subsidize the cost of cached input tokens to virtually zero if they would allow for a more flexible API (e.g. tree of message blocks instead of chain). Most of the cost is the infrastructure around keeping KV caches, estimating their lifetimes, etc. When mist people just want to run one context block with multiple subsequent variants of a second block in parallel. I still stand by my statement.
That's an interesting point, if you send a batch with a shared prefix you basically only end up paying for the sequence length difference effectively.
There is still some minor memory bandwidth issue on outputting more tokens, but the truth is that if you process e.g. 16 messages at once you wont end up being much slower than Jev even though you have to perform several autoregressive passes.
"you wont end up being much slower than Jev" -- I would even go as far as saying that "you will end up being Jev".
With this cost, does it perform the same quality and speed as Jev?
I'm quite interested in this; my current understanding is though that Jev is great when scored with response quality and latency metrics.
Seems to be slightly higher quality and substantially faster, although this compares remote API vs local deployment.
The prevalent idea of Jev's superiority in price, speed and accuracy seems to come from TypeSafe's marketing and their, I'd say even bad faith, benchmarking. In independent benchmarks the relative numbers tend to be very different.
https://github.com/Mushroom-Systems/lichen
They can't overturn the economics of attention by restricting themselves to a single token output.
Sure they are no longer memory bandwidth bound thanks to that but someone could add a similar projector to a conventional model, train with a Jev style dataset and call it a day.
Whatever they are doing on inputs must either mean they intentionally chose a Mamba successor or they suffer from the same compute costs as everyone else.
Jev claims 70-500 ms latency, including for the first request. This requires some clever engineering at least, which will take a little to duplicate.
Maybe first request is unbatched, to have fast prefill, and the subsequent ones are batched.
They also don't restrict your prompt. You can have a dumb one, where you put the variable data at the front, and the details on how to process it at the back, thus you bust the user-part of the KV cache every request.
That is the most intuitive way of doing it. The hype is insufferable.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]