dkersten

You could make it a requirement only for people who want to attribute “made by”. If you publish a no name extension, you could skip it.

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).

It separates context/state from prompt/questions. That’s a key ingredient for prompt injection hardening. If it is designed and trained to never treat state as instruction, and you only ever put untrusted user input into state, and never the questions, then why wouldn’t it be?

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.

I’m not claiming you can’t get some of the properties in some ways with LLMs, just that Jev is the sum of its parts, not just one or two properties.

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).

My point is that it’s not replicated. You replicate the accuracy, but not the other properties. The Jev-competitors only proved that you can get or beat the accuracy, nothing about the other properties. Especially the “zero hallucination” output and the (if it works how the documentation make it sound) prompt injection resistant architecture. You can’t get that with a fine tuned LLM.

Most of them appear to be small LLM’s fine tuned for the role.

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.

So "Deno" isn't joining Cloudflare, Deno is effectively defunkt and its former team is joining Cloudflare.

Well, yes. Amusing might have been a better word than funny.

> if minor data or chat sessions are mishandled without explicit parental consent

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.

Interestingly, for me on iOS, all of the examples worked except the textarea one, which didn’t allow me to interact at all.

It’s also glitchy and flickery for me on iOS.

I enjoyed this talk. It’s long, but it’s interesting and goes into a lot of “lost” history.

Exactly, not all tasks require smarts, they just need to be good enough. I’ve found that if prompts are really focused, the tiny models do alright.

I stopped using Claude because of this BS. If I pay for a service, I want to know what I’m paying for, I want it to be predictable.

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).

> LLMs can now write perfect code in low-level languages, that is frankly _safer_ and _exponentially_ faster than implementations in high-level languages.

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++

> Completely agree with your closing point. Dynamic custom software, fitted to a particular workload rather than a class of workloads, seems like a very likely outcome.

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).

Pretty cool! rust-analyzer takes such a huge amount of memory. Usually it’s not a problem but occasionally I’ve run into issues. Having an alternative, even with tradeoffs, is great.

I resisted Rust for a long time too. I’ve been using C++ since 2002 and always liked it especially with the modern additions. I liked the idea of Rust early on and even tried it in little amounts and it seemed nice enough, but then over time it just felt over complicated for not enough payout.

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.

If you can’t be bothered to write it, then I can’t be bothered reading it.

At what cost though? “Beating” isn’t enough if it costs 100x or even 10x the amount.

You still have to remember what sizes or whatever to use for what to make it consistent, it’s just they get packed into the “class” attribute. It’s not uncommon to see very long class attribute lines with tailwind with all kinds of p-this and mx-that or whatever. I’ve also seen quite a lot of p-[whatever] tags, at which point all the consistency goes out the window.

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)

Yep, it’s also availability on Together.ai for your sale price. Fireworks and Together were the first places I checked!

Oh, absolutely.

Because it lets you constrain the parts that the compiler can’t check and has to trust you on. The alternative is either a langue that can’t do necessary things, or a language that can’t check what could be checked.

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.

Finally, we can replace daylight saving time by just making more daylight instead

I love Mantine. It’s easy to use, full featured with lots of components and helpers, and yet if you need to, you can use it headless and customise it too (I’ve never bothered though; I did add my own additional spacing/sizing options via the theme support though)

Many vendors and service providers have SLA’s and contracts, at least for the critical services.

Sure but that adds a lot of complexity and cost to your business. It’s much simpler and safer to just work with more reliable vendors to begin with. Why build on quicksand when there’s rock available?

altmanaltman is correct, I was talking about vendors. If you rely on a vendors service for your own business, you want it to be consistent. How can you plan around and rely on something that is inconsistent?

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.

I honestly find it crazy how many people trust them for their business needs. For a business, you want consistency be no surprises. With them you get exactly the opposite.