Can you share a sample prompt demonstrating it? I’d be interested to see, especially since you’re saying it’s incredibly easy (20 seconds would mean it’s easier than on most normal LLMs even).
11,961 karma · joined August 27, 2008
The jev documentation says this is what you should do. It doesn’t mean that it’s actually designed for prompt injection resistance, but it could be. We won’t know for sure until they either release more details or someone proves otherwise.
But the split is one that doesn’t exist in normal LLMs and it’s the exact split that is needed for immunity or resistance to prompt injection.
LLMs can produce structured output by limiting the next token based on a grammar, that ensures correctly formed output.
But (presumably, again I haven’t seen Jev’s insides) Jev doesn’t need to do that, it just has to output probabilities for each answer, and can do it natively without artificially limiting output tokens.
So jev is cheap, fast, never produces malformed output, its output always carries correct semantic meaning (but this doesn’t mean it always answers correctly), and it separates correct from prompt (which if it truly does that is the most exciting part).
That’s a different set of properties in terms of size, cost, and latency. Jev (apparently, not like I’ve seen its insides) is extremely cheap, extremely fast, doesn’t cost any output tokens as it speaks the output natively, can’t get the output wrong because it speaks the format natively, and (presumably based on the docs), the context is separate from the question, meaning it should be immune (or at least highly resistant) to prompt injection attacks.
It’s not just about the accuracy of the result, it’s a collection of all the properties that make Jev interesting.
Jev took years to develop, I strongly doubt that a copycat that was put together within days after Jev’s release will be able to match it on a sun of its properties. Even if fine tuned LLMs can outperform it on raw accuracy.
I know this isn't what you meant, but I can't help but laugh at the thought of a parent consenting: "I consent to the mishandling of my child's data"
As to your actual point, yes, I assume they are trying to reduce liability, especially if they're gearing up to an IPO.
Anthropic have been anything but. Flip flopping on model availability, model access behind an opaque filter, their past behaviour of model degradation as they prepared their next model… these are not signs of a reliable service.
I’ve mostly settled on using a mixture of open weights models through Together.ai and Fireworks.ai, a MiniMax subscription for high-token-use tasks that don’t need the best model (for $20 I get what feels like infinite tokens), and codex for the occasional high complexity task, although with Kimi K3 and hopefully soon GLM 5.3, it’s becoming increasingly less important. Deepseek 4 flash is my cheap main with delegation to other models as needed.
I’ve also found LFM2.5 8B surprisingly useful for single-focus tasks like “does this diff touch anything that isn’t related to the task”, and it’s incredibly cheap ($0.03/0.12 per M in/out).
Your experience does not match mine.
It writes ok code, it does not write good code. I see it leaving a lot of performance on the table, doing silly things like wrapping everything in a global mutex. Or certainly doesn’t write idiomatic code in Rust or C++
I disagree with the premise that this is the desired outcome. If every piece of software is bespoke and everyone’s instance of it works slightly differently, then it’s impossible to get support or a shared knowledge of how it works. There’s no “just share the excel file”, there’s no “press the this button on the left”, there’s no “oh I use program X to solve Y” (instead you have to know what you need so the custom software can solve it, but my time in startups taught me that most users don’t know what they want or need).
Until I learned it for real and forced myself to overcome the hurdles. Now I love it and find it hard to go back to C++. Why would I want to use any language that doesn’t prioritise safety!? Yes Rust can be complex, because things that are safe sometimes can’t be proven to be safe, and then you need a mindset shift to structure the code in ways where it can be proven safe (or if you absolutely need, unsafe lets you isolate the bits that you have to prove yourself. Many people think what’s the point of rust if it has unsafe, but they fail to understand that 100% of your code in other languages is in a rust unsafe block, while in rust at least only the smallest surface needed has to be).
Anyway, yeah, I’m a convert. As for your last paragraph, it’s true, memory safety (and concurrency safety etc) does not mean bug free. But it does eliminate one kind of common high impact error.
So you end up wrapping the components (if you’re using react or something similar) so that you can centralise the styles and use a set of consistent components instead. And at that point it really doesn’t matter if you use tailwind, custom classes, per component css modules, style attributes, css-in-js, or what have you. At this point I prefer to drop the extra dependency and use per-component css files with css module imports. (Or when I do less custom styled UI’s, I prefer to use Mantine and use its attributes for layout and styling)
With unsafe, you’re telling the compiler “I’ve taken extra care to make sure that what I’m doing is safe and doesn’t break your rules” and the compiler can go ahead and assume that you don’t, in fact, break the rules, and therefore can verify everything else as if the rules never got broken.
In less safe languages, the entire program is “trust me, it’s safe”, while in rust only the parts flagged as unsafe are.
The point is that you should only use unsafe when 1. It’s absolutely necessary for functionality or performance and 2. You have verified and are very certain that the code is correct.
That’s a very useful property to have.
Your vendors plans to grow fast and break things shouldn’t affect your ability to provide your service to your customers.
Anthropic has not been a reliable vendor. Previously, when they were compute starved, the quality of their models degraded in the weeks before new releases, without warning to their customers. You just suddenly got a worse service. I wrote a little more a few months ago: https://news.ycombinator.com/item?id=47375818 And then there’s the transparent downgrading they did with Fable.
If your running a business, that’s not what you want to be relying on.
It works quite well for me, a lot better than when the LLM makes these decisions.