croemer
croemer on Hacker News
Domain registration doesn't mean that much. Many similar domains are already registered, eg python2shell.com is 5k aftermarket but js2shell.com is unregistered. Might not be a bad investment to register the .com for all the top PLs.
I'm not sure I've ever read a sentence like this before LLMs. Maybe I didn't pay attention, possible. I should do a search of pre-LLM writing for this construction.
I see, you're updating the graph with 3 weeks delay, that's a bit confusing. Now there are 4 days at least.
That code font is painful to read, no syntax highlighting and extremely pixelated. It's retro but an eyesore.
Dashboard was last updated on September 7, it started on September 5. Bug? Or no progress? It's linked in the blog post so would expect it to work:
https://turbopuffer.com/v3
This one sentence sounds very LLMish:
> Object storage as the source of truth gave the economics, and tiered NVMe SSD/memory caches gave the performance.
Thanks for the tip! Set it up locally and it works!
Is there a Jev-like model I can run on my Mac? Something like Ollama? Or what's the best way to play with it? Is there a cheap/free API service eg on OpenRouter?
Oh cool, I missed that the raw data is available. I shall see if I can do the analysis myself then.
This seems like a poorly executed analysis of very interesting underlying data.
With this degree of average age variability they can't compare failure rates.
They should show us Kaplan-Meier (survival) curves not failure in this quarter.
Unless they set some datacenter on fire, not much in Q2 should be different vs Q1 for the same hard drive other than it being older.
Sure, internally, I'd do a better analysis controlled for age that shows if there are common failure rate increases but here they focus on model failure rates which is completely confounded by age differences.
For those outside US, in Europe I got "Service unavailable".
Switched on US VPN and it works.
Edit: Now it seems to work. Maybe it was a glitch. Or a US government agent is watching this page.
The title is misleading, they found 24 vulnerabilities in Android _apps_ not in Android itself. That's a big difference.
In their own words from the body:
> I’ve reported more than 20 vulnerabilities in Android applications
Pretty crazy that the model doesn't know that it needs to stop before it hits 128k output tokens. I guess it has no sense of how many tokens in it is? Wouldn't this be possible to work into the architecture?
This is evidence that Sonnet 5.5 wasn't yet trained on the HN comments from the Opus 5.5 release. Maybe Pelicanmaxing will lead to 127000 thinking tokens being used on Max.
Playing around with it for a few minutes, Sonnet 5.5 feels very fast, much quicker than Opus 5.5. Can't tell yet if it's a lot worse but the speed is definitely welcome.
Ah, I see, you mean "Jev cannot possibly be calibrated for everyone as there is always missing context".
I understood it as "It is impossible to calibrate Jev".
I typed some German and it was breaking up words so much more than English. Not really surprising given tokenizers are optimized for most commonly used text.
Here's the token efficiency of a corpus translated into various languages and tokenized with the latest OpenAI one:
Language Relative tokens
--------------------------------------
English 1.00x
Portuguese 1.23x
Chinese (Simplified) 1.25x
German 1.31x
Spanish 1.32x
French 1.37x
Arabic 1.38x
Chinese (Traditional) 1.42x
Korean 1.47x
Swahili 1.49x
Hindi 1.57x
Japanese 1.66x
Burmese 3.16x
Amharic 5.78x
Santali 13.70x
Source: "Tokenizer Fairness in 2026", a reproduction/extension of
Petrov, La Malfa, Torr & Bibi, "Language Model Tokenizers Introduce
Unfairness Between Languages" (NeurIPS 2023), using FLORES-200.
https://github.com/partyfly/tokenizer-fairness-2026
TFA seems to be sloppy in writing, they should have kept the "meaning... [Some incorrect assumptions about GET]" out of the paragraph.
You're not missing anything. TFA really state this wrong assumption in their own voice.
> This access seems to have only allowed the agents to make ‘GET’ requests, meaning they could fetch and read websites, but not interact with them, submit forms, or send data to them
The authors of this (very interesting) analysis should really not state the sandbox's wrong assumptions in their own voice.
GET absolutely allows you to interact with sites. And of course GET can also send information. It's all up to the server that receives the GET to decide what it let's callers do with it.
Article says that it _can_ be calibrated, it just isn't out of the box. So the title seems contradicted by the body.
> If you want calibrated probabilities you’ll still need to recalibrate Jev’s probabilities on your own data. The good news is that is cheap. A few hundred labeled examples from your actual data can be enough to fit a Platt scaling on top of Jev’s scores.
Hah! You independently picked exactly the same sentences I flagged (I know you posted this 11min before me but the comment only appeared after I had submitted mine).
That's the standard annoying pattern though: "Rewrites are declared by the publisher, never inferred from overlap." and "NULL means dirty, and DELETE is the fence." - still the same LLMisms. I didn't expect them to disappear, but it's not a radical improvement either.
Of course it was exposed - not sure it's explicit or not. Why wouldn't HackerNews comments be part of the training data? And Simon's blog and the many discussions about Pelicans? It'd be hard to miss. Doesn't mean Anthropic has made this an explicit goal in training.
A demo video would be useful, so one can see what it does without having to run oneself.
Which is presumably why Debian developers voted to allow responsible use of LLMs.
Also had a bunch of typos so wasn't even LLM proof read (at least not final form).
I'm not sure I get what you mean.
There are commercial thermostats where the wax element itself is both the temperature sensor and the actuator, eg Thera-100 T1002W0.
Thanks, makes sense! No need to be sorry!