maltalex

> They would recover the training cost eventually if they stop training

"if they stop training" is exactly the point I'm making. They can't stop training if the competition is still training.

It's hard to say anything about the actual financials with the main players being private companies.

However, we know that users frequently switch models/providers, and that models stay relevant for (increasingly) short periods release. I don't know what the training costs are, but I bet they're very substantial.

These companies have a coordination problem.

They're all burning billions to incrementally one-up each other with no hope of these investments ever paying off since models are interchangeable and have no moat. They're trying to get regulators to step in and force a pause.

Any automation-friendly email hosting is going to have a serious spam problem, and therefore a blacklisting problem.

I suggest taking a look at what providers like Sendgrid, Mailchimp, etc are doing to prevent abuse.

An alternative explanation for this “over-hiring” is that many companies’ operating expenses have grown substantially because of AI spending. Companies can either eat the additional expense, hope AI adoption offsets it, or cut costs.

For most software companies, operating expenses are mostly wages. So, cutting costs means reducing headcount, which is likely especially true in lower-wage regions. If an engineer costs $4K/month, adding $1K/month in token costs increases employment cost by 25%. If an engineer costs $2K/month, the same $1K raises costs by only 5%.

So, I'd argue that everyone should be worried at least to some degree until the industry finds a new equilibrium.

> 1. human verification for auth.

How, at scale?

Wouldn't a "WebRip" have to come from a streaming service by definition?

Only with certificate pinning or something similar. Otherwise, the attacker can get valid TLS certificates for any domain hosted on the hijacked IP addresses.

Here are some examples:

The attacker can impersonate the victim, get a valid x509 certificate issued to it, and create a perfect replica of their website/api/whatever.

The attacker can perform a man-in-the-middle attack on the victim - record traffic, inject traffic, manipulate traffic, etc.

The attacker can just deny access to the victim - just drop packets meant for the victim.

RPKI doesn't make BGP safe, it makes it safer. BGP hijacks can still happen.

RPKI only secures the ownership information of a given prefix, not the path to that prefix. Under RPKI, an attacker can still claim to be on the path to a victim AS, and get the victim's traffic sent to it.

The solution to this was supposed to be BGPSec, but it's widely seen as un-deployable.