The title of the article is "How long until AI automates all cognitive labor?"

The main point of the article is summarized by its intro: "Recently, though, I noticed that many great researchers have now published two or more precise forecasts, all using similar definitions of AGI, and all providing confidence intervals. So I was able to visualize how their forecasts changed over time."

The closest the article comes to saying the HN submitted title is:

> And every single person who updated their timelines from January 2026 to April 2026 has moved their timeline to say AGI is coming sooner, myself included.

> So I think the data supports the impression I got from Daniel, Eli, and the AI Futures team. One way I could characterize it is: in the ChatGPT era, people updated towards AI coming sooner. Then in the xAI, Meta, and Gemini era, people updated towards it coming later. Then in the Anthropic era, people updated towards AI coming sooner. Take from that what you will.

That seems like an especially wild guess. If you take e.g. Opus 4.7 prices, and make the assumption that you are consuming roughly $30 for every million tokens of output (this comes from just summing the $25 per million tokens of output and $5 per million tokens of input and assuming that caching basically makes all that work out), and assume an output rate of 80 tokens per second (which seems like a high estimate based on online searching), it would take you about 2411 days of non-stop Opus 4.7 usage to hit 500k in API spend.

The only way you could possibly run that amount of usage in 6 days is if you were running ~400 instances in parallel. From personal experience, that seems crazy high for this project.

I think you are off by at least an order of magnitude (potentially even 2 depending on how the person is managing agents, but I could see something like dozens of agents 24/7, so I'm way less confident in 2, but I think it's still more likely to be closer to 10-20k in API spend).

What do you mean by "apparently well evidenced view?" No I'm not saying "someone taught it at university." That's a public high school exam. That is specifically secondary schooling.

Moreover, this gets mentioned in official publications and popular media frequently. See for example this official article from the Chinese Academy of Social Sciences (which is a state-run entity), which just happened to be the first article that caught my eye.

> 1935年12月，蔡元培、鲁迅、郭沫若、叶圣陶、茅盾、陈望道、陶行知等688位知名人士，共同发表文章《我们对于推行新文字的意见》，其中说：“中国已经到了生死关头，我们必须教育大众，组织起来解决困难。但这教育大众的工作，开始就遇着一个绝大难关。这个难关就是方块汉字。方块汉字难认、难识、难学。……我们觉得这种新文字值得向全国介绍。我们深望大家一齐来研究它，推行它，使它成为推进大众文化和民族解放运动的重要工具。” (http://ling.cass.cn/keyan/xueshuchengguo/cgtj/202112/t202112...)

And my very rough translation.

> In December of 1935, 688 well-known individuals including Cai Yuanpei, Lu Xun, Guo Moruo, Ye Shengtao, Mao Dun, Chen Wangdao, and Tao Xingzhi, published "Our views on spreading Sin Wenz [Latinxua Sin Wenz, i.e. a Latin alphabetization of Chinese]." It stated in part, "China has already arrived at the point of life or death, we must educate the masses and organize [them] to solve difficulties. But the work of educating the masses, at its very beginning already runs into an enormous problem. That problem is Chinese square characters [Chinese characters usually are roughly proportioned as if they were in a square frame]. Chinese square characters are difficult to recognize, difficult to understand, and difficult to learn.... We believe that Sin Wenz deserves to be introduced to the entire nation. We deeply hope that everyone will study them, spread them and put them into practice, and make them into an important tool for improving the culture of the masses and the movement to liberate the people."

More broadly this is a very common topic among Chinese netizens. There are as I linked dozens of forum posts on this across Zhihu, Baidu, etc.

It's not the first thing people learn about Lu Xun. But it's definitely not hidden.

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

All this is to say, even for very compute cheap things, companies shut down "mostly passive income" revenue streams all the time (see e.g. Google's graveyard of products). There are all sorts of other organizational costs associated with ongoing maintenance of a product.

Anyways, the calculation for the costs seem crazy high (and are pulled from an ft article). In particular they are based off a calculation that assumes Sora videos take 10 min to generate (which seems simply wrong; I've personally generated Sora videos that take less than 10 min to return fully formed), fully saturate 4 H200s at once (this seems wrong with batching; I would assume they're batching a lot of tokens together per forward pass), and, crucially, that OpenAI is paying full spot, end-user pricing for an H200 (at $2 an hour). As an individual, I can rent an H200 for $2 an hour on e.g. vast.ai (and sometimes even cheaper than that!). There is absolutely no way OpenAI is spending anywhere near that number.

I also have no idea where the Appfigures $2.1 million comes from. As far as I can tell it doesn't exist at all in the linked website.

I don't really trust the numbers here.

>> The post is factoring in training costs, not just inference.

It is not because training costs are irrelevant here. Training costs do not cause your costs to go up as you accumulate more users.

None of these calculations we're talking about include training costs. You're saying that inference is unprofitable (at least given the subscription plans). I'm simply pointing out that we are talking about inference not training as you stated earlier. You are (very accurately) not talking at all about training costs.

> in fact, they actually compound the problem by encouraging significantly more usage

because if eliminating training costs makes running the model above cost, the problem is helped by significantly more usage not compounded.

More usage compounds the problem only if inference is unprofitable.

(the article briefly mentions training but that's later).

Again, let's say the system prompt is "deploy X" and the user prompt provides falsified evidence that one should not deploy X because that will cause a production outage. That technically overrides the system prompt. And you can arbitrarily sophisticated in the evidence you falsify.

But you probably want the system prompt to be overridden if it would truly cause a production outage. That's common sense a general AI system is supposed to possess. And now you're testing the system's ability to distinguish whether evidence is falsified. A very hard problem against a sufficiently determined attacker!

> The hypothetical approach I've heard of is to have two context windows, one trusted and one untrusted (usually phrased as separating the system prompt and the user prompt).

I want to point out that this is not really an LLM problem. This is an extremely difficult problem for any system you aspire to be able to emulate general intelligence and is more or less equivalent to solving AI alignment itself. As stated, it's kind of like saying "well the approach to solve world hunger is to set up systems so that no individual ever ends up without enough to eat." It is not really easier to have a 100% fool-proof trusted and untrusted stream than it is to completely solve the fundamental problems of useful general intelligence.

It is ridiculously difficult to write a set of watertight instructions to an intelligent system that is also actually worth instructing an intelligent system rather than just e.g. programming it yourself.

This is the monkey paw problem. Any sufficiently valuable wish can either be horribly misinterpreted or requires a fiendish amount of effort and thought to state.

A sufficiently intelligent system should be able to understand when the prompt it's been given is wrong and/or should not be followed to its literal letter. If it follows everything to the literal letter that's just a programming language and has all the same pros and cons and in particular can't actually be generally intelligent.

In other words, an important quality of a system that aspires to be generally intelligent is the ability to clarify its understanding of its instructions and be able to understand when its instructions are wrong.

But that means there can be no truly untrusted stream of information, because the outside world is an important component of understanding how to contextualize and clarify instructions and identify the validity of instructions. So any stream of information necessarily must be able to impact the system's understanding and therefore adherence to its original set of instructions.

Is the number of suppliers low because demand is also low or is the number of suppliers low because demand is high but supply is constrained?

A field that previously had a supply of labor in it "for the money" who all leave is indicative of the former scenario not the latter.

That does not lead to higher wages. That leads to low wages.

(There are a variety of reasons why this story is too simple and why I remain uncertain about developer salaries in the short term)

There is a broader question of whether having people who are in it for the money leave independently "causes" wages to go down (e.g. if you were to replace all such people with people "purely in it for the passion"). My suspicion is yes. Mainly because wage markets are somewhat inefficient, there are always mild cartel-like/cooperative effects in any market, people in it for passion tend to undersell labor and the people in it for the money are much less likely to undersell their labor and this spills over beneficially to the former.

Note that this broader question is simply unanswerable assuming perfect competition, i.e. a supply-demand 101 perspective (which is why it doesn't make sense to posit "perfect competition" for this question).

It posits durable behavioral differences among suppliers that are not determined purely by supply and demand which do not update reliably in the face of pricing. This is equivalent to market friction and hence fundamentally contradicts an assumption of perfect competition.

No. Floating number arithmetic is deterministic. You don't get different answers for the same operations on the same machine just because of limited precision. There are reasons why it can be difficult to make sure that floating point operations agree across machines, but that is more of a (very annoying and difficult to make consistent) configuration thing than determinism.

(In general it is mildly frustrating to me to see software developers treat floating point as some sort of magic and ascribe all sorts of non-deterministic qualities to it. Yes floating point configuration for consistent results across machines can be absurdly annoying and nigh-impossible if you use transcendental functions and different binaries. No this does not mean if your program is giving different results for the same input on the same machine that this is a floating point issue).

In theory parallel execution combined with non-associativity can cause LLM inference to be non-deterministic. In practice that is not the case. LLM forward passes rarely use non-deterministic kernels (and these are usually explicitly marked as such e.g. in PyTorch).

You may be thinking of non-determinism caused by batching where different batch sizes can cause variations in output. This is not strictly speaking non-determinism from the perspective of the LLM, but is effectively non-determinism from the perspective of the end user, because generally the end user has no control over how a request is slotted into a batch.

On the other hand if you "raise your bar" (let's say you do so by some method that makes it twice as expensive to judge a candidate; twice as likely to reject a candidate that would fit what you need, i.e. doubles your false negative rate; but cuts down on the number of applications by 10x, so that now 1 out of 100 candidates are what you need, which isn't that far off the mark for certain kinds of things), you cut down the effort (and time) you need to spend on finding a candidate by over double.

EDIT: On reflection I think we're mainly talking past each other. You are thinking of a scenario where all stages take roughly the same amount of effort/time, whereas tmorel and I are thinking of a scenario where different stages take different amounts of effort/time. If you "raise the bar" on the stages that take less amount of effort/time (assuming that those stages still have some amount of selection usefulness) then you will reduce the overall amount of time/energy spent on hiring someone that meets your final bar.