dlenski

Logically, gambling is like going to the movies. You expect to pay x currency for y value of entertainment.

I don't think gambling is at all like paying a set price for a ticket and having a pretty good idea of how long the entertainment will last. If "gambling" means making a series of short-term bets for entertainment value, you don't have any clear idea how long you'll be entertained for or how much it will cost.

People will show up at a casino with let's say, $200 and a debit card, and expect that they'll be able to spend $50, be entertained for 2 hours, and then just leave… while secretly hoping that they'll actually leave with more than they came with.

Then they burn through their $50 in half an hour, and dip into their remaining stash in order to keep playing. OR they triple their money in half an hour and feel such a rush that they want to keep playing with more money. Then, repeat repeat repeat.

They're giving everyone their next hit.

Yes, 100%. The author seems to be describing, quite lucidly, how he is getting sucked into a gambling-like addiction to these LLMs… although he seems unaware of the implications of that.

https://news.ycombinator.com/item?id=48961596

Gambling addition implies dopamine hits from irregular and uncertain outcomes

Your post literally describes your fascination with trying to figure out the pattern of a "random" reward that you get, and trying to maximize the value you get out of it.

I put "random" in scare quotes because I strongly believe that—just as slot machine payouts are carefully structured to keep you playing—these LLM resets are structured to keep heavy users like you coming back to max out their usage, and to progressively upgrade it.

Several other commenters have also stated this same suspicion about the pattern of resets you're describing.

"Not wanting to waste money" is the polar opposite of gambling.

From everything I've read about gambling addiction, particularly Jay Caspian Kang, that seems wrong.

The desire to "not waste money" and "get back to even" seems like a huge part of what motivates gamblers to keep gambling.

it's just insanely irritating to work with a tool that 1) limits its' own use 2) with a random interval.

Do you understand how the psychological response to the "random" disappearance of an annoyance is pretty much exactly the same as the psychological response to the "random" appearance of a reward?

I put "random" in square quotes because neither are in fact totally random, but both are clearly quite carefully engineered to provoke the desired response.

you're projecting

I am not projecting. My total lifetime gambling consists of maybe 10 or 15 cash poker games with high school friends, ten minutes at a casino in Montréal which I found a revolting experience, and receiving a few $1 scratch lottery tickets as party favors.

This article reads like a description of gambling-addiction behavior; the author appears to be addicted to using LLMs.

He's eagerly awaiting his next hit of dopamine from his favorite model. He's setting timers to be ready for when his next hit comes available. He's spinning up unnecessary queries just to start the timer ticking on new models.

You could basically write the same article about some guy who sits in a casino all day eagerly awaiting double-your-winnings bonuses or similar.

Hmm. I'm curious about which org that was.

I spent the slight majority of my time at AWS in RDS.

Even ignoring the political aspects, like the fact that EFF/ACLU don't want to be in this business (as you note)…

This system will likely fail in the same way that almost every new DRM system has failed: someone will implement the "secure element" badly and its keys or secrets will get exfiltrated and cloned.

It's one thing to keep a cryptosystem secure when its users appreciate that system (e.g. hard disk encryption or TOTP 2FA)… but it's very hard to keep cryptosystems secure when millions or billions of people are unwilling and resentful users having those systems imposed on them.

Which ones?

Services emit metering values that arent directly tied to prices.

Yep. The metering ("Kona") is separated from the billing to such degree that it's basically impossible to find anyone at the company who understands both.

I remember having to work on some metering code, and trying to figure out whether it would result in correct billing that matched our service's documentation. I was basically told off by a more senior engineer for wasting my time on something that was completely tangential and outside of the "engineering" domain entirely.

COEs are such a huge annoyance for teams that they create a strong incentive to be proactive in preventing issues like this from happening.

Absolutely not my experience at AWS.

All the teams I was on treated them as "not a big deal", kind of a non-punitive exercise in technical writing, and the COE was always assigned to be written by an engineer who was not involved in causing the COE.

Also, the kinds of issues that did or didn't lead to COEs appeared to be largely random. I was considered to be an extremely good operational trouble-shooter on the team where I spent most of my time at AWS, and I was never able to predict what an L7-8 manager would decide was COE-worthy.

This was very much my experience, having worked in two different sub-organizations at AWS, and on several different services, in two different countries.

There's just extreme variation in the quality of the management, the quality of the engineers, the operational/development role split, the on-call schedule, and the development and testing methodology.

> If Anubis were to be even more widely adopted, botnet operators would surely adopt and optimize native code solvers en masse.

Then anubis adopts it itself, increases the amount of work that needs to be done and the bar stays the same again for everyone?

No, the bar doesn't "stay the same" for everyone interacting with Anubis.

My otherwise-perfectly-usable 8-year-old phone, which can't be patched to run a native solver, becomes even more unusable on sites gates with proof-of-work challenges like Anubis.

This is the whole problem with PoW. It forces thousands or millions or billions of client devices to do increasing amounts of useless work which is relatively easy for cloud-based attackers to adapt to, but very difficult for hardware-constrained and software-ossified mobile clients to adapt to.

In other words, it asymmetrically punishes the clients that it's not intending to punish.

Right, and as I understand it the timing also lines up: these ill-behaved scraper-bot-nets exploded along with GenAI in the last 3-4 years.

Still, it seems to me like something doesn't add up. Running these botnets is perhaps cheap but it isn't free, and dumping all their data into LLM training is truly expensive: would so many of these bots be so blitheringly inefficient in their scraping patterns if all of the results were getting fed into LLM training?

Have there been no leaks or whistleblowers from the "semi-legit" RP brokers?

Anubis appears to be a temporarily-useful stopgap that has been cargo culted into prominence and an expectation of permanent usefulness, for reasons I don't fully understand.

The cost of solving the default Anubis PoW is negligible on cloud servers, and it's even lower if you use native code rather than JavaScript to solve it, which Tavis Ormandy helpfully demonstrated last year (https://lock.cmpxchg8b.com/anubis.html). If Anubis were to be even more widely adopted, botnet operators would surely adopt and optimize native code solvers en masse.

So Anubis doesn't do much to stop bots, but it makes otherwise lightweight websites (little JavaScript or interactivity) almost unusable on low-resource systems like my old phone or an old Atom-based nettop.

when tokens are bound to the connecting ip, scrapers must limit the connecting IP pool for each site they want to scrape

This "IP-bound proof-of-work" thing is gonna kill multipath TCP and bring down IPv6 with it. Uffff.

As this article points out, it's tremendously unclear who is using residential proxies.

The big AI models claim they're not using them. I'm not inclined to "just believe them", but no incriminating evidence has leaked, and—as pointed out in the article—many of the bots that are running on these residential proxy botnets are coded in incredibly stupid and inefficient ways.

How confident are people who research this stuff that the RP botnets are actually being used for AI training?

To add to the other comments…

At a very abstract level, when you're manufacturing DRAM you need to manufacture a lot of circuit elements that have HIGH capacitance, since a DRAM cell is basically a capacitor and the higher its capacitance the less frequently it needs to be refreshed.

On the other hand, when manufacturing logic (CPU/GPU/ASIC) you want to minimize the capacitance of almost all circuit elements, since capacitance introduces delay and switching energy cost.

Nearly everything about the manufacturing processes for DRAM and logic is optimized around this fundamentally incompatible figure of merit.

I worked on the development of Intel's eDRAM process, which was used to integrate DRAM into the CPU/GPU die for Iris Pro embedded graphics from 2013-23. https://ieeexplore.ieee.org/document/6576667/

My suspicion as well. I don't see any crystal clear evidence for it, but I'm sure looking for it.

Thanks. (4) is the critical piece here.

I work at ngrok, and this is not how our freemium plan works. Free plans limit based on usage alone, not on machine IDs.

Thank you! This is not only good to know as an ngrok user myself, but it's also more informative than what's in the article.

Sounds like we can rule that out as the avenue of detection.

And then what?

Does the Microsoft store imprint an identifier into the network traffic of all the binaries downloaded from it?

And if so, how?

All of ngrok's traffic is TLS encrypted which means that only the client software and the server/peer should be able to decrypt or modify it.

And what I'm saying is that it's probably unlikely that this "one" exists.

Yeah, this is what's glaringly missing from the article.

Exactly how does Microsoft's device identifier get associated with the ngrok session (normally initiated via its closed-source CLI)?

I can't tell from the article whether Microsoft is doing something underhanded to inject its device identifiers into network traffic, or whether the ngrok client software (again, closed-source!) grabbed the device identifier… and might well do the same on any other OS, using /etc/machine-id on Linux for example.

Since ngrok uses a "freemium" model, it wouldn't surprise me at all if its clients send machine IDs to try to catch users trying to get around its free limits.

Interesting read. Canada would be even more US-skewed.

Canada is lacking in large domestic cloud providers and Canadian companies often use the default US regions of public clouds (e.g. AWS us-east-1) rather than Canada regions (e.g. ca-central-1).

There are not too many mentally-sharp, fully-employed, terminally-ill people that I have met. Even fewer at tech companies.

And even fewer who are single and childless. (Google would likely go after the estate of anyone who did this.)

I didn't see the word "try" in the headline, did you?

I read about 60% of it and skimmed the rest and my conclusion is:

Man, I just. don't. care.

Why should I worry about this hypothetical future dystopia, which seems to me incredibly unlikely to come to pass, rather than the glaring and terrifying current dystopia being enacted by Donald Trump in the USA?

I have been a major LLM skeptic and "late adopter." I had never actually used LLMs for anything at all (either in work or personal life) until about two months ago, although I had followed their development with interest and skepticism.

A couple months ago, I started using Claude for some tasks related to processing really messy data. Our company was making a big push for its use, and a co-worker gave me a fairly impressive demo of what he was able to do with this data in an hour or two.

Our company's Claude subscription defaulted to Opus 4.7 and we were encouraged to use it as much as we could.

I don't think I ever did more than 10 or 15 prompts in a day; I tend to do very detailed prompts and then spend 10-30 minutes playing around with the results and resulting code.

Today we get this:

TL; DR: We're nearly at NNN Claude users and growing fast. Three quick asks: (1) default to Sonnet for everyday work; we have launched XXXXXXX to help with clarity, …

…

As we scale, let's be smart about how we work. Claude offers several models, and for everyday work — … — Sonnet is your go-to.

Quite honestly, this is the most interesting and useful thing that I have ever read, directly responsive to the question of "how good are LLMS at doing difficult tasks, in terms of both bang-for-the-buck and in terms of raw performance?"

My hat's off to swelljoe.

This part was especially interesting:

The cheap Chinese models kick ass. MiMo and DeepSeek are directly competitive with Opus 4.8 and GPT 5.5 at roughly an order of magnitude lower price. There have been accusations of “benchmaxxing” with the Chinese models, but I don’t think there’s any reasonable way for the models to already be tuned for these very recently disclosed bugs. I think they’re genuinely becoming competitive with the frontier from Anthropic and OpenAI. If you’re in a hurry, DeepSeek was the fastest, on average, while finding 4/9 bugs. And, if you’re cheap, MiMo found bugs as well as any model for the lowest price.

Got it, thanks. I believe that the version I have might be a later printing of the 1978 version, but actually the book I'm remembering most clearly was a later 1986 book by Ahl with a similar title of "Basic Computer Adventures" which has 10 longer adventure games… including an early version of Oregon trail.

https://archive.org/details/basic_computer_adventures

My copy is at my parents’ house so I can't check the exact date now, but it's from the mid-to-late '80s and targets 8-bit home computer BASIC (e.g. Commodore 64) and IBM/Microsoft BASIC.

So I presume there were several revisions or additions.