- 4comments
- 299comments
- 18comments
- 161comments
- 302comments
- 117comments
- 84comments
- 283comments
- 8comments
- 1comments
- 1comments
- 12comments
- 4comments
- 50comments
- 171comments
- 111comments
- 3comments
- 138comments
- 2comments
- 112comments
- 15comments
- 77comments
- 17comments
- —discuss
- 20comments
- 18comments
- 11comments
- 3comments
- 773comments
- 24comments
Likely works even better with fireworks ai since they have proper grammar support
Ah, will try, thanks!
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.
[A] Hotdog
[B] Not a hotdog
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…
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
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.
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.
How does the model get context to decide ABCD ?
As described in the blog post – e.g. image via a camera feed.
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/
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
I've created a Jev wrapper so that it can work via any OpenAI-compatible endpoints https://github.com/zhulinchng/jevper